The industry is going back to native. Your app never had to

An iOS app built with GoodBarber is compiled in Swift. An Android app is compiled in Kotlin. These are the languages Apple and Google use for their own apps, and the result is a real native app: a binary that you submit to the App Store and Google Play, the same way a development agency would. A third engine produces a Progressive Web App for the browser and the desktop. All three are generated from the same back-office: you design your app once, and each engine renders it correctly for its own platform. The full stack is described on our native technology page.

Cross-platform frameworks such as React Native or Flutter take a different route: one shared codebase, rendered on both platforms through an intermediate layer. It is a legitimate approach, and for years it was the pragmatic one for a company building a single app. It is also the one we chose not to take.

When we built our first engines, the question was not which technology produced the best app that year. It was which layer would still be there in ten years. The platforms would: Apple and Google were not going to abandon their operating systems, their tools or their SDKs. Everything in between, the frameworks promising to spare developers the platforms, still had to earn a decade of existence. So we built directly on the layer that was certain to remain, and treated everything stacked on top of it as temporary.

The years that followed tested that reading. Every few years, a new framework was presented as the future of mobile: PhoneGap, React Native, Xamarin, Flutter. We evaluated the most serious ones and passed each time, on the same question of lifespan. Then the answers came in: Adobe discontinued PhoneGap in 2020, Microsoft ended Xamarin support in 2024. The intermediate layer kept changing names. iOS and Android kept theirs.

The bet has a price. Three engines mean three teams, three expertises and three implementations to keep in step, and that is exactly why most companies building a single app could not afford it. A platform can: the engines are built once and amortized across every app it produces. Fifteen years of native app creation rest on that arithmetic, and it is also why the cost never reaches you. The engines, hosting, push infrastructure and store publishing are included in the subscription.

Your app runs on the foundation that Apple and Google maintain themselves, not on a layer whose future depends on a third company's roadmap. When a framework is discontinued, nothing happens to your app. When iOS or Android evolves, our engines adopt the change once, centrally, and your app is regenerated into the new version without you touching anything. An app configured years ago is a current app today.

It also shows in what your users feel, below what most people can name: scrolling that follows the exact physics of the system, transitions that belong to the operating system, haptic feedback, a floating tab bar, a media player that keeps playing when the screen goes dark, local notifications that fire from the app itself when someone enters a geofence, with no server involved. None of this is configured. It comes with the way the app is built, and users sum it up in one word: "professional."

Something changed this year in the way software teams talk about mobile. In September 2026, Shopify announced that all of its mobile apps are moving back to Swift and Kotlin, six years after adopting React Native, and its reason is not that native suddenly got better. It is that AI removed the main reason to avoid it: the cost of building the same app twice. When models and agents handle most of the translation and testing between platforms, the shared codebase loses its economic argument, and the platform's own language becomes the default again.

We never had to make that trip, and the bet paid in a way we had not planned: we expected time to prove it, and the proof came from AI instead. Our Head of Frontend Engineering, Mathieu Poli, tells that story from the inside, including the frameworks we evaluated along the way: Everyone is going back to native. We never left.

Ask one question: what does the platform actually produce? A compiled Swift binary and a compiled Kotlin binary, submitted to both stores under your name, is a different object from a web app wrapped for mobile. Ask to see an app running on a real device, and pay attention to the scroll, the transitions and the tab bar. If the answer is native, you will feel it before anyone explains it.

You can test it yourself: start a free trial, build a first version of your app, and install it on your phone.

Are GoodBarber apps really native?

Yes. The iOS app is compiled in Swift and the Android app in Kotlin, and both are submitted to the App Store and Google Play as real binaries, under your name. The third engine, the Progressive Web App, runs in the browser by design.

Native app or PWA, which one should I choose?

Both come from the same GoodBarber project, so it is rarely one or the other; how to decide between a website, an app and a PWA has its own article. The native apps are the ones your users find in the stores and the ones that give you the platform's own scrolling, transitions and device features; the PWA adds the browser and the desktop.

Does a native app cost more?

Not with an app builder. The engines are built once and amortized across every app on the platform, so their cost, along with hosting, push infrastructure and store publishing, is included in the subscription. The price of building twice only applies to custom development, and it is the reason the industry looked for alternatives.