Problem
When building a conversation feed where multiple cards come from the same provider (e.g., a weather skill rendering 5 forecast cards), each card currently spins up its own Hermes VM on iOS. That’s 5 isolated VMs for content that could safely share one.
On Android, this is already solved — sandboxes with the same origin prop share a single ReactHost and Hermes VM via SharedReactHost. The first card pays the cold start cost, and every subsequent same-origin card gets a warm start by creating only a new Fabric surface on the existing VM.
In a POC on iOS (Release build, iPhone 17 Pro simulator), we measured a 89ms cold start for a new VM vs a 4ms warm start when sharing a VM via a prototype factory pool. That’s a 22x difference per card. In a feed with 10 cards across 2 origins, the memory impact is equally stark — roughly ~70 MB (10 VMs) vs ~29 MB (2 VMs + 8 surfaces).
The POC demonstrated that sharing works at the VM/surface level, but event routing (onMessage, onError) only reaches the first view’s delegate — the same limitation described in the companion issue for Android event handler routing.
Expected behavior
Two sandboxes with origin="weather" should share a single Hermes VM on iOS, just like they do on Android. The second card should mount in ~4ms, not ~89ms. Memory should scale with the number of unique origins, not the number of visible cards.
Additional context
The origin prop already exists in the codegen spec and is passed through to the iOS native layer. The gap is in the iOS component view and delegate — there’s no pooling or sharing mechanism keyed by origin today.
Environment
| Field |
Value |
| react-native-sandbox |
0.6.0 |
| React Native |
0.80.1 |
| Platform |
iOS |
Problem
When building a conversation feed where multiple cards come from the same provider (e.g., a weather skill rendering 5 forecast cards), each card currently spins up its own Hermes VM on iOS. That’s 5 isolated VMs for content that could safely share one.
On Android, this is already solved — sandboxes with the same
originprop share a singleReactHostand Hermes VM viaSharedReactHost. The first card pays the cold start cost, and every subsequent same-origin card gets a warm start by creating only a new Fabric surface on the existing VM.In a POC on iOS (Release build, iPhone 17 Pro simulator), we measured a 89ms cold start for a new VM vs a 4ms warm start when sharing a VM via a prototype factory pool. That’s a 22x difference per card. In a feed with 10 cards across 2 origins, the memory impact is equally stark — roughly ~70 MB (10 VMs) vs ~29 MB (2 VMs + 8 surfaces).
The POC demonstrated that sharing works at the VM/surface level, but event routing (
onMessage,onError) only reaches the first view’s delegate — the same limitation described in the companion issue for Android event handler routing.Expected behavior
Two sandboxes with
origin="weather"should share a single Hermes VM on iOS, just like they do on Android. The second card should mount in ~4ms, not ~89ms. Memory should scale with the number of unique origins, not the number of visible cards.Additional context
The
originprop already exists in the codegen spec and is passed through to the iOS native layer. The gap is in the iOS component view and delegate — there’s no pooling or sharing mechanism keyed by origin today.Environment