feat(ios): recover tracking after the app is killed#2
Merged
Conversation
After the app was killed by the user or the OS, tracking never resumed. Two causes, both against the MotionTag iOS integration guide: - The Expo plugin injected MotionTagBootstrap.bootstrap() after startReactNative(), so on a background location relaunch the SDK only initialized after the whole RN/Expo startup — too late to catch the wake-up event. It is now the first statement of didFinishLaunchingWithOptions. - application(_:handleEventsForBackgroundURLSession:completionHandler:) was never wired up in the Expo path, so the SDK's background upload events were swallowed by ExpoAppDelegate's default handler. The plugin now injects an override that routes MotionTag-owned sessions (new MotionTagBootstrap.handlesBackgroundURLSession check) to the SDK and everything else to super. Reported by MotionTag support during their iOS integration testing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The MotionTag Android guide requires initialisation as early as possible in Application.onCreate, and the Expo plugin already injects the bootstrap before loadReactNative — the bare-RN README snippet showed it after, contradicting both. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
jaymaycry
added a commit
that referenced
this pull request
Jun 2, 2026
…ting PR #2 was merged with a merge commit, so release-please counted both the merge commit (resolved via the PR title) and the underlying feat commit as separate changelog entries. Keep the one linking to the actual commit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Why
MotionTag support reported that after the app is killed (by the user or the OS), it cannot recover and resume tracking on iOS.
Two causes, both deviations from the MotionTag iOS integration guide:
SDK initialized too late. The Expo plugin injected
MotionTagBootstrap.bootstrap()afterstartReactNative(). On a background location relaunch the SDK only initialized after the whole RN/Expo startup — too late to catch the wake-up event. The guide requires init "as early as possible" indidFinishLaunchingWithOptions.Background URL session events never reached the SDK.
application(_:handleEventsForBackgroundURLSession:completionHandler:)was not wired up in the Expo path, soExpoAppDelegate's default handler swallowed the SDK upload-session events (calling the completion handler immediately when no Expo subscriber claims them).What
plugin/withIosAppDelegate.js: bootstrap is now injected as the first statement ofdidFinishLaunchingWithOptions; ahandleEventsForBackgroundURLSessionoverride is injected that routes MotionTag-owned sessions to the SDK and everything else tosuper. Block placement is idempotent acrossexpo prebuildre-runs (existing misplaced blocks are moved).ios/MotionTagBootstrap.swift: newhandlesBackgroundURLSession(identifier:)— checks the SDK session-identifier prefixes (com.motion-tag./com.motiontag., verified against the SDK 6.5.0 binary).README.md: bare-RN iOS instructions updated to the routed pattern + early-init warning; SDK-bump checklist notes the hard-coded prefixes; Android bare-RN snippet fixed to init beforeloadReactNative.Verification
react-native-motiontagpod target compiles (incl. new bootstrap API)expo prebuildruns (placement, idempotency, upgrade path)ExpoModulesCore/ "no such module 'React'" environment issue — proven unrelated via counterfactual build on unmodifiedmain(identical failure)🤖 Generated with Claude Code