fix(app/ios): Apple Watch connectivity & reliability hardening

[mdmohsin7]

Summary

Apple Watch ↔ phone audio streaming had several silent failure modes where the Watch UI showed "recording" but the iOS app received nothing. This PR addresses each one. The headline bug — silent audio chunk drop on state divergence — is fixed three ways for defense in depth: at the source (Watch sends start with a durable fallback), at the destination (phone now handles start in the background path), and at the symptom (chunks arriving without a prior start auto-recover instead of being dropped).

No new dependencies. No new background runtime modes. No protocol changes — just plugging holes in the existing WCSession lifecycle.

What's broken in main today

#	File	Bug
1	app/ios/Runner/AppDelegate.swift:538	didReceiveUserInfo (background path) had cases for sendAudioChunk/stopRecording/etc but no case for startRecording. Phone backgrounded when Watch starts → start message routed via transferUserInfo arrives, never flips isRecordingActive, every audio chunk silently dropped.
2	app/ios/omiWatchApp/WatchAudioRecorderViewModel.swift:49,82	Watch sent startRecording/stopRecording/recordingError/microphonePermissionResult via sendMessage only, no errorHandler. Phone unreachable → message lost, no retry path.
3	app/ios/Runner/AppDelegate.swift:347	handleAudioChunk dropped any chunk arriving while isRecordingActive=false and only printed to console. Watch UI showed recording, phone received nothing.
4	app/ios/omiWatchApp/WatchAudioRecorderViewModel.swift	RecorderHostApiImpl falls back to updateApplicationContext for start/stop/permission, but the Watch had no didReceiveApplicationContext handler — dead-code fallback.
5	app/ios/Runner/AppDelegate.swift:422	sessionDidDeactivate was a print-only stub. Apple's docs require WCSession.default.activate() here for multi-Watch swap; without it the session stays dead until app restart.
6	both sides	didFinishUserInfoTransfer:error: unimplemented — durable-queue failures were completely silent.
7	both sides	activationDidCompleteWith empty stub — activation failures proceeded silently.
8	both sides	No sessionReachabilityDidChange: / sessionWatchStateDidChange: — Flutter could only learn state by polling.

Commit-by-commit

Each commit is independently revertable.

1. fix(app/ios): handle startRecording in background WCSession path — phone-side didReceiveUserInfo now has a startRecording case mirroring the foreground handler.
2. fix(app/ios): give Watch state messages a transferUserInfo fallback — sendReliably(_:) helper applied to start/stop/error/permission messages.
3. fix(app/ios): recover from Watch↔phone recording state divergence — chunks arriving without a prior start now log loudly, flip isRecordingActive, notify Flutter, and continue processing instead of dropping.
4. fix(app/ios): wire Watch handler for applicationContext commands — session:didReceiveApplicationContext: dispatches start/stop/permission to the same handlers as didReceiveMessage.
5. fix(app/ios): reactivate WCSession on sessionDidDeactivate — Apple's documented multi-Watch pattern.
6. fix(app/ios): log transferUserInfo failures on both sides — durable-queue errors now visible in Console.app.
7. fix(app/ios): log WCSession activation outcome on both sides — activation failures no longer silent.
8. feat(app/ios): surface Watch reachability and state changes to Flutter — two new Pigeon FlutterAPI callbacks (onWatchReachabilityChanged, onWatchStateChanged); generated code regenerated for Dart, Swift, Kotlin.

Why no Opus / VAD / extended-runtime / custom ack protocol

Considered and dropped after design review:

• No application-level per-chunk ack protocol. WCSession's built-in delivery (sendMessage:replyHandler:errorHandler: for foreground ack, transferUserInfo for system-managed durable queue) is sufficient. A custom sequence-number protocol on top would amplify load and duplicate work the OS already does.
• No WKExtendedRuntimeSession. The standard audio background mode (already declared in Info.plist) keeps the Watch app alive while actively recording. Extended-runtime sessions are for screen-off recording continuation — a separate UX feature, not a reliability fix.
• No Opus encoding / VAD on Watch. Out of scope for connectivity & reliability. Each is a substantial dependency-introduction that wants its own PR for binary-size + battery review.
• No custom watchdog timer. The reliability gaps were all in lifecycle handlers we hadn't implemented; once those are wired the standard WCSession lifecycle covers reconnection.

Test plan

This needs physical iPhone + Apple Watch hardware — WatchConnectivity behavior cannot be exercised in the simulator. The Linux build environment used here cannot compile iOS Swift, so the Swift changes were validated by static reading and adjacent-pattern comparison; Dart code passes flutter analyze (the only finding is a pre-existing pigeon import diagnostic on pigeon_interfaces.dart).

Golden path

• iPhone foreground, Watch foreground: tap record on Watch → phone receives audio within 1.5s.
• iPhone foreground, Watch foreground: tap stop on Watch → phone stops within 1.5s.
• Phone-initiated start (Flutter UI): Watch starts recording.

State divergence (the headline failure mode)

