Why native app development is (nearly) always the best option.
As the Technical Director at Atomic, I often find myself talking to clients about what the best technology is to use for mobile app development. There are a lot of different tools available and in particular I am often asked about the pros and cons of cross-platform frameworks.
The development team at Atomic have the experience and capability to develop mobile apps using the majority of third-party frameworks, however, we nearly always recommend the pure native development route. This article explains why.
As a digital agency, we follow the latest developments in the technology industry very closely. It’s our job to stay up to date in order to give the best possible advice to our clients, but also to ensure we stay ahead of the competition. As the technology industry grows at an ever-increasing pace, we are challenged with researching and assessing a relentless flood of new tools and frameworks.
We see new frameworks come and go in cycles. Every six months or so a new framework pops up that promises to revolutionise software development. This is then adopted by thousands of developers who use it to create amazing products, only for something else to come along six months later resulting in those developers jumping ship.
As a client, this creates a big risk that you can end up with a product that uses an old, unsupported framework and you can’t find a developer who can continue to develop it for you. This situation is common across the entire software development industry, not just mobile apps.
This is why one of the key things we look for in a new framework, is the size of the community around it, and whether or not it has long term support. We develop all our projects with long term maintainability in mind, so it is our responsibility to ensure we build on top of mature frameworks, rather than risk creating something that ends up being short-lived.
Other key considerations are:
Speed – does the framework allow us to develop quicker, saving our clients time and money
Extensibility – does it allows us to develop custom functionality and bespoke features?
Integration – how well does it integrate with other systems and APIs?
What is a native app?
There are many different definitions and meanings when people talk about “native” apps. For our purposes, we define a native app as an app that is developed using the target operating system’s supported programming language. For Android apps, this is Java, and for iOS, this is either Objective-C or Swift.
This means having two completely separate codebases. One for iOS and one for Android. This, in turn, means we need two separate teams of developers to write code for each platform. This is often seen as a problem because in most markets businesses need their apps to be available on the two most popular mobile operating systems in order to maximise their user base. Outside of software development houses, it is normal for people to think of an app as a single entity, and not know or care that developers actually need to create specific apps for each app store.
This perception of doubling up on effort has lead to a widespread search to find a solution that allows developers to build apps in a single programming language that work for both iOS and Android. These types of apps are known as hybrid apps.
What are hybrid apps?
Hybrid apps are mobile apps that work on iOS and Android devices but are not developed using the native programming language for each platform. Instead, they use a framework, a type of development tool, which allows developers to use a single programming language to develop an app which can then work across both platforms.
On the face of it, hybrid apps sound great! Surely it means that we only need one team of developers who can write code once and deploy it to both platforms, saving time and money? While there is some truth in that, things aren’t quite so simple and we need to take a closer look to get the full picture.
Pros and cons of native apps
Put simply, developing apps natively allows you to get the best possible results in terms of quality, performance, user experience and security. Anything that Google or Apple make possible on their platforms, you can do by developing an app natively.
While the biggest downside to native app development is the requirement for two development teams, there are a whole host of positives to counteract this.
Native apps have full access to all the device hardware such as the camera, GPS, gyroscope etc. You can support complex functionality such as offline mode, push notifications and fetching data in the background so the user has the latest content available as soon as they open their app. Native apps also have the fastest possible performance as they don’t have middleware layers slowing things down. This results in a slick user interface that feels responsive and is satisfying to use.
Here’s a summary of the pros and cons of native apps:
Pros and cons of hybrid apps
Native app development allows you to do anything that is possible on the iOS or Android platforms. While hybrid app development has some advantages in terms of time and cost, the savings are not actually significant and there are limitations which far outweigh the gains. Hybrid apps are a good option for prototypes or small, low priority apps, but for professional apps where quality and long term support is a concern, native applications are the best option.
The biggest advantage of hybrid apps is the ability to develop in a single programming language. There is no denying that this sounds like a great benefit, but it comes at a cost and there are several drawbacks to consider.
Whereas some hybrid app frameworks can allow you to do most of what you can do natively, there are limitations on what is possible. There isn’t scope in this article to give an in-depth review of each framework, so I will have to make some generalisations, but our experience in using different hybrid frameworks shows that most frameworks have at least some limitations such as not being able to store data offline, limited access to device hardware etc. Depending on an app’s specific requirements, it can be possible to select a framework where these limitations aren’t an issue, but software is exactly that… soft. Things change and new features are required so you can never be 100% certain that these limitations won’t be a problem in the future. By choosing native, you guarantee that you can do anything that is possible on the iOS or Android platforms.
While some hybrid platforms are better than others, you can nearly always tell when an app has been built in a hybrid framework just by using it. The user interface is often laggy, things take longer to load and the overall user experience just isn’t as good. This may be an acceptable compromise, but for a lot of brands the quality of their engagement with their customers is extremely important. So, having an app which is substandard compared to their competitors just isn’t an option.
And finally, the biggest issue with hybrid apps, in my opinion, is the fact that you are dependent on a middleware layer. As discussed earlier in this article, there is a risk that the framework becomes obsolete and you have to rebuild your app, but there is another issue which is highly likely to happen that will negatively affect your end users: Operating system updates.
Apple and Google release new versions of their mobile operating systems on a regular basis. Apple generally releases a major update every September, with dozens of minor updates throughout the year. Google takes a similar approach but Android updates are generally quite slow to reach end users, whereas iOS updates are made available to end users within days of being announced.
This causes problems for developers as operating system updates can often mean that changes are required to their apps in order to keep them working when the update is released. As approved Apple developers, we get early access to operating system updates which allows us to test our apps before the update goes public. This provides a window of opportunity to make any required fixes and submit an updated app before the release date.
As hybrid apps use a middleware layer, it is not always possible to do this because the middleware layer needs to be updated first. So, you have to wait for an update to the framework before you can even start testing your app. We have experienced several occasions where the framework update wasn’t available until after the new operating system went public. Having a broken app in the app store is very damaging to a brand’s reputation, and as app developers, being unable to do anything about it until the middleware framework is patched is a very stressful situation. So if the uptime of your app is a high priority, then this reason alone is enough to make the decision to go native.
Here’s a list of pros and cons for hybrid app development:
The decision on whether to go down the native or hybrid route comes down to whether the limitations of hybrid apps are acceptable, and how much the time and cost saving would be.
Let’s explore that time and cost saving…
Weighing it up
It sounds reasonable to assume that if we don’t need two development teams, then the development cost should be halved. Unfortunately, it’s not quite that simple. iOS and Android are very different operating systems and the way you write code for one is different to how you would write it for the other. Hybrid development allows you to use the same programming language, but you still need to write code specifically for each operating system. This conditional code increases the size of the codebase as you end up with a lot of code that says “if iOS do this, else if Android do that”. In places, this can double the amount of code required, which requires double the amount of time.
There can still be a good amount of code reuse, so there are some savings to be made in terms of development time. However, it is nowhere near 50% and in our experience, it is more like 10%. You then still need to test everything on both platforms, which takes the same amount of time regardless of how the app is written.
So the cost saving is fairly minimal, what about the time-saving? If you develop a hybrid app, you can have one team working on the app for both platforms from start to finish. However, if you develop it natively, you can have the iOS and Android teams working in parallel which actually means you get to market much quicker.
Another benefit of having dedicated iOS and Android developers is that they specialise in their respective platform, and have much more in-depth knowledge of how that operating system works. They are also highly likely to be users of that operating system so they are more in tune with how end users expect an app to work. It can be infuriating for an Android user to use an Android app that has clearly been developed by an iOS developer and vice versa. Again, it’s all about user experience and their perception of quality in your app and your brand.
Airbnb, property rental platform, have publicly shared their experience with native and hybrid app development. Their mobile apps are fundamental to the success of their business and quality it top priority.
However, in 2018, Airbnb abandoned the framework citing that they had failed to achieve the goals they originally aimed for; instead of being able to develop faster, they found their development team was putting the majority of their effort into debugging issues with the framework which slowed them down overall. They also had to spend a lot of time writing code to bridge the gap between native and hybrid code as the required functionality didn’t exist in the framework.
There is a lot we can learn from this. Airbnb is a multi-million dollar profit company and has the capital to invest in different technologies and take a different direction if required. No doubt the switch back to native will still be painful and require a lot of resources, but it is well within their capabilities. A lot of smaller companies do not possess that capability, so it is imperative to learn from others and make sensible decisions early on.
Hybrid app development is perceived to be much cheaper and quicker than native development, but in reality, the difference is very slim; there are so many drawbacks that in our opinion, native is nearly always the best option. For basic apps or prototypes where quality is less of a concern, then hybrid development is a viable option, but for professional app development which puts you ahead of the competition, native app development is the only option.
This is why at Atomic we made the decision to invest heavily in recruiting and training separate teams of native app developers. While we can develop hybrid apps if clients specifically request this approach, we will always advocate the native mobile app development route. We always aim to build long term relationships with our clients, and this starts with developing high quality products that can be supported long term.