Build Native Apps or Hybrid Apps
The question arrives early in almost every product conversation we have. Someone has an idea, a rough budget, and a deadline, and they want to know whether to build native or hybrid. The honest answer is that the choice is more consequential than most people realise, and getting it wrong tends not to reveal itself immediately. It reveals itself six months after launch, when performance is sluggish, when half the intended audience cannot access the product, or when the cost of adding a single feature has ballooned beyond what anyone expected.
We have seen each of those outcomes in real projects. On the social football platform we worked on, a platform split decision made midway through the build meant the product launched on iOS only, addressing roughly half the potential market on day one. On the alcohol trading platform, a technical constraint we discovered mid-build forced us to embed web elements directly into a mobile product rather than connect via a clean API layer, leaving the final solution less scalable than it should have been. These were not theoretical risks. They were decisions made under pressure, with real consequences that shaped everything that followed.
The Platform Split Decision and Who It Cuts Out
One of the most consequential choices in any mobile project is whether to build for both platforms simultaneously or launch on one first. Budget pressure often forces this decision, and it is usually made later than it should be, under conditions where the rational answer is hard to reach.
On the grassroots social football platform we worked on, the original plan was to launch on both iOS and Android. As the project progressed, scope kept growing and design kept changing, driven by someone on the client's own team without consideration for the development impact. Budget eroded. Midway through the build, we made the call to pause Android development and put all remaining budget into the iOS product.
The client launched iOS-only, which addressed roughly half the potential market. But the audience was younger and disproportionately skewed towards Android users, so the impact on day-one adoption was larger than that split suggests. Because they could not build the user base they needed, the subscription model became unviable. They had to introduce advertising, a direction they had explicitly said they would not go. That financial strain ran through the product's subsequent development and constrained every decision that followed.
Before finalising a platform strategy, look at the device split of your actual target audience, not the general population. For younger audiences, Android's share is often significantly larger than headline market figures suggest.
| Consideration | iOS-first | Android-first | Both simultaneously |
|---|---|---|---|
| Day-one reach | Partial, typically higher-income demographic | Partial, broader demographic skew | Full market from launch |
| Budget required | Lower upfront | Lower upfront | Highest upfront |
| Subscription viability | Reduced until Android ships | Reduced until iOS ships | Full addressable market from day one |
| Main risk | Cuts out a portion of audience permanently or for too long | Same risk, different demographic impact | Budget strain mid-project |
When the Wrong Choice Gets Locked In
The most expensive mistakes in app development are the ones that work well enough to ship, grow a user base, and then reveal their structural problem when changing course has become genuinely costly.
On the buying and selling platform for bottles of alcohol that we worked on, we had already started building the mobile product when we discovered the API situation. The client's existing web application had been built by a previous developer in a way that made it too complex to expose cleanly via an API. We could not build the integration layer we had planned. Instead, we ended up embedding web elements from the existing site directly into the mobile product. The final solution was not as scalable or robust as it should have been, but we were constrained by what the underlying architecture allowed.
That kind of technical debt, inherited from decisions made before the project started, is exactly what locks teams into a path they did not choose. The mobile product was shaped by the quality of someone else's earlier work, and there was no clean way out. This is why technical discovery, done early and done thoroughly, is not optional overhead. It determines what is actually buildable within the constraints you have.
Before beginning a mobile build that needs to connect to an existing web product, commission a technical discovery sprint to assess the API surface. Finding a constraint at that stage costs a day. Finding it mid-build costs weeks.
The Hidden Costs That Only Appear Later
Development cost comparisons between native and hybrid almost always focus on the initial build. What they rarely account for is the ongoing cost of maintenance, platform updates, and the accumulating overhead of keeping two codebases current when your team's attention is on building new things.
Apple and Google both release major OS updates annually. Each one can break things. With native builds, each update has to be addressed separately in each codebase. With hybrid, you typically update once, though framework updates carry their own dependencies and occasionally introduce regressions. Neither approach is free of maintenance overhead, but the nature of that overhead differs in ways that matter depending on the size and structure of your team.
There is also the less obvious cost of architectural constraints discovered post-launch. The travel app we worked on, designed for exotic holidays and backpacking in remote wilderness areas, had to be retrofitted with offline capability when the product expanded into a new type of trip. The app required an internet connection for every core function: map search, saved pins, tickets, itineraries, location times. In remote locations, it would display a "not connected" error and become completely unusable. Retrofitting offline support into an architecture not designed for it is significantly harder and more expensive than building it in from the start.
When a Web-Based Approach Beats Both
There is a category of product where the right answer is neither native nor hybrid, but a well-built mobile web experience. The instinct to build an app is strong, partly because apps feel more serious, more committed, more like a real product. But that instinct is worth questioning, because app store downloads create real friction, and friction reduces completion rates.
On the performance coaching survey app, we recommended against requiring the audience to download a native app at all. The interaction was essentially a simple touchpoint: a presenter shows a survey, audience members respond. Asking those audience members to find an app, download it, and create an account before they could participate was too high a barrier for what the moment actually was. Instead, we proposed a QR code approach. The presenter created a survey in their native app, a QR code appeared on screen, and anyone who scanned it landed immediately on a fully branded, mobile-responsive web page. Survey completion rates were significantly higher as a result.
For the backend we used Firebase's real-time database rather than building a traditional API. Each survey generated a record in Firebase, and audience members accessed their own unique response record via keys embedded in the QR code URL. Responses logged in real time, security was tight, and the build stayed lean. This was a proof of concept that did not need a heavyweight architecture, and building it that way meant we could demonstrate the value quickly without unnecessary complexity.
- Ask whether an app store download is genuinely necessary for the interaction you are designing.
- Consider whether a mobile-responsive web experience would serve the user better at the moment they need it.
- Evaluate the backend accordingly: not every product needs a traditional API from day one.
How to Make the Decision Without Regret
The decision between native, hybrid, and web-based approaches rarely comes down to a single factor. It comes down to the honest answer to a set of questions that are easy to skip when a project is exciting and a launch date has been agreed.
Start with the audience and the device split. The social football platform experience showed clearly that building the polished version of a product for the smaller portion of the market is a costly way to learn this lesson. Know who your users are and what they are carrying before you decide what to build for.
Then look at what the product actually needs to do. If the core experience depends on device hardware, real-time performance, or interactions that need to feel native to feel right, native development earns its cost. If the core experience is content, forms, and standard UI patterns, hybrid gives you most of the outcome at a lower cost and with a single codebase to maintain.
Finally, be honest about the existing technical landscape. The alcohol trading platform experience is a reminder that what came before the mobile build shapes what the mobile build can be. Technical discovery is what prevents the build from discovering its constraints after work has already started.
Run a structured technical discovery before committing to an approach. The questions about API availability, offline requirements, and platform audience split all have cheaper answers before development begins than after.
Conclusion
Native and hybrid are tools, and tools serve purposes. The question is never which one is better in the abstract. It is which one fits the product, the audience, the budget, and the technical reality of what already exists around it.
We have seen hybrid deliver clean, performant products that users loved, and we have seen native development justify every pound of its higher cost when the experience demanded it. We have also seen both approaches fail when the underlying decision was made without enough honest information about the constraints involved.
The social football platform, the alcohol trading app, the water tracking tool with its Apple Watch component, the performance coaching survey app: each of these projects taught us something specific about where the real decisions sit, and it was never purely about the technology. It was about understanding the audience, the architecture, the budget reality, and what the product genuinely needed to do before any code was written.
If you are at this stage in a project and want to think through the decision properly, let's talk about your app.
Frequently Asked Questions
Native apps are built specifically for one platform, either iOS or Android, using that platform's own development tools and languages. Hybrid apps use a single codebase that runs across both platforms, often wrapping web technologies inside a mobile shell.
The choice shapes performance, scalability, and long-term development costs in ways that often do not become obvious until months after launch. Getting it wrong can make adding new features unexpectedly expensive and limit how well the product serves its audience.
Before making that call, you should look closely at the device split of your specific target audience rather than relying on general market figures. For younger audiences in particular, Android's share is often much larger than headline statistics suggest, so launching iOS-only could cut out a significant portion of your potential users from day one.
Launching on one platform means you are addressing only part of your potential market, which can undermine subscription models and slow user growth. As the social football platform example shows, a reduced user base can force unwanted changes to your business model, such as introducing advertising when that was never the intention.
Discovering a constraint partway through development often forces compromises that reduce the quality or scalability of the final product. The alcohol trading platform example in the article illustrates how embedding web elements directly into a mobile product, rather than connecting via a clean API, left the solution harder to scale than it should have been.
Platform strategy should be agreed before any significant development work begins, ideally as part of the initial scoping and planning stage. Delaying that decision until budget pressure forces the issue, as happened on the social football project, tends to produce outcomes that constrain everything that follows.
Yes, and this is a common problem. When scope grows and design changes without proper consideration of the development impact, budgets erode and teams are forced into difficult trade-offs, such as dropping one platform entirely to keep the project on track.
Building for both iOS and Android at the same time gives you the widest possible audience from launch and makes subscription models more viable from day one. However, it requires the highest upfront budget, so it is only the right choice if the project is properly funded to sustain that scope throughout the build.