We already saw why you may want to have an app. Now let’s see what your options are for building one. It won’t be an in-depth, technical article, but it should give you a good overview of the solutions currently (2014) available.
The Many Worlds Of Native Technologies
In order to be able to distribute your app in current main app stores (Apple App Store and Google Play), you have to use so-called native technologies. This means that you don’t use classic web technologies such as HTML, CSS and Javascript. Instead you use languages and frameworks provided by Apple and Google. Objective-C for iOS apps and Java for Android.
Once development is complete, you compile your app and submit it to the app stores. After that, when it gets validated, your app has its place in the app store catalog and users can download it. When updating your app, the process is the same. That’s right, there are no instant or automatic updates as you can have for websites.
It’s very important to understand that apps are installed on smartphones (like classic software on our good old fashioned desktop computers) as opposed to web apps which behave as websites being accessed on a distant server through a browser.
Being a permanent resident of user phones has its advantages. Mainly, it allows us to access phone features such as the camera, and to be less dependent on network availability. At the moment, native frameworks are also the most optimized and integrated way to provide a smooth and efficient app user experience.
Facebook Paper app is a very good of the kind of UI you may achieve with native technology.
https://www.youtube.com/watch?v=IhrbT9O6kW8
The downside of native technologies is that you have to invest in several different technologies, known to have quite steep learning curves. It leads to (really) high development costs to ensure your presence on your users’ mobiles. If your economic model doesn’t have room for this kind of investment, then building an app can be a problem.
Web Technologies
Web apps have existed since the beginning of the mobile era. In fact, they have been pushed even before apps became the favored solution.
In 2007, Apple Computer launched the iPhone, the company’s first ever smartphone. When the device launched, the device did not provide any support for third-party software: Apple’s CEO Steve Jobs believed that web apps served over the internet could provide adequate functionality required for most users. Soon after its release, however, developers had managed to “jailbreak” the iPhone and begin coding third-party apps for the device, distributed through package managers such as Installer.app (which itself was based on APT) and Cydia. (Extract from the Wikipedia article about app stores.)
You can see web apps as a cousin of web sites. They use the same technologies and technical architecture (HTML, CSS, JavaScript, Ajax, web servers…) but they emphasize an application UI rather than the classic web page model.
Web apps often co-exist with apps. Famous examples of that are the Facebook and GMail apps. You can download apps for these two services and you can also access them as mobile-optimized web apps. Sometimes, it’s even the only mobile offer for big brands such as the Financial Times. Since August 2013, Amazon App Store welcomes HTML5 apps.
In the beginnings of the mobile phone, web apps could not match the native experience. They lacked many features related to hardware access (eg. Camera access). But HTML5 is progressively closing the gap, and you can now build very good mobile UI with web technologies.
But even with an almost technical parity, web apps are still web sites. Yes, you can create a shortcut on the mobile desktops but users must have a connection to launch and use them, and you won’t be in the app stores. Finally, some technologies are still only available for apps such as notifications.
Bridging The Gap
Along the path to finding the right technical mobile strategy where you can use web technologies and benefit from mobile features such as notifications, many solutions have emerged under the name of hybrid apps.
The concept behind hybrid apps is fairly simple: mixing web and native technologies. Native technology provides a standard encapsulation of an app written with web technologies. The native shell adds a JavaScript API to access the phone’s hardware and renders the HTML app using the phone’s browser. It means that you can build your UI with HTML, CSS and Javascript, then embed it into a pre-defined, native shell (one per OS) and release your apps in app stores.
LinkedIn and Facebook have been early adopters of this method for building apps. But at the time, it was hacky at best. Clumsy UI, performance and cost issues brought them back on the track to native technologies (around 2012 for Facebook and 2013 for LinkedIn).
These changes have been largely discussed and some people saw them as a proof that web technologies are no match for native technologies regarding apps. Here, we have to focus on the fact that mobile is at the heart of the growth of these big brands, and that they can afford to invest in it.
So what’s left? Is there an efficient solution for building apps with web technologies for the rest of us?
Hopefully yes. Many solutions to industrialize hybrid apps creation have emerged and matured over the last few years. Among them PhoneGap (an open source project fully supported by Adobe) is probably the most well-known. It offers a standard way to encapsulate HTML apps into native shells and thousands of apps are currently made with it.
This video gives a quick intro of what is PhoneGap.
At the same time, HTML5 is making progress, mobile browsers are becoming increasingly efficient and many developers around the world are building HTML app frameworks to help ease the work needed to create your app.
So, we’re not yet to the point where going native or hybrid is the same, but in many situations hybrid is a very good solution for lowering the cost of production, notably when apps are content-oriented.
But mind the gap! You have to remember that native technologies are fairly mature technical worlds. Don’t assume that what you see in native apps can be done out the box in hybrid or web apps. Currently, you still have to benchmark different solutions (hybrid, HTML, JavaScript… frameworks) and then glue them together to create your app, opposed to the consistency found in integrated native solutions.
This article has been carefully edited by our friend Jenny Beaumont. A thousand thanks Jenny! All mistakes are ours.
Have something to say about this article? Great! Comments are there for that. Please remember that comments are moderared. SPAM or off-topics comments won’t be published.
