Why I Don’t Use Cross-Platform Mobile Dev Tools
How I decided. The reasons may surprise you.
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?
I could go into detail on the differences of each genre of toolset but since the comparisons between them have been defined time and time again Ill try to keep this part short.
Native Development:
Using platform specific tools to create an app for iOS or Android. I.e. there is one codebase for each platform. The toolsets usually include Swift/Objective-C + Xcode/Appcode for iOS and Kotlin/Java + Android Studio for Android.
Cross-Platform Development:
Using a platform/tool that translates/compiles/runs your code as native components. The process differs depending on what tools you use but the end result is that native code (or close to) is run on the device your app is installed on. This essentially means that you can use one programming language to make an app for both iOS and Android.
Some example tools include: Xamarin, React Native, Flutter
Hybrid Development:
Using a platform/tool that runs a webview that your app is then hosted in. What this means is that your app is essentially a website that is run from within a native app. The platform/tool usually provides access to native functionality like the camera through plugins.
Some example tools include: Cordova and Ionic
Primary vs. Inherent Characteristics
To properly understand my decisions I need to explain two different types of tool 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
Over my years in software development I’ve had the privilege of using multiple tools for many different projects. Usually, the choice of toolsets was made for me by management or by the primary engineer on the project. Once I jumped into freelance I decided to niche down into a technology stack in order to introduce consistency in my work. This meant that I had to make a difficult choice, what should I work with?
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
When I first started programming back in 2013 there was a lot of chatter about Cordova and Appcelerator. After a few years the conversation switched to Xamarin. A few years after that it was React Native. Now? Flutter is making a name for itself.
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.
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
This is something I don’t hear many people discuss when comparing tools. I have asked various developers and even tech business owners about this and the closest thing I’ve received to a response has been a blank stare. It is important to know the kinds of business values and vision that the supporting people or organizations have. Their values can be a clear indicator on the future trajectory of that tool.
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
Ah yes, time savings. The holy grail of development efficiency. This hotly debated topic surrounding ANY development tool can make or break a business. It is at the forefront of any project as it directly affects cost. But let us take a step back for a minute and ask ourselves a question.
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
Ultimately, there were many other considerations I made before actually choosing native development. Many of which I made throughout my career trying different tools, processes and mindsets. Including them all would make for an incredibly long article though. So for brevity I will include a list of some of them.
Things that I considered before choosing native development:
- Developer onboarding/learning curve
- Supporting infrastructure
- Development pipelines
- Maintaining antiquated projects
- Layers of abstraction = increased opportunity for bugs
- Availability of developers (# of developers using said tool)
- Business hierarchy (Airbnb has a great blog series that touches on this)
- Platform’s reliance on plugins
- Developer happiness while using the tool
- Design overhead: the need to design in a way that supports both platforms
- Out of the box project structure
- Knowledge resources
- # 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.)
- Licensing + cost
- Landscape of mobile operating systems. Ex. for how long will there only be 2 main players?
Conclusion
So far I’ve been using native development as my primary toolset for the past 2 years. One of the many reasons I’m happy with my decision is that I took the time to consider as many angles as possible for each tool. I know the pros and cons and that feels empowering.
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.
