App development in Zurich.

For most businesses a progressive web app is the right start; you need a native app when offline operation, heavy use of device features or the app store are central. The third option, a cross-platform app, sits between the two and is mainly worth it when iPhone and Android must be served equally well from day one.

Progressive web app (PWA). Technically a web app that can be added to the home screen from the browser, starts without a browser bar and can receive push notifications. On the iPhone, web push has worked since iOS 16.4, but only once the app has been added to the home screen. You have one code base for every device, updates reach everyone immediately, and there is no store review.

Native app. An app written in the platform’s own language — for iPhone and iPad today mostly Swift with SwiftUI, for Android Kotlin. It is installed from the App Store or Google Play, has full access to camera, location, widgets and background services, and can work reliably without a connection. The price: a separate development track per platform, and adjustments with every major operating system release.

Cross-platform app. One code base that frameworks such as React Native or Flutter turn into an iPhone and an Android app. It saves effort compared with two native apps, but adds a dependency on that framework. It makes sense when both platforms matter and the app needs no unusual device features.

Our recommendation in most cases: start with a web app that works properly on the phone and can be installed as a PWA. If day-to-day use shows that offline operation or device features are missing, the native app follows on the same data basis. That is exactly how it went at Karo Kanaltechnik.

Two projects show the two routes: a native iOS app for technicians without reception, and a PWA for a restaurant that wants every reservation on the phone immediately. Both sit on a web app of their own with a database, as almost every business app does.

Karo Kanaltechnik: native app for iPhone and iPad. For this drain-services company we built operations software in which the office, technicians and clients work on the same data. On top of it sits an iOS app written in SwiftUI for iPhone and iPad. Under “My day” a technician sees the day’s jobs, picks the route and fills in the job report with a six-step assistant: done, services, photos, price for the customer, signature, send to the office. Because technicians often work in shafts and basements without reception, the app stores every change locally and sends it once there is a connection again. The app is built and in testing via TestFlight. More in the Karo Kanaltechnik case and under software for trades businesses.

Han Kitchen: a PWA with push instead of an app store. The Korean-Japanese restaurant in Zurich-Oerlikon takes reservations through its own website. The admin, “HK Reservationen”, is an installable web app: it sits on the home screen of the phone, and every new reservation or message triggers a push notification as well as an email. A native app would only have added store review and double maintenance without any extra benefit. More in the Han Kitchen case and under restaurant booking system.

We only show screens from live operations with the data made unrecognisable. We do not quote download or usage figures, because the iOS app is still in testing.

With us a prototype or MVP starts from CHF 10,000; what an app costs beyond that is driven mainly by platforms, offline needs, roles and interfaces — not by the number of screens. A reliable figure for a finished app can only be given by someone who knows the workflows. Flat prices from online calculators say little, because they usually leave out the back end.

Platforms. A PWA is one project for every device. A native iPhone app is a second project, an Android app a third. Cross-platform reduces that without removing it, because testing, store listings and approvals still happen per platform.

Offline operation. An app that only displays data is quick to build. An app that captures data without a connection and syncs it with the server later needs well-thought-out conflict handling: what happens when two people change the same job while one of them is offline? That part is often the most demanding.

Back end and interfaces. Sign-in, roles, database, file storage for photos and the link to accounting or ERP are the invisible part of every business app. At Karo the web app and the iOS app share one back end, which makes the second interface far cheaper than building from scratch.

Running costs. Apple charges an annual fee for its developer programme, Google a one-off registration. On top come hosting, updates for new operating system versions and bug fixes. We bill operation and further development by effort or through a monthly allowance. An overview of software costs as a whole is on software costs in Switzerland.

In five stages: workshop, clickable draft after one week, beta with real users, test distribution and store approval, then operation. After every stage you hold a result in your hands and can decide whether to continue.

In the workshop we talk to the people who will use the app every day: where are they standing when they open it? Are they wearing gloves, do they have a hand free, do they have a signal? The result is a one-page concept with workflows, roles and a clear split between “must be there at launch” and “can come later”. For a native iOS app, selected people test the beta through TestFlight, Apple’s channel for test versions; on Android through the Play Console’s internal testing track. Only once everyday use shows that the app holds up do we submit it for review by Apple and Google.

One thing specific to internal apps: not every app has to be public in a store. Apple offers separate distribution routes for company apps, and a PWA sidesteps the question entirely. We settle which route fits at the start, because it determines which kind of Apple account you need.

A good app developer first asks whether you need a native app at all, puts the rights to the source code in writing and registers every account to your company. Those three points decide your freedom of action in five years’ time more than the design of version one.

• They also advise against. Whoever quotes a native app for two platforms for every idea earns from your extra effort. Ask when the provider recommends a PWA.
• The accounts are yours. Apple developer account, Google Play Console, code repository, database and domain are registered to your company, and the developer is invited. Otherwise switching provider is barely possible.
• The rights are settled. The contract states that the custom source code belongs to you, including the right to modify it. Background on custom software in Switzerland.
• Operation is planned for. New versions of iOS and Android appear every year. An app with no maintenance budget eventually stops working properly. Ask about the update model.
• Data protection is built in. Where is the data stored, which third-party services are inside the app, and what does the privacy statement in the store listing say? Switzerland’s revised Data Protection Act applies to apps too.

And an honest positioning: we are a small digital agency with our own development team, and the native Karo app is our first and still in testing. Our strength is apps tied closely to how a business operates and built on a web app of their own. For games, apps for a mass audience or projects that tie up a large team for years, we recommend specialised studios.