Release 2.15.3 - #209
Closed
itmindbox wants to merge 18 commits into
Closed
Conversation
Merge 'master' into 'develop' after release
Ship a Package.swift alongside the existing podspec, so the plugin
resolves via SPM (Flutter ≥ 3.29) and via CocoaPods unchanged. Swift
sources move to ios/mindbox_ios/Sources/mindbox_ios/ — the layout
required by SwiftPM — and the podspec source_files now points there
plus the legacy ObjC AppDelegate from Classes/.
Drop the Objective-C plugin bridge (MindboxIosPlugin.{h,m}); the plugin
registers directly through the renamed Swift class MindboxIosPlugin
(the `Swift` prefix was a carry-over from the ObjC bridge era and
stopped describing anything once the bridge was deleted). Flutter's
GeneratedPluginRegistrant.m falls back from `#import` of the missing
ObjC header to `@import mindbox_ios;`, which picks up the Swift class
via the auto-generated mindbox_ios-Swift.h. The corresponding stale
#import in the ObjC AppDelegate goes away too.
ObjC MindboxFlutterAppDelegateObjc stays in Classes/ for existing
CocoaPods consumers, marked deprecated. It is intentionally not exposed
via the SPM target — gating that on Flutter ≥ 3.41 (the documented
minimum for SPM ObjC plugins with FlutterFramework) is not worth
bumping the SPM-minimum for a deprecated path.
Misc cleanups in the moved Swift files: drop the unused
'MindboxNotifications' import in MindboxFlutterAppDelegate.swift, and
simplify writeNativeLog by seeding the local 'level' var from
'Mindbox.logger.logLevel' to inherit the LogLevel type via inference.
That drops the 'import MindboxLogger' from the plugin — which would
otherwise fail in SPM mode since MindboxLogger is a target in
ios-sdk's Package.swift but not exposed as a product.
Verified locally on Flutter 3.44 (Example) and Flutter 3.29
(flutter-app) on iPhone 17 Pro simulator: both SPM and CocoaPods builds
initialize the SDK, return an APNS token and device UUID. No crash, no
duplicate framework load. 'pod lib lint mindbox_ios.podspec' passes
after dropping the local cocoapods-spm gem (its macro_pods hook breaks
unrelated specs).
Drop the artificial Dart 2 compat-mode constraint ('<3.0.0') on all
four packages — mindbox, mindbox_ios, mindbox_android,
mindbox_platform_interface. Lower bound (>=2.12.0) is unchanged, so
this is hygiene, not a consumer-visible breaking change.
Motivated by the SDK ecosystem catching up to Dart 3; clients on modern
Flutter no longer need a 'dependency_overrides' shim to satisfy the
constraint.
Integrate MindboxNotifications into the example's notification extensions
through Swift Package Manager instead of CocoaPods, so the example builds
the SDK entirely via SPM in SPM mode.
- Add the mindbox-cloud/ios-sdk package at the Xcode project level and link
its products to the extension targets:
MindboxNotificationsService -> MindboxNotificationServiceExtension
MindboxNotificationsContent -> MindboxNotificationContentExtension
Mindbox itself is NOT linked to Runner (left as "None"): the main app gets
it transitively via FlutterGeneratedPluginSwiftPackage -> mindbox_ios.
SPM unifies this project-level ios-sdk with the one the plugin pulls into
the same package identity, so the whole app resolves to a single ios-sdk
version (verified: Package.resolved lists ios-sdk once at 2.15.1).
- Use an "up to next major" rule (>= 2.15.1, < 3.0.0) for that package so it
auto-aligns with whatever exact version the plugin pins, surviving 2.x
releases without manual pbxproj edits. A conflicting/too-narrow rule would
fail resolution loudly rather than drift silently.
- Drop the CocoaPods extension blocks (pod 'MindboxNotifications') from the
Podfile; extensions no longer use CocoaPods. The Podfile stays only for the
Runner target, since shared_preference_app_group and permission_handler_apple
have no SPM support yet.
- Drop the duplicate top-level pod 'Mindbox' from Runner (it double-loaded the
Mindbox framework and mismatched versions, crashing inside MBDatabaseRepository
on first launch). Pin platform :ios, '13.0' so CocoaPods stops auto-assigning
15.0. Hard-set flutter.config.enable-swift-package-manager: true so the
example always exercises the SPM path.
.gitignore picks up dev-only artifacts (pubspec_overrides.yaml, ios/.spm.pods/,
**/xcshareddata/swiftpm/). pubspec.lock regenerated from the Dart SDK bound bump.
Verified on Flutter 3.44, iPhone 17 Pro simulator: clean build with no Mindbox
pods, NSE/NCE compile against MindboxNotifications via SPM, app launches and the
SDK initializes.
The native iOS SDK version prompted by the release tooling now also bumps the 'exact:' pin in mindbox_ios/ios/mindbox_ios/Package.swift, alongside the existing podspec bump. Without this hook a release would ship a podspec on the new native SDK but an SPM manifest still pinned to the previous one. Two release entry points exist and both are updated in lockstep: - git-release-branch.sh — local interactive bash script (BSD sed). - .github/workflows/manual-prepare_release_branch.yml — the actual CI-driven release prep (GNU sed on Ubuntu, runs under 'set -euo pipefail'). The substitution is addressed by the 'mindbox-cloud/ios-sdk' URL so unrelated 'exact:' pins (if more SPM dependencies are added later) stay untouched. Verified with both BSD and GNU sed against normal X.Y.Z, X.Y.Z-rc, multi-digit versions, repeated runs (idempotent), and a synthetic Package.swift with a second unrelated 'exact:' pin.
Flutter's SPM docs don't cover the Mindbox-specific steps: wiring the notification extensions to the ios-sdk products in Xcode, and removing the CocoaPods Mindbox pods (Runner's `pod 'Mindbox'` and the extensions' `pod 'MindboxNotifications'`) so the SDK isn't loaded by both pod and SPM — which duplicates the framework and crashes at runtime. SPM_MIGRATION.md documents this (mirroring UISCENE_MIGRATION.md) and is linked from the README; the CocoaPods path is unchanged.
permission_handler 12 and shared_preference_app_group 2 now ship Swift Package Manager support, so every iOS plugin in the example resolves via SPM — CocoaPods is no longer needed. Deintegrated it: removed the Podfile, the Pods xcconfig includes, the Pods workspace reference, the empty Pods group, the now-dead Pods framework/header search paths on the notification extensions, and an orphan Mindbox.framework reference. Runner.xcworkspace stays (Flutter needs it to manage SPM integration; it errors 'Xcode workspace not found' without it) but now references only Runner.xcodeproj. Bump the remaining direct deps to latest (permission_handler ^12, shared_preference_app_group ^2, flutter_lints ^6) and align the extensions' marketing version with the app (1.0.0) to clear the parent/extension version-match warning. Verified pod-free build and run on the simulator: SDK init, permission grant, and in-app all work.
The example's notification-extension targets referenced MindboxNotificationsService/Content only through their Frameworks build phase — the targets' packageProductDependencies arrays were missing (a known Xcode SPM wiring bug; see ios-app SPM-NOTES). Re-adding the ios-sdk package wires each product into both the build phase and the target's packageProductDependencies, so the structure is complete and Xcode manages add/remove correctly. Pin (Up to Next Major 2.15.1), Mindbox=None on Runner, and product→target mapping are unchanged. objectVersion bumped 54→60 to match the toolchain. Verified: pod-free build + in-app on the simulator.
Removed the obsolete ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES (the Swift runtime ships with iOS 13+), enabled String Catalog symbol generation, bumped LastUpgradeCheck. Kept CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER off at the project level — enabling it floods unfixable warnings from Flutter.framework's own quoted-include headers. Verified: clean build + in-app on the simulator.
flutter_lints 6 enables strict_top_level_inference, which flags the example's static ViewModel methods that have no explicit return type — failing `flutter analyze` in CI. Add void return types to the eight methods. No behavior change.
Address PR #199 review: replace the untyped 'Function complition' parameter with 'void Function(String) completion' in getSDKVersion/getToken/getDeviceUUID so callers get proper type checking, and fix the typo. flutter analyze clean.
The guide said SPM is opt-in / off by default; Flutter 3.44 enables it by default (flutter#184495), so an upgrader who keeps the Mindbox pods silently double-loads Mindbox and crashes at launch (Expected CDEvent). Correct the activation per Flutter version, keep that warning with the CocoaPods opt-out inline, and cut the rest to the actionable core.
MOBILE-146: SPM support and Example update
#200) The NSE suiteName and push_item_manager.dart appGroupID used group.cloud.Mindbox.cloud.mindbox.flutterExample — the App Group of the old bundle id (cloud.mindbox.flutterExample) — while the Runner/NSE/NCE entitlements use group.cloud.Mindbox.mindbox.Flutter.Example for the current bundle id (mindbox.Flutter.Example). The processes weren't entitled to their suiteName, so the shared container was empty and the notification centre showed stubs instead of received pushes. Point both at the entitled group.
Remove a trailing space on the last line so the Gitleaks workflow is byte-identical across ios-sdk/react-native-sdk/flutter-sdk. Whitespace-only.
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
4 participants
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.
Automated PR: merge
release/2.15.3intomasterVersions:
2.15.32.15.32.15.2