Skip to content

FAQ

No. SymbioteNative drives React Native Fabric and paints real native iOS and Android views.

No. The native stack stays stock React Native: Fabric, JSI, Yoga, Hermes, and the platform hosts remain ordinary dependencies. SymbioteNative replaces the JavaScript renderer path that talks to Fabric.

Does SymbioteNative support React Native’s New Architecture?

Section titled “Does SymbioteNative support React Native’s New Architecture?”

It requires it — there is no other option. SymbioteNative’s renderer talks directly to global.nativeFabricUIManager, the JSI-bound mutation API the New Architecture’s Fabric renderer exposes (createNode, cloneNodeWithNewProps, completeRoot, …). That API doesn’t exist under the legacy bridge, so there is no old-architecture fallback to support — SymbioteNative is built on Fabric from the ground up, not migrated onto it. Any React Native version and toolchain that runs Fabric (0.76+ with the New Architecture on by default, or an earlier version with it explicitly enabled) works; anything still on the legacy renderer does not.

Why does the app still depend on react-native?

Section titled “Why does the app still depend on react-native?”

react-native is the native runtime singleton and Metro/native version anchor. Apps should pin it explicitly at the top level. SymbioteNative hides most imports from app code, not the runtime dependency from the app manifest.

Does a wrapper package like Haptics or Sensors need setup?

Section titled “Does a wrapper package like Haptics or Sensors need setup?”

One step, once per app: add @symbiote-native/expo-modules-link to dependencies and "postinstall": "symbiote-expo-link" to scripts. Every wrapper package you install afterwards is picked up on the next install. Skip it and the JS imports still resolve — the app fails later, at runtime, with Cannot find native module '<Name>'. Full setup: Wire up an Expo native module.

No. A third-party React Native package that exports a JavaScript React component still calls React hooks or uses the React dispatcher internally. Non-React adapters need a native-view wrapper over the underlying Fabric view instead.

Why are Vue events not identical to React props?

Section titled “Why are Vue events not identical to React props?”

Because Vue users should get Vue APIs. React uses callback props such as onValueChange; Vue exposes typed emits such as @value-change. The native payload and shared logic can be the same while the framework contract differs.

Yes — it’s on the landing page’s live framework switcher alongside React and Vue, with its own guide, demo GIF, and API reference, and wrapper packages like Slider ship an Angular build too. One thing is still catching up: Angular has its own real-device Detox e2e suite, but doesn’t yet share the identical canary-journeys spec file that React and Vue run byte-for-byte. See the status page for the exact line.

Yes. It’s a DOM shim over stock compiled Svelte output driving the same engine, with full component parity against React, Vue, and Angular, verified on-device on iOS and Android (examples/svelte). The Slider wrapper package ships a Svelte build too, and it’s on the landing page’s live framework switcher alongside React, Vue, and Angular. Two things are still catching up: a recorded demo clip for the landing page’s demo grid, and its own learn guide page.

Can I use Svelte stores, Context, or svelte/motion/svelte/easing in a SymbioteNative app?

Section titled “Can I use Svelte stores, Context, or svelte/motion/svelte/easing in a SymbioteNative app?”

Yes, almost all of Svelte’s own runtime works completely unmodified. svelte/store (writable/readable/derived), svelte/easing, svelte/motion, svelte/events, svelte/attachments, and nearly all of svelte/reactivity (SvelteMap, SvelteSet, SvelteDate, SvelteURL, createSubscriber) are pure JavaScript with zero DOM dependency, so the DOM-shim adapter never gets in their way. Context (setContext/ getContext) also works as-is — @symbiote-native/navigation’s Svelte port uses it internally to hand each mounted route its own navigation scope.

Only two members are browser-only and rejected at build time: svelte/reactivity/window (reads window.innerWidth/scrollY/etc, which React Native never defines — use innerWidth/innerHeight/outerWidth/outerHeight/devicePixelRatio from @symbiote-native/svelte instead) and MediaQuery from svelte/reactivity (built on window.matchMedia — use orientation, createWidthQuery, or useColorScheme from @symbiote-native/svelte instead).

Can I use <svelte:window>, <svelte:document>, <svelte:body>, or <svelte:head>?

Section titled “Can I use <svelte:window>, <svelte:document>, <svelte:body>, or <svelte:head>?”

No — all four fail the build (and are flagged live by svelte-check/the editor) with an explicit error, rather than silently compiling into something that does nothing on native. Use the matching runtime module instead:

  • <svelte:window bind:innerWidth> / bind:innerHeightuseWindowDimensions() from @symbiote-native/svelte (const windowSize = useWindowDimensions(), then read windowSize.current.width/.height).
  • <svelte:document bind:visibilityState>AppState from @symbiote-native/svelte (AppState.currentState, AppState.addEventListener('change', handler)).
  • <svelte:body> — no equivalent; there is no native page body to bind listeners to.
  • <svelte:head> — no equivalent; native apps have no page head.

No code exists yet. The architecture is built for thin adapters over the same shared engine, so it fits the same long-term model React, Vue, Angular, and Svelte all proved out, but it stays in architecture diagrams and roadmap text only until that work starts.