Over the past two decades or so, people have gone from “How do I build a website?” to “How do I develop a mobile app?” or “Should I have a website or a mobile app?”
The safest (and most accurate) would be “it depends.” That said, this article might appeal to you more if you’re involved in an established business, or a startup wanting to cut through the clutter.
How Apps came about
The launch of the iPhone in early 2007 changed the way the world viewed the mobile phone, but it was the iTunes App Store introduced a year and a half later that brought transformative change. Through this store, software became a thing for general people and as a result, Apps became truly personal.
For the first time Apps could surprise and delight. They were simple but never skimping on the details. They were sticky, causing the user to return more often, and they were only ever an arm’s length away.
They were also coded natively.
If a business intends to use an app as a central tool for interacting with customers and stakeholders, it must deliver an excellent customer experience that delights and fosters ongoing use. Dissatisfaction with a main channel of customer engagement may lead to low app uptake at best and churn at worst.
Without a doubt, the majority of the best mobile experiences today still continue to be delivered through native applications, while other development options continue to fall short and disappoint.
For this reason alone, Enabled is unapologetic in our recommending the use of native code to create native apps. Let’s explore further.
What are the development options on mobile?
For simplicity purposes, there are three major options for providing functionality to mobile phones.
These are:
- A website which is responsive or formatted for mobile, serving content from the Internet accessed via a browser on the mobile phone.
- An application developed using a web technology layer such as HTML, CSS and Javascript that is downloaded as an App to the phone (e.g. PhoneGap, Cordova). Usually this web-tech layer still needs to talk to the native layer provided by the operating System.
- Natively Coded applications (Native), in the case of iOS in Swift and Android most likely Java, which is downloaded as an App to the phone.
If you want to get specific, there are a number of options along the spectrum Web-Native, as shown in the graph below.
A Hybrid Mixed (sometimes called Native Hybrid) app is usually a combination of 1 and 3, or 2 and 3, where code written for the device and some content or functionality is loaded into the app from a web server.
Option 2 points to a Hybrid Web or Packaged Hybrid app, i.e. a true app but one predominantly coded with a non-native framework or language.
Source: Outsystems
Why build native apps?
We believe there is no technology that by default is best in all circumstances.
Rather, Enabled’s core philosophy is to understand what a user is trying to accomplish and choose the best digital technology to facilitate this (we wrote about this framework - Jobs To Be Done in another blog post).
Therefore, it is prudent for Enabled to recognise that any existing website may already provide a mobile-friendly format with many functions desired in an app.
The question then is: What benefits does an app bring that a mobile-enabled website cannot? The logical answer would be activities enhanced by being mobile e.g. for a user on the move.
Logging in to a website to periodically check requires diligence. An icon on a mobile phone screen would encourage more frequent engagement. Providing gentle reminders via badge icons or more explicit alerts via push notifications provides additional encouragement. Gaining attention of the user while out and about via a push message is also an enhanced feature not possible with a website.
A generation of users being mostly mobile and on the go provides a strong case for a mobile offering in app form. Let’s explore the pros and cons of each development option for mobile phones.
1. Web-served (or Packaged Hybrid)
Some have tried exposing portions of a website via web-views and wrapping this in an app shell.
This method is not advisable as it runs the risk of contravening 4.2 of Apple’s Developer Guidelines: “Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store.”
Apple’s stance is: if it is a website, it does not need to be an app.
Although this is more possible on Android, this method does not adequately allow basic functions such as push notification and location-based notifications.
2. Middle Web-Tech Framework (or Hybrid Web)
Using a framework like Cordova allows JavaScript to be used to build actual apps and overcome Apple’s 4.2 clause. An app built with this framework also allows push notifications and geo-location triggered alerts, which on the most part are only possible with an app.
In the recent past, Enabled has built apps with such frameworks with moderate success. One of them was even a fast-paced promotional game for Clipsal.
Success is a subjective term, because although these apps were functional, the limitations of the framework caused these apps to fall short of our vision and short of the standards we usually expect from our work. Moreover, the Clipsal game consumed the same budget that would have been required to construct two native apps, one for each platform.
In our experience, most of these frameworks easily allow you to reach 80% of the desired functionality, though the remaining 20% often requires much more than its fair share of the budget.
Unfortunately, some of these difficulties are hard to foresee until they are stumbled upon. Most are related to getting these cross-platform frameworks working consistently on all of the different devices and operating systems.
An example of a Cordova app by Enabled: My Wine World
Problems with these middle web-tech frameworks are:
- Slow speed in loading the app and loading the screens (compared with native)
- Compromised interface, aiming for the lowest denominator between Android and iOS
- User alienation as interface elements look similar to native but do not behave as expected
- Inability to utilise the unique strengths afforded by each of the platforms’ user standards
- Too many edge cases and bugs to address as each OS and each device model can conflict with the code generated, leading to considerable testing / fixing overhead
- High consumption of budget required for developing two native apps
- Other general performance issues especially on Android handsets
- Ambiguity in understanding if it is the developer’s code or the framework’s code that contains an issue
- The above means development tools and code themselves contain bugs that have to be overcome. This might be beyond the capabilities of a typical web-developer.
- Myth that because websites are easy then using web-tech to make apps should be easy. This is only true from the perspective of a web developer who would need to learn how to properly code software to create an app. For software developers, native applications are faster to create and deploy.
(We also wrote about how to choose software developers in another article.)
Apart from first-hand experience of these issues, other apps developed with these frameworks all share similar app store reviews with words like buggy, slow, laggy, and unintuitive.
Unfortunately, these faults may be small, but reviews featuring lists of faults are more prominent than those discussing the features of the App.
3. Native and Native Hybrid (or Hybrid Mixed)
A native app means it has been coded in a language that is natively provided by the two platforms. On iOS, this would be coded with Objective C or Swift and on Android, Java. This gives app developers considerably more control with the user experience and also allows them to design the apps for easy support and extendibility.
Note: coding an app natively does not remove the opportunity to leverage web content loaded from a web-server. An app that does this is considered a Native Hybrid (or Hybrid Mixed).
In reality, many of the apps developed at Enabled are automatically considered native hybrid.
We use the native components where speed and responsiveness is most important, e.g. navigational elements. Then we display web content in web views when motion and interactivity is minimal, or that content management is important.
Web views that can be loaded into an app are not just limited to content. HTML5 / Javascript applications can be deployed via a web server and displayed within the app.
The award-winning Clipsal iCat App developed by Enabled has a web-based management system that allows both Enabled and Clipsal’s internal teams to create simple HTML apps and add these to the native navigation of the App.
Clipsal iCat app
The app can thus be quickly extended functionally outside of the Apple App Store review process. Should these functions become popular, they can be recreated as native components to deliver an enhanced user experience.
In short, a native approach will better allow any future extension and place the app in an excellent position to take advantage of new features offered by Apple and Android.
The curious case of React Native
The development framework built and mostly maintained by Facebook has gained traction in recent years. Essentially, it allows developers familiar with the web language (Javascript) to build a mobile app that has a native feel.
You can also drop native code in the app if needed. Some big names using this framework are Facebook (obviously), Instagram, Walmart, Airbnb.
Sounds good so far, so what’s the catch?
As it uses Javascript, React Native inherits the headache caused by this language too. Other issues are:
- Constant updates required, as React Native is relatively new
- Lower performance and efficiency than native frameworks
- More work if the app needs to take advantage of native components (also mentioned in the next section)
Other advantages of native apps over web apps (or language)
Coding frameworks
An important consideration is that non-native tools were never created to make the best apps. They were created to try and save writing code twice, but most have been created to allow a larger population of people to make apps.
Thus, a majority of non-native apps may be poor because these tools are the choice of less sophisticated developers, whose skills shortfall leads to lacklustre result.
A lot of success in mobile today is about removing small pieces of friction that have little impact in theory, but in reality make a huge difference. Not just in the software itself, but also in the activities that these apps support.
Introducing a 3rd party non-native development framework decreases our likelihood of eliminating these small pieces of friction. On the contrary, new points of friction will actually be introduced.
The app we built for BrewArt - the world’s first fully automated beer brewing machine - is an example. For an Internet of Things app that needs to talk to a piece of hardware, imagine the friction and pain it would have created had the app been built in a non-native language.
Screens of BrewArt - the Internet of Things app
User Experience
Technical and functionality shortcomings aside, non-native apps cannot compete on responsiveness and user experience.
Without spending a considerable amount of effort in testing and optimisation, an app using web-tech is simply no match for a natively coded app offering superior experience.
We expect the computing power in smartphones and development tools will improve over time and become capable of delivering better experiences. We will continue to trial these technologies to determine use cases for them.
Over the next few years, we expect the opportunities with native apps will continue to stay several steps ahead those of web-tech.
Currently, there are many aspects only possible with a native approach.
Apple, in particular, has a vested interest to ensure experiences offered on its platform are the best possible. They therefore incentivise the construction of Native apps by providing new features that are not available through web-tech options. These currently include and are likely to include:
- Apple Watch extensions and applications
- Integration with Siri voice activation allowing functions of apps to be accessed without opening apps
- Deep app indexing and interactivity between apps
- Custom Integration with Apple Pay
- Apple CarPlay considerations (rumours of Apple Cars themselves, of course in the more distant future)
Clipsal iCat Apple Watch app concept
Android has a similar situation. Akin to the Apple Watch is Android Wear which requires native code, but also Android widgets are native extensions that place content directly on the home screen. Widgets can be used to display key information, which a user can see without even opening the app.
Maintainability
Apple is continuously improving its hardware, and both Apple and Android will enhance their operating systems and coding environments, with a major release at least every 2 years.
An app once developed must be maintained to keep up with these hardware and operating system changes. This could include fixing bugs and creating enhancements to take advantage of new features on offer.
Dealing with a middle web-tech frameworks is another layer that needs to be maintained. Often, updates to these frameworks by the communities that maintain them lag behind Apple and Android, causing durations of poor function, or additional development work to fix the frameworks or establish workarounds.
The true software environments of Swift and Java also require that better code be written. Better code means less technical debt will build up over time, making it simpler to update and extend.
In summary
An app that does not capture the imagination of a first-time user is unlikely to regain traction with that same user in the future.
With this in mind, our imperative is to build great experiences at all costs because not doing this could cost the whole project.
Enabled’s recommendation thus remains a Native approach. Follow the link to see examples of our mobile app development work.
