feat: add Swift Package Manager support for iOS plugin

[fadi-george]

Description

One Line Summary

Add Swift Package Manager (SPM) support for the iOS plugin while maintaining full CocoaPods compatibility.

Details

Motivation

Flutter is gradually adopting Swift Package Manager as the default dependency manager for iOS. Plugins that don't support SPM can cause build problems for projects that have migrated to SPM. This change ensures the OneSignal Flutter plugin works with both CocoaPods and SPM, following Flutter's official migration guide.

Scope

Plugin iOS source restructure (ios/):

The core change restructures the iOS plugin source files from ios/Classes/ to the SPM-compatible directory layout at ios/onesignal_flutter/:

ios/
├── onesignal_flutter.podspec         (updated paths)
└── onesignal_flutter/
    ├── Package.swift                 (NEW — SPM package definition)
    └── Sources/
        └── onesignal_flutter/
            ├── *.m                   (implementation files)
            └── include/
                └── onesignal_flutter/
                    └── *.h           (public headers)

Key details:

• Package.swift — Declares the SPM package targeting iOS 11.0, depending on OneSignal-iOS-SDK exact version 5.5.0 via SPM. Library name is onesignal-flutter (underscores to hyphens per Flutter convention). Depends on OneSignalFramework, OneSignalInAppMessages, OneSignalLocation, and OneSignalExtension products.
• Header files moved from ios/Classes/*.h → ios/onesignal_flutter/Sources/onesignal_flutter/include/onesignal_flutter/ (SPM public headers directory).
• Implementation files moved from ios/Classes/*.m → ios/onesignal_flutter/Sources/onesignal_flutter/.
• #import statements in all .m files updated to use relative paths (./include/onesignal_flutter/HeaderName.h) since headers are now in a subdirectory.
• onesignal_flutter.podspec updated source_files and public_header_files to point to new paths — CocoaPods continues to work with the same files.
• ios/Classes/ and ios/Assets/ (empty) directories removed.

What is NOT changed:

• No public API changes (Dart or native)
• No changes to Android plugin
• No changes to the CocoaPods dependency (OneSignalXCFramework 5.5.0)
• No changes to the demo example app (remains CocoaPods-based)

examples/demo_spm/ — SPM example app:

Scaffolded the existing demo_spm stub into a full example app with ios/ and android/ platform folders. This app uses SPM for iOS dependency resolution (no Podfile). Includes a OneSignalNotificationServiceExtension target configured with the OneSignalExtension SPM product for push notification processing.

Testing

Prerequisites

Enable Swift Package Manager in Flutter (one-time setup):

flutter config --enable-swift-package-manager

1. CocoaPods build (examples/demo/)

demo has enable-swift-package-manager: false in its pubspec.yaml to ensure CocoaPods is used.

• Ran flutter run on iOS simulator
• Tested all workflows: notifications, in-app messages, tags, aliases, email/SMS, location, Live Activities
• Pod install resolves correctly with updated podspec paths

2. SPM build (examples/demo_spm/)

Wiped simulator, then ran flutter run on iOS simulator.

• No Podfile — dependencies resolve entirely via SPM
• OneSignal-iOS-SDK 5.5.0 resolves via SPM
• Tested all workflows: notifications, in-app messages, tags, aliases, email/SMS, location, Live Activities

3. CocoaPods → SPM migration (examples/demo/)

Wiped simulator, then tested migrating demo from CocoaPods to SPM:

1. Comment out the SPM disable config in pubspec.yaml:

   # config:
   #   enable-swift-package-manager: false

2. Delete Podfile and Pods/ directory
3. Remove the CocoaPods include line from ios/Flutter/Debug.xcconfig and ios/Flutter/Release.xcconfig:

   #include? "Pods/Target Support Files/Pods-Runner/Pods-Runner.release.xcconfig"
   

4. Run flutter run — Flutter adds SPM integration and builds successfully
5. Tested all workflows: notifications, in-app messages, tags, aliases, email/SMS, location, Live Activities

Notes

• No unit tests added — this is a build system / packaging change with no logic changes
• Existing Dart unit tests continue to pass

Affected code checklist

• Notifications
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

None of the above are affected. This is a build system change only — source files are moved but their content is unchanged (only #import paths updated).

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

Made with Cursor

[abdulraqeeb33]

why do you need seperate a demo_spm example? is it to maintain backward compatibility?

[fadi-george]

The demo folder has:
config:
enable-swift-package-manager: false
so its to test the pods install flow

[nan-li]

What do you think about using https://github.com/OneSignal/OneSignal-XCFramework? I know for native iOS we recommend people to use that repository when using SPM rather than https://github.com/OneSignal/OneSignal-XCFramework for size

[fadi-george]

Done