iOS and Android app development for businesses

The first question we ask is not what to build the app with, but what people will open it with. An app costs money to build, to get through store review and to maintain on two platforms. If users would in practice still open a browser, that money creates no value.

Our own operations system shows this. In a 30-day count on 5 September 2026 there were 403 clock-ins, and 91% of them came from a web browser. Staff work at computers and clock in there. So we usually build the web version of a business system first, and add an app for what phones do better.

An app is worth building when at least two of these hold: people open it several times a day; push notifications are central to the work; or it needs device features such as the camera, location, Face ID, barcode scanning or background processing.

We chose native for our own software: the iPhone app of our operations system is written in SwiftUI for iOS 17 and later with no third-party libraries, and the Android app is written in Kotlin with Jetpack Compose and distributed internally. Native has a cost too: two native apps mean every change to the business rules is made twice. For a company building its first app and needing both platforms, we usually propose React Native or Flutter instead.

Publishing is often underestimated in quotes and is where many delays arise. We set up the Apple Developer and Google Play accounts in the company's name from the start, because moving an iPhone app from a personal account to a company account forces every user to uninstall and reinstall it.

• Internal test builds before submission (TestFlight on iPhone, internal testing track on Google Play).
• Store listing: name, description, keywords and screenshots for each device size.
• A public privacy policy that matches the data the app really collects, and the stores' privacy declarations.
• A test account and instructions for the reviewer when the app needs a login.
• Time in the plan for a rejection; the usual causes are missing test accounts, unclear permission explanations, or an app that is only a website.

The part users see on the phone is only one part of the project. A quote that counts only screens is incomplete.

• The mobile app: screens, sign-in, push notifications and behavior when offline.
• Server and API: data storage, permissions, notifications and connections to other software.
• A web admin area where your staff manage content, orders and users.
• Integrations such as domestic payment, maps, delivery providers, and the sales or accounting software you already use.
• Store submission and listings on both stores.
• Measurement: active users, abandoned flows and crash reports.

If you already have a web system, the app should share its server and data. That is how our own system works: the web app, the iPhone app and the Android app call one server, so data never drifts between them.

Apps need more regular maintenance than websites because they follow the schedules of Apple and Google. New iOS and Android versions arrive every year, and the stores periodically raise minimum SDK and privacy requirements. The contract warranty applies to apps like any project; updates for new operating system versions and feature changes are agreed separately in a maintenance contract.