Comparison of Different Development Approaches

Not all apps are born equal. In fact there are many different languages and approaches to building apps. The right solution for your app depends upon many factors including: the specific requirements; budget; the importance of performance and user experience; whether you want to own the code; what hardware features of the phone you want to access; whether your requirements are similiar to lots of other apps (so there might be a platform available); and many more.

If you start down the development path on the "wrong" platform, it can often lead to a dead end. And a very wasteful and expensive trip back to the beginning. Many of our clients come to us from other developers who have forced them to use the approach that they specialise in (often out-dated hybrid languages or web apps) before realising, too late, it was the wrong approach.

We are platform-agnostic. That means we don't force our clients to select only the approaches that we prefer because we know them all and, in our experience of having developed more than 100 apps over eight years, we have developed apps in most of them. Our most important role is to use our experience and recommend the right approach for your app.

What is native code?
Native code (in terms of app development) means the app is built in the same language as the phone's operating system. So for Apple (iOS) this is Swift and Android this is Java (C and C++) or Kotlin. These apps are typically built in XCode (iOS) and Android Studio.

OK, but what does that mean?
Because the app and the phone are speaking the same language, they work better together. There is no delay for translation (lag) or chance for mis-understanding (instability) and mis-translation (security flaws). And when a new version of the operating system is released (e.g. iOS12) there are not normally any compatibility issues. And because Apple and Google like you using their languages you've got a better chance to get your app approved and ranked highly in their stores.

Sounds good. What's the catch?
Because the iOS (Apple) and Android apps are built in totally different languages, the code needs to be built, tested and maintained twice. And because native apps typically have most of their code base within the app, rather than online, changes are likely to require app version updates.

What some examples of native apps?
Pretty much all of the big hitting apps are native - Facebook, Instagram, Uber etc. This is because the performance and security advantages outweigh the costs for them.

Do we build native apps?
Absoutely. Native is where we started and most of our apps today are still built natively.

What is hybrid or cross-platform development?
The idea is great. Rather than developing two code bases (as required in native development), hybrid code should work across multiple platforms (hence the name - cross-platform). One code base to build, test and maintain. A no-brainer, right?

But why then doesn't everyone use it?
Because hybrid apps are not written in the phone's own language there can be performance issues, for example a lag when buttons are pressed whilst the instruction is "translated" into the phone's own language. Security and stability can be worse than native apps. Also, sometimes new native device hardware features can't be access by hybrid apps and new operating system releases (e.g. iOS12) can require app updates.

What are examples of hybrid app platforms?
PhoneGap, Xamarin, Flutter, Ionic, React Native, Appcelerator and many more

Which is the best?
Hybrid platforms vary a lot and their popularity changes over time. Some are better for things like data collection or integration with existing servers built on, for example .NET. Some use a lot of native UI elements and perform better. But our current favourite is Flutter because it performs (almost) natively and is supported by Google so the developer community around it is growing quickly.

So when is hybrid the right option?
Nowadays we think Flutter is the right answer as often as not, especially if budget/ timeframes are limited or you if want to test a concept quickly across Android, iOS and Web. React Native is also a great option.

What is a web app?
Honestly, we're not really sure. And we don't think anyone else is either. It's a vague term for the grey area between a "proper" app that's downloaded from the app stores and where a large amount of code and content resides on the phone itself and a mobile-friendly or "responsive" website (where the content is online). Some developers call a responsive website a web app. But they're just wrong... it's still just a website.

And a PWA?
A PWA or Progressive Web App is a new class of application that allows users to do some things on their phone on websites that only proper apps used to be able to do. For example access GPS location, upload photos from galleries and even receive push notifictions. Because they are downloaded directly from the website (or anywhere in fact) rather than through the App Stores they are more quickly accessible.

What are the problems with them?
Because PWAs are relatively new, there is very little alignment across operating systems and devices on what they can do. Apple and Android allow differing access to phone functions and there are even big differences between versions of iOS and Android. And ultimately, although web apps and PWAs can do some things offline, they are designed to be used primarily online so performance can depend a lot on things like internet connection.

So when are web apps the right option?
People today suffer from "app apathy". Your app needs to be very compelling to persuade them to read marketing blurb, go to their App Store, download, install and register on your app. If you just want to enhance their experience (for example to share photos from a gallery, get their GPS for deliveries, receive push notifications) then a web app is a quick, simple way to provide this. If your budget is very limited and you want to test the concept before investing too much, web apps also have a place.

What are "no-code" platforms?
For many common types of apps, companies have created platform solutions that allow users to quickly and cheaply launch their own branded versions of the core app functionality.

What sorts of apps can I build on platforms?
Initially the platforms specialised in making it easy for companies to launch their own marketing apps with modules for common content for these apps such as: about; contact; location; examples of work as more advanced features such as push notifications. Nowadays there are no-code platforms across a wide range of app types including data collection, eCommerce, panic buttons and even Uber-type apps.

What are the advantages of them?
Because someone has already built most of the functionality based on their experience and customer feedback, you are often able to quickly launch a branded, sophisticated app with relatively low initial development costs. They can therefore help to prove an MVP and reduce your risk.

What are the problems with them?
Caution! There are dragons here! There are many potential risks for using these platforms such as: you don't own the code, so if you want (now or in the future) a feature or design that the platform doesn't offer, then you're stuck; typically these platforms offer a low initial cost and then a "service as a software" monthly fee in US$ per user or based on usage so costs can rise very quickly with app popularity; Apple in particular have clamped down on launching apps based on platforms and they will often reject them leaving you in the lurch at the last minute; sometimes the platforms are actually just design templates where the functionality/ backend still has to be built and we have often found the code to be poorly written and buggy.

When are they the right option?
If your app requirements (now and future) fit perfectly with what the platform offers then they can be a very cost effective and quick way to get to market and prove the concept. But do your research (or ask us for advice) first of all.