• Force-quit iOS app. Open Watch app, tap record. Reopen iOS app within ~10s. Expected: iOS shows recording, audio chunks flowing. Console.app log shows [Watch] Audio chunk arrived without prior startRecording — recovering state.
• iOS app backgrounded (not killed). Tap record on Watch. Bring iOS to foreground. Expected: recording state visible immediately, no audio loss.
• iOS app foreground, then user puts Watch in airplane mode briefly while recording. Re-enable. Expected: chunks queued during airplane mode delivered when reachable; recording continues.

Lifecycle hardening

• Pair a second Apple Watch (settings → My Watch → All Watches). Trigger Watch swap. Expected: iOS app stays responsive to the new Watch (sessionDidDeactivate reactivation).
• Force-quit iOS app while Watch is recording. Relaunch. Expected: activation logs visible in Console.app; first audio chunk triggers recovery.
• Uninstall Watch app from paired Watch. Expected: onWatchStateChanged(isPaired:true, isWatchAppInstalled:false, ...) fires (visible in Flutter debug log).

Reachability

• iOS in foreground, Watch on same wrist, recording. Walk out of Bluetooth range (~10m+ wall). Expected: [Watch] reachability changed: false log; chunks queued; on return, queue flushes and audio resumes.
• iOS app backgrounded with screen off. Recording active. Expected: chunks delivered via transferUserInfo system queue with no loss visible in final transcript.

Negative

• Tap record on Watch with phone bluetooth off entirely. Expected: recordingError surfaces with permission/connectivity error message instead of silent failure.
• Force a WCSession activation failure (e.g. revoke entitlements in dev build). Expected: activation failure logged in Console.app; no silent no-op.

Files touched

• app/ios/Runner/AppDelegate.swift — phone-side delegate hardening, silent-drop fix, new Pigeon callbacks
• app/ios/omiWatchApp/WatchAudioRecorderViewModel.swift — Watch-side delegate hardening, sendReliably(_:) helper, didReceiveApplicationContext handler
• app/lib/pigeon_interfaces.dart — two new FlutterAPI callbacks
• app/lib/services/bridges/apple_watch_bridge.dart — bridge implementations
• app/lib/services/devices/transports/watch_transport.dart — debug logging for new callbacks
• app/lib/gen/pigeon_communicator.g.dart, app/ios/Runner/PigeonCommunicator.g.swift, app/android/app/src/main/kotlin/com/friend/ios/PigeonCommunicator.g.kt — Pigeon regen

Out of scope (deliberate)

State persistence via updateApplicationContext for isRecordingActive truth — the recovery path in commit 3 covers the same failure mode reactively. UI plumbing for the new reachability/state callbacks beyond debug logging — bridge and Pigeon channel are in place; downstream subscribers can attach without further iOS changes.

[mdmohsin7]

@morpheus review — Approved ✅

Well-structured reliability hardening. All 8 commits address real WCSession lifecycle gaps that caused silent audio drop. Reviewed the full diff (277 insertions / 22 deletions across 8 files).

What I verified:

Defense in depth for the headline bug (silent chunk drop):

• Commit 1: Background startRecording case in didReceiveUserInfo — mirrors the foreground handler at line 478 exactly (adjacent pattern parity ✅). Same 4-line state reset, DispatchQueue.main.async for Flutter notification.
• Commit 2: sendReliably — clean sendMessage→transferUserInfo fallback. Correctly applied to state messages only; audio chunk paths left inline (different fallback shape). No retry amplification.
• Commit 3: Divergence recovery — handleAudioChunk no longer drops chunks when isRecordingActive=false. Instead: log loudly, flip state, reset chunks, notify Flutter, continue processing. Data validation guard (audioChunk, chunkIndex, isLast, sampleRate) preserved above the recovery block. Trade-off documented in commit message (one resurrected chunk in worst-case race vs. indefinite silent drop).

Lifecycle hardening:

• Commit 4: didReceiveApplicationContext dispatches to same handlers as didReceiveMessage, @MainActor correct. Covers the three methods RecorderHostApiImpl sends via context fallback — dead code is now alive.
• Commit 5: sessionDidDeactivate → WCSession.default.activate() — Apple's documented multi-Watch pattern.
• Commits 6-7: Transfer failure + activation logging. Both sides. No app-level retry (correct — system queue handles durable retry).

Pigeon plumbing (commit 8):

• Two new FlutterAPI callbacks (onWatchReachabilityChanged, onWatchStateChanged). Phone-side delegate wires them, Watch-side logs only (no Pigeon on Watch target — correct). Generated code follows existing patterns. Bridge + transport wire-up clean. Debug-log only for now, downstream subscribers noted as out of scope.

Process: 8 atomic commits, each independently revertable. Good commit messages with root-cause context. Labels set (bug, ios, area: Apple Watch). No scope creep — considered and dropped list in PR body is thoughtful.

Needs hardware verification — iPhone + Apple Watch testing per the test plan. The code changes are correct by static review and adjacent-pattern comparison.

[ThomsenDrake]

Closing as stale after confirmed stale-close triage. This PR was identified as high-confidence stale due to age plus one or more of: conflicts, draft/failing status, superseded work, or obsolete architecture. No merge was performed. If the work is still needed, please reopen with a fresh rebase or start from current main.

[github-actions]

Hey @mdmohsin7 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our roadmap and vision

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community! 💜