How to select an architecture for your app

Hello friends, 

In today's article, we will discuss mobile apps, more specifically how to choose the implementation your new app. There are quite a few different options for app development, but these mainly fall into two major camps: Native mobile apps and mobile web apps. I will cover a brief definition of each type of app architecture, and the various considerations for selecting one over the other. Now there are many different ways to develop mobile apps, with many different languages to choose from. In this article, we won't be discussing any cross-platform framework or development languages, but two high level approaches for getting your killer product out and used on mobile devices. These are Native mobile apps and mobile web apps. With that, let us get started.

Definitions of different types of app architectures

Mobile apps have exploded in popularity since the iPhone was released in 2007. Today there are hundreds of thousands of apps on both the App Store and Google Play. The list of these apps is seemingly endless. At the start of the mobile revolution, there was only a couple of ways to develop apps for either the iPhone or Android, with Xcode (Objective C) and Eclipse (Java / Android SDK) being the two main choices. 

Native mobile apps
Native mobile apps are designed and coded to be run on a specific mobile device. These apps are built upon the foundations of the device's own O/S and use their core services to do things on the device, show a window, access the camera etc. Native mobile apps are designed and coded to be used on a specific device (IOS/Android), and generally a particular type of device (Phone/Tablet). Native mobile apps are installed on the device using the respective App Store. Each time a developer wants to deploy a new app to an App Store, it needs to go through a rigorous approval process from either Apple or Google. Similar approvals are required each time updates to an app are required.

Mobile web apps
Mobile web apps are software that is designed to be run in a browser on any type of device. Mobile web apps are built on web technologies of HTML and Javascript to do the heavy lifting of the front end. Mobile web apps typically cannot access the core services of the device so they are more limited in what they can do vs their native mobile app cousins. Mobile web apps are deployed to a web server without any device installation required. 

Things to consider in choosing native vs mobile web architectures 

So let us dig into the considerations in selecting the architecture of your app. This is not an exhaustive list of factors, however, it should provide some food for thought in terms of making this crucial decision. 

The critical thing I would like you to take away from this article is that while it is technically possible to deliver most functions in any given architecture, there are positivities and negatives involved in each path. While you may have your heart set on creating the next viral app with your killer product idea and dominate the App Store charts, it may be more suited to mobile web implementation. So please take some time to carefully consider how you will architect and deliver your app.

How is the product expected to be used?
The first consideration we will discuss is what does your product actually do? What is the core reason your app is needed? Is the app's use case a quick 10-second social interaction? This requires an app which opens fast, gets straight down to business and then is shut down equally as quickly. In this situation, a Native mobile app would be the best choice to provide the responsiveness and the ability to tidy up things in the background long after the user has moved on to the next task. 

Or is your use case a quick 5 minute game with rich graphics and soundtrack to help the tram ride go quicker. Again in this situation, a native mobile app would be a better choice to deliver the performance and responsiveness required to power the gameplay. 

Conversely is your use case, a product that is used a handful of times per year to help you get your finances in order or to book an appointment with a specialist doctor. The interactions would be typically longer and would require more data entry for later processing. However, the app wouldn't really tax the device, nor would it need access to any camera's, GPS etc. In this use case, a mobile web application would be a better choice to entry and store the information. Additionally, when an app is used infrequently, we often find that they struggle to maintain their place on the device, especially for devices with limited storage, with the settings offloading infrequently used apps. Consideration of what your product does will go a long way towards your selection of app architecture.

What does the product need to do its job?
The second area to consider after we know the functionality of our app is to understand what the app will need access to do its job. For instance, if your app needs to use the features built into the device such as GPS, Accelerometers or internal storage, your app may not be suited to be deployed as a web application. Now access to things such as the device's camera can be achieved on mobile web apps so this is less of a decision point than it used to be. However, I feel if an app has to implement a lot of computational logic such as image compression or encryption, to achieve performance and user experience expectations a native app may be more suitable for this purpose.

On the other hand, if your app doesn't need to do anything fancy with the device and only needs to render a lot of content, a mobile web app would be a suitable choice. 

How often will you need to update it?
The 3rd consideration we will discuss is how often the app will need to be updated. Is the nature of the app such that it requires frequent updates to remain current, or is the app more static in nature with less regular updates being pushed through? With native mobile apps, there is more friction involved in updating an app, with an approval process in place which each and every update requiring approval which can take up to 24-48 hours to process. With mobile web apps, the update process doesn't need approvals from Apple or Google and is only limited by the speed of your development cycle. Apart from the increased friction around the app approval process, with the native mobile apps, you also need to factor in updates to the two major platforms (if you support them), which is further complicated if your app supports both phone and tablet versions. The updates to the mobile web are done only one time for all platforms. 

Resources
The final consideration we will discus is around resourcing. Does your team already have experience in either native mobile or mobile web apps? A pre-existing knowledge of a particular technology and a track record of delivering in it gives you a headstart on delivery of your killer product. While needing to learn everything from scratch can have a negative impact, especially if the deadlines are tight, and the technologies being explored are bleeding edge.

The other vital consideration around resources involves the ability to support the apps once they are deployed and require updating. If your app needs to be deployed across IOS and Android, phone and tablet, there is a lot of work to support keeping the versions in sync and updated. This is ok if you have a good-sized team able to juggle these demands, however, if you have a small group, then supporting this may be a stretch.

Conclusion 

I hope this article gives you food for thought in terms of how you will deliver your mobile app using either native mobile or mobile web development. As I stated at the start of this article, this is not about which framework or language decision. Still, more around an architectural decision to select an app deployment to each device or a centrally deployed web application. Both choices have their pluses and minuses, so the decision really comes down to the particular needs of your app, and your ability to resource them.