The problem: an SDK is not an app
Most React Native tutorials teach you to build a standalone app. You control the root navigation, the splash screen, the lifecycle — everything. But what happens when your React Native code has to live inside someone else's native app, one you don't control and definitely can't crash?
I was the sole frontend developer on this: architecture, performance, and shipping were entirely on me, working closely with Kwaaka's backend team and Onay's iOS/Android engineers who wired the SDK into their production app.
Why React Native (and not native-native)
Kwaaka's whole product suite runs on React on the web. Choosing React Native meant the team could share mental models and logic between web and mobile without hiring separate iOS/Android frontend specialists. State management ran on Effector — again, for consistency with Kwaaka's web stack, plus it's well-documented and widely used across the CIS developer community. In my experience, Effector is a genuinely simpler and more modern state manager than old-guard Redux (or Redux Toolkit, for that matter) — no action types to name, no reducers to switch over, no selectors to memoize by hand. You just declare events and stores, and derive everything else from them. Less boilerplate, less ceremony, and the dependency graph between stores stays explicit instead of hiding behind connect() or useSelector. Farfetched sat on top of Effector to handle caching, retries, and stale-while-revalidate out of the box.
