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, if you already determine that your startup or business needs an app, this article delves into the successive decision: what kind of app should you build?
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, we’re 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.
- A website which is responsive or formatted for mobile, serving content from the Internet accessed via a browser on the mobile phone.
- 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.
Why build native apps?
We believe there is no technology that by default is best in all circumstances.
Rather, we should try 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 us 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)
In the recent past, we have 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.
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.
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.
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.
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.
The Clipsal iCat App has a web-based management system that allows both us and Clipsal’s internal teams to create simple HTML apps and add these to the native navigation of the 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
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?
- 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)
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.
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)
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.
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, automatically making it simpler to update and extend.
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.
Our recommendation thus remains a Native approach. Follow the link to see examples of our mobile app development work.
Grant Hull, CEO and Director at Enabled
Grant has helped guide Enabled through the “Dot Com Bust” to grow steadily ever since. A popular presenter and speaker in the digital space, he has also been teaching an annual innovation course at the University of Adelaide.
Follow Grant on Twitter and LinkedIn