Repository navigation
Override deployment target in CocoaPod dependencies when they're less than Xcode's minimum - #190677
Conversation
… than Xcode's minimum
There was a problem hiding this comment.
Code Review
This pull request reorganizes build settings logic in podhelper.rb by moving the deletion of IPHONEOS_DEPLOYMENT_TARGET and MACOSX_DEPLOYMENT_TARGET earlier in their respective configuration methods, and updates a test podspec in plugin_tests.dart. Feedback suggests updating an outdated comment in podhelper.rb to reflect that deleting the deployment target avoids build errors in newer Xcode versions rather than just suppressing harmless warnings.
| s.source_files = "Classes", "Classes/**/*.{h,m}" | ||
| s.dependency 'plugintest' | ||
| s.ios.deployment_target = '12.0' | ||
| s.osx.deployment_target = '10.14' |
There was a problem hiding this comment.
The only way to test this is through an integration test, so this is just added the requirements to make the error occur
|
auto label is removed for flutter/flutter/190677, Failed to enqueue flutter/flutter/190677 with HTTP 400: Pull request Required status check "Check Code Freeze" is expected.. |
|
autosubmit label was removed for flutter/flutter/190677, because - The status or check suite Dashboard Checks has failed. Please fix the issues identified (or deflake) before re-applying this label. |
Xcode 27 fails to build when dependencies have a deployment target lower than 15 for iOS and 12 for macOS. Previously it was just a warning.
This changes our CocoaPod logic to remove the deployment target of dependencies when it's lower than the minimum to also include transitive dependencies.
Fixes #190676.
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.