There are many solutions for mobile application development that give a “write once, run everywhere” promise. But is this a real thing? Is it true that you can write the code once and then run it on different platforms without much hassle? There isn’t one simple answer and it really depends on what your goals are and what resources are available to you.
Terms
First, let’s define some terms we are using in the following text:
Native apps are built for one mobile platform with native tools. To build a native iOS application developers will have to use Xcode toolset with Objective-C language, and for Android it’s Eclipse with Java. These apps will always look and perform best.
Web/HTML5 apps are built with web technologies such as HTML5, CSS, ASP.NET or others. These apps run on the server-side and can be accessed with a mobile web browser. It’s relatively easy to adapt these apps to run on different platforms. A developer only has to style the web page appropriate to each platform and adapt it to the screen size.
Hybrid apps are usually built with web technologies but are run as native apps on the device. HTML content is wrapped in a native container, which allows the app to use native APIs and have access to the camera, accelerometer and other functions that simple web apps cannot use.
Semi-Native apps are coded using one programing language and are then customized to every platform’s specific code before they are released. These solutions will build true native apps but they have limits that we’ll discuss later.
Native apps
Most of the apps on your smartphone are native. Developers have to write separate code for different platforms. Two main platforms, Android and iOS, have more than 80% of today's market share. So the question arises: is it worth it to target the rest? It all depends on your product, but for most companies there are enough users on just one platform.
There is a general consensus that native apps are the best performing and best looking apps. These are very important properties that define how a user will experience an app. Better user experience leads to higher user adoption, engagement, usage and overall satisfaction. Research shows that native apps can increase usage volume up to 100 percent compared to web apps.
Web apps
The promise that you will only have to write code once and it will run on all platforms is very tempting. If you MUST be on all platforms and have very limited resources, then the web app approach could be your salvation. It’s also worth mentioning that a web app is your only solution if you have a subscription but don’t want to add it to your app and split the revenue with Apple.
One example of a successful web app supporter is the Financial Times web app. Their decision to go with a web app was mostly encouraged by Apple’s unwillingness to lower the cut they take and unwillingness to provide information about their subscribers. While companies usually see an increase in users by going native, Financial Times claims that they saw bigger user adoption in the first weeks of their web app than of their native app. You can read more about their decision in Financial Times' technical Q&A.
Hybrid apps
One of the biggest problems with web apps is that they cannot access the camera, accelerometer, GPS, and other functions on a device. Additionally, it’s impossible to get a list of contacts or save big files on a device without an Internet connection.
This is where hybrid apps come in. The most popular solutions, but not the only ones, are Sencha and PhoneGap. Developers code a web app with HTML and JavaScript and then using those tools wrap it in native containers. This allows for rapid deployment of apps on different platforms and to use some native APIs such as the camera or GPS. This is a very good approach if the app uses a lot of HTML to render its contents. Examples of such apps could be journal or news apps. For example, the Wikipedia Foundation mobile app was built with PhoneGap. When you think about the content of Wikipedia, it makes a lot of sense to use this type of solution, as all of the content is HTML. However, if a developer wants to display connections between articles, as in the WikiNodes application, then PhoneGap becomes too limited and it’s almost impossible to build a quality app with these tools.
Semi-Native apps
So how about semi-native apps? Authors claim that you’ll be able to reuse most of the code for all platforms and this will save you a lot of resources. If you want to build a semi-native app, you first need to make sure that the company behind your chosen solution is deeply committed to supporting it in the future. This is because you might bind yourself to a product/solution that is not guaranteed to stay around for a long time.
In writing a semi-native app you will tap in to native APIs on different platforms. These APIs are different; therefore the code will have to be different. You will have to build separate UI for each platform because they differ so much. If you don’t do this, the apps will not look native.
The semi-native approach is a viable solution if you don’t have programmers that can develop a native app but you do have a team of JavaScript or .NET programmers in-house. You will not have to teach your team a new language but you should take into account that there will be loads of new things that will take time to learn and understand. At the very least, you should have someone with moderate experience in mobile application development. There are a lot of startups offering semi-native solutions but I would recommend checking out Appcelerator Titanium (JavaScript) and Xamarin Monotouch (.NET).
For a final thought about semi-native apps I would like to share a comment that sums up my opinion: Sure you can pound a nail in with a screwdriver. But do you really want to?
Future
You should always think about what you want to achieve with your current app as well as your future plans. What functionality will be necessary for you to achieve your goals? You could save some money by developing a very simple web app, but as the app develops and more functions need to be added you will have to rebuild everything from scratch.
A recent example is Facebook and how they had to remake their app from scratch. This quote from Mark Zuckerberg on using HTML5 as their main technology illustrates how important is to make the right choices from the start. "We burned through two years on that," Zuckerberg said. "It probably was the biggest strategic mistake we made." He also claims that people are consuming twice as many news feed stories using the new iOS app compared to the old one. Visually almost nothing has changed, but because of increased speed the app became more appealing and user-friendly.
Conclusion
The mobile market is big and getting bigger. Therefore, it makes sense to start with one platform, validate the concept, and build out to others . In such a competitive market it is very important to deliver the best user experience and focus on main functions. For example, Instagram initially built a wonderful product on one platform, and only when they perfected every little detail and process of their app they released an Android version.
At Devbridge we firmly believe that technology should enable, not limit a user. There isn’t a one-size-fits-all solution when it comes to deciding on what type of mobile app is right for your company. Contact us and we will help you choose the best technology solution for your unique needs.
