React Native developer for apps that already exist
I take over running React Native codebases: wire up native modules, fix render and performance problems, move the React Native version forward and get releases to the Play Store and App Store working again.
- React Native
- TypeScript
- Native Modules
- Play Store
- App Store
Built for teams with code already running
Most requests do not arrive at the start of a project. They arrive in the middle: the app is live, the developer who built it has moved on, and nobody on the team wants to touch the native side. That is the situation this page is written for.
What usually blocks a React Native app
None of this is exotic. These are the reasons a working app slowly turns into one nobody dares to release.
The native side is a black box
Between JavaScript and Kotlin or Swift sits a layer nobody on the team wants to open. Camera, Bluetooth, background work or a vendor SDK end up parked on the backlog instead.
Lists stutter on real hardware
Too many re-renders, long lists and badly loaded images do not show up in the simulator. They show up on a three year old Android phone in a user's hand.
The upgrade keeps getting postponed
Every skipped React Native version makes the next jump larger. Eventually the old version is exactly what blocks the library you actually need.
The release is stuck
A rejected build, an expired certificate, a missing privacy entry. The route into the Play Store and App Store rarely fails on the code itself.
A handover without documentation
The previous developer is unreachable and the repository does not explain itself. Until somebody reads it properly, every change is a gamble.
Android and iOS drift apart
One codebase does not mean two identical apps. Permissions, keyboard behaviour, safe areas and push notifications differ per platform and have to be tested on both.
Work on React Native itself
This page is about React Native, not the tooling around it. If your app runs on Expo, the Expo developer page is the right one: it covers EAS Build, over the air updates and SDK upgrades.
Taking over a codebase
I read what is there, build the app locally, write down how to get started and report back what is healthy and what is not. Changes come after that, not before.
Bridging to native code
Native modules in Kotlin or Swift, vendor SDKs, permissions and background tasks. What React Native does not ship gets added natively instead of worked around.
Performance and render behaviour
Measure instead of guess: render cycles, lists, images and navigation profiled on real devices, then fixed where the time is actually spent.
React Native version upgrades
A stepwise move to a current version including libraries and the native project files, with a full pass on both platforms before anything ships.
Play Store and App Store releases
Signing, store listings, test tracks and review. The release is reproducible instead of depending on one particular laptop.
Native Android where it fits
Next to React Native I work with Kotlin and Jetpack Compose every day. Parts that belong in native code get written there and wired in as a module.
From the first look at the code to a build in the store
Four steps, with no discovery phase that bills for months. If you need someone around after the release, ongoing app maintenance is the arrangement for that.
Read the code
You give me access to the repository. I build the app and go through structure, dependencies and the native projects.
Written findings
You get a short written assessment: what blocks you, what costs time, what is worth doing first. The quote follows from that.
Implementation
Small steps on their own branches, each one buildable and testable on a device. You see progress instead of status emails.
Release and handover
Publishing to the Play Store and App Store, handing over the credentials and writing down how the next build runs without me.
Send the code, not just the requirements
Repository access or a few screenshots of the problem is enough to start. You get an honest read on what is feasible, where the effort sits and what I would advise against.
Questions about React Native work
Yes, that is the most common request. It starts with a pass through the existing code: building the app locally, going through dependencies and the native projects, listing what is open. You get that in writing before a single line changes.
Usually the upgrade. A rebuild throws away logic that already works and has been tested in production. The jump runs step by step through the intermediate versions, library by library, with a pass on both platforms before release. A rebuild is only the honest answer when the native side has been modified so heavily that no safe upgrade path is left.
Both, daily. Expo specific topics such as EAS Build, over the air updates and SDK upgrades live on the Expo page. This page is about React Native itself: native modules, performance, version jumps and the route into the stores.
Yes. Next to React Native I work with Kotlin and Jetpack Compose, and I have published several Android apps for business clients. When part of an app belongs in native code, it gets written there and wired in as a module.
That depends on the state of the code, so there is no number on this page. After the first pass through the repository you get a quote with a fixed scope for the next step instead of a guess.
Yes. I work remotely from Germany, so European business hours overlap completely. English is fine for calls, code review and written handover.
Let's build something great together.
Have a project in mind? I'd love to hear about it. Send me a message and I'll get back to you as soon as possible.
