feat(ios): add Swift Package Manager support - #56
Closed
zoocityboy wants to merge 1 commit into
Closed
zoocityboy wants to merge 1 commit into
zoocityboy wants to merge 1 commit into
Conversation
An app with no ios/Podfile — SPM-only, which is how dronetag/app-ng is set up —
could not depend on this plugin at all: every published version (1.0.1, 1.1.0,
1.2.0) shipped ios/flutter_opendroneid.podspec and no Package.swift. That is a
blocking finding for app-ng's R0.3, filed there as
.df/issues/flutteropendroneid-na-spm.md.
Package.swift is declared alongside the podspec rather than instead of it.
Flutter resolves whichever the consuming app uses, so an app on CocoaPods —
including the legacy dronetag/app — keeps working unchanged.
Sources move to the layout SwiftPM requires:
ios/Classes/*.swift → ios/flutter_opendroneid/Sources/flutter_opendroneid/
and the podspec's source_files follows them, so one tree serves both.
The ObjC registration shim goes: FlutterOpendroneidPlugin.m forwarded
registerWithRegistrar to SwiftFlutterOpendroneidPlugin and nothing else, and
pubspec's ios pluginClass now names the Swift class directly. This is only
possible on this branch: a single SwiftPM target cannot mix ObjC and Swift, and
794bfb1 replaced the ObjC Pigeon bridge (ios/Classes/pigeon.{h,m}, still present
on master) with Pigeon-generated Swift. On master this change cannot be made
without keeping a second ObjC target.
Podspec platform 8.0 → 12.0 to match Package.swift. Not a real narrowing: the
plugin class is already @available(iOS 13.0) and the legacy app targets 14/16.
Verified: `swift package dump-package` parses the manifest — one iOS 12.0
platform, product flutter-opendroneid, target flutter_opendroneid. Not verified:
an actual device or simulator build, which needs macOS. That is in the issue's
definition of done and has to happen before a release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An SPM-only app (no
ios/Podfile) cannot depend on this plugin: every published version — 1.0.1, 1.1.0, 1.2.0 — ships onlyios/flutter_opendroneid.podspec. That blocksdronetag/app-ng, whose iOS target is SPM; filed there as.df/issues/flutteropendroneid-na-spm.md.What changed
ios/flutter_opendroneid/Package.swift— one target, no ObjC, iOS 12.0.ios/flutter_opendroneid/Sources/flutter_opendroneid/; the podspec'ssource_filesfollows them, so one tree serves CocoaPods and SwiftPM both.FlutterOpendroneidPlugin.{h,m},flutter_opendroneid.h). It forwardedregisterWithRegistrarto the Swift class and did nothing else;pubspec.yaml's iospluginClassnow namesSwiftFlutterOpendroneidPlugin.Package.swift. The plugin class is already@available(iOS 13.0)and the legacy app targets 14/16, so nothing actually loses support.Why against
chore/updateand notmasterA single SwiftPM target cannot mix ObjC and Swift.
masterstill carries the ObjC Pigeon bridge (ios/Classes/pigeon.{h,m});794bfb1on this branch replaced it with Pigeon-generated Swift. Onmasterthis change would need a second ObjC target — I tried that base first and backed out.CocoaPods consumers are unaffected: the podspec stays, and Flutter picks whichever the app uses.
Verified / not verified
swift package dump-packageparses the manifest — one iOS 12.0 platform, productflutter-opendroneid, targetflutter_opendroneid.Not verified: a real device or simulator build, which needs macOS. Dropping the ObjC shim changes how registration happens, so that check is not optional before a release — it is in the issue's definition of done, along with publishing, which app-ng needs before it can take the plugin.