Skip to content
Vijay Gojiya
All services

Native iOS and Android

Native iOS and Android development

Swift and Kotlin, written as Turbo Modules for the New Architecture or as the native half of an app that needs one.

Most React Native work never touches a native file. The work that matters usually does. When the ecosystem has no library for the thing you need, or the library it has is a JavaScript wrapper pretending to be native, someone has to write Kotlin and Swift, and that is the part I enjoy most.

I have published a Turbo Module to npm that renders the Google Places autocomplete interface from Google own Android and iOS SDKs, driven from JavaScript across the New Architecture with no bridge in between. I have written the Android half of a push notification library in Kotlin: permission requests, token registration, and both foreground and background message handling. These were not experiments, they went into shipping apps.

That native layer is also where migrations live. Moving an app onto the New Architecture is mostly a native problem wearing a JavaScript costume, and the libraries that break are the ones with an old-style bridge module underneath.

What you end up with

  • Turbo Modules built bridgeless for the New Architecture
  • Kotlin on Android and Swift on iOS, in the same module
  • Native SDK integrations that the JavaScript ecosystem has not wrapped well
  • Published to npm where it makes sense to reuse
  • Platform release work: signing, capabilities, store review responses

Where this has shipped

Questions

Do you build fully native apps, without React Native?

I can, and I will say plainly where my depth is: five years of it has been React Native apps whose native layer I wrote myself, in Kotlin and Swift, including a published Turbo Module. If you want an app built entirely in SwiftUI or entirely in Compose with no shared codebase, there are people who do only that and you should probably hire one of them. If you want an app that is React Native everywhere it should be and genuinely native where it has to be, that is exactly the work I do.

What is a Turbo Module and why does it matter?

It is the New Architecture way of calling native code from JavaScript: typed through codegen, synchronous where it needs to be, with no serialised bridge in the middle. It matters because the old bridge is being retired, and a dependency that still ships an old-style module is a dependency that will stop your next upgrade. Knowing how to write one is also how you fix one.

Our app is stuck on the old architecture. Can it move?

Usually yes, and the work is more predictable than it sounds. The pattern is always the same: find the dependencies with bridge modules, check whether each has a New Architecture release, replace or rewrite the ones that do not, then flip the flag and fix what falls out. The unknown is the size of that middle list, which is why I audit it before quoting rather than after.

Tell me what you are building.

A sentence about the product and where it is stuck is enough to start. I answer every mail myself, including the ones where the answer is that I am not the right person.