feat(native): align latest Swift and Kotlin SDKs

[tolgahan-arikan]

Summary

• Align the React Native SDK release metadata, docs, and examples for 0.1.0-alpha.4.
• Update Android to io.github.0xsequence:oms-client-kotlin-sdk:0.1.0-alpha.4, lower wrapper/example defaults to minSdk 24, and align Kotlin/coroutines/serialization settings.
• Update iOS to oms-client-swift-sdk 0.1.0-alpha.4 and align native error details with Android.
• Update bridge serialization for native SDK timestamp strings.
• Refresh the standalone Expo example for the current OMSClient API and add yarn expo-example:install for published-package or local-tarball installs.

Validation

• PR checks passing: lint, lint-typecheck, build-library, build-android, build-ios, and CodeQL.
• Also verified locally/manual: yarn lint, yarn typecheck, yarn test, yarn expo-example:install, Expo typecheck, SDK example Android/iOS builds, Trails actions Android build, and Expo iOS simulator smoke test.

Publishing

After merge, publish 0.1.0-alpha.4 from master with the alpha tag:

yarn prepare
yarn npm publish --dry-run --access public --tag alpha
yarn npm whoami
yarn npm publish --access public --tag alpha

Then verify the npm tarball and refresh the Expo example lockfile against it:

npm view @0xsequence/oms-react-native-sdk@0.1.0-alpha.4 version dist.integrity
npm --prefix examples/expo-example install --package-lock-only --ignore-scripts
git diff --exit-code examples/expo-example/package-lock.json

If the lockfile changes, commit the refreshed examples/expo-example/package-lock.json.

[github-actions]

Claude finished @tolgahan-arikan's task —— View job

---

PR Review — align latest native SDKs (alpha.4)

Overall this is a clean, well-scoped version-alignment PR. Native bridge changes are consistent with the existing TS contract, no backwards-compat shims, and docs/changelog are updated. A few notes below; nothing is a hard blocker except confirming the two external dependency-publish preconditions.

Correctness / native bridge consistency

• Kotlin timestamp change is correct. event.expiredAt and session?.expiresAt are now passed through as String instead of .toString(). This matches the TS types (expiresAt: string | null, expiredAt: string in src/NativeOmsClientReactNativeSdk.ts:58,66 and src/types.ts:44,51) and mirrors the iOS side, which formats Date → ISO-8601 string (ios/…Impl.swift:786-801). ✅ Consistent across src/, android/, ios/.
• iOS error mapping now matches Android. The rejection userInfo now emits operation/status/txnId/retryable (with NSNull for absent values) plus a new upstreamError map (ios/…Impl.swift:1259-1306), aligning with the Kotlin userInfoMap/upstreamErrorMap shape (…Module.kt:1200-1217). Good consistency win.
  • Nit: nullableUpstreamError / upstreamErrorDictionary and webRPCJSONObject etc. are only reachable via the error path now — no functional issue, just confirm iOS compiles with the alpha.4 OmsUpstreamError type (CI iOS build covers this).
• Version bumps are paired correctly: android/build.gradle (kotlin-sdk 0.1.0-alpha.4) + OmsClientReactNativeSdk.podspec (oms-client-swift-sdk 0.1.0-alpha.4) — matches the Maintenance Matrix requirement. package.json → 0.1.0-alpha.4 and both example build.gradle defaults lowered to minSdk 24 / Kotlin 2.1.20. ✅

Auth / session / signing / tx security

• No changes to the auth/signing/wallet-selection code paths beyond the timestamp field type. pendingWalletSelection client-scoping checks and fee-option continuation handling are untouched. No new security surface introduced.

Backwards-compat shims

• None added. The resolutions block removal in package.json (and matching AGENTS.md matrix rows) is a genuine simplification — confirm the trails example still resolves 0xtrails@0.16.2 transitively without the pin (the yarn.lock update should cover this; trails-actions Android/iOS CI will validate).

Expo dependency policy ⚠️

• The PR bumps examples/expo-example to @0xsequence/oms-react-native-sdk@0.1.0-alpha.4 before that version is published to npm, and removed the README line "Its dependency is not updated until this SDK version is published."
• The new scripts/install-expo-example-dependencies.sh mitigates this: it only runs npm ci if npm view <pkg>@<version> resolves, otherwise it packs a local tarball and rewrites the lockfile temporarily. This is a reasonable bridge, but note:
  • CI risk: npm ci requires the package-lock.json integrity hash to match the registry tarball. The lockfile here already contains an alpha.4 integrity sha512. If the eventual npm publish produces a different tarball hash than the one baked into the lockfile, yarn expo-example:install will fall into the local-pack branch on CI (fine) but a downstream consumer running plain npm ci would fail. Confirm the committed integrity hash matches the final published tarball, or regenerate the lockfile post-publish.
  • Per the repo's stated policy (and the line you removed), consider gating the version bump on the npm publish, or keep the README caveat until 0.1.0-alpha.4 is live. The PR body already flags this as a release precondition — just make sure it's enforced before merge/release.

Docs

• API.md, README.md, CHANGELOG.md, AGENTS.md, CONTRIBUTING.md, TESTING.md all updated coherently. Nit: PUBLISHING.md wasn't touched — check whether the new expo-example:install flow or the alpha.4 tarball-pack step needs a mention there (the direct review ask called out PUBLISHING.md).
• Nit: API.md/README.md say compileSdk 34 or newer while the wrapper uses compileSdkVersion 36. Just a stated minimum, not a conflict.

Test coverage

• No automated tests for the changed serialization (timestamps, error upstreamError). Repo has no native test harness yet (per TESTING.md), so this is consistent with current conventions; validation is via the listed manual/CI builds. Not a blocker, but the string-timestamp and error-shape changes are exactly the kind of thing a small bridge-serialization unit test would guard.

Out of scope (pre-existing, FYI)

• The TS layer (client.native.ts) doesn't appear to re-surface the native upstreamError/retryable/operation userInfo into a typed error — src/types.ts error type only exposes code. The iOS change now emits these fields to parity with Android, but they're still not consumed on the JS side. Pre-existing; flagging only so it isn't assumed to be wired up.

Summary

• ✅ Native bridge changes are correct and consistent across src/android/ios.
• ✅ No shims; version bumps paired correctly.
• ⚠️ Verify the two publish preconditions before release: npm alpha.4 published (Expo dep) + kotlin-sdk alpha.4 on Maven Central; confirm the committed Expo lockfile integrity matches the final published tarball.
• Nits: PUBLISHING.md mention of new install flow; optional bridge-serialization test.
  • Branch: align-latest-native-sdks