Cross-Platform vs Native: The 50 Shades of Mobile App Development

Hint: You can try both

The global mobile app market has been growing exponentially in the past years. Given the present growth trends, businesses’ decision to go mobile is understandable, if not entirely logical.

• The global mobile app market is currently worth US $112.6 billion and is anticipated to increase 2.7x by the end of 2031. 
• Proliferation of mobile devices, Internet penetration in developing countries such as India, China, and Brazil, as well as the lasting effects of the COVID-19 pandemics act as the main market drivers.
• Google and Apple dominate the market. In the third quarter of 2021, users downloaded 27.6 billion apps from Google Play and 8.1 billion from App Store.
• Even though Google Play Store has always made up the bulk of app downloads, Apple App Store performs much stronger in terms of revenue generation.

Most merchants choose to design their mobile apps for both platforms. But here comes the challenge: because of different iOS and Android operating systems, developers are at times forced to make the same app twice to reach both audiences.

I’ve seen this technical hurdle plaguing the industry for years. Fortunately, there are two solutions to address it: either by developing two native apps or by applying a cross-platform approach. Each solution brings its benefits to the table and should be considered based on the stage of business maturity and market demand.

How to choose between a native or cross-platform development and which pros and cons each of these approaches have for the business — read more in this article.

Cross-Platform vs Native Mobile Apps: One Size Does Not Fit All

There’s the basics you need to know before choosing between native vs cross-platform apps.

A native app is made with platform-specific code in a language dedicated to a specific mobile OS. These are usually Java or Kotlin for Android and Swift or Objective-C for iOS. So if you want to see your app in both Play Market and App Store, you would  need to employ two teams of programmers working in IDEs specific to a chosen OS.

A cross-platform mobile app is built as a single solution for multiple operating systems and platforms (Android, iOS, Windows). Some most popular cross-platform frameworks are Xamarin, React Native, and Flutter. Such apps pretend to have the native look and feel and are praised for their cost-effectiveness.

Problem solved, you might think. Not so fast, I’ll say.

Even though a cross-platform app will take much less time to develop and less budget to invest, it’s not as performant as a native app. Your choice should depend on your targeted user expectations, complexity of your app and the stage of your business maturity.

Here are four common case scenarios businesses might experience in mobile development.

Case #1: You’re a startup that needs an MVP to test the market traction.

The most cost-effective solution for startups is to use their own engineers with current skills. 

• Are you proficient in iOS SDK? Way to go with a native iOS app as an MVP! 
• Fancy Javascript? Use React Native to run a Javascript mobile app.
• Are you a web-based startup? Go with web-based development based on JavaScript.

The point is: sticking to the technology you’re already familiar with might save you a pretty penny at the beginning of your business journey. 

Case #2: Your product is good enough for your users or has its own immersive UI.

You must be taking strides with your product, and your users seem to be satisfied with it. Such businesses usually opt for a hybrid solution, especially if:

• they run on a limited budget and simply can’t afford paying twice for native look and feel, seamless performance and specific OS integration features.
• their product is a kind of immersive app, such as a full-screen game, and doesn’t require standard system UI elements, like buttons, scroll views, complex navigation, etc.

In this case, cross-platform solutions will strike a compromise between your budget and the app’s user experience.

Case #3: Your users are demanding top notch user experience, and your competition is using native apps.

At this stage of business maturity, your primary objective should be to attract and retain your audience by improving UX. So even in the case of a cross-platform app, you would eventually decide to introduce some native plugins under the hood. This way, your app can access the platform-specific features, like native Bluetooth, ARKit, notification systems, or something else entirely.

Case #4: Your business requirements are so complex that only a native app can fulfill them.

Congrats, you’ve reached the level of Pokemon Go or Spotify business maturity where only full-fledged apps with platform-specific functions will fit. Your app probably requires extensive control over the mobile device (like camera, GPS tracking, NFC, etc.) and contains in-app purchases or tokens. 

The aforementioned stages are purely descriptive and vary from one use case to another. At the end of the day, you may go completely native or stay on cross-platform depending on what brings more profits at every stage.

Is Cross-Platform Really the Holy Grail of Mobile App Development? Here Are a Few Things You Should Know

Let’s talk specifics now. When discussing the cross-platform apps, we need to consider their pros & cons in the following three context categories:

Web-based apps. Developed, for example, on Ionic or Firebase, web-based apps are easy to implement but rather slow in terms of performance. They have limited access to hardware features, such as location or mobile sensors.

Language-centric apps. Built with Qt (C++) or Java, language-centric apps can be easily customized but have issues accessing platform-specific UI, like native animations, toolbars, screen customizations, etc.

Hybrid apps. Developed on React Native, Flutter, or Xamarin, hybrid cross-platform apps have the best of both worlds. You can use the language of your choice, as in web-based apps, but with the performance of native apps. 

No matter the context, all cross-platform solutions boast of the number of benefits:

You get to use the language you like or know (or work with developers who have such technical expertise). Be it Javascript, C#, or C++, cross-platform apps can be written in any language.

You can target various markets. Thanks to the shared codebase, you won’t have to spend additional  financial or engineering resources to develop an extra app.

You’ll cut your time-to-market. Because cross-platform solutions are compatible with different OS, you can quickly introduce and test the in-app changes. That leads to a faster product launch which beats competition and translates into revenues.

You’ll go easier on your budget. Cross-platform development is seemingly cost-effective; in most cases, you’ll need to hire only one team of developers to build and maintain your app.

But every silver lining has a cloud. Oftentimes, businesses opting for a cross-platform solution face a grim reality for a number of disadvantages.

• Cross-platform apps are a kind of universal knight. They work quite well for MVPs and simple websites. However, they might not fit best a specific OS because such solutions don’t use the key differentiators of each platform. 
• The software development kit (SDK) of each OS is a huge API framework that is somehow adopted, integrated, or wrapped into a cross-platform solution. Unless a developer is familiar with these SDKs, your mobile app project will likely fail.
• Each OS has a rich ecosystem of third-party libraries to be reused. But cross-platform solutions don’t. That’s why native apps allow for a much faster time-to-market and more effective burn rate as compared to cross-platform solutions in a long run. 
• Cross-platform solutions lag behind when it comes to the release of the specific features in a current platform. 
• App maintenance can become a real pain in the neck: platform-specific features are hard or impossible to support without native modules, and an app defect (if any) goes to the app creator rather than to the OS. 
• Overall UX look and feel suffers in one way or another.

Actually, a number of these disadvantages have forced Airbnb to move off cross-platform development. Different text rendering on each platform, JavaScriptCore inconsistencies, continuous investments to support the volatile landscape of the React Native ecosystem — these are only a few pain points that have impeded the company from further growth.

I wouldn’t say that cross-platform apps are the holy grail of software development. Indeed, they pave their way as a revolutionary technology but will yield positive results only if applied in specific business contexts. 

Why Developers Still Choose Native Solutions

Not all pros of cross-platform solutions are the cons of native development. Here are the key reasons why businesses consider native solutions for their projects.

Optimal Performance

Slow performance of cross-platform solutions provokes a domino effect no entrepreneur wants to see. Such apps usually wrap over native SDKs. This causes the app lagging. And slow performance affects user experience. 

Just compare the boot time of native vs cross-platform databases. SQLite database access and or REST networking performance of native iOS and Android apps is more than 500 percent (!) faster than any Xamarin analogue. You would see a remarkable difference: Xamarin is just slow.

Performance issues and frustration over long-term maintenance costs were actually the reason Udacity scrapped React Native. The load time of some animations in the app was longer than the team expected. It also hardly felt like a seamless transition, especially on Android devices which were more prevalent in international markets.

Time-to-Market

Optimal performance isn’t the only strength of native apps. Their next greatest strength is the instant availability of resources.

Think about it. With a native app, you have every tool of the specific platform at your disposal – right now and with every update. With a cross-platform solution, you constantly need to adapt to new platform features and technologies. 

You might tailor your cross-platform app manually or wait for about six to eight months until the existing solution adapts itself to the new OS automatically. But the trick is that you’ll experience this with every new OS release or update. And that also slows down your time to market. 

I see this almost every month in Apple. They often tighten the screws on what a mobile app can and cannot look like to be released in the App Store. Sometimes it’s about an additional checkbox in the Xcode project settings; other times it’s about the new key in a plist file of the product bundle, and so on. While such changes can be easily handled in Xcode, cross-platform apps will take ages to adapt. Because you rely so much on developers of the cross-platform framework/solution, your product launch is delayed and your business suffers. It’s a pity to see projects that have everything ready for the final release tomorrow, including banners and promotion, but can’t update because of one checkmark.

So unless you wish to run a race without a finish line, you’ll have to switch to native development sooner or later.

Cost

Cross-platform development is praised for its cost-effectiveness but, truth be told, this is highly application-dependent.

If your app doesn’t require access to the device features or its hardware data, cross-platform is indeed the best solution. But suppose your app needs to access CoreML, Vision, or the latest additions in secure networking, what do you do? That’s right, you still call a native developer to implement such features.

Even if your app runs on React Native, you’ll still need to implement a bridged API using the native API. So your developer must be familiar with native SDKs and experienced at React Native itself. Frankly speaking, this combination of skills is hard to find. Even if you do, the hiring process of such guys could become a nightmare: they’re expensive and hardly available for other projects.

My point is: even if you build a cross-platform app, you can’t avoid native development. Cross-platform development is still technologically tricky, and frequent consultations with the “natives” will increase the time, resources, and cost of development.

Burn Rate

Every startup knows what a burn rate is. It relates directly to time-to-market (see above) and measures how quickly the company spends money. 

Many businesses view cross-platforms solutions as a magic sword to cut their burn rate to the minimum. Tech leaders believe they will burn less investors’ money by creating an MVP fast and releasing it to the market ASAP.

In reality, this plan works only until a certain extent. Cross-platform approach will allow you to build an MVP and earn a quick buck in the face of the investors. But its polishing to the production quality and maintenance might burn your budget much faster: you can never predict the complexity of tasks to fix bugs and polish up the app. 

Key Takeaways

Obviously, there’s no simple answer as to what app development approach is better. Both cross-platform and native development can become powerful solutions as long as you apply them at the right time of your business maturity.

Let me give you a few final pointers that will, hopefully, make this decision easier:

• Cross-platform solutions are great for MVPs. If you’re looking forward to testing the waters of the market, releasing fast, and saving some costs — especially if you’re a web-based startup — cross-platform development should be a no-brainer. 
• Engineers choose a cross-platform approach for a familiar technology behind it. Just think: it doesn’t make sense for a Javascript developer to invest time and money in learning Swift or Kotlin. In my experience, they are wary of switching to native development later but will take the most out of cross-platform solutions.
• You’ll need to have a native developer at hand to consult about your cross-platform solution. Paradoxical as it may seem, cross-platform apps should be tailored to the features of the particular OS, which is impossible to do without sufficient expertise in the SDK of a particular platform and, for that matter, in native development.
• If you need to produce a best-in-class app that lasts for years, you can’t avoid true native development. Key here — best-in-class!