feat: SPM Support and new MP SDKs

[BrandonStalnaker]

Background

• The Flutter plugin was pinned to older native SDKs (mParticle-Apple-SDK ~> 9.2, android-core:5.79.0) and only supported iOS integration via CocoaPods.
• mParticle has released Apple SDK 9.3.1 and Android SDK 6.0.0, which include API changes (especially around Rokt), stricter platform requirements, and new capabilities like device-level consent and Swift Package Manager support in the Apple SDK.
• Flutter now recommends dual CocoaPods + SPM support for plugins, and Android 6.0 moves Rokt types out of android-core and removes several deprecated APIs used by the existing bridge.
• Rokt Kit Availability for exposed classes like RoktEmbeddedView means we need to guard against whether or not Kit is included

What Has Changed

• Bumped native dependencies to Apple SDK ~> 9.3 and Android SDK 6.0.0 (android-core + android-rokt-kit), and released plugin version 2.2.0.
• Added Swift Package Manager support for iOS: new ios/mparticle_flutter_sdk/Package.swift, relocated native sources under ios/mparticle_flutter_sdk/Sources/, and updated the podspec paths for CocoaPods compatibility.
• Migrated the Android bridge to SDK 6.0 APIs: updated Rokt imports/packages (com.mparticle.kits, com.rokt.roktsdk), switched from Rokt() to MParticle.rokt, replaced UserAttributeListener with TypedUserAttributeListener, and removed onMarginChanged padding callbacks removed upstream.
• Raised Android minSdkVersion from 16 to 23 and updated Kotlin to 2.1.20 to satisfy Android 6.0 / Rokt 6.x requirements.
• Updated example app, README, and CHANGELOG to reflect the new versions and migration notes.

Checklist

• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.
• I have added tests that prove my fix is effective or that my feature works.
• I have tested this locally.

Reference Issue (For employees only. Ignore if you are an outside contributor)

• Closes https://go/j/[ticket-number]

[cursor]

PR Summary

High Risk
Breaking Android minSdk 23 and major native SDK upgrades affect all integrators; optional Rokt classpath behavior and removed padding callbacks can break Rokt-heavy apps that omit android-rokt-kit or relied on margin events.

Overview
This release (2.2.0) upgrades the Flutter plugin to mParticle Apple SDK ~> 9.3 and Android SDK 6.0.0, and adds Swift Package Manager support on iOS via Package.swift with native sources under ios/mparticle_flutter_sdk/Sources/.

On Android, Rokt integration is refactored behind RoktKitAvailability / RoktBridge: android-rokt-kit is compileOnly on the plugin, and Rokt platform views and method-channel handlers run only when com.mparticle.kits.RoktEmbeddedView is on the app classpath; otherwise Rokt calls return a clear error. The bridge is updated for SDK 6.0 (com.mparticle.kits, com.rokt.roktsdk, MParticle.rokt), TypedUserAttributeListener replaces UserAttributeListener, and layout margin/padding callbacks are removed. minSdkVersion is raised from 16 to 23 (breaking), with Kotlin 2.1.20 in the plugin build.

Docs, example app, and CocoaPods paths are aligned with the new versions; the Dart Rokt API is unchanged aside from an Android doc reference to rokt.

^{Reviewed by Cursor Bugbot for commit 5e35311. Bugbot is set up for automated code reviews on this repo. Configure here.}

[nickolas-dimitrakas]

The changed section is above the version header

[nickolas-dimitrakas]

Small issue with the changelog. Also a callout that this PR has included some changes that usually go within our Release - Draft workflow. Fine otherwise

[thomson-t]

I think createDelegate and registerPlatformView methods need not be wrapped in the RoktKitAvailability object. They can be in the RoktBridge class, right?

[BrandonStalnaker]

I agree on the registerPlatformView but for createDelegate I have some concerns.

If we move this to RoktBridge.createIfAvailable(), the plugin must reference RoktBridge in source. Invoking a companion method still loads the RoktBridge class — and that class imports RoktEmbeddedView, rokt, RoktConfig, etc. Which kinda goes against the optional-kit pattern.