Migrate iOS plugin to Swift Package Manager - #7
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request migrates the iOS plugin to a Swift Package Manager structure, updates the example app's iOS deployment target to 13.0, and integrates the new implicit Flutter engine delegate in the AppDelegate. Feedback recommends renaming the library in Package.swift to use underscores for consistency and uncommenting the platform version in the Podfile to match the project's deployment target.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
- Declare the FlutterFramework dependency in Package.swift, per Flutter's Swift Package Manager guidance for Swift plugin authors. Resolves the warning emitted on `flutter pub get`. - Bump the iOS deployment target from 12.0 to 13.0 (Package.swift and podspec): FlutterFramework requires iOS 13.0, which is also Flutter's current minimum supported deployment target. - Ignore SwiftPM build artifacts (.build/, .swiftpm/, Package.resolved) and the example's xcshareddata/swiftpm/ workspace to avoid committing clutter. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@binSaed Can this be merged? |
2 participants
Summary
Adds Swift Package Manager support to the
open_mail_app_plusiOS plugin, following Flutter's standard dual-support pattern (the same layout first-party plugins likeurl_launcher_iosuse). The plugin now builds under both SPM and CocoaPods from a single shared set of source files.Plugin changes (
ios/)ios/open_mail_app_plus/Package.swiftdeclaring theopen_mail_app_plustarget (iOS 12 min) and bundlingPrivacyInfo.xcprivacyas a processed resource.ios/Classes/OpenMailAppPlusPlugin.swift→ios/open_mail_app_plus/Sources/open_mail_app_plus/OpenMailAppPlusPlugin.swiftios/Resources/PrivacyInfo.xcprivacy→ios/open_mail_app_plus/Sources/open_mail_app_plus/PrivacyInfo.xcprivacyopen_mail_app_plus.podspecto read the same relocated sources (source_files+resource_bundles), so CocoaPods and SPM share one source of truth — no duplicated code.OpenMailAppPlugin.h/.m). These were leftover template files referencing a non-existentOpenMailAppPluginclass (the.meven called itself recursively) and were never wired up —pubspec.yamlonly registersOpenMailAppPlusPlugin.Example app changes (
example/ios/)Podfile(+ generatedPodfile.lock). The project still carried CocoaPods build phases but had no Podfile, so${PODS_ROOT}resolved empty and the build failed withUnable to load contents of file list: '/Target Support Files/Pods-Runner/...'. With the Podfile back,pod installregenerates the xcfilelists and SPM + CocoaPods coexist as Flutter expects.Incidental (Flutter tooling auto-migrations)
Running the example under the current Flutter SDK triggered standard project migrations that are included in the diff:
AppDelegate.swiftadoptsFlutterImplicitEngineDelegatefor plugin registration.Info.plistgains theUIApplicationSceneManifest(FlutterSceneDelegate) entries.AppFrameworkInfo.plist/project.pbxproj/ scheme / lockfile updates.Testing
swift package describeresolves the manifest, target, and privacy resource cleanly.flutter runon an iOS simulator builds and launches the example successfully.Resolves #6 .