The Real Cost of Cross-platform Development
If it is too good to be true, it probably is. That flat we rented for a great price but had the loudest neighbours. That Kickstarter product we ordered that turned out to be a joke. That outfit we bought which only looked great online.
The value just wasn’t as substantial as we hoped for. But we went for it anyway — against our gut feeling — since the savings were tangible.
Most of us who have come across mobile app development have faced the dilemma of cross-platform vs. native at a certain stage. We have all heard very compelling cases on the potential amount of money we were supposed to save with the prior. And a lot of us have gone down the road of cross-platform development. But not many have come back saying it was worth it.
So why is that? Why do companies continue to be disappointed? Why do they fail to assess the real cost of cross-platform?
Because it’s damn hard. The million-dollar question — often times quite literally — is:
‘Should we go cross-platform?’
When you ask that question, you are really looking to measure saving over potential tradeoffs. It’s like placing a weight on each side of the scale: the anticipated saving by going cross-platform over native and the anticipated cost of the same.
Let’s have a quick look at those savings:
- Common Code: The main argument for going cross platform is that you need to code less. Mostly true, especially if you are aiming for 3 or more platforms. But with Windows Phone obliterated, this case is becoming less prevalent.
- Single team: Having one team makes life relatively easy, right?
- Building on existing skills: you can use your existing HTML, JavaScript, C# skills. To what effect, remains a question.
- In-sync versions: You have one version so you are in sync. Unless you have to redevelop the UI for each platform.
- Unique framework libraries: Some frameworks have them. But they mostly exist because you can’t use regular native libraries.
You can often see companies only considering the Savings side. “Look, we can have 60% common code!”. “We are only going to need one team!”. “Our current C# code can be entirely reused!”. It is pretty easy to convince yourself that you can quickly realise $100k of savings on a $200k project.
It is certainly what cross-platform tools encourage you to think like. After all, it is their business. But it’s too good to be true.
“THE CATCH”
If you would like to go for a more balanced approach, you will have a hard time. Unfortunately the tradeoffs are much harder to measure accurately. While the cost saving on coding time or building new teams is relatively easy to estimate, assessing the cost of performance loss or UI tradeoffs is very hard to quantify. Let’s just highlight some of these costs:
Cost on User Experience:
- UI tradeoffs: The more native experience you are going for on each platform, the further you go down the rabbit-hole of using less common code. Also forget about the fancy animations of native apps.
- Feature delay and restriction: Since the framework sits on top of the OS, you now have restrictions. All your native competitors can roll out features faster, plus they will have access to all features while you most likely won’t.
- Performance: Maybe the biggest and most recognized pain point of all. Your app will be larger and clunkier. You will try to optimize but that will drive you further down the rabbit-hole.
Cost on Development:
- Learning curve: New tools need to be learnt. New architectures are introduced. Sometimes the learning curve is so steep that savings are completely diminished on the short run.
- Community size: There is at least a magnitude gap in the size of the community behind native vs. your chosen cross-platform tool. It will not only mean that you won’t find readily available answers on Stackoverflow but you will struggle to find platform specific third party libraries to speed you up. Integration of third party services for authentication or analytics can easily become a difficulty.
- Layer of complexity: The framework sitting on top of the native OS introduces a new layer of complexity that can act as a multiplier of bugs — especially when it comes to large, interconnected apps.
Other Costs:
- Building the team: For some HTML-based tools it might be easy to build a team. For some other tools such as Xamarin it seems easy. The problem is that you can’t just assign a .Net developer and expect the savings to be realized. Unfortunately, you need intimate understanding of all targeted OS’ plus the Xamarin tools and architecture. Then you might be able to realize most of those savings. But people with this knowledge are hard to come by. Attracting and retaining top talent is pretty difficult as well if you are trying to utilize a framework that makes development seem more painful over native.
- Flexibility: Eventually, your product’s fate is tied to the platform. If user or business requirements of your product change over time, you might not be able to follow. If sudden changes take place in the platform, you need to cope (like Microsoft killing RoboVM recently). This carries an inherent new layer of risk.
- Security: Most professionals agree that introducing a new layer on top of the native OS introduces a completely new layer of vulnerabilities as well. Another headache.
- Cost of rebuilding: Lastly, there is a chance that further down the road you will realize that you need to rebuild the whole product in native. Due to framework limitations. Due to low app store ratings. Due to hiring difficulties. It’s a massive cost and a massive time loss.
You would of course be right to point out common code savings are more likely to be realized than the cost on a framework-related security breach. But these factors are still present and they have a very tangible business impact. So now that scale looks entirely different.
‘INHERENT DISADVANTAGE’
To be completely frank, cross-platform has its well deserved niche uses. One is using Unity3D in game development. Another is utilizing Xamarin for B2B apps with massive business logic and little UI. So is going for HTML frameworks if you have a really tight budget.
But if you put users first — something that your competitors will do — cross-platform is generally not worth it.
And I am not only talking about fancy B2C apps which are trying to win space on the market. There is no more saying “This app will do, it’s internal-only anyway”. You would want to keep your best and brightest efficient and happy by providing them tools with a great UX. If you won’t, the competition will.
But let’s just take a final step back and focus on the big picture. Why does cross-platform put you in an inherently disadvantaged position? The answer is rather philosophical.
You are introducing a complex new layer on top of the native one to realize some anticipated savings. In return, you are willing to accept tradeoffs in User Experience, development and various other areas. You are accepting an inherent, undeniable handicap compared to your competitors in the quality of your product in order to save cost. In theory the company going native will always triumph over the competition if all other variables are fixed, and development costs are a small part of all costs. It is how the mobile ecosystem is constructed.
Anyway, here is a key takeaway. If you are ever about to make the decision of cross-platform vs. native, you better look well into those tradeoffs. The value proposition for cross-platform needs to be very-very compelling for your product in order to reap real, long term benefits.
Don’t fall for the classic mistake. If it looks too good to be true, it probably is.
Quick disclaimer here: Over the years, we built over 100 mobile apps at Supercharge and we had the opportunity to test a good number of frameworks. We have had a long love and hate affair with Xamarin. We built apps using Unity3D. We flirted with Phonegap. We always ended up going back to native.
Andras Tessenyi, CEO @ Supercharge
