Why I Don’t Use Cross-Platform Mobile Dev Tools

How I decided. The reasons may surprise you.

Rob Barber
Nov 5, 2019 · 10 min read

Let me tell you a secret. I love the idea of cross-platform tools. To be able to use one toolset for all my work is a dream. Who wouldn’t want to use just one tool to get the job done? Code once run everywhere? Sign me up.

I also love the idea of a utopian society. One where everyone respects others’ beliefs, have meaningful/logical/intelligent arguments and challenge themselves to be better than they were yesterday. However, the real world is rarely, if ever, that perfect.

I’ll admit, I’ve been meaning to open up on the argument between native vs. cross-platform/hybrid app development for some time. It’s not from a lack of motivation but rather from a hope or a wish that one day a unified toolset would come along, kick down the doors, and provide the best value in creating mobile apps. I’m still waiting for that day and this article should help explain my affinity for native development.

Native, Cross-Platform, Hybrid Mobile?…What?

Native Development:

Cross-Platform Development:

Some example tools include: Xamarin, React Native, Flutter

Hybrid Development:

Some example tools include: Cordova and Ionic

Primary vs. Inherent Characteristics

There has been much debate over the years as to how one tool is better than another. Most articles review the obvious features of a tool like codebase size, development time, how many platforms the tool can build to etc... These comparisons are based off of what I like to call “primary characteristics” of each toolset. They are the pieces of functionality or features that were intentionally built into each tool and are marketed to the target audience. Primary characteristics of a tool are the most straight forward to reason about and weigh against other tools as you can usually quantify their value based off of empirical data (i.e. speed of development, build time or even response time of a list-view in the end build). These characteristics are usually what most people are concerned with but they don’t tell the whole story.

In order to fully understand the consequences of choosing a tool consideration of its “inherent characteristics” must be considered. These characteristics are usually more subtle and harder to quantify than primary characteristics. Unfortunately, recognition of these characteristics usually only happens after the tool is chosen and heavily invested in. If you have ever heard of a developer discuss the elegance of a framework or lack of documentation then you have encountered some inherent characteristics.

Making a proper decision on a development tool requires an understanding of its inherent characteristics.

Why I Chose Native Development

Ultimately my final decision came down to considering not only the factors of the tools but also how the inherent characteristics will affect each project in various situations over time. Here are my considerations.

1. Popularity over Time

What I’ve found is that the popularity of a tool also represents the support it gets. If the tool is owned by a private company then the popularity equates to sales, which then leads to more money for support. If the tool is open source then popularity relates to how many active developers are improving the codebase. Popularity can come and go and affects the entire development ecosystem around that tool.

Take a look at this Google Trends chart that looks at different cross-platform tools over time.

Google Trends chart roughly depicting search results for various cross-platform mobile technologies.

While this chart is more of a rough estimate on popularity (since it only represents search results) it does put some understanding on what I was experiencing as a developer. Businesses and individuals tend to use what is new. This doesn’t necessarily mean a tool is better or worse (as many articles will argue for/against regardless of release date) but that people jump on what’s new.

As a tool is released it tends to be hyped up by the development community and seen as the “future”. This can cause older tools to then have less support and slowly atrophy over time. As a developer I see this as the need to relearn a new tool every few years in order to produce the same products. So that list-view that I create, which acts the same across toolsets, could be coded differently year to year.

Contrast this to native development which is guaranteed to have support. As long as Apple supports iOS and Google supports Android native development will ALWAYS be relevant. This why native development has the biggest ecosystem of developers; it has just been around for longer and has been consistent in its popularity.

Another consideration to make is with project handoffs. The likelihood that the next person has at least some experience with native development is fairly high. Even if they don’t primarily work with native tools most developers have at least touched the tools in some way. This is far less likely with cross-platform tools.

2. Business Values/Vision

Take Xamarin for instance. Back in February 2016 Microsoft bought Xamarin for around $400–500 Million. At the time Microsoft’s vision was all about a mobile first future. They made some great strides with the tool and even included it as an “out of the box” add-on to Visual Studio and Visual Studio for Mac. Fast forward just a few years and Microsoft’s vision shifted to artificial intelligence.

Throughout this shift I was working on a project with Xamarin. During this time I saw the platform I had enjoyed using go from a robust state to a slowly degrading toolset. Each update to the tool felt like a hail-mary pass sitting with your fingers crossed hoping that your work wouldn’t be affected. At best, everything worked as it should. At worst, you spent hours or even a day or two rolling back updates and trying to get your environment back into a workable state.

This slow degradation isn’t documented on the Xamarin homepage (which makes sense) but if you search high and low over the forums you can start to get a sense that something has changed over time. Posts about things that used to work out of the box are just broken now or how the developer’s experience with the tool has changed. All of this has a direct impact on the cost of development not only from raw hours but from the quality of the code.

Friction using a tool causes overhead and lost profits.

I’ll admit that native development has its issues here. For instance, Apple usually tries to force a developer into a certain way to develop (i.e. using Storyboards or MVC pattern). The tooling isn’t always polished either, which is why I actually use AppCode for most of my iOS development. However, both Apple and Google spend an enormous amount of time and money making sure that native development works well for developers. Just take a look at Android Jetpack, SwiftUI or even the move to Kotlin and Swift.

Ultimately I stuck with native development here. It’s not that Google or Apple both have the best vision in the world but rather that they have the most consistent. There is such a low risk that either company will stop supporting their tools that it’s hard for me to choose even a slightly more volatile toolset.

3. Time Savings

What methods should we use to save time?

I’ll explain. Much like in software in business there is usually more than one way to solve a problem. The solution largely comes from that individual’s or businesses’ situation. This means that a “one size fits all” approach is dangerous; it also falls very close to the “we have always done it that way” mentality. Unfortunately, when it comes to mobile development the common approach to save time is to choose a cross-platform tool. But is this the best way? Could we, say, come up with another method to solve the issue? There is a saying in business “People over Processes over Tools”.

People over Processes over Tools

This is exactly what should be considered when making a decision. How is the development time affected between choosing a tool vs. creating processes/procedures or even creating a different development mindset?

Does a tool solve bad mentality when coding?

Does a tool allow for a more streamlined development process?

Could a slightly tweaked process or mentality produce better time saving results?

Could we use infrastructure to solve our needs?

All are valid questions that also reveal the complexity in a decision. Things aren’t as straight forward as choosing React Native over native development. What is right for you or your business? Well, only you can make that choice.

My decision ultimately came down to this; since native development will produce a higher quality product, at a base level, and be supported almost indefinitely, it will be my choice for a toolset. My own personal values drive this choice (to strive for excellence). This then brought me back to development time. Native development does take more time (how much more varies greatly). Is there a way to save time? Should I even need to save time? Should I just look for projects where budget isn’t a problem?

One way to solve the time-savings issue is to create reusable code and take on similar projects. Just like the DRY principle in software I can use the same idea in freelance. Create tested reusable code that can quickly be iterated on and deployed to multiple projects. Since I chose a toolset with longevity in mind I can rest assured that my reusable code will be useable for quite some time.

4. Other Considerations

Things that I considered before choosing native development:

  1. Developer onboarding/learning curve
  2. Supporting infrastructure
  3. Development pipelines
  4. Maintaining antiquated projects
  5. Layers of abstraction = increased opportunity for bugs
  6. Availability of developers (# of developers using said tool)
  7. Business hierarchy (Airbnb has a great blog series that touches on this)
  8. Platform’s reliance on plugins
  9. Developer happiness while using the tool
  10. Design overhead: the need to design in a way that supports both platforms
  11. Out of the box project structure
  12. Knowledge resources
  13. # of knowledge domains required (Ex. Xamarin requires: Xamarin Api’s + platform, C#, Android specific functionality, iOS specific functionality and knowledge on the quirks of each platform and how they interact through Xamarin.)
  14. Licensing + cost
  15. Landscape of mobile operating systems. Ex. for how long will there only be 2 main players?

Conclusion

I hope that this article helps you ask the right questions when choosing a tool. Don’t just take the marketing for face value and PLEASE don’t follow the hype train because it’s “what’s in”. Dig in, get dirty and think critically. At the end of the day you will be better off for it.

The Startup

Get smarter at building your thing. Join The Startup’s +800K followers.

Rob Barber

Written by

Multipotentialite searching for wonder in this chaotically delicate place we call home.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +800K followers.

Rob Barber

Written by

Multipotentialite searching for wonder in this chaotically delicate place we call home.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +800K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store