Developing an application separately for iOS and Android means maintaining two implementations. For years, sharing code has allowed teams to spend more of their budget on features and ongoing improvements. Coding agents can now reduce the cost of some of that work. The technical choice deserves another look.
At Appik, we see this change as another option for mobile projects. Our experience with native development, React Native and the web helps us compare approaches against the product, its users and its maintenance needs.
Shopify and Coinbase reassess mobile development
On 10 September 2026, Shopify announced its return to Swift and Kotlin. Agents have changed the cost of maintaining two implementations. The company says its React Native apps are fast and the framework delivered the benefits it expected.
Coinbase describes an AI-assisted rewrite of its mobile application in Swift and Kotlin in an official job listing. This is an ongoing project, not an announcement of a completed migration.
These decisions raise a useful question for product leaders. If building and evolving two versions becomes less expensive, which platform-specific benefits justify that investment for our application? The answer also depends on the teams and resources available.
Why Appik adopted shared code
Before working with React Native, we were already developing native iOS and Android applications. Sharing code addressed a concrete problem. A feature delivered on one platform often had to be rebuilt on the other, then evolve in the same way.
Sharing code reduced this repetitive work while keeping applications performant. Depending on the user journeys, some business rules and components could also be used on the web. Platform-specific adaptations were still necessary.
For an SME that needs to provide a tool on phones and computers, this approach still has value. The budget can go towards improving workflows in the field, connecting the ERP or preparing another team to take over the product. The percentage of shared code is a means to an end. The goal is a usable product that can be maintained over time.
React Native can deliver excellent performance
A React Native interface is not a web page placed inside an application. The React Native architecture connects React to native components and capabilities. The choice of rendering tools and the way computations are organised then matter a great deal.
Skia and Graphite for graphics rendering
React Native Skia uses the Skia C++ graphics engine and its JSI integration. It can draw interfaces, charts and effects on a canvas without asking JavaScript to calculate every pixel.
Version 3.0.2 in William Candillon's repository, released on 3 October 2026, makes Graphite the default API. This change applies to the new v3 branch. It does not mean that all applications using older versions have switched engines.
Google describes Graphite as an architecture suited to modern GPU APIs, which allows graphics work to be prepared with independent recorders. It has practical value for custom rendering. Adoption should be tested on the target devices.
Reanimated for interactions and animations
Reanimated runs worklets on the UI thread. Animation logic can therefore run without waiting for the main JavaScript runtime to finish another task.
This provides tools suited to dragging a map, interacting with a chart or controlling a transition with a gesture. However, the Reanimated performance guide points out that versions, animated properties and the number of components affect the result. A library does not automatically fix a resource-intensive architecture.
Worklets to put computations in the right place
React Native Worklets distinguishes between RN, UI and Worker runtimes. Some JavaScript functions can run in a dedicated runtime, for example to process data. They do not become Swift or Kotlin code as a result.
The aim is to prevent a computation from monopolising the resources needed for interaction. Exchanging data between runtimes also has a cost. Moving all the work without measuring would be a poor strategy.
Legend List for long lists
Legend List v2 uses virtualisation and offers component recycling. Scrolling can reuse elements instead of recreating them. Its published benchmarks compare React Native list solutions. They do not establish an advantage over every native list.
These tools matter for a message feed, a catalogue or a list of service visits. Oversized images or rows that constantly recalculate their content can still make scrolling less smooth.
Can React Native outperform a native implementation?
Yes, on a particular user journey. A React Native rendering approach that uses a C++ engine and the GPU can require less work than another implementation of the same screen built around many components and updates. This is a technical possibility to measure, not a result we promise for every project.
Swift and Kotlin can also use the GPU and specialised engines. The tools discussed here mainly show why a language or framework alone cannot predict how smooth an application will be.
To compare two options, we use the same interactions, content and devices, with production builds. We examine response time, dropped frames during scrolling, startup, memory and energy consumption. A smooth screen on a high-end phone does not prove that the whole application meets the needs of users in the field.
AI expands the options, including for React Native
Agents can help adapt a feature, prepare tests and propose an implementation on another platform. In our work, they are also very useful with React and React Native. We cannot confidently attribute this effectiveness to the volume of their training data, which we do not know.
The economic question concerns the cost of the product over time. Two native applications still require testing, releases and monitoring of operating system changes. A shared codebase also requires work on dependencies, native parts and platform differences.
An organisation equipped to maintain two versions can benefit more from direct access to Apple and Google tools. A team that needs to deliver on mobile and web may favour shared code. An existing React Native application that meets users' needs deserves an assessment before a rewrite is funded.
Bonani and our native development work
We developed Bonani, a small birthday notebook, natively for iOS and Android. Its limited scope lets us explore this approach in a concrete product, with local data, access to contacts and reminders.
Bonani uses SwiftUI and SwiftData on iOS, and Kotlin, Jetpack Compose and Room on Android. The interfaces are separate, but the rules and test examples remain shared. A birthday without a year does not produce an age. A 29 February birthday stays recorded as such, even when its reminder falls on 1 March.
Bonani does not provide a performance benchmark against React Native. Its limited scope does not allow us to draw conclusions for a large enterprise application.
At Appik, we want to use the experience accumulated over the past ten years to choose the right stack for each project, with support from agents. The team remains responsible for architecture, validation on devices and production releases.
Which approach suits your application?
Are you planning a mobile application or looking to evolve an existing product? Contact Appik to discuss it. We can review your use cases, integrations and the constraints that guide the choice between native development, React Native and the web.
Sources and references
- Shopify · Return to native
- Coinbase · Mobile rewrite in progress
- React Native · Architecture
- Shopify · Skia, C++ and JSI
- React Native Skia · Graphite default in v3.0.2
- Google · Graphite graphics architecture
- Reanimated · Animations and worklets
- Reanimated · Performance guide
- React Native Worklets · RN, UI and Worker runtimes
- Legend List · Virtualization, recycling and v2 benchmarks
Swiss Made Software
