chore: eliminate analyzer and iOS build warnings#9
Conversation
Dart/analyzer cleanups (example app): - use super parameters for widget keys (use_super_parameters) - replace deprecated Color.withOpacity with withValues(alpha:) - drop dead fields/methods in main.dart (_isTesting, _myAddress, _preInitializeLib) and remove a redundant null-aware on non-null keys - // ignore_for_file: avoid_print on the integration-test harness (stdout logging is intentional there) iOS build (example/ios): - Podfile post_install: suppress third-party pod warnings, disable the module verifier (old Google/Flutter headers fail isolated module compilation), and re-stamp the generated Pods project's LastUpgradeCheck so Xcode stops showing "Update to recommended settings" each pod install - regenerated Podfile.lock Clean iOS build succeeds (flutter build ios --no-codesign, 0 errors); residual warnings are all upstream third-party header/storyboard notes we don't own. Runner project LastUpgradeCheck is left to Flutter's tooling, which manages it on every build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis PR modernizes the Cardano Flutter SDK example app across multiple dimensions: widget constructors adopt Dart's ChangesExample App Modernization
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@example/ios/Podfile`:
- Around line 58-69: The post_install loop is unconditionally applying
warning/module-verifier suppressions to all generated targets
(installer.generated_projects.each → project.targets and
config.build_settings[...] keys), which also affects the local first-party pod
(cardano_flutter_rs referenced via :path); update the loop to only apply these
settings for third-party pods by skipping pod targets that originate from a
local :path spec or by white-listing known problematic pods. Concretely, inside
the post_install block locate the installer.generated_projects.each /
project.targets iteration and: map each Xcode target back to its Pod::PodTarget
(installer.pod_targets), detect pod_target.specification.source.key?(:path) (or
compare pod_target.name to "cardano_flutter_rs"), and only set
GCC_WARN_INHIBIT_ALL_WARNINGS, SWIFT_SUPPRESS_WARNINGS, ENABLE_MODULE_VERIFIER,
and CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER when the pod is not a
local/:path pod (or when it matches a configured third-party list).
- Around line 40-42: The Podfile currently calls
flutter_additional_ios_build_settings only for installer.pods_project.targets
while the warning/deployment overrides iterate installer.generated_projects,
which can miss targets; change the Podfile so
flutter_additional_ios_build_settings is also applied to the same target set
used by the overrides (i.e., iterate installer.generated_projects and call
flutter_additional_ios_build_settings(target) for each relevant target). Also
narrow the suppression loop that modifies build settings to skip local-path
plugin pods by filtering generated targets (e.g., exclude targets whose
pods/project path or name indicates .symlinks/plugins or local path plugins) so
the suppression only applies to external third‑party pods.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a167e80c-8ecc-4617-9bf4-578c7f3533e2
⛔ Files ignored due to path filters (1)
example/ios/Podfile.lockis excluded by!**/*.lock
📒 Files selected for processing (8)
example/integration_test/send_flow_test.dartexample/ios/Podfileexample/lib/accounts_screen.dartexample/lib/cip30_screen.dartexample/lib/main.dartexample/lib/message_screen.dartexample/lib/send_screen.dartexample/lib/stake_screen.dart
| installer.pods_project.targets.each do |target| | ||
| flutter_additional_ios_build_settings(target) | ||
| end |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show Podfile (around the relevant lines)
if [ -f example/ios/Podfile ]; then
echo "---- example/ios/Podfile: head/tail with line numbers ----"
nl -ba example/ios/Podfile | sed -n '1,130p'
else
echo "Podfile not found at example/ios/Podfile"
fi
# Search for the helper usage in the repo
echo "---- usages of flutter_additional_ios_build_settings ----"
rg -n "flutter_additional_ios_build_settings" -S . || true
# Search for generated_projects / pods_project usage in Podfile(s)
echo "---- usage of installer.generated_projects / installer.pods_project ----"
rg -n "installer\.(generated_projects|pods_project)" -S example/ios/Podfile . || trueRepository: pawsitivegames/cardano-flutter-sdk
Length of output: 198
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "---- repo root listing (top level) ----"
ls -la
echo "---- find Podfile candidates ----"
fd -a -t f "Podfile" . || true
echo "---- if example/ios/Podfile exists, print it with line numbers via awk ----"
if [ -f example/ios/Podfile ]; then
awk '{print NR "\t" $0}' example/ios/Podfile | sed -n '1,160p'
else
echo "example/ios/Podfile not found"
fi
echo "---- usages of flutter_additional_ios_build_settings ----"
rg -n "flutter_additional_ios_build_settings" -S . || true
echo "---- usage of installer.generated_projects / installer.pods_project ----"
rg -n "installer\.(generated_projects|pods_project)" -S example/ios/Podfile example/ios/*.rb . || trueRepository: pawsitivegames/cardano-flutter-sdk
Length of output: 5918
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "---- Search repo for podhelper.rb ----"
fd -a -t f "podhelper.rb" . || true
echo "---- Search repo for flutter_tools/bin/podhelper ----"
rg -n "packages/flutter_tools/bin/podhelper" -S . || true
echo "---- Search repo for definition of flutter_additional_ios_build_settings ----"
rg -n "def flutter_additional_ios_build_settings" -S . || trueRepository: pawsitivegames/cardano-flutter-sdk
Length of output: 249
🌐 Web query:
flutter_additional_ios_build_settings podhelper.rb
💡 Result:
flutter_additional_ios_build_settings is a Ruby method defined in the Flutter SDK's podhelper.rb script, designed to be called within the post_install hook of an iOS project's Podfile [1][2][3]. It automatically applies essential build settings to CocoaPods targets in a Flutter project [1][4]. Role and Functionality: The primary purpose of this method is to ensure that Flutter plugins and the main application target are configured correctly for the Xcode build system [4][5]. By invoking this method, Flutter ensures several critical build-time requirements are met [4]: - Artifact Alignment: It ensures that plugins link against the correct versions of the Flutter.framework artifacts (e.g., matching debug/release, simulator/device configurations) [3][4]. - Architecture Management: It dynamically manages build settings such as EXCLUDED_ARCHS to prevent common build errors, such as attempting to build unsupported 32-bit architectures or resolving simulator architecture conflicts (e.g., handling arm64 vs. x86_64 simulator builds) [3][4]. - Build Compatibility: It applies necessary flags and configurations to maintain compatibility with different Xcode versions and iOS deployment targets [3][4]. Usage in Podfile: To use it, you include the call within the post_install block of your ios/Podfile to iterate over all pods and apply these configurations [1][6]: post_install do |installer| installer.pods_project.targets.each do |target| flutter_additional_ios_build_settings(target) end end This method is standard in Flutter's default iOS project templates [7]. Removing it can lead to build failures, particularly when using plugins that rely on specific Flutter framework linking or that have complex architecture requirements [6][8]. While you can add your own custom build configurations after calling this method, it is highly recommended to keep it present to maintain the integrity of the Flutter build environment [6][8].
Citations:
- 1: https://github.com/flutter/flutter/blob/master/packages/flutter_tools/bin/podhelper.rb
- 2: https://github.com/flutter/flutter/blob/c3d0f60407f4fe556a73f9bef495aac352d4595b/packages/flutter_tools/bin/podhelper.rb
- 3: https://chromium.googlesource.com/external/github.com/flutter/flutter/%2B/refs/heads/flutter-2.5-candidate.3/packages/flutter_tools/bin/podhelper.rb
- 4: Exclude armv7 from iOS add-to-app plugins flutter/flutter#101943
- 5: https://deepwiki.com/flutter/flutter/7.2-ios-and-macos-build-system-(xcode)
- 6: getting this issue after updating from xcode 16 to xcode 15 flutter/flutter#156465
- 7: Add extra Flutter settings to ios_app_with_extensions Podfile flutter/flutter#70719
- 8: https://stackoverflow.com/questions/71662760/flutter-2-10-3-ios-pod-file-differentiate
🌐 Web query:
CocoaPods installer.generated_projects pods_project.targets difference
💡 Result:
In CocoaPods, the primary difference between installer.pods_project and installer.generated_projects is their scope and reliability, especially when using advanced configuration options like:generate_multiple_pod_projects or:incremental_installation [1][2][3]. installer.pods_project This refers specifically to the main Pods.xcodeproj file [3]. Historically, this was the primary interface for post-install hooks to modify build settings across all pods [3]. However, it is not always available; if CocoaPods determines that no changes are needed during an incremental installation, this property may be nil [1]. installer.generated_projects This returns an array of all Xcode projects generated during the installation process [2][4][5]. When:generate_multiple_pod_projects is enabled, CocoaPods creates a main container project (Pods.xcodeproj) and separate projects for individual pods [6]. In this scenario, iterating over installer.generated_projects is necessary to ensure that post-install modifications are applied to every relevant target across all generated projects, rather than just the main container project [2][3]. Key Takeaways for Post-Install Hooks: - Use installer.generated_projects for better compatibility: It is safer and more robust because it handles both single-project and multi-project configurations automatically [2][3]. - Avoid direct reliance on pods_project: Relying solely on the main Pods.xcodeproj can lead to missed targets or errors when incremental installation is active or when multiple projects are generated [1][3]. - Clean Installs: If you change your post-install hook logic, especially with incremental installation enabled, run pod install --clean-install to ensure all projects are correctly regenerated and the new hooks are applied to all targets [2][3].
Citations:
- 1: Could not access pods_project on post_install hooks when incremental_installation is enabled CocoaPods/CocoaPods#8604
- 2: Converting post_install hooks once generate_multiple_pod_projects is set to true CocoaPods/CocoaPods#8739
- 3: Use 'generate_multiple_pod_projects' project error CocoaPods/CocoaPods#8967
- 4: https://rubydoc.info/github/cocoapods/cocoapods/Pod/Installer
- 5: https://www.rubydoc.info/gems/cocoapods/Pod%2FInstaller:generated_projects
- 6: https://rubydoc.info/gems/cocoapods/Pod/Installer/Xcode/MultiPodsProjectGenerator
🌐 Web query:
CocoaPods 1.16 installer.generated_projects sub-project pod library targets
💡 Result:
In CocoaPods 1.16, installer.generated_projects is a method that returns an array of all Xcode projects generated during the installation process [1][2][3]. This is particularly relevant when using the generate_multiple_pod_projects installation option, which splits the standard Pods.xcodeproj into individual projects for each pod library target [4][5]. When generate_multiple_pod_projects is enabled, relying solely on installer.pods_project—which typically only references the main Pods.xcodeproj—is insufficient for accessing all pod targets [6]. Instead, you should iterate over installer.generated_projects to ensure your post-install hooks are applied to every generated sub-project [7][6]. Example usage in a Podfile: post_install do |installer| installer.generated_projects.each do |project| project.targets.each do |target| # Apply your configuration changes here target.build_configurations.each do |config| config.build_settings['SOME_SETTING'] = 'VALUE' end end end end It is also important to note that when using incremental_installation, not all projects may be regenerated during every pod install [8]. If your post-install hooks are not executing as expected, or if you need to ensure all projects are processed, you should run pod install --clean-install [7][6]. Additionally, recent updates to CocoaPods have improved the inclusion of subprojects in the plugin post-install hook context, making it more reliable to manage these targets [4][5].
Citations:
- 1: https://www.rubydoc.info/gems/cocoapods/1.16.1/Pod%2FInstaller:generated_projects
- 2: https://rubydoc.info/gems/cocoapods/Pod/Installer
- 3: https://www.rubydoc.info/gems/cocoapods/Pod%2FInstaller:generated_projects
- 4: https://raw.githubusercontent.com/CocoaPods/CocoaPods/master/CHANGELOG.md
- 5: https://github.com/CocoaPods/CocoaPods/blob/d18f49392c5e9ed9a2cdcb2ee89391cf7690ee5d/CHANGELOG.md
- 6: Use 'generate_multiple_pod_projects' project error CocoaPods/CocoaPods#8967
- 7: Converting post_install hooks once generate_multiple_pod_projects is set to true CocoaPods/CocoaPods#8739
- 8: Could not access pods_project on post_install hooks when incremental_installation is enabled CocoaPods/CocoaPods#8604
🌐 Web query:
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/bin/podhelper.rb flutter_additional_ios_build_settings definition
💡 Result:
The flutter_additional_ios_build_settings method is a Ruby function defined within the Flutter SDK's podhelper.rb script, located in packages/flutter_tools/bin/podhelper.rb [1][2]. It is designed to be called within the post_install hook of an iOS project's Podfile [1][3]. Its primary purpose is to apply essential Flutter-specific build configurations to CocoaPods targets [1][2][3]. When invoked, it performs the following operations: 1. Target Validation: It checks if the target is an iOS platform and confirms it is a Flutter-related dependency (e.g., links against the Flutter framework) [2]. 2. Deployment Target Handling: It manages deployment target versions, often ensuring compatibility with Flutter's requirements [2]. 3. Framework Search Paths: It dynamically updates FRAMEWORK_SEARCH_PATHS for both simulator and device builds to ensure the correct engine binaries are used based on the build configuration (debug vs. release/profile) [2]. 4. Build Settings Enforcement: It enforces specific build settings (such as linking against the Flutter framework and adjusting warning levels) necessary for Flutter's build process to function correctly across different Xcode configurations [2][3]. Developers commonly use it in their Podfile as follows [3][4]: post_install do |installer| installer.pods_project.targets.each do |target| flutter_additional_ios_build_settings(target) end end This method abstracts complex build logic, reducing the need for developers to manually configure build settings for Flutter plugins in their iOS projects [3].
Citations:
- 1: https://github.com/flutter/flutter/blob/master/packages/flutter_tools/bin/podhelper.rb
- 2: https://chromium.googlesource.com/external/github.com/flutter/flutter/%2B/refs/heads/flutter-2.5-candidate.3/packages/flutter_tools/bin/podhelper.rb
- 3: Move logic from user project's Podfile to a Ruby script in Flutter tools flutter/flutter#45197
- 4: https://github.com/januscaler/flutter_janus_client/wiki/Take-away-Apple-IOS-and-macOS-related-pain-from-me-%F0%9F%92%AF-(building-for-apple)
🌐 Web query:
flutter_additional_ios_build_settings target.build_settings EXCLUDED_ARCHS SWIFT_SUPPRESS_WARNINGS GCC_WARN_INHIBIT_ALL_WARNINGS
💡 Result:
The flutter_additional_ios_build_settings function is a utility provided by the Flutter framework, defined in the podhelper.rb script [1][2]. Its primary purpose is to apply essential build settings to CocoaPods targets in a Flutter project, ensuring compatibility between the Flutter engine and your app's dependencies [1][3][4]. Key Aspects: - Purpose: It configures necessary build settings (such as FRAMEWORK_SEARCH_PATHS) to ensure CocoaPods targets can correctly locate and link against the Flutter engine's binaries [1]. - Usage: It is designed to be called within the post_install hook of your ios/Podfile [2][4]. post_install do |installer| installer.pods_project.targets.each do |target| flutter_additional_ios_build_settings(target) end end Regarding the specific build settings mentioned: 1. EXCLUDED_ARCHS: Flutter manages this setting automatically to handle architecture compatibility [5][6]. For example, Flutter monitors dependencies for exclusions (like arm64) and may force matching exclusions in your project to prevent build failures on simulators [5][6]. You generally do not need to manually manage this via this function [5]. 2. SWIFT_SUPPRESS_WARNINGS and GCC_WARN_INHIBIT_ALL_WARNINGS: These are standard Xcode build settings used to suppress compiler warnings [7]. They are not managed by flutter_additional_ios_build_settings [1]. If you need to suppress warnings from your dependencies, you can manually set these in the same post_install loop where you call the Flutter helper [8][7]. post_install do |installer| installer.pods_project.targets.each do |target| flutter_additional_ios_build_settings(target) target.build_configurations.each do |config| config.build_settings['GCC_WARN_INHIBIT_ALL_WARNINGS'] = 'YES' config.build_settings['SWIFT_SUPPRESS_WARNINGS'] = 'YES' end end end It is recommended to only use these settings if absolutely necessary, as suppressing warnings can hide genuine issues in your dependencies [9]. Always ensure your Flutter and CocoaPods versions are up to date to resolve common build issues automatically [4][10].
Citations:
- 1: https://github.com/flutter/flutter/blob/c3d0f60407f4fe556a73f9bef495aac352d4595b/packages/flutter_tools/bin/podhelper.rb
- 2: https://github.com/flutter/flutter/blob/master/packages/flutter_tools/bin/podhelper.rb
- 3: Add extra Flutter settings to ios_app_with_extensions Podfile flutter/flutter#70719
- 4: https://stackoverflow.com/questions/79108490/flutter-flutter-h-file-not-found-when-trying-to-archive-ios-app-using-xcode
- 5: https://chromium.googlesource.com/external/github.com/flutter/flutter/+/9d88f8e9dd853eb6f3e3d698cd76d0cb46dfc665%5E%21/
- 6: Exclude arm64 if any dependencies do and print warning when using Xcode 26 flutter/flutter#182913
- 7: https://stackoverflow.com/questions/13208202/ignore-xcode-warnings-when-using-cocoapods
- 8: iOS error: 'WebRTC/WebRTC.h' file not found flutter-webrtc/flutter-webrtc#1026
- 9: [tool] Add --xcode-warnings-exceptions flag flutter/packages#8524
- 10: Fix all "Double-quoted include in framework header, expected angle-bracketed instead" warnings flutter/flutter#60025
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show Podfile with line numbers around the relevant hook
echo "---- example/ios/Podfile (lines 30-90) ----"
awk 'NR>=30 && NR<=90 {print NR "\t" $0}' example/ios/Podfile
# Inspect Podfile.lock for pod names and any indication of local/path pods
echo "---- example/ios/Podfile.lock (head) ----"
head -n 120 example/ios/Podfile.lock
echo "---- Any local/path pods in Podfile.lock ----"
rg -n "PATH|path:" example/ios/Podfile.lock || true
echo "---- Pod names excerpt from Podfile.lock ----"
rg -n "^ - " example/ios/Podfile.lock | head -n 80 || trueRepository: pawsitivegames/cardano-flutter-sdk
Length of output: 8943
Apply flutter_additional_ios_build_settings to the same target set you’re overriding
- In
example/ios/Podfile,flutter_additional_ios_build_settings(target)runs only forinstaller.pods_project.targets(40-42), but the warning/deployment overrides run for every target acrossinstaller.generated_projects(49-72). With CocoaPods multi-project generation, some targets can be missed by the Flutter helper, leaving Flutter-required build settings un-applied. - The suppression loop is unconditional for all generated pod targets, including local-path plugin pods from
.symlinks/plugins/...(e.g.,app_links,cardano_flutter_rs,flutter_secure_storage,flutter_webrtc, etc.), so it suppresses more than just external third-party pods.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@example/ios/Podfile` around lines 40 - 42, The Podfile currently calls
flutter_additional_ios_build_settings only for installer.pods_project.targets
while the warning/deployment overrides iterate installer.generated_projects,
which can miss targets; change the Podfile so
flutter_additional_ios_build_settings is also applied to the same target set
used by the overrides (i.e., iterate installer.generated_projects and call
flutter_additional_ios_build_settings(target) for each relevant target). Also
narrow the suppression loop that modifies build settings to skip local-path
plugin pods by filtering generated targets (e.g., exclude targets whose
pods/project path or name indicates .symlinks/plugins or local path plugins) so
the suppression only applies to external third‑party pods.
| # Silence deprecated-API / nullability warnings from third-party pods. | ||
| # Only touches Pods (never the Runner app), so our own warnings surface. | ||
| config.build_settings['GCC_WARN_INHIBIT_ALL_WARNINGS'] = 'YES' | ||
| config.build_settings['SWIFT_SUPPRESS_WARNINGS'] = 'YES' | ||
| # Disable the module verifier: a separate clang pass that compiles each | ||
| # framework's headers in isolation. On these old Google/Flutter pods it | ||
| # FAILS the build ("could not build module", "Flutter/Flutter.h not | ||
| # found", quoted-include errors) because the headers aren't self- | ||
| # contained. We can't patch upstream headers; disabling verification is | ||
| # the standard CocoaPods + Xcode 16/26 fix. | ||
| config.build_settings['ENABLE_MODULE_VERIFIER'] = 'NO' | ||
| config.build_settings['CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER'] = 'NO' |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Print Podfile around the referenced lines with context
sed -n '1,120p' example/ios/Podfile | nl -ba | sed -n '45,95p'
# Also search for where these build_settings are assigned / any surrounding loops/filters
rg -n "GCC_WARN_INHIBIT_ALL_WARNINGS|SWIFT_SUPPRESS_WARNINGS|ENABLE_MODULE_VERIFIER|CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER" example/ios/Podfile -n || true
# Show the full post_install block (or any similar block) where config.build_settings are mutated
rg -n "post_install|pre_install" example/ios/Podfile -n || true
rg -n "config\.build_settings\[" example/ios/Podfile -n || trueRepository: pawsitivegames/cardano-flutter-sdk
Length of output: 121
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Repo root =="
ls -la
echo "== Podfile (lines ~50-90) =="
sed -n '45,90p' example/ios/Podfile | cat -n
echo "== post_install / loops =="
rg -n "post_install|each do \|config\||installer\.pods|pods\.each|installer\.analysis|target\.name|target\.build_configurations" example/ios/Podfile || true
echo "== Build settings assignments =="
rg -n "GCC_WARN_INHIBIT_ALL_WARNINGS|SWIFT_SUPPRESS_WARNINGS|ENABLE_MODULE_VERIFIER|CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER|config\.build_settings\[" example/ios/Podfile || true
echo "== Full post_install block (bounded) =="
python3 - <<'PY'
import re
path="example/ios/Podfile"
with open(path,'r',encoding='utf-8') as f:
lines=f.readlines()
# Find post_install block start and print up to next end; best-effort via indentation
start=None
for i,l in enumerate(lines):
if re.search(r'\bpost_install\b', l):
start=i
break
if start is None:
print("No post_install found")
raise SystemExit(0)
# Print next ~120 lines from start for context
end=min(len(lines), start+140)
for i in range(start,end):
print(f"{i+1:4d}: {lines[i].rstrip()}")
PYRepository: pawsitivegames/cardano-flutter-sdk
Length of output: 6393
🏁 Script executed:
#!/bin/bash
set -euo pipefail
path="example/ios/Podfile"
echo "== Podfile top (1-120) =="
sed -n '1,120p' "$path"
echo "== Podfile full pod declarations (lines with 'pod ') =="
rg -n "^\s*pod\s+['\"]" "$path" || true
echo "== Podfile pod declarations with local podspec/path (':path' or '.podspec') =="
rg -n "^\s*pod\s+['\"].*(:path|\.podspec)" "$path" || true
echo "== Podfile post_install (already known) but show full function/next lines if any =="
sed -n '120,220p' "$path" || true
echo "== Search for flutter_additional_ios_build_settings(target) definition =="
rg -n "def\s+flutter_additional_ios_build_settings|flutter_additional_ios_build_settings" example/ios/Podfile || trueRepository: pawsitivegames/cardano-flutter-sdk
Length of output: 3775
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Find local podspec files in repo =="
fd -e podspec . || true
echo "== Check for any Pods lockfile in example/ios =="
ls -la example/ios || true
fd Podfile.lock example/ios || true
echo "== If Podfile.lock exists, show pod entries (trimmed) =="
if [ -f example/ios/Podfile.lock ]; then
rg -n "PODS:|DEPENDENCIES:|EXTERNAL SOURCES:" example/ios/Podfile.lock || true
sed -n '1,200p' example/ios/Podfile.lock | cat
fi
echo "== Look for plugin iOS podspecs under example/.. or packages =="
fd -e podspec packages example || trueRepository: pawsitivegames/cardano-flutter-sdk
Length of output: 6850
Scope warning/module-verifier suppression to third-party pods only.
In example/ios/Podfile’s post_install, the installer.generated_projects.each → project.targets loop unconditionally sets GCC_WARN_INHIBIT_ALL_WARNINGS, SWIFT_SUPPRESS_WARNINGS, ENABLE_MODULE_VERIFIER, and CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER for every generated pod target, with no filtering by pod origin. Since this repo ships a local pod (dart/ios/cardano_flutter_rs.podspec, referenced in example/ios/Podfile.lock as a :path dependency), the suppression applies to first-party/native code as well, potentially hiding regressions. Exclude first-party/local pods (or restrict the overrides to known problematic third-party pods, e.g. Google/Flutter trunk pods).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@example/ios/Podfile` around lines 58 - 69, The post_install loop is
unconditionally applying warning/module-verifier suppressions to all generated
targets (installer.generated_projects.each → project.targets and
config.build_settings[...] keys), which also affects the local first-party pod
(cardano_flutter_rs referenced via :path); update the loop to only apply these
settings for third-party pods by skipping pod targets that originate from a
local :path spec or by white-listing known problematic pods. Concretely, inside
the post_install block locate the installer.generated_projects.each /
project.targets iteration and: map each Xcode target back to its Pod::PodTarget
(installer.pod_targets), detect pod_target.specification.source.key?(:path) (or
compare pod_target.name to "cardano_flutter_rs"), and only set
GCC_WARN_INHIBIT_ALL_WARNINGS, SWIFT_SUPPRESS_WARNINGS, ENABLE_MODULE_VERIFIER,
and CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER when the pod is not a
local/:path pod (or when it matches a configured third-party list).
2 participants
Summary
Clears the remaining analyzer and iOS build warnings in the example app. No functional changes — all cleanups and third-party noise suppression.
Dart / analyzer cleanups
use_super_parameters)Color.withOpacitywithwithValues(alpha:)main.dart(_isTesting,_myAddress,_preInitializeLib) and a redundant null-aware on non-null keys// ignore_for_file: avoid_printon the integration-test harness (stdout logging is intentional there)iOS build (
example/ios)Podfilepost_install: suppress third-party pod warnings, disable the module verifier (old Google/Flutter headers fail isolated module compilation), and re-stamp the generated Pods project'sLastUpgradeCheckso Xcode stops showing "Update to recommended settings" on everypod installPodfile.lockLastUpgradeCheckleft to Flutter's tooling (it manages that value on every build)Verification
flutter build ios --no-codesign→ BUILD SUCCEEDED, 0 errors🤖 Generated with Claude Code
Summary by CodeRabbit
Refactor
Style
Chores