Native App.

'Native' means something like 'in its own language'. A native iOS app speaks Apple's language, uses its interface elements and is built with Xcode; a native Android app uses Google's tools. The result feels natural on the respective device: gestures, fonts, menus and system functions behave the way users are used to on their phone. A native app also has access to everything the device offers, from the camera and background location to widgets on the lock screen.

The most important practical advantage is often offline operation. A native app can store data locally, keep working without a network and synchronise changes with the server later. For field service, trades, logistics or care, where people work in basements, on building sites or in buildings without reception, this is often the reason for a native app. A progressive web app can cache content, but it reaches its limits with extensive data entry without a network.

The downside is effort and maintenance. Serving both iPhone and Android natively means two codebases. Every new version has to pass review by Apple or Google. And every year new operating systems are released, to which an app has to be adapted. Then there are fees: Apple charges an annual fee for its developer programme, Google a one-off registration for the Play Console.

Between the native app and the web app sits the cross-platform app, built with frameworks such as React Native or Flutter from one codebase for both platforms. It saves effort but depends on the chosen framework. Which of the three variants fits depends less on the technology than on where and under what conditions the app will be used. The in-browser alternative is the web app; a comparison of both routes is on the page app development Zurich.