
One question that pops up again and again from prospective clients is this: “Should we make a native app for each platform, or just a web app or cross-compiled app that can run on any platform?” In fact, if I had a Greek bond every time someone asked us this, I would be able to purchase a small glass of beer.
So, before we get started on what you should and shouldn’t do, let’s examine the three primary types of app development technologies for a moment:
Native apps: Developed in the native programming language for each platform that the app is made available for. If you want to make the app for both iOS and Android, you’ll need to do most of the coding twice since they use different programming languages.
Web apps: It’s a diplomatic way of saying that it’s a website. The obvious upside is that you can support all platforms without having to do the work all over for each operating system.
Cross-compiled apps: They’re written in one common programming language (such as JavaScript) but with a special development tool, they’re compiled natively for multiple platforms.
To the untrained beholder, web apps and cross-compiled apps sound mighty tempting. Being able to support multiple platforms by writing an app once sounds almost too good to be true, and unfortunately, I am here to tell you that it is.
Design
First, there’s design. Design is important. It’s how you interact with the app, and it’s how the app interacts with you. Since all platforms look, feel and work differently, great apps need to be designed specifically for the platforms they are appearing on.
Designing an app one time and then using the same design on all platforms will almost certainly result in an awful experience for your users. For example, Android users are usually less than stoked to use an app that looks and behaves exactly like an iPhone app, and vice versa. It’s even more pronounced with Windows Phone’s Metro interface, which is very different from all other platforms on the market. Android 4.0 has also taken a step further away from its iPhone-inspired roots towards a more unique look and feel. This makes it pretty intolerable to reuse the same user experience across multiple platforms.
You could of course create a design that looks nothing like any platform. That way you don’t offend anyone, right? Well, as we see it, you might offend everyone, since you will end up with something that looks nothing like an app.
This is very much a usability issue. An iPhone user will instantly know how to use a good iPhone app, but an app that does not adhere to the iOS Human Interface Guidelines will likely lead to frustration. The same goes for Android and Windows Phone, and as these platforms evolve in separate directions, this divide in user experience methodology is only going to increase, making one size fits all solutions less and less adept.
There are of course design elements and concepts that can be used across platforms, but the point is that if you want to be taken seriously, you need to respect the design languages and navigational methods of the various platforms.
Web apps
The primary upside of doing web apps is that web development skills are much more common among coders. However, while it may be tempting to base large projects entirely on web content, we advice against it.
As any experienced web developer will know, web projects quickly grow in complexity as more and more functionality is added. Making very small and limited apps web based may work out alright in terms of development time, but larger projects quickly become much more complex compared to similar apps written in native code, where new functionality can quickly be added.
Also note that when writing native apps, we get a lot of the UI elements that users take for granted for free: lists, menus, transitions, etc. When writing web apps, you have to do all these elements manually. And since the various platforms look and work differently, you may end up spending a LOT of time developing all these basic things from scratch, that you would get for “free” if you made your project as a native app. This is time that could have been used on making user-facing functionality that you are now spending on making these very basic elements. And even with hours and hours poured into replicating native UI interaction in your web app, it will still not look and behave with the same feel and fluidity as a native app. It is simply not possible to achieve this with current browser technology. This may change in the future, but we need to act according to how things are today and for the forseeable future.
Cross-compiled apps
So, if web app development does not provide a good way of making beautiful and advanced apps on multiple platforms, then maybe development of cross-compiled apps do? There are several different tools that can be used to make cross-compiled apps. One of the most popular ones is Appcelerator Titanium. Using mainstream programming languages such as JavaScript, developers are able to write apps once for multiple platforms that are executed natively on the supported platforms.
This sounds great, but in reality it is not so fantastic. One of the many issues with this approach is that you are technically limited by the boundaries of the cross-compiler’s framework. If Apple, Google or Microsoft releases a cool new feature for developers to utilize, then you can’t use it until the vendor of the cross-compiler implements support for it. This means that cross-compilers are mostly unusable for more than very simple apps. If you want to make something that is cutting-edge, you will run into these boundaries rather quickly. With the rapid development of mobile OS’es, this means that you are always one step behind developers of native apps.
Additionally, if there are bugs in the compiler, resulting in bugs in your software, there is nothing that you can do about it. This is why we (and other skilled developers) tend to advice strongly against making apps this way. It is simply not desirable to invest time and money in an app that is entirely dependent on a third party, based on a technology that is one step away from the platform vendor.
Also, just as with web apps, cross-compiled apps simply do not feel right. It may not be evidently obvious to many of your users, but they will notice that your app feels laggy and unpolished, since the sort of manic optimization and polish that makes a good app great isn’t something that lends to the way that these cross-compilers are used. And since the bar for great UI design is constantly going upwards, it is getting more and more difficult to make competitive apps using these tools.
Conclusion
So how does traditional native app development stack up against these alternative approaches? With development of native apps, you will:
- Be closer to the core of the operating system enabling you to utilize the latest hardware and OS functionality
- Be able to make more advanced apps that scale better without becoming too complex to manage
- Be able to optimize your app so that it runs great on older devices
- Be able to more easily ensure an optimal design and user experience for each individual smartphone platform.
In addition, Apple, Google and Microsoft are more likely to highlight your app on their stores if you make a beautiful native app. In fact, most OS vendors tend to steer away from apps that are the products of cutting corners.
So unless you want to spend a substantial amount of money on an app that performs worse, is not as beautiful, not as user-friendly, not as stable, and forces you to work with limited functionality set forth by a third party, then we advice you to make a native app.