Release 0.2.2
0.2.2 (2026-07-28)
Bug Fixes
- gate animation start on displayability; re-latch on last unregister (5a660a7)
0.2.1 started a held animation at the first registerView. Live diagnosis
proved that is still too early: a Core Animation animation committed while
the host's layer tree is detached from the render tree does not survive the
later attach commit. RNScreens presents transparentModal view controllers
asynchronously (even with animation: 'none'), so the install was stripped
~one frame after the window attach and the layer snapped to its model
values — the target. The symptom was byte-identical to the pre-0.2.1 bug.
Animations now hold until a registered view can actually display — layout
plus a window on iOS, attached plus real host geometry on Android — and
start inside the attach commit with a rebased clock, so the first visible
frame is t=0 of the full duration.
Fixed alongside, both platforms:
- last-participant unregister mid-flight re-latches the remainder (start =
the departing view's visible geometry, duration = remaining) instead of
completing at the target, so a re-registering host resumes rather than
snaps; - a take-ownership seed no longer cancels a held latch — a held latch is
strictly newer intent than any value the seeder read; - frozen presentation skips unlaid-out views, so freezing beside a
zero-geometry peer can no longer collapse the clip; - detached relayout and the keyframes install path defer on the same
displayability gate.
Public API unchanged. Full write-up, including the addendum covering this
release, in docs/pending-animation-latch.md.