Short answer: Start by establishing why someone will return to the app, then match the approach to that reason. A progressive web app suits a product whose important tasks work well through the web. Shared-code development with React Native or Flutter suits iOS and Android journeys that are substantially similar. Platform-specific development suits a product whose value depends on deep integration with one platform. Whichever you consider, build or review a focused prototype of the most uncertain capability on real target devices before committing to the whole app.
This guide is for founders, business owners and product teams deciding how to build an app, and for anyone comparing app proposals. The documentation linked below was checked on 27 October 2026. Support for installation, offline behaviour, notifications and device access has to be checked feature by feature when the product is scoped.
Before deciding how to build an app, establish why someone will return to it. Repeated tasks, account access, device capabilities and a dependable service experience provide stronger reasons than simply wanting an icon in an app store.
There are three useful approaches to assess: an enhanced web application, a shared-code mobile application and platform-specific development. The right choice depends on the journeys you need to support, the devices your customers use and the team that will maintain the product.
How do the three approaches compare at a glance?
The table gives the starting question for each approach. The sections below add the detail and the sources.
| Approach | What it is | Consider it when |
|---|---|---|
| Progressive web app | A web application enhanced with capabilities such as installation and offline behaviour where supported | Customers should reach a service directly from a link and the important tasks work well through the web |
| Shared-code mobile app | Mobile development that reuses code across Android and iOS, such as React Native (with Expo's tools) or Flutter (built around Dart) | iOS and Android need substantially similar journeys and a shared delivery team is a practical fit |
| Platform-specific app | Separate implementations, such as Swift with SwiftUI on Apple platforms and Kotlin with Jetpack Compose on Android | The product's value depends on deep integration with a platform, specialist interaction or different experiences for different devices, or it launches on one platform first |
When does a progressive web app deserve consideration?
A progressive web app, or PWA, is a web application enhanced with capabilities such as installation and offline behaviour where supported. It remains a web product and should begin with a sound responsive website. Browser and operating-system support determine which enhanced features are available (Google's PWA course).
Consider this route when customers should reach a service directly from a link and the product's important tasks work well through the web. A catalogue, account workspace or booking journey can be assessed this way before assuming that a store-distributed app is necessary.
Do not treat offline support as a checkbox. Decide what users can read, change or submit without a connection, how they see stale information and what happens when they reconnect. Test those behaviours on the actual target devices. The same applies to installation, notifications and device access: support must be checked feature by feature.
What does shared-code mobile development offer?
React Native is a framework for Android and iOS applications using React and platform capabilities. Expo supplies tools and services for developing and distributing JavaScript or TypeScript applications across supported platforms. These are related technologies, not synonyms.
Flutter is a cross-platform UI toolkit built around Dart, a programming language. Its architecture supports reuse across platforms while providing ways to integrate platform services.
Assess a shared-code approach when iOS and Android need substantially similar journeys and a shared delivery team is a practical fit. Reuse can include product logic, interface components or integration work, depending on the architecture.
The amount of shared code is not a quality score. Device integrations, platform conventions and store requirements still need their own attention. Prototype the difficult part first: perhaps a camera workflow, background operation or specialist hardware connection. A simple home screen will not expose those risks.
When is platform-specific development justified?
Swift is a programming language used across Apple platforms, and SwiftUI is Apple's declarative UI framework. On Android, Kotlin is a programming language, while Jetpack Compose is a native UI toolkit. These distinctions matter when reviewing a proposal and its staffing requirements.
Platform-specific development deserves consideration when the product's value depends on deep integration with a particular platform, specialist interaction or different experiences for different devices. It can also suit a product that is intentionally launching on one platform first.
Separate implementations introduce coordination work. Specify how shared business rules, content and analytics remain consistent. Some teams share backend services while maintaining different interfaces; that decision should be visible in the scope.
How do we test capabilities before debating frameworks?
Prepare a short product brief covering:
- The three tasks that make the app worth returning to.
- Target devices and the minimum operating environments you will support.
- Required device features and behaviour when permissions are refused.
- Offline needs, account roles and data synchronisation.
- Distribution, release and ongoing support responsibilities.
Then build or review a focused prototype for the most uncertain capability. Record what was tested, on which device and with which limitations. This gives the commercial decision a technical basis without committing to an entire application prematurely.
What should the budget cover beyond the first release?
The first release is only one part of the commitment. The scope should address store submission where relevant, review feedback, privacy information, crash reporting, support and future operating-system changes. A successful build does not itself confirm app-store approval.
Ask how the team will ship fixes, recover from a faulty release and maintain account access if the supplier changes. Company-controlled accounts and clear release instructions reduce avoidable handover difficulties.
Where should we start?
Discuss your mobile product with 4AI, or start with UI/UX design to test its important journeys before choosing the implementation approach.
Frequently asked questions
Is cross-platform always less expensive?
No. Compare the full scope, including integrations, platform-specific work and maintenance. A shared codebase can be useful, but it is not a universal cost guarantee.
Can we turn an existing website into an app?
Some assets and services may be reusable. The mobile interaction, capabilities, distribution and support model still need to be designed.
Should a business launch on every platform at once?
Start with the platforms supported by your audience evidence and product requirements. Expanding distribution adds testing and operational responsibilities.