Why every app we make is native

People often ask why a two-person studio would build every app twice. A shared codebase sounds like half the work. For the apps we make, it rarely is, and the reasons are practical rather than ideological.

Two platforms, two specialists #

2MAD Labs is literally two Mobile App Developers: one writes Android in Kotlin and Jetpack Compose, the other writes iOS in Swift and SwiftUI. Each of us works in the language, tools and design conventions of one platform every day. Splitting the work this way means neither of us is translating between platforms in our head, and each app feels at home on the phone it runs on.

What native buys the people using our apps #

• Platform-correct behaviour. Navigation, gestures, text sizes and system settings work the way people already expect on their phone, because we use the platform's own building blocks.
• Performance. A price map with more than a million deals, like the one in Cenilko, has to scroll and zoom smoothly on an ordinary phone.
• Everything the system offers, on day one. Widgets, Wear OS and Apple Watch, Android Auto and CarPlay, TV apps and foldable layouts are available as soon as the platform ships them, without waiting for a wrapper to catch up.

The layouts that make the difference #

Big screens are where native pays off most visibly. On a tablet, Cenilko turns its bottom bar into a side rail and opens a building's report next to the map. On a foldable, half-fold the phone into a tabletop and the map moves above the hinge with the details below it. On iPad, the SwiftUI app gives the map its own half of the screen. None of that is a stretched phone layout.

Where we make an exception #

Games are a different kind of project. When one game should run the same on both platforms, a single Unity codebase can be the right fit, and we use it when it is. For everything else, which is most of what we build, we write each app natively.

What it costs, honestly #

Building natively does mean writing core features twice and keeping two apps in step. We accept that trade because the result is better for the person holding the phone, and because a shared plan, a shared design and shared data formats keep the two versions close. It is also why a new app sometimes reaches one platform before the other.

The same approach applies to client work. If you have a project for phones, tablets, watches, cars or TVs, write to us and we will give you a straight answer about fit and timeline.