Skip to content

feat: [SDK-4998] add Mac Catalyst XCFramework support - #18

Open
fadi-george wants to merge 2 commits into
mainfrom
fadi/sdk-4998
Open

feat: [SDK-4998] add Mac Catalyst XCFramework support#18
fadi-george wants to merge 2 commits into
mainfrom
fadi/sdk-4998

Conversation

@fadi-george

Copy link
Copy Markdown
Contributor

Summary

  • Add arm64 and x86_64 Mac Catalyst slices to OneSignalKMP.xcframework.
  • Verify Catalyst architectures, platform metadata, and the iOS 14.0 minimum deployment target.
  • Add Catalyst Swift import smoke tests to CI and release workflows.
  • Upgrade Kotlin to 2.3.0 for Kotlin/Native Mac Catalyst support.

Motivation

The iOS SDK needs to use the shared KMP logger when built for Mac Catalyst. The existing XCFramework only contains iOS device and simulator slices, so Catalyst builds cannot import or link OneSignalKMP.

Testing

  • ./gradlew verifyOneSignalKMPXCFramework
  • Verified both Catalyst architectures report platform MACCATALYST and minos 14.0.
  • Verified Swift can import OneSignalKMP for the arm64-apple-ios14.0-macabi target.

Checklist

  • I reviewed my changes.
  • I added or updated tests, or explained why they are not needed.
  • I confirmed there are no unintended public API changes.

Made with Cursor

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Multi-model adversarial review (interrogate)

Verdict: request changes before merge — Catalyst packaging works in the verify path (CI green), but the PR leaves a dual-producer footgun, does not update consumer manifests, and the Kotlin 2.3.0 bump collides with the still-advertised iOS 11 floor.

Intent

Add Mac Catalyst (macabi) support to OneSignalKMP.xcframework so the iOS SDK can import/link the shared KMP logger when building for Mac Catalyst. Upgrade Kotlin to 2.3.0 for K/N Mac Catalyst; build macabi frameworks from iosX64 + iosSimulatorArm64; lipo-merge + rebuild XCFramework with ios-arm64_x86_64-maccatalyst; verify arch/Mach-O metadata; add CI/release Catalyst Swift smoke tests.

Reviewers

  • A claude-fable-5-thinking-xhigh — 10 findings
  • B gpt-5.6-sol-xhigh — 6 findings
  • C cursor-grok-4.5-high-fast — 10 findings
  • D claude-opus-5-thinking-high — 10 findings

Act On

  1. Canonical assemble path still ships a 2-slice XCFramework (A/B/C/D) — assembleOneSignalKMPCatalystReleaseXCFramework deletes/rewrites KGP’s assembleOneSignalKMPReleaseXCFramework output. README still documents/instructs the 2-slice assemble task. Only verify… (which the iOS host happens to call) produces Catalyst. Make one producer own the final artifact (finalizedBy, distinct output path, or single create-xcframework task) and update README.
  2. Kotlin 2.3.0 raises Apple floor to iOS 14; this PR still stamps/advertises iOS 11 (A/B/C/D) — JetBrains docs: min iOS 14.0, overrides “not guaranteed… can break at runtime.” Device/sim still force osVersionMin.*=11.0; Package.swift / podspec still say iOS 11; verify only asserts Catalyst minos 14.0. Decide + align (raise to 14, or explicitly document/verify the unsupported 11 override).
  3. Consumer contracts omit Catalyst (A/B/C/D) — unchanged Package.swift (no .macCatalyst) and podspec (iOS-only deployment). CI’s Catalyst check bypasses SPM/CocoaPods resolution via -F on a slice dir.
  4. Catalyst “smoke test” never links (A/B/C/D) — swiftc -typecheck only; no x86_64-macabi exercise; SPM xcodebuild remains simulator-only. Add a real Mac Catalyst link (or xcodebuild destination platform=macOS,variant=Mac Catalyst).

Consider

  • Android host still on Kotlin 1.9.25 (A/D) — same tag/source can compile under 2.3 here vs 1.9 in Android; breaks the “mirrors Android root” invariant. Coordinate host bump or gate 1.9 compatibility.
  • Experimental macabi + iosX64 tier-3 / planned 2.4 removal (A/C/D) — document expiry plan for Intel Catalyst.
  • Gradle ownership / incrementality (A/B/C/D) — catalyst task has no inputs/outputs; mutates another task’s outputs; always dirty.
  • minos 14.0 asserted but not configured on macabi binaries (A/C) — pin explicitly like iOS overrides.
  • coroutines 1.7.3 with Kotlin 2.3.0 (C/D) — bump or justify.

Noted

Debug macabi links registered unused; hardcoded KGP task/path/member names; CI/release heredoc duplication; Catalyst Info.plist cloned from simulator framework.

Dismissed

  • “Rewrite packaging for style / prefer different architecture” without a concrete failure mode beyond the dual-producer issue (folded into Act On #1).
  • Security findings — none traced.

Agreement map

All four models independently hit dual-producer path, Kotlin 2.3 vs iOS 11, missing Catalyst manifests, and typecheck-only verification. Divergence was mostly severity labels and packaging redesign depth (Info.plist / plutil vs vtool, debug binary nits).

CI verify job is green — treat that as “happy path via verify works,” not as clearance for the Act On items above.

Open in Web View Automation 

Sent by Cursor Automation: Untitled

Comment thread kmp/build.gradle Outdated
Comment thread build.gradle
Comment thread kmp/build.gradle
Comment thread kmp/build.gradle Outdated
Comment thread .github/workflows/ci.yml Outdated
Make the canonical assembly produce the complete XCFramework and validate real Catalyst resolution and linking across both architectures.

Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant