Photo by bennoptic on Unsplash
When I wrote my previous article, “What’s Native?”, I focused on the technical foundation of what native really means. That piece laid the groundwork for understanding the nuances of native development — from language bindings to runtime execution — so we could move beyond vague definitions and have a shared baseline.
Now, I want to shift the conversation. Instead of asking what is native, I want to ask whetheritreally matters to be native.
In such a team, where knowledge spans both native and cross-platform approaches, does the native advantage still hold weight? Or are we already past the point where native makes the decisive difference?
Factors That Shape the Decision
It’s important to recognise the different forces that influence whether a team goes native or cross-platform. Some of these forces come from the outside world, others are shaped by your own team and product, and some lie within the technologies themselves. And of course, there are always the practical constraints that no one likes to talk about but everyone must deal with.
External Factors — The environment you operate in
Clients may set rules, the market dictates talent availability, and broader trends shape what feels like a safe choice. These external forces are often beyond your control, but they matter just as much as technical merit.
Client
Sometimes the very first constraint comes from the client. Some clients are flexible, giving you freedom to decide what’s best for the project. Others might impose their own preferences — maybe because they already have in-house expertise, existing codebases — , or just a strong opinion. In these cases, being native or not might be less about engineering reasoning and more about aligning with the client’s expectations.
Market
Even when the client doesn’t dictate the choice, the broader market plays a role. The availability of skilled developers in a given stack, the long-term sustainability of hiring, and even the perception of which technologies are safe bets will shape the decision. Choosing a stack that is strong in the market often reduces hiring friction and lowers long-term maintenance risk.
Internal Factors — The environment you control
The people you have, the product you’re building, and the time you have to deliver, these internal conditions shape whether native or cross-platform is the more pragmatic path.
Team
The skills and availability of your team are usually the most decisive internal factor. If you already have engineers with strong native expertise (Kotlin and Swift), then leaning into that might feel natural. On the other hand, if your team is mostly experienced in JavaScript or Dart, it may not make sense to reinvent the wheel just to claim you’re native. Team bandwidth also matters: sometimes the choice isn’t about the ideal technology, but about which team is free to deliver right now.
Product
The nature of the product shapes the decision as well. Are you building a greenfield app from scratch, or extending an existing one with years of history? Is this a throwaway proof of concept, a fast-moving MVP, or a long-term product meant to scale? Native stacks often shine in mature, long-lived products, while cross-platform approaches can be powerful accelerators for experiments and rapid iterations.
Time-to-Market
Even if your team has the right skills, deadlines change the calculus. A native approach may give more control and fine-tuning in the long run, but when the goal is to launch quickly, cross-platform can often deliver features faster across platforms simultaneously. It’s not always about what’s technically better, sometimes it’s about what gets the product into users’ hands first.
Technology Factors — The tools you choose
Not all stacks are equal: some are mature, stable, and deeply integrated, while others are newer, faster-moving, or more experimental. Here the discussion shifts from people and business into the strengths and weaknesses of the tools you choose.
Maturity
Not every technology stands on the same ground. Some stacks are battle-tested, widely adopted, and deeply integrated into existing ecosystems. Others are newer, less stable, or designed with an all-in philosophy that makes them harder to mix into existing architectures. Maturity matters, it affects not only technical stability but also the confidence you can have in committing to that technology for the long run.
Community & Ecosystem Support
Closely tied to maturity is the health of the surrounding ecosystem. Are there active contributors, reliable libraries, and strong tooling support? Or will you spend half of your time building basic infrastructure because the ecosystem isn’t there yet? The strength of the community often determines how productive your team can be day to day.
Performance & User Experience
Performance has traditionally been the flagship argument for native. Smooth animations, predictable memory usage, low latency, these are areas where native stacks tend to shine. But the gap has narrowed: cross-platform frameworks are often good enough for many use cases. The real question is whether your product demands that extra 10–20% of performance, or whether trade-offs in speed and flexibility are acceptable.
Abstraction Layer
Cross-platform frameworks always add an extra abstraction layer on top of native SDKs. That extra layer has a cost: when Apple or Google introduce new features, you’re dependent on the framework maintainers to catch up. Sometimes that lag is short, sometimes it lasts months. It can also surface unexpected bugs when the abstraction doesn’t fully cover edge cases. Native, by definition, doesn’t carry this overhead.
Scalability & Evolution
Finally, it’s worth asking how the choice will play out over time. Will the technology scale as your product grows in complexity? Can it evolve with the road-map, or will it become a bottleneck when new platform features or advanced integrations are required? Today’s shortcut can become tomorrow’s technical debt if scalability isn’t considered from the start.
Practical Factors — The constraints you live with
Budgets, timelines, and risk tolerance often shape the decision more than technical ideals. These are the realities that sit in the background of every project, quietly influencing whether native or cross-platform makes the most sense. These practical realities may not be as exciting as performance benchmarks or ecosystem debates, but they often tip the scales.
Cost & Budget
At some point, every technical decision is influenced by budget. Native development often requires two specialised teams — one for iOS, one for Android — which doubles certain costs. Cross-platform can stretch resources further by allowing a single team to ship across platforms. The trade-off isn’t just financial: it’s about deciding whether you want two deep specialists or one broader unified team.
Long-Term Risk
Choosing a stack is not only about today’s delivery, but tomorrow’s survival. Betting on a framework with limited adoption or weak community support can become a liability. If that framework fades or breaks with future OS changes, you may face expensive rewrites. On the other hand, staying purely native might minimize risk but also limit speed or hiring flexibility. Balancing immediate wins with long-term sustainability is key.
These factors form the backdrop of every decision. Once we put them on the table, the real question is how they combine in practice, which is where things get interesting.
Case Studies
Before diving into theory-heavy comparisons, I want to ground this in reality. I’m currently an engineering manager, and navigating these kinds of trade-offs is part of my day-to-day. I bring over a decade of experience as a mobile native developer. My team today is multidisciplinary: we have engineers skilled in the native stacks (Kotlin and Swift) — some have experience in both — and others with strong cross-platform expertise (React Native). Flutter, for the time being, isn’t part of our mix.
This diversity means that every decision is shaped by real constraints and trade-offs, not just by what looks best on paper. I’ll share a few real use cases from my own experience. My hope is that by walking through them, you’ll see how these factors play out in practice, and maybe even reflect on how they show up in your own projects.
For non-technical readers, a project has two layers: logic and interface.
Native builds both layers separately for each platform.
Cross-platform shares both, reducing duplicated work.
Case 1
The client had little technical background and pushed hard for a very short time-to-market. There was already a responsive web version in place, and the client’s main goal was to have a presence in the app stores, with the option to evolve the mobile solution gradually.
Given those constraints, we focused on integrating the existing web solution while adding just the minimal native functionality required to pass store requirements and deliver quickly.
Choice: one cross-platform developer, using React Native.
Case 2
The client had a medium-to-high technical background and the constraints were clear: a tight budget, a medium time-to-market, and a project with moderate UX complexity but heavy hardware needs (NFC).
The strategy was to share the entire business logic while keeping the UI native on each platform, aligned with their default design systems. NFC integrations were handled separately, as each platform required custom implementation.
Choice: one native developer, using Kotlin Multiplatform with Kotlin/Swift.
Case 3
The client had a medium-to-high technical background and a short time-to-market. The project was tied to a large-scale event with high expected traffic, which made reliability critical but left little room for a long development cycle.
Given those constraints, speed of delivery and cross-platform reach were the main priorities. React Native allowed us to ship quickly while ensuring presence on both stores in time for the event. With three developers focused on the stack, we balanced delivery speed with enough robustness to handle the anticipated audience.
Choice: three cross-platform developers, using React Native.
Case 4
The client had a strong technical background and a clear priority: deliver a highly optimised experience. This was an evolving product with a strong roadmap ahead, including integrations with Android Auto and CarPlay, as well as advanced media features such as audio streaming and background playback. Time-to-market was moderate, but long-term scalability and UX polish were non-negotiable.
These requirements pushed us toward full control over each platform’s capabilities. To ensure performance and deep integration, we placed two native developers on each platform, each focused on building the best possible experience for their ecosystem.
Choice: four native developers, using Kotlin for Android and Swift for iOS.
These cases aren’t about proving one approach is better. They show how context — client, budget, timing, requirements, and team — directly shapes the outcome. The right choice lives at the intersection of constraints and goals.
Job Offers
OUR VIDEO RECOMMENDATION
Jobs
Comparative Analysis
With that in mind, we can now move to a more direct comparison of the stacks themselves, to understand their strengths and trade-offs in isolation.
At the highest level, the debate often comes down to multiple codebases (native per platform) versus a single codebase (cross-platform). Each side carries clear strengths and trade-offs.
But single vs multiple is still an abstract debate. In practice, the decision plays out across specific stacks, each with its own trade-offs. Native stacks, cross-platform frameworks, and emerging multiplatform solutions all sit somewhere along this spectrum. Understanding their pros and cons helps us see how the theory translates into real technology choices.
Some of these dimensions are self-explanatory, like Performance, Platform Integration or Development Speed. Others need a bit more context. Ecosystem reflects the maturity of tooling, libraries, developer experience, and community support that a developer can rely on. Incremental refers to whether a technology can be introduced gradually into existing native codebases, rather than requiring an all-in rewrite from day one. Market reflects talent availability and adoption trends: how easy it is to hire, and how widely used the technology is in the industry.
There’s no silver bullet. Each stack reflects a balance between control, speed, and long-term sustainability. The key is not asking which is the best in absolute terms, but which is the best fit for the constraints you face.
Although one may ask: which cross-platform stack will thrive in the future?
From my perspective, Compose Multiplatform shows strong potential. It blurs the line between native and cross-platform by offering the benefits of a single codebase while staying true to native foundations (as I argued in “What’s Native?”). Unlike all-in frameworks, it allows incremental adoption, letting teams bring it into existing projects piece by piece. And because it’s built on the same stack as native (Kotlin) — something that until now was only offered by non-native stacks — , it gives mobile developers a natural cross-platform path. As an example of step-by-step integration, Compose can even be nested within SwiftUI when needed.
Compose Multiplatform (CMP) can be seen as the upper spectrum of Kotlin Multiplatform (KMP): where KMP focuses on sharing business logic, CMP extends that to also unify UI and design systems across platforms. This means it inherits all the advantages that KMP already has over pure native approaches, while at the same time positioning itself as a strong contender against established cross-platform frameworks.
Though still evolving, it already stands out as one of the most promising options for bridging native and cross-platform development in the coming years.
Closing remarks
There is no universal answer to whether native or cross-platform is the right choice. What we’ve seen is that the decision is never made in a vacuum: it’s shaped by clients, teams, budgets, markets, and the evolving maturity of the tools themselves.
The real challenge is not to argue which stack is better in absolute terms, but to recognise the trade-offs and choose consciously, knowing why you are making that decision. Context defines the winner.
As technologies converge and new options like Compose Multiplatform emerge, the lines are blurring. Perhaps the future won’t be about native vs cross-platform at all, but about how seamlessly we can balance performance, speed, and maintainability while meeting the real-world constraints that shape every project — because, in the end, the question isn’t native or not — it’s whether the technology you choose empowers your product, your team, and your future.
Appendix
The Mobile Stacks table is not a universal ranking. It reflects a synthesis of our team’s experience over more than a decade, combined with observed market trends, developer experience, and ecosystem maturity. Your own results may vary depending on your team’s skills, product requirements, and client context. The goal is not to establish an absolute hierarchy, but to provide a practical lens for evaluating trade-offs.
This article was previously published on proandroiddev.com.
