If you’re running an early stage startup, you know how to make the most of limited resources. From getting the most bang out of every marketing buck to jockeying the pace of a small development team, you must execute quickly and efficiently to ensure your company’s success.
This is one reason hybrid app development is so attractive: It allows you to build iOS and Android apps simultaneously instead of having to write code twice using each platform’s native language. The result is two apps for half the work, precisely the kind of efficiency an early stage startup craves.
The simplicity of hybrid development was the driving factor for deciding to adopt it when we began working on the Android version of our first app, Prep4GMAT. But as we found out first hand, simplicity and ease of use can come with high costs once your app gets more complex; we had no choice but to switch back to native development.
Making the switch cost us money, time and effort, and put the company at risk. Making the right decision in the beginning is crucial. Here are three lessons we learned that (hopefully) will prevent you from making a similar mistake.
Define What You Need Your App To Do — Now, And In The Future
Your app’s technological requirements should drive the decision of which development strategy to adopt.
If your app’s desired functionality requires complex communication or data extraction, the use of platform components such as the GPS, camera or communication chips, or advanced graphics and UI/UX, you need to develop native.
If, on the other hand, platform components aren’t used heavily and the app’s design or functions and UI/UX are straightforward, hybrid development can provide the capabilities you need, with the added benefit of speed and efficiency.
Your first priority is to get a product to market and test it.
Of course, the real challenge is predicting the technological capabilities your app will need in the future. At LTG, we misjudged the restrictions we’d face with hybrid development as we added more advanced features to our app. While hybrid worked great initially, we began hitting technological walls and QA almost ground to a halt, which necessitated our switch back.
Although you can’t predict with perfect accuracy what you’ll need your app to do in the future, assess current and future technological requirements to the best of your ability. If they are heavy, choose native.
Don’t Let Business Needs Outweigh User Expectations
Users only care about the experience of using the app and the utility they get out of it. They don’t care about the technology behind the app. Smartphone owners use around 26 apps a month, and you can bet that the apps they use most all have superb UI/UX. The bottom line is that if your app doesn’t live up to such standards, users will quickly uninstall.
While the design of your app’s UI/UX is separate from development, technical aspects like speed and responsiveness are not. So, if you are salivating at the prospect of expanding quickly to both Android and iOS with hybrid development, make sure you’re not sacrificing the app’s usability. People will not use a slow or clunky app. It’s not to say you can’t have amazing UI/UX on a hybrid app — you can; however, there are more limitations with hybrid, so make sure these are not an issue before choosing this route.
If You Choose Native, Focus On One Market First
If it looks like native development best fits the needs of your app, you’re probably wondering how to develop two separate apps with the limited resources of an early stage startup. The best advice I have to offer — which worked well for us starting out — is to not worry about tackling both the Android and iOS markets initially. Pick one platform to start, and leave expansion to the other platform for later. Your first priority is to get a product to market and test it.
Once you’ve proven the product in one market, then consider ramping up your development effort and expanding to the other mobile app market. At this point, you’ll likely need to hire more developers. Although having two teams costs more, one benefit we’ve discovered is that it creates friendly intercompany competition. Each team inspires the other to produce a better app.
We’ve found that developing natively works best for us and, understandably, most of my advice is colored in the light of this experience. Native development matches our needs the best, and that’s the bottom line in choosing one development strategy over the other. You need to find the process that works best for your company’s needs.