entries platform-native · verified 2026-07-10 · react-native

Native UI extensions — Live Activities, widgets, App Clips, portals

draftedconfidence: mediumthis tier holds 50% on the public scorecard (3/19 graded · 0 overturned) →

re-verified 3× — 2026-07-10 · 2026-07-09 · 2026-07-06 · changelog

recommendation

On Expo → expo-widgets for iOS widgets/Live Activities (stable in SDK 56, no native code). Bare RN → Voltra 2 (now bare-RN capable). Custom native targets / App Clips / share extensions → Expo Targets.

iOS widgets / Live Activities on Expo → expo-widgets (SDK 56, stable, no SwiftUI)
Live Activities on bare RN → Voltra 2 (Turbo Modules; no longer Expo-only)
widgets / App Clips / share extensions needing custom native → Expo Targets

Options & tradeoffs

the field considered — and why each one isn’t the default here

option	tradeoff
expo-widgets (Expo)	iOS home-screen widgets + Live Activities from Expo UI components — no SwiftUI/native code; STABLE in Expo SDK 56 (alpha in SDK 55); full env access, no pre-render
Voltra (Callstack)	Live Activities + widgets; SwiftUI-style layout (VStack/HStack); v2.0 (2026-06-18) rewrote to Turbo Modules → now works in BARE RN (no Expo Modules); iOS 16.2+ (interactive 17+), iOS 18+ activity families; v2 migration required
Expo Targets	native targets (widgets, App Clips, share extensions) in Swift/Kotlin or RN; multi-step setup
react-native-teleport	portals rendering in the native layer (re-parenting); web + native

Verified notes

Settling but still iOS-leaning. VERIFIED (2026-06): expo-widgets is STABLE in Expo SDK 56 (alpha in SDK 55) — iOS widgets + Live Activities from Expo UI components without SwiftUI; Voltra 2.0 (2026-06-18) rewrote onto Turbo Modules and now runs in BARE RN (dropped the Expo-Modules / Dev-Client requirement; v2 migration required). Android widgets and the portal/other options remain less settled — prototype platform coverage before committing. EXPO UI + WORKLETS (2026-07-10, verified vs the post's og:description): Expo UI integrates react-native-worklets — SwiftUI and Compose state can be driven SYNCHRONOUSLY on the UI thread, no JS round-trips; relevant when native-UI surfaces must track gestures/animation.

Canonical reading

Editorial annotations on why each piece matters — the articles themselves are the originals; read them there.

Apple Home Screen Widgets with Expo (Continuous Native Generation)Evan Bacon (Expo)

Generating native Apple widget targets from Expo via CNG — pbxproj manipulation to keep SwiftUI targets editable yet outside /ios, App Group / NSUserDefaults data sharing, CSS-to-colorset conversion. The foundational mechanism behind Expo Targets / expo-widgets.

Using Live Activities in a React Native AppMichael Hayes (Add Jam)

End-to-end Live Activities in RN — the ActivityKit Attributes/ContentState model, a separate widget-extension target for Lock Screen + Dynamic Island, a native module bridging JS↔Swift, and the HTTP-refresh vs APNs-push tradeoff. Platform constraints that outlast any single library.

How we built the v0 iOS app (React Native + Expo)Fernando Rojo (Vercel)

Production case study of making RN feel truly native on iOS: Liquid Glass via @callstack/liquid-glass, native menus via Zeego/UIMenu, patching RCTUITextView for platform-correct text behavior, ~1,000 lines of keyboard logic on react-native-keyboard-controller (see RB-E-KEYBOARD), synchronous New-Arch measurements, LegendList — and the share-types-and-logic-not-UI lesson. What 'native feel' actually costs and where the wins come from.

Watching

Curated talks, podcasts & videos — the A/V companion to the reading list.

Building v0 iOS and Fixing React Native Along the WayFernando Rojo, Szymon Rybczak & Oskar Kwaśniewski

The v0 iOS team on what shipping a native-feel RN app took — including the upstream RN fixes it produced. Video companion to the v0 case study in `reading`.

Sources

Related in platform-native: native · media · storage · keyboard · payments · brownfield · games · alt-frameworks