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.
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.
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.
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.
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.
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.
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?
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.
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.