Skip to content

Re-wire the Spotlight deep-link reveal onto the UIKit timeline#136

Merged
Considus merged 1 commit into
mainfrom
fix/spotlight-deeplink-reveal
Jul 23, 2026
Merged

Re-wire the Spotlight deep-link reveal onto the UIKit timeline#136
Considus merged 1 commit into
mainfrom
fix/spotlight-deeplink-reveal

Conversation

@Considus

Copy link
Copy Markdown
Owner

Summary

Completes the parked mid-point-review item: tapping a Catchlight result in iOS Spotlight now navigates to the Take.

  • The UIKit timeline consumes ui.spotlightTargetTakeID: scrolls the row to centre, pulses the card with the ember accent (same 0.18 treatment as the old SwiftUI flash), then clears the one-shot state — so a re-tap on the same Take re-targets (the old path never cleared it).
  • A reveal set before the data exists stays pending and resolves when the row appears — which fixes the most common flow: a cold Spotlight tap lands on the locked app, where the old existence check silently dropped the target; it now defers the check and navigates after Face ID.
  • The pinned Obie (not a collection row) keeps its existing flash path, now with the missing clear.
  • No accessibility-contract changes; render-only overlay.

Tests

  • Local simulator build clean; CI runs the full XCUITest matrix (a11y ids untouched).
  • Flagged for device review: scroll landing position, pulse visibility in Night/Daylight, and the locked → unlock → reveal flow (Spotlight is a system surface — sim is not faithful for the end-to-end tap).

🤖 Generated with Claude Code

…6.19)

The M7 rewrite left ui.spotlightTargetTakeID dangling: only the pinned-Obie
row path still read it (flash only, never cleared), the collection never
consumed it, and no scroll-to-item existed — a Spotlight tap opened the app
and visibly did nothing.

- UIKitTimelineViewController gains requestReveal/attemptReveal: scroll the
  target row to centre, pulse the card ember (flashingID -> reconfigure ->
  cell overlay, 0.4s ease both edges), then fire onRevealHandled so the host
  clears the one-shot state. A reveal whose row isn't in the snapshot yet
  stays pending and resolves on a later apply.
- TimelineReadCell/TimelineSwipeCell thread isSpotlightTarget; the overlay is
  render-only (same ember 0.18 treatment as the old row flash).
- DailiesView passes the target (filtering out the pinned Obie, which is not
  a collection row) and clears the Obie case itself after its rowContent
  flash pulses.
- handleSpotlight: the existence check only runs while UNLOCKED — a cold
  Spotlight tap lands on the locked app where the store is the empty
  placeholder, and the old guard silently dropped the target, so the most
  common path (tap -> Face ID -> timeline) never navigated. The pending
  reveal now resolves after unlock; a deleted Take's reveal simply never
  fires.

Needs device review: scroll landing position, pulse visibility both modes,
and the locked -> unlock -> reveal flow.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@Considus
Considus merged commit 851bce3 into main Jul 23, 2026
4 checks passed
@Considus
Considus deleted the fix/spotlight-deeplink-reveal branch July 23, 2026 19:13
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