React Native apps your own team can maintain.

Usually not, and that is the strongest argument for React Native rather than against us. A team already writing React reviews the same language, the same state model and often the same API client, so the app joins what they maintain instead of becoming a second thing to staff. What they will not have done before is the store pipeline, the signing, the native modules at the seam and the review process, which is a well-bounded piece of work rather than a permanent role. We build that part, hand it over, and watch your team cut a release before we go.

The language, the state model, the business rules and usually the API layer. What does not transfer is every screen, because a web layout and a mobile one are different products, and anything that touches the device, which has to be written natively on each platform. The saving is real and it is smaller than a single-codebase pitch implies, so we list what transfers line by line before quoting rather than after. If the web product itself is the thing that needs work first, that is a different engagement.

Fixes, yes. Changes to what the app does, no. Apple’s App Store Review Guideline 2.5.2 states that an app may not download, install or execute code which introduces or changes features or functionality of the app, and that line is the boundary every over-the-air pitch in this market leaves out. In practice it means a broken screen or a wrong string is a same-day rollout, and a new feature is a submission. We agree which is which in writing before the release plan is built, because the alternative is discovering it inside a rejection.

Yes, through native modules, and the work is native on both sides of the bridge. A wallet is reached through a module written in Swift on iOS and Kotlin on Android, and the national identity sign-in is an app-switch that registers your own URI scheme and hands over to another application. On Android that also needs the manifest to declare what the app wants to see. The approval to use national identity sign-in sits outside the build entirely, and the Dubai page sets out what it waits on.

Yes, and the mirroring comes from the platform rather than from the framework, which is the practical difference here. Because React Native renders the operating system’s own components, the platform rules apply directly, so the Android manifest flag and its mirrored resources still matter and styles have to use start and end rather than left and right. That also means a direction fault can look different on each platform and has to be seen on both. A framework that draws its own pixels handles this differently, and that model is set out on the Flutter page.

Usually, and the code is rarely the hard part. Dependencies years behind are a week or two of work, and an undocumented codebase is readable by anyone who writes React. What actually blocks a takeover is access: the store accounts, the signing keys and the update channel, which frequently left with the person who set them up. We establish what you can still reach before quoting anything, because a rebuild and a recovery are very different numbers and only one of them is usually necessary.

More than one salary, which is the number most plans use. One developer cannot review their own work, cannot cut a release while on leave, and takes the whole project with them when they go, so a sustainable in-house capability is two people rather than one. That is easy to justify when there is a pipeline of product work to keep both busy, and hard to justify for a single app that changes a few times a year. Where it does not add up, extending a React team you already pay for is the smaller structure and the sturdier one, and the framework decision itself sits with the hub page.