Most mobile projects don’t go wrong because someone picked the wrong programming language. They go wrong because a team settles on a mobile app tech stack before agreeing what the app must do, who it serves, and how it needs to change. Get that sequence right — product first, technology second — and choosing between native and cross-platform app development becomes a straightforward, evidence-based decision rather than a guess.
For a simple customer app, the fastest route to market may be a shared codebase for iOS and Android. For a product that depends on advanced camera processing, continuous location tracking, complex offline work or the newest platform features, native development may be the more sensible investment. Neither route is automatically better. The right answer comes from the work the app needs to perform.
Start with the product, not the framework
It is tempting to begin with a familiar question: React Native, Swift, Kotlin or Flutter? That is useful later, but it is not the first decision. Start by writing down the app’s actual job.
Ask what users need to achieve in their first session, what data the app handles, and which features are essential at launch versus desirable later. Clarify whether the app is mainly a companion to an existing web platform, a field tool used without reliable signal, or the primary place customers interact with your business. These differences affect architecture far more than a framework popularity chart — the same discipline that goes into scoping a strong first version of any product applies just as much to mobile.
A booking app that displays account details, sends notifications and takes payments has a different technical profile from an app used by engineers in warehouses, with barcode scanning, Bluetooth devices and offline records. The first may be well suited to cross-platform mobile app development. The second may need deeper native integration and more careful testing on real devices.
This early work also prevents a common mistake: treating iOS and Android as identical. The core user journey can be consistent, but each platform has conventions around navigation, permissions, settings and accessibility. A good stack lets you share what should be shared without forcing users into an interface that feels out of place on their phone.
Choosing a mobile app tech stack: the main routes
Most bespoke mobile projects fall into three broad approaches: native apps, cross-platform apps, or a web-first product such as a progressive web app. Each has a legitimate place, and the performance gap between them matters less than it used to — but it hasn’t disappeared.
Native iOS and Android development
Native apps use Swift for iOS and Kotlin for Android. They give engineers direct access to each platform’s capabilities, interface components and performance characteristics. They are usually the strongest option where the app relies heavily on device hardware, sophisticated animations, background tasks, high-performance graphics, or features released by Apple and Google that must be supported quickly.
The trade-off is that you maintain two application codebases. Some business logic, APIs and design decisions can still be shared, but the user interface and platform-specific work are separate. That can be justified when the product needs it. It is not justified simply because native sounds more serious.
Native is often a sound choice when mobile is central to the business model and the product roadmap is likely to become more technically demanding over time. It is also sensible if the internal team already has strong Swift and Kotlin capability.
Cross-platform development with React Native
React Native allows teams to build iOS and Android apps from a largely shared TypeScript and React codebase. For organisations already using React or Next.js on the web, this can create useful continuity in skills, patterns and product thinking. It can also reduce duplication when the two mobile apps share the same workflows and visual language.
React Native is not a shortcut that removes all platform work. Senior engineers still need to test on both operating systems, handle native modules where required, and respect differences in interaction design. But for many content, account, marketplace, booking, workflow and SaaS companion apps, it is a practical balance between delivery speed and product quality. We’ve set out how we weigh React Native against fully native builds in more detail on choosing between React Native and native apps, including where the decision tends to be close.
The question is not whether React Native can produce a good app. It can. The question is whether its constraints fit your hardest requirements. If a critical feature relies on specialised hardware or needs exceptional performance, validate that feature with a small technical prototype before committing to the wider build.
A web app or progressive web app
Sometimes the best mobile app is not an app-store app. A responsive web application can be opened immediately from a browser, updated without store review, and found through search. That matters when acquisition, sharing and low-friction access are more important than deep device integration.
A progressive web app can offer installation prompts, limited offline behaviour and notifications in some circumstances. It is not a full replacement for native mobile development, particularly when reliable background processing, extensive hardware access or an app-store presence is fundamental. But it can be the right first product, or the right product full stop.
Be honest about user behaviour here. If customers need to use the service once or twice, asking them to install an app may add friction. If they return daily and rely on alerts, saved sessions or device features, an installed app may earn its place.
Judge the stack against your difficult requirements
A good decision framework focuses on the parts most likely to cause delay or compromise. Do not choose based on the easy screens. Almost any modern stack can render a login form and a list of items.
Consider these areas early:
- Device features: camera, biometrics, Bluetooth, NFC, GPS, health data, wearables, scanning and printing may require native work or careful library evaluation.
- Offline use: decide what happens when a user loses signal, edits data on several devices, or reconnects after several days. Offline sync is a product and data problem, not a checkbox.
- Performance: large lists, maps, media editing, real-time updates and complex animations should be tested on representative devices, not only a developer’s latest phone.
- Security and privacy: map data flows, permissions, authentication, encrypted storage and account recovery. The app should request only the permissions it genuinely needs.
- Accessibility: support screen readers, scalable text, adequate colour contrast, touch target sizes and predictable navigation from the first design iteration.
- Release operations: account for app-store submission, crash reporting, analytics, feature flags and a process for shipping urgent fixes.
The outcome may still be cross-platform. The point is that you reach that decision with evidence rather than optimism.
The backend is part of the mobile stack
Mobile technology conversations can become overly focused on the app itself. In practice, the mobile client is one part of a system that also includes APIs, authentication, databases, file storage, notifications and operational monitoring.
A clean backend architecture matters because mobile users operate on variable connections and older app versions remain in use after a new release ships. APIs need sensible versioning, clear error handling and backwards compatibility. Authentication needs to cope with expired sessions and secure recovery flows. Data models need to support the product’s likely next steps without being designed for imaginary scale.
For many products, a TypeScript and Node.js backend with PostgreSQL provides a clear, maintainable foundation. The specific choice should follow existing systems, team capability and data requirements. If you already have a working backend, the priority may be improving its mobile-facing API rather than replacing it for the sake of consistency.
This is also where ownership matters. Your team should receive documented source code, deployment access and a clear explanation of how the system works. If you’re commissioning the work externally, a technical due diligence checklist is a useful way to check what “done” should actually include before you sign off. A technology stack is not just a launch decision. It shapes how easily another capable engineer can maintain the product later.
Avoid decisions driven by short-term demos
A polished prototype can conceal difficult engineering. Before selecting a stack, build or commission a focused proof of concept around the riskiest requirement: scanning in poor light, synchronising offline changes, handling a Bluetooth connection, or rendering a data-heavy screen on an older device. This is the same logic behind prototyping before production on any build — it’s the cheapest way to be wrong.
This need not become a full discovery project with weeks of speculative work. The aim is to answer a precise question early, while changing direction is still cheap and straightforward. It also gives founders and product leads something more useful than a generic recommendation: evidence from their own product.
Be cautious of two opposite promises. “One codebase means half the effort” ignores testing, native integrations and store operations. “Native is always premium” ignores the maintenance burden of duplicated work where platforms genuinely share the same needs. Both are oversimplifications, and both tend to surface after the contract is signed rather than before.
Plan for change without over-engineering
The most durable stack is usually the one that makes ordinary change safe. That means a clear code structure, automated tests around important business rules, sensible separation between app screens and data services, and documented release processes.
It does not mean building a complex microservices estate for an early product. A smaller, well-organised system is easier to understand, test and evolve. Add complexity when a measured need appears, such as independent scaling, specialist processing or clear boundaries between separate product areas.
Choose tools your team can support. An unusual framework may look attractive in a demonstration, but it becomes a liability if hiring, debugging and updates depend on a small pool of specialists. Established technologies are often the sensible choice because their behaviour, tooling and failure modes are well understood.
Make the decision with the people who will deliver it
Founders should not be expected to choose a framework alone. They should, however, expect a delivery team to explain the recommendation in plain English, including what it rules out and where uncertainty remains.
A useful technical recommendation sets out the product assumptions, the chosen approach, alternatives considered, known risks and how those risks will be tested. It should also cover accessibility, security, analytics and support after launch, rather than presenting them as later add-ons.
If you are weighing options for a new product or an existing app that has become difficult to maintain, book a free consultation and we’ll review the requirements with you and show how the decision would affect delivery and future change. The best choice is rarely the most fashionable stack. It is the one that gives your users a dependable experience and gives your business room to learn.
