As you start to build a new mobile app (or maybe you have a mobile app that needs major renovations) — the first technical choice is: Do you leverage one of the many cross-platform tool-set available or go directly to the iOS and Android SDKs?
There are absolutely situations where the cross-platform tool-set approach is preferable to writing and maintaining purely native applications on multiple platforms. But before you hook your horse up to that attractive looking wagon, let’s discuss a few important considerations that might save your project, and your bottom line.
Cross-platform mobile development has come a long way in the last couple of years. Lessons learned have pushed the development of these frameworks to address the more painful points (performance, access to native APIs, test-ability…), moving further from the old Hybrid approach that leverages WebView components toward a much more native experience.
That being said, here are 5 Things to Consider Before Leveraging Cross-platform Mobile Development Frameworks
1. It Ain’t All Technical.
Oh, I’d love if it were. But let’s not pretend that it is. If it were, then the considerations would be much easier.
You only get one chance to make a first impression. And if your application is not responsive and intuitive, then your retention rate will suffer. Of course, if it takes you 2 years to get your MVP into the customers hands, they may already have something else to hold.
I will say this unequivocally: An application written entirely using the native platform SDK directly will result in an application that is functionally equal or better than one written using any proxy framework. I will not qualify this statement here except to put the burden of proof on the counter-point: How can a tool-chain that relies on generated native code (as well as a bridge to access said code) ever perform better than something written directly to the native platform? It cannot, and thus the choice isn’t about technical superiority, it is about time and money.
The reality of the situation is that there are a lot of tough decisions when you intend to spend good money creating something that you expect to leverage to make better money. Somewhere the Wallet behind the work is going to want some input on how much it’s going to cost, and how quickly bills are going to start filing back in instead of falling out. This is probably the greatest driver behind making the tough choices. I support the Wallet, and I don’t envy his job. What I will tell him, and I am telling you now, is please sit at the whiteboard with me and discuss the risk versus reward of the next 4 points we’re going to discuss. If you can’t say them out loud, then maybe you don’t yet understand the risks. And if you don’t understand risks, then you don’t really understand the final costs.
2. Hold My Beer, I Got This.
Let me slow your roll right there.
The languages for mobile development are Objective-C/Swift for iOS, and Java/Kotlin for Android. If you do not have a developer with these proficiencies, then you may not be able to objectively make the right decision. I’m not saying your RockStar developer isn’t capable of “stackoverflowing” his way into a demo-able version in the vein of your MVP. But are you both sure he can actually produce that MVP on his first attempt into this new realm? Can you afford this new expedition? This leads to my next point…
3. Down the Rabbit Hole.
Shortcuts can be dangerous. One time, pre-Google, my wife and I were trying to get to a party. The major roads were busy, so we decided to cut through a neighborhood we’d never been in before. We knew the destination was just on the other side. We certainly spent the time moving in the right direction, and we saw some really nice houses and landscaping that we decided we might incorporate ourselves. However, what we learned after spending that time is that even though we got close to where we wanted to get… we couldn’t quite get there. We had to go back to the front of the neighborhood, and get back onto a path we knew would succeed.
Your lead developer is your navigator. If he’s not familiar with developing mobile applications, then bear in mind that choosing the cross-platform shortcut may take you down a path that will not lead easily (if at all) to your MVP.
4. Keeping Up With the Jones’.
Apple and Google have done a fine job of making sure that iOS and Android stay current to meet the ever changing needs of the consumer and push the capabilities of our evolving mobile devices. XCode9 with Swift4 is coming out this fall. Kotlin is just starting to get its hooks into Android, as Java 1.8 support is leaking into Android Studio (Canary). Think about this… there is no other platform on which the underlying hardware technology evolves, the operating systems evolve, and the very development languages evolve on a semi-annual frequency that is adopted by the general population. Quite literally, if it takes you 6 months to author both iOS 1 and Android 2 applications, your development lifecycle will experience at least one major-revision language migration on one or both platforms. And note the key words in that last sentence: “major-revision”. They aren’t tweaking the languages, they are transforming them. Not to mention the myriad of hardware accessible changes (Bluetooth Low Energy, Graphics, Camera,…) and additions (Watches, VR devices,…). Keeping your application, unit tests, and build environment up-to-date with all these changes will be a full-time job. Whatever methodology you choose to bank your code base on will need to move just as fast. This sets up my last point…
5. Who’s Steering this Boat?
Whenever you choose to put a proxy between your code and it’s target platform, you are choosing to give up some level of control. This is the risk/reward point that you will eventually have to make. What you are deciding is to take the risk to speed your MVP to market at the expense of some level of control. For simple, minimal applications that don’t interface too heavily with external components and don’t have very complex background tasks, this is very advantageous. For applications that are more complex, there will be a need for some level of Native coding in addition to the cross-platform work. And this means learning not only the native languages but also the framework environment that sits between you and your platform. And if your choice of cross-platform tool-set can’t keep up with the shifting landscape from point 4 above (or worse, fails to maintain support at any level), then you’ll learn the hard way that the risk you thought you were taking just tore off your rudder and threw out your oars.
And remember, not only are these frameworks supporting changes to the Native APIs, but they are also trying to keep up with changes to the other underlying technologies on which they are built. Take for example Ionic, who recently released Version 3.0 that was migrated to Angular 4. Since the initial release, there were 13 updates address numerous bug fixes — in just 4 months.
Need a Little Bit More…
Don’t let me scare you away from the cross-platform tool-set. But the risk rewards truly need to be quantified through analysis. Consider that Facebook leverages a cross-platform framework for part of their mobile offerings. But Facebook isn’t likely to let that framework (React Native) steer their application. Facebook will steer React Native. After famously transitioning from using an HTML5 approach to a native application offering (2012), Facebook authored their own cross-platform framework. Not many companies can mitigate the dependency risk that way.
If you’re still early in the life-cycle of your mobile development and don’t have your own Native mobile application team, let us help you understand your risk/rewards.
Orange Robot is customer software development firm that designs and builds native mobile applications and back-end server solutions.