Start with the product's hardest requirement
Choose the approach that makes your essential workflow straightforward to build and maintain. A booking product, an offline reference and a television media player have different constraints. Sharing code matters, but so does keeping the central feature reliable.
Write down what users must accomplish in the first release. Separate launch requirements from possible future features. Then identify anything that could rule out an approach: a required device integration, an unsupported browser capability or a platform your maintainers cannot support. A hard requirement should outweigh a collection of minor conveniences.
- Audience: which phones, tablets, computers or televisions must work at launch?
- Access: do users need an installed app, or would a link serve the workflow?
- Device features: what must happen outside the app's main screen?
- Ownership: who will handle bugs, operating system changes and releases?
What the four approaches actually mean
Here, native means Swift with SwiftUI and other Apple frameworks for Apple devices, or Kotlin with Jetpack Compose and Android APIs for Android. SwiftUI spans Apple platforms; Compose provides native Android UI through Kotlin APIs. Supporting iOS and Android this way means maintaining separate platform implementations, though they can use the same backend. See Apple's SwiftUI overview and Android's Compose overview.
React Native uses React and JavaScript, commonly with TypeScript, to build mobile apps. Its core components are backed by native platform views. Flutter uses Dart and its own widget and rendering system. Both support shared application code, with platform-specific integration where needed. See React Native's component guide and Flutter's architecture overview.
A web app runs in a browser. A progressive web app, or PWA, can add capabilities such as installation and offline behaviour. Support varies by browser, operating system and feature, so check the actual devices your audience uses. Google's PWA capability guide explains why feature detection matters.
| Approach | Consider it when | Main budget driver | Check before choosing |
|---|---|---|---|
| Native Swift/Kotlin | Platform integration defines the product | Separate iOS and Android implementation | Platform skills and launch priorities |
| React Native | Mobile workflows overlap and React skills exist | Shared screens plus native integrations | Required libraries on both platforms |
| Flutter | A shared custom interface is central | Dart development plus platform adaptations | Plugins, accessibility and rendering |
| Web app/PWA | Link access and desktop use matter | Browser testing, offline scope and backend | Device APIs and storage behaviour |
When we recommend native Swift or Kotlin
We recommend native when the operating system is central to the experience. That includes products built around platform-specific interactions, demanding device integrations or an Apple TV experience. Native is also a sensible starting point when the first audience uses one platform and there is no immediate business reason to ship another.
Native gives developers direct access to platform tools and APIs. It does not remove engineering work or make every screen fast automatically. For two mobile platforms, budget for implementing, testing and maintaining both interfaces. Share backend services, data definitions and product decisions where practical.
For example, an iPhone utility whose main value sits in a widget deserves a native prototype early. An Android field tool tied to particular hardware deserves the same treatment in Kotlin. Validate the unusual feature before polishing account settings.
When we recommend React Native or Flutter
We recommend React Native when iOS and Android need substantially the same workflows and the people maintaining the product already understand React. Existing web experience helps, but browser components do not automatically become mobile screens. Navigation, permissions, keyboards and releases still need mobile expertise.
We recommend Flutter when a consistent custom interface across mobile platforms is a priority and the maintainers are comfortable adopting Dart. Prototype the distinctive interaction and any essential plugin before committing. A shared design should still accommodate each platform's navigation and accessibility expectations.
Neither choice means every feature lives in shared code. React Native supports platform-specific files and logic; Flutter can call native code through platform channels. Include that work in the estimate. Our recommendation depends on the product and maintainers, rather than a promise of universal code reuse. See React Native's platform guide and Flutter's platform channels guide.
When we recommend a web app or PWA
We recommend starting with the web when users mainly sign in, search, book, submit information or manage records, and those tasks work well in a browser. This can suit customer portals, internal tools and products used at a desk as well as on a phone. A link also lets someone try the product without an app installation.
Add PWA features where they solve a specific need. Test installation, notifications, file handling and offline behaviour on your target browsers before making them essential to the experience. A capability working on one device is not enough evidence for the whole audience.
A browser product can also establish which workflows deserve a later mobile app. Keep the data model and backend reusable, but expect a future mobile interface to need its own design and implementation.
Budget for the work around the screens
Shared code can reduce repeated implementation when the platforms genuinely overlap. It does not remove backend development, design, data migration, payment integration, accessibility work or device testing. A cross-platform app with many native exceptions can lose much of the simplicity you chose it for.
Compare estimates against the same feature list and acceptance criteria. Ask what is included for release preparation and maintenance. If the scope exceeds your budget, reduce the first release or choose one launch platform deliberately. Changing frameworks alone may not resolve the mismatch.
- Account for existing developer skills and the time needed to learn unfamiliar tools.
- Identify integrations without a suitable maintained library, and scope custom work.
- Include offline synchronisation, failure recovery and data migration where required.
- Specify supported devices, operating systems, browsers and accessibility checks.
- Assign ownership of build systems, store submissions and dependency updates.
Test performance against a real workflow
Do not choose from a generic claim that one framework is fast. Define what acceptable performance means for your product: opening a large record, scrolling an image feed, starting playback or responding to a gesture. Use representative data and the oldest devices you intend to support.
Build a small prototype of the hardest workflow. Test a release build on physical hardware, including slow connectivity and prolonged use where relevant. Measure startup, response time, memory and battery impact as appropriate. Set your acceptance thresholds before comparing results.
Also test large text, screen readers, keyboard input and interrupted tasks. A smooth animation does not prove that someone can complete the job. Native, React Native, Flutter and web implementations all need this work.
Treat widgets, extensions and Apple TV as separate scope
A Home Screen widget is a separate product surface with its own interaction limits. Apple provides WidgetKit for widgets. A Safari Web Extension has a different integration model again. List these explicitly instead of hiding them under a general mobile app requirement. Consult Apple's WidgetKit documentation and Safari extension overview.
For a shared mobile app, establish which parts need native targets, plugins or custom integration. Verify data sharing and update behaviour in a prototype. A plugin name in a proposal is not proof that the complete workflow works.
For Apple TV, plan for a remote, focus navigation and a television layout. Do not assume an iPhone screen or a mobile framework's platform list establishes tvOS suitability. We would normally recommend native Swift/SwiftUI for an Apple TV product, with shared services underneath where useful.
Define offline behaviour before choosing storage
Offline can mean reading downloaded content, searching a bundled reference or editing records that later synchronise. These are different projects. Native and cross-platform apps can use local databases; PWAs can store structured data through IndexedDB. Browser storage limits and persistence need explicit consideration. See Google's offline data guide.
Describe what happens when a user loses connectivity during a save. Decide whether edits queue, how retries avoid duplicates and what happens when two devices change the same record. Show users whether information is saved locally or has reached the server.
Test reopening offline, expired sessions, interrupted downloads and upgrades with existing data. For a read-only reference, a bundled database may keep the scope manageable. For collaborative editing, synchronisation and conflict handling may influence the estimate more than the UI framework.
Plan App Store review as part of delivery
Choosing native, React Native or Flutter does not settle App Store acceptance. Apple's guidelines address the submitted product, including completeness, privacy and functionality. Its minimum-functionality guidance also makes a basic website wrapper a review risk. Read the App Review Guidelines while scoping the product.
Allocate work for signing, store metadata, screenshots, review access and testing the purchase flows you intend to offer. Check the current requirements for the features and markets involved. Leave room for questions or revisions during review; do not make launch commitments depend on an assumed approval date.
A web app delivered directly through the browser does not need an App Store submission for that delivery route. Packaging it for a store adds a separate release process.
Choose a stack someone can maintain
Name the people responsible for the next release, not just the first build. Native apps need platform maintenance. Cross-platform apps also need framework and plugin maintenance alongside their platform projects. Web apps need browser testing and maintenance of their application dependencies and hosting.
Before approving the stack, inspect essential dependencies, document custom integrations and establish a repeatable build. Keep signing access, store accounts and release instructions under deliberate ownership. Schedule updates and test database migrations with existing records.
Record why you chose the approach and what would justify changing it. If an existing app works, identify the actual maintenance problem before proposing a rewrite. A neglected backend will remain neglected after a new interface.
Why our own apps use native Swift/SwiftUI
Our nine owned apps are native Swift/SwiftUI apps, live on the App Store and released between April and October 2026: Rain, Tifo, Moonflower, SNAAAAKE, LIGATURE, COMPOSE, Broski, ICD Atlas and МКБ-10. They are our products, not client work.
Native fits this portfolio because its scope is closely tied to Apple devices and capabilities. Tifo includes Apple TV. Moonflower includes a Safari extension. Across the portfolio, our work includes SpriteKit games, Home Screen widgets, StoreKit purchases, offline SQLite data and multilingual interfaces. Those are concrete reasons to work directly with Apple's frameworks.
That portfolio demonstrates Apple platform implementation and App Store submission work; it is not comparative evidence that every product should use native. For your app, bring the launch platforms, essential workflows and maintenance constraints. hehe.software is a small, independent studio based in Vancouver, British Columbia, working remotely across Canada and the United States. Pricing is quote-only: we scope the work and provide a fixed quote or an hourly estimate. Paid discovery is available when the technical choice needs investigation.