Options are great – except when there are too many of them. It should be taught on the first day of Mobile App Development 101 that too many options will just paralyze and frustrate the user.
On a macro level, the same is true for all myriad options you face when it comes to building your mobile app. However, a comprehensive blog covering all of your options would be roughly the size of the internet. Instead, this guide will help you categorize your options and see a way forward, but you may still need to do more research to find the exact match for your skills and goals.
If you’re up in the air about how to build your mobile app, it helps to narrow it down to three options:
- Developing native, directly for iOS or Android
- A mobile-optimized development tool
- Some sort of hybrid approach
Here’s an overview of some advantages of the first option over the others.
When to Develop Native
The world of app development involves more than iOS or Android, but those two comprise 97 percent of the smartphone OS market. Developing native makes the most sense in one or both of those worlds.
When customer experience is paramount, nothing beats native. Apps built within the official app guidelines and within the proper ecosystem have a distinctive look and feel shared by all native apps. Typically, users will register this as a responsive, high-quality, intuitive app experience. You are also able to directly use any of the peculiar affordances of the device, such as the camera or the GPS, whereas in other approaches you may have indirect access through a variety of plug-ins.
App Store Placement
Some developers say that the biggest benefit is getting placed in the app store of the respective OS. Native apps will automatically be considered for inclusion on the app store. If you are using some other mechanism than native apps, then developers need to ensure that the output will produce an artifact which the app store will consider for approval.
After all, if you can’t be found in the app store, you’re basically wasting your time since it will be much more difficult for your potential audience to find your app if they have to go to some other source to find it, and it will take a lot more time, money, and effort to educate your potential audience about where to find your app. This may not be as much of big issue if your app is intended only for a private audience, such as a company’s internal stakeholders only, for which they may operate a private enterprise app store, vs. the general public.
The counter argument is that the app store is no replacement for marketing. Regardless, you have to get out there and promote it no matter where users go to download it. Unless it’s immediately popular, it could easily get buried amid all the other apps. The whole art of mobile app marketing and user acquisition, engagement, and retention is an entire subject unto itself, usually referred to as Mobile Growth. You can look for meetups in your area or entire conferences which are dedicated to the tools and techniques for acquiring and growing your app user base.
Regardless of your app store or mobile growth strategy, it won’t matter how many people download your app, all of your efforts for engagement, retention, UI/UX design, A/B testing etc. will be completely moot if the app doesn’t perform well. There are innumerable studies showing that consumers will delete or abandon an app/brand due to a single poor mobile experience, and app performance is one of the single largest contributors to the consumer’s experience of the app.
Another differentiator where native apps excel is if your app depends on ultra-fast graphics. If you are creating a static, information-rich app, it won’t matter. On the other hand, native does better at handling animation and rapid refresh rates. On Android, in particular, you can program directly at the operating system layer using the NDK (native development kit) in conjunction with your Java Android app. You need native if you intend to have fluid access to high-level components like the camera and geolocation.
The biggest costs derive from the development time and the fact that you are tied to the OS. When it’s time to scale up and expand to another OS, you have to start all over again.
Security is the second most quoted reason for going with native. The more moving parts, the more holes there are for cybercriminals to exploit. For the security of your native app, pay attention to the most common attack vectors that seek out weak SSL, unprotected data storage and areas where malware can deliver code injection. Also, make sure that you stay on top of the latest updates from the platform vendors, which frequently include security patches for vulnerabilities that have been identified. In some cases, your app may actually be removed from the store if it hasn’t been updated to include the latest fixes.
If your team has chosen to go native, your next decision is whether to start with iOS or Android. Here are a few considerations:
When to Go iOS Native
Apple continues to come in second in mobile market share, but the iOS app revenues are enormous. Depending on who you talk to, developers chalk it up to better quality or better branding. Strong engagement with loyal Apple users is certainly one of the top reasons to develop an iOS native app. In any case, the truth of the matter is that 94% of US app store revenue goes to the top 1% of monetizing publishers. Many developers say that the biggest benefit of iOS is a lower degree of fragmentation. You’re dealing with one manufacturer, instead of the wide range of different hardware types on Android. But even Apple now has devices in the market which can no longer run the latest versions of iOS, so you will have to make determinations if you will only support the latest devices and cease updating your app for older devices.
When to Go Android Native
Android is where many developers start due to the relative ease of working in Java. More importantly for most companies, Android has the largest user base around the world, not only in developed economies, but especially in developing countries where the much lower cost of Android handsets makes them much more attainable. This is particularly true in the largest growing market of China where there are also many local domestic Android handset OEMs.
If you are looking to expand to new markets and other countries, Android will get you much broader reach. And while each individual Android user may not monetise as highly as iOS, many strategies are linked to having a larger audience at lower ARPU. If you’re going to go to Chrome OS in the future, Android is the logical place to start since Google is making it possible to run Android apps on Chromebooks. Even Microsoft is getting on the Android bandwagon with its acquisition of Xamarin, which can output Android apps (though not native).
When to Use a Hybrid-Native Mobile-Optimized Development Tool
When mobile was young, development tools that worked across platforms were the way to go. These tools became the preferred platforms for developers when skills were scarce for native programming. There was (and still is) intense pressure to get to market quickly and teams could use these tools to support both platforms from a single code base and development environment. These mobile-optimized tools helped developers collapse the learning curve and incorporate features and functionalities from other popular apps as they only had to learn one IDE but could create native apps for both major mobile OSs.
Today, these platforms are still popular for beginners who may be intimidated by trying to learn native development in Swift or Java and companies using a single dev team to support both iOS and Android or whose developers have existing programming and development skill sets that they are leveraging for mobile development. Here are a few of the most prevalent mobile-optimized tools on the market now:
There are also many projects such as Monaca that have developed entire UI/UX libraries that very closely resemble native design guidelines like Material Design, so that apps built using it look for all intents and purposes indistinguishable from native applications. Even more importantly, the ability to use the styling properties of CSS it makes possible to quickly and easily change the look and feel of these apps.
Of course, one of the disadvantages of this approach is that it relies upon having a web container embedded in a native wrapper. The embedded web container does not have any of the chrome of a stand alone web browser (which is why it can look like a native app), but it also doesn’t support the standard web timing and navigation APIs defined by the W3C, so it becomes much more difficult to monitor the performance of the app. The web container also can add significant overhead and may limit the ability of the app to work off-line without significant effort to use local storage.
2. Appcelerator Titanium
This is another one that’s been around for nearly a decade and has seen the app market flip from B2C to B2E. Kony is a good rough and ready system that always seems to be one step ahead of technology. Kony seems to be particularly useful to companies that can’t or don’t want to have dedicated native app development teams.
Nobody can say Microsoft isn’t trying. They seem to have turned on a dime from advocating for Windows Phone to pushing a cross platform app development IDE. Part of that strategy involved acquiring this independent app development environment which is based on the open source Mono project, though there has always been close collaboration with Microsoft over the years. It’s a good platform to help developers learn C# for native iOS or Android. Microsoft is still the standard in many large corporate environments and those types of companies tend to have internal developers who are skilled in using Visual Studio and .NET to develop both internal corporate apps and external customer facing applications.
Xamarin makes it possible for these types of developers to use their existing skill sets to develop mobile applications for the most common smartphone platforms. This is particular important since in many large enterprises, employees had already adopted these devices for their personal use, so it was not practical to mandate use of Windows Phone devices, which, in the end, Microsoft is now de-emphasizing with its recent write-offs in its phone hardware divisions. Given the tiny market share of Windows Phone devices, these companies were also hard pressed to produce apps iOS and Android, and they needed a way to do that with their existing teams and skill sets.
In the meantime, it gives you a clear cut, interactive dashboard with real-time metrics for the most common app KPIs, though there can still be some bugs, such as the problem with the way Xamarin wraps NSProxy. This can cause an issue if you want to monitor the performance of an iOS app produced using Xamarin, since you need to wrap the NSURLSessionDataDelegate in order to interpose on delegate operations so that its usage can be monitored.
When to Go With a Hybrid
More developers have turned to hybrid options over the past few years just to keep up with customer expectations. B2E moves fast and competition is fierce, so companies feel pressured to generate the user experience of a native app, but with the shorter development times and pre-built components of a mobile-optimized platform.
Whenever developers mention hybrid, Ionic usually comes up among the top hybrid options. Some teams start out by building a CSS framework with the SASS extension language to contain the native look and feel. It’s built on HTML5, and AnjularJS is emerging as the go-to way to drive app features. The next gen Ionic will have drag-and-drop programming capabilities, so expect a flood of new developers to try it out. The community of Ionic developers is already strong and helpful.
2. React Native
It is somewhat ironic that this approach has come out of Facebook, since Facebook itself very publicly and spectacularly made a complete architecture switch from a hybrid native approach several years ago to fully native apps, and the main justification for making the switch was improved performance which resulted in very significant improvements in key business outcome KPIS such a the time spent in app, number of photos being uploaded etc. which are critical measures for Facebook that have a very direct influence on their bottom line which is dependent on selling ads.
There was much debate and discussion in the technical community at the time about whether or not Facebook’s hybrid implementation was the problem, and not the architecture choice itself. For example, some argued that Facebook had essentially just been cramming it’s website into a native container rather than explicitly programming it as a native/hybrid app from the ground up.
Of course, very, very few companies have the scale of a Facebook both in terms of the number of users (wouldn’t we all love to have the problem of a billion plus MAUs?) and the amount of the content being run through the app, so any performance hit from taking a hybrid approach is much less likely.
3. Mobile AngularUI
This is one of the new advanced hybrids. Mobile AngularUI is ideal for enterprise-level developers who are comfortable with Bootstrap 3 and AngularJS modules. However, it also has built-in mobile components like switches and overlays that aren’t in Bootstrap 3. If you’re not a fan of jQuery, this hybrid bypasses it for libraries like fastclick.js.
Native development in iOS or Android (or both) makes the most sense to take full advantage of the native capabilities and if you have development teams that are experienced in the native IDEs or you have hired a third party development house that can do the same. Mobile-optimized platforms like Appcelerator Titanium and native-hybrid Phonegap are best for single environment development teams and when devs don’t have the skill sets or inclination to learn Java and Swift. However, a hybrid approach using technologies like HTML5 can run the risk of making it harder to monitor the performance of your application, especially once it is in production. It can be a fast way to get a minimum viable product on both Android and iOS especially by leveraging existing skill sets from the web or other programming languages.
Regardless of what approach you take, it is imperative to monitor the performance of your app once it goes into production, so you can then iteratively upgrade and refine the app based on metrics and user feedback. It may be tempting to just rely on app store ratings and reviews to get feedback from your users on problems, bugs, crashes etc., but by that time it may already be too late if the user has deleted the app due to a poor performance experience. More over the poor ratings and reviews are public and may negatively influence other new users from even trying the app.
Consequently, no matter what approach you take, it is absolutely imperative that you have a strategy and plan for monitoring the performance of your app in real time.
We’d love to hear which route your dev team chose in the end and what were the deciding factors. If you used a mobile-optimized platform or a hybrid that wasn’t listed here, let us know in the comments what you found and how it worked out. Similarly, let us know about your experience in monitoring the performance of your application, and if you haven’t started yet, then get in touch so we can help you get going.