Mobile Development in 2025: Native vs. Cross-Platform

Mobile development in 2025 presents a critical choice: should you go cross-platform, or should you go native? There are several things to look at, and we'll discuss them in this article.

The Default Position on Mobile Apps

When it comes to building mobile apps for devices like the iPhone, Android phones, and tablets, the default position for many is to first look at cross-platform solutions. This could include frameworks like Flutter, React Native, PWAs, and other solutions like the one Microsoft previously had with Xamarin.

As a matter of solid business practice, the default is to see if you can build it cross-platform. Why? Because when you build a mobile app non-natively with a framework like Flutter or React, you have one codebase to maintain, which can save a significant amount of money.

However, using a cross-platform solution is not all peaches and cream. There are issues that you have to contend with. Nothing is perfect in this world; there are pros and cons to everything.

The Cons of Cross-Platform Solutions

So, what are the cons of using React, Flutter, a PWA, or any other cross-platform solution?

Limited Hardware Access

One major issue is that you may have limited access to certain hardware features. For example, a feature like the gyrometer might not be fully supported by a framework like Flutter. When you're using a cross-platform solution, there may be some hardware functionalities that you can only access via native programming.

Inevitable Bugs

Another issue with cross-platform solutions is the likelihood of bugs. Any software, no matter what, is going to have bugs. When you're using a middle layer between your code and the operating system (like iOS or Android), you're introducing another layer where mistakes can happen. Whether it's Xamarin, Flutter, or React Native, this layer of code can have its own bugs that you'll have to contend with. That's just part for the course.

Performance Hits

Performance is another significant consideration. For every layer of code you add, you take a hit in performance. An app built with Flutter or React will never be as fast as one written with native code. This isn't an insult to these frameworks; it's just the reality of how software layers work.

Many times, though, this performance difference doesn't really matter. For instance, a native app might respond in one-hundredth of a second, while the Flutter or React Native version might take one-tenth of a second. While that's technically much slower, the user probably won't notice the difference. In that situation, the performance loss is a non-issue.

However, if you're developing games where you need direct access to the hardware and as much power as possible, then a framework like Flutter or React Native may not be your best choice.

The Advantages of Cross-Platform Solutions

So, why would you go with a cross-platform solution? There are a few major advantages.

A Single Codebase

The most significant advantage is having one codebase. As mentioned, a single codebase is far easier and cheaper to maintain than two. When you write native apps, you typically need to support both iOS and Android. This means having a team of developers writing Swift for iOS and another team writing Kotlin for Android. While you could still use Java for Android or Objective-C for iOS, the industry has largely moved toward the lighter, more nimble languages.

Maintaining two codebases in two different technology stacks is expensive. You need different groups of developers, or developers who know both stacks, which increases costs.

Simplified Skill Sets

With native development, you need two sets of skills. Every operating system, whether it's Android or iOS, has its own quirks and idiosyncrasies that you have to contend with. One advantage of a middle layer like Flutter or React is that, at least in theory, they can handle these minor issues for you, so you don't have to worry about them as a developer. This is a moving target, of course, as things change with new releases, but the principle remains.

This is similar to how jQuery worked in the early days of the web. It allowed you to access the DOM regardless of the browser, hiding the underlying inconsistencies. Bootstrap also comes to mind; its purpose was to help create web layouts easily without worrying about browser-specific quirks in Internet Explorer, Edge, Firefox, or Chrome. The analogy isn't perfect, but it illustrates the idea.

The Major Disadvantage: Framework Dependency

With all the advantages of cross-platform solutions, there is one major disadvantage: dependency on the framework. If you build an app based on Xamarin, for example, you are dependent on the Xamarin development team, which was once controlled by Microsoft.

What happens if a new bug appears in the underlying OS? You might have to wait for the cross-platform layer to be updated. What if the OS releases a new feature, or a new phone has a new button? You'll have to wait for the Xamarin, React Native, or Flutter development teams to update their respective frameworks to take advantage of it. When you use a cross-platform solution, you are dependent on their update and development cycles.

A Real-World Case Study

A few months ago, a publicly traded company's development team was facing a serious issue with their mobile app. A large portion of their clients used this app, and it was a key aspect of their technology, even though they weren't strictly a tech company.

The problem was that their mobile app was extremely buggy. Based on its behavior and update cycles, it had all the telltale signs of being built with a middle layer rather than native code. The underlying codebase seemed fragile.

Upon discussion, it was confirmed that they were using Xamarin to build their app. The core problem was that Xamarin was no longer being officially supported by Microsoft. This is one of the biggest downsides of using any piece of software: when it stops being supported by its creator, you're in trouble. They were dealing with strange bugs, partly because Xamarin itself was buggy and had been effectively dropped by Microsoft. Even if another group takes over, it's not the same.

They were faced with a very tough decision: should they continue investing time trying to fix a buggy, cross-platform solution built on a deprecated framework, or should they go native?

They had data showing that 80% of their user base was on iOS, which clearly indicated where they should focus their development efforts. There's an old expression: "Don't throw good money after bad." For a key piece of technology that so many clients depend on, basing it on a platform that's been kicked to the curb by its creator is a major issue. The recommendation was to pull the trigger on a rewrite from scratch, starting with iOS.

The Rewrite Strategy

This problem is not unique. A similar situation arose with a web application that had to be rebuilt. The old codebase was ancient—over five years old—and had accumulated numerous bugs over time, especially since it had evolved from an MVP. In the first few years of a product's life, you learn a lot about use cases. Clients call in a panic, you write quick patches, add new features, and soon you have "Franken-code" on your hands.

That's the situation the publicly traded company was in. Their app was based on discontinued technology and was riddled with bugs. The decision to rewrite from scratch is a big one, but the good news is that when you do, you already know the use cases. After several years, they understood what the application needed to do. Rebuilding from scratch is actually much less work than building it the first time because the requirements are clear.

When undertaking a rewrite, it's a good practice to have the new team work on the old codebase for a period, perhaps six months or more. This allows them to become intimately familiar with the existing problems, bottlenecks, and information flow. That way, when it's time to architect the new version, design the new databases, and choose the frameworks, they have a deep, intimate knowledge of how the app works.

The new version will inevitably have some new bugs, but they will be relatively minor. Furthermore, you can optimize processes that were impossible to fix in the old codebase. It's a difficult decision, but a rewrite often results in a far more solid and better-performing application.

Final Verdict

So, for mobile development in 2025, should you go cross-platform? The answer is to make every attempt to do so, but you have to evaluate it on a per-project basis.

• Does the middle layer (Flutter, React Native, PWA) provide sufficient access to the hardware for your needs?
• Despite the performance hit, is it still fast enough for your app? It very well could be.

Numerous large, publicly traded companies use cross-platform solutions all the time. After all, it's better to maintain one codebase than two.