React Native Development in TypeScript

Start with the managed tooling unless there is a concrete reason not to. It gives you a build service, over-the-air updates, a coherent set of maintained libraries for the things every app needs, and a way to run the app on a tester device without anyone installing Xcode. The historic objection was that you could not add native code, and that is no longer true: you can write a config plugin, generate the native projects when you need them, and keep everything else. The case for a bare project is narrower than it used to be, and it is usually one of these: a native SDK that fights the build system, an existing native app you are adding React Native into, or a client whose own engineers will maintain the native side. We make the call before the first sprint, because moving between the two mid-project is disruptive rather than difficult.

Yes, within limits that are worth understanding before you build a process around it. Because the JavaScript bundle is loaded at runtime, a fix to that bundle can be delivered straight to installed apps and applied on the next launch. Anything touching native code, permissions, capabilities or store metadata still needs a normal submission. The policy line on both stores is that these updates must not change what the app fundamentally is or do things review never saw; bug fixes, copy corrections, layout adjustments and configuration changes are the intended use. Shipping a whole new feature this way to avoid review is a policy problem rather than a clever trick. We also treat an over-the-air update as a real release: staged to a percentage first, monitored, and reversible, because a bad bundle pushed to everyone at once is worse than a bad build.

The logic, not the interface. What shares cleanly is everything below the screen: TypeScript types and the API client generated from them, validation rules, formatting and currency handling, permission and entitlement logic, state management patterns, and the vocabulary your team already uses for all of it. That is a genuine saving and it also removes a class of bug where web and mobile quietly disagree about a business rule. What does not share is the components. Layout, navigation, gestures, keyboard handling and platform behaviour are different problems on a phone, and attempting to run web components on mobile produces something that works in a demo and feels wrong in a hand. The realistic expectation is a shared core package plus a mobile app that looks nothing like the website in code, which is also true of apps built any other way.

Almost always, and it is usually four causes rather than one. Rows that re-render because a new function or object is created on every parent render. Images loaded at full resolution and scaled down by the layout instead of being resized before they arrive. Row components doing work, such as date formatting or filtering, that should have happened once when the data loaded. And a list that measures every row because the heights are unknown, rather than being told them. Fixing those normally gets an ordinary feed to scroll smoothly even on a cheap Android device. When the rows themselves are genuinely heavy, with video, maps or charts, a recycling list implementation with native backing is the next step. We measure this on the slowest device in the agreed matrix, because the problem does not exist on a modern iPhone and shipping without checking is how it reaches your reviews.

Commercially, three things. Startup improves, because native modules are created when they are first used rather than all of them at launch. Interactions that need an immediate answer from the native side, such as measuring a view before drawing, stop having to wait for a round trip across an asynchronous queue, which removes a category of visible flicker and one-frame jump. And the interfaces between JavaScript and native are generated from typed definitions, so a mismatch becomes a build error instead of a crash on a user device. Architecturally it is a rewrite of how the two halves talk to each other. New projects get it as the default and it is not something you decide. For an existing app the work is proportional to how many unmaintained native dependencies it carries, which is exactly the audit we would run before quoting an upgrade.

Plan on a meaningful upgrade roughly once or twice a year, and treat it as scheduled maintenance rather than an emergency. The pressure does not come from React Native wanting to be new; it comes from the platforms underneath. Apple and Google require apps to be built against recent SDKs, each annual OS release breaks something, and the library ecosystem follows the framework rather than your release plan. The cost of an upgrade scales with how far behind you are and how many native dependencies you depend on, which is why sitting still for two years is the expensive option rather than the safe one. Apps on the managed tooling have an easier time of it, because the upgrade is coordinated across a set of libraries that are tested together.