Image by @goshua13

This is an informative post on the different kinds of mobile apps you can build. We will discuss the technology behind them. And, we will look at some common pro's and con's. We do not endorse one solution over the other. And, we are not attempting to persuade you into using any of these solutions.

Introduction

A new project owner has approached your business. They have decent funding. But, they don't yet have a development team to build their project. After a couple of project meetings it is determined they want to build an app.

The app should be easily update-able and be performant enough to enjoy. The app should also be completed in the next three months and be available on Android, iOS, and the web. This project is now being sent to the development team.

One of the first steps in this process is determine what kind of app architecture we should build with. The good news is that there is a plethora of solutions that can fit this project.

We can build native applications for each platform. Or, we could build a hybrid app using React Native. We could even build a web app with a service worker to enable a PWA experience. Or, we can build a simple shell app and provide a webview to the main app.

All of these options are viable. Let's review each type of app so that we may determine which is most suitable for this use-case. Through this process we hope to learn you a thing or two.

Native Apps

Native apps are apps written in the native language or ecosystem of an OS or community. An example would be writing an app in Java for Android. Or, writing an app in Swift for iOS. These apps normally have better performance and are sometimes easier to maintain.

Why do they have better performance you ask? Well, it is simple really. You are not running any abstraction layer. You have powerful memory management and diagnostic tools if the app is written properly. And, you are not running a sub-app to render the main-app in which the users interact.

Native apps are able to take advantage of native solutions and libraries more easily than hybrids. This is because native apps have been around longer than hybrids. This fact is becoming less true and the industry marches forward though. In the near future we may see just as many native/hybrid packages. (Packages are code libraries that help solve a problem)

Okay. So they can manage their memory and their native packages mo' better. But, how are they easier to maintain? I'm glad you asked! Okay. So, native apps are easier to maintain for a couple of different reasons. Let's look at API changes and community support.

Their packages and programming API's change less frequently than other solutions. This is thanks to the communities and companies behind the popular platforms. Let's take Android for example. You can still target Android 4! iOS can still target iOS 8! That means that your app can still be written to target these OS versions and their API's will still work! Pretty cool right?

I admit. This argument can be kind-of weak. Especially since the hybrid app community is making numerous improvements. We will explore hybrid apps next.

Hybrid Apps

Hybrid apps are apps that take advantage of native functionality while providing an abstraction layer to another interface. Common examples of this would be React Native, NativeScript, Flutter, and Ionic. These work by providing native API's to speak to the native app wrapper. Then, you code in your favorite framework to build your app. We will be exploring Javascript specific Hybrid Apps.

There are some major benefits to this approach. Hybrid apps can be built for different platforms at the same time. Most React Native apps can be built for iOS, Android, and the web. This reduces the workload required to target these other platforms. This also means the teams working on projects tend to be less specialized which reduces project owner costs further.

Hybrid apps also are easier for UI design and development. This is thanks to their common HTML structure (Not talking about Flutter here). Anything you can design in the browser can be built into to a hybrid mobile app. This also allows developers to break from the OS ecosystems design system more easily.

Hybrid apps tend to rely on countless community packages (software packages that solve a problem) to interact with native API's. There are numerous advantages and/or disadvantages here. Let's touch on a couple of benefits first.

First, these community packages tend to provide a wrapper around the native API. These wrappers are usually not 1 to 1 with the API's they are wrapping. This means they tend to simplify API usage or add additional functionality to the API. This can be extremely useful for when you are interacting with some difficult native API's. This wrapper layer also allows the hybrid app to write one set of code and target two or more operating systems.

Community packages can introduce major risk to a project as they tend to be updated more frequently. This is because they are normally not developed with the full weight of a major tech company. They tend to be community hobby projects. Or, a solution that was developed specifically for another company that was eventually open-sourced. Community packages also introduce security risk into your project.

Please note: Security risks can be introduced through community packages. This is because so many developers have their hands in the cookie jar here. They can be intentional security holes. Or, they could be included by accident. But, when you use a popular community package, attackers can more easily exploit your project when a security hole is found and exploitable. (looking at you Log4J) This problem is present in any programming environment that the developer chooses to include community packages. This is not isolated to Hybrid Apps.

Hybrid apps tend to be performant. But, they can also be a little slower than native apps. This is because the Hybrid app is being rendered by the native app integration. You are essentially running two apps in one. This is less noticeable as of recently. Our devices are becoming faster and more capable.

PWA

This one will be veeery short. A PWA (Progressive Web App) is a website that registers a service worker for offline capabilities. These are not inherently bad. But, should serve as a saved website on a mobile device more than anything. Please do not depend on true PWA's for client work that needs more than a "bookmark" of sorts.

PWA's are essentially a bookmark that the mobile OS saves to the home screen. You can access them like an app. Android treats them more like an app than iOS. iOS you have to click "share" then "save to home" to install the PWA. Android on the other hand will allow you to click a button that installs the service worker.

PWA's can be very convenient and allow for truly rapid development. However, they are very lightweight and lack any access to native API's. They also can not be listed on app stores.

Performance here is determined by the speed of the internet connection. All content must be delivered by a web page. This can be not ideal when internet connections might be weaker.

Webview

Webviews are a native app strategy that aim to create a PWA experience within an app container. The advantage to this is using "some" of the native API's provided by the OS. However, through our research we have found that these apps tend to be rejected or de-listed from app stores as they can be difficult to scan for malicious code. And, they don't meet app store policies.

Webviews work by having a real native app host an internal browser without showing the browser controls. (Basically how the OS treats a PWA) The webview can talk via webhooks to the website api. And, the native app can receive data from it as well. The part that typically violates the app store policies is that they can not look at the code. And, there is no content moderation available to the app stores.

Performance here is determined by the speed of the internet connection. All content must be delivered by a web page. This can be not ideal when internet connections might be weaker.

Conclusion

There are many app building strategies and architectures out there. What you use will likely depend on the needs of you project. Let's review.

Our new client project meets a lot of criteria for the PWA. However, we know this is not the best option after reviewing what each app type is and how they work. What we can determine is that the best option for this project is a Hybrid app. We can target multiple operating systems simultaneously and provide a small development team. This will reduce the cost to the project owner while promoting a dependable app. We can push regular updates to the app stores more quickly than native apps as we can develop the fix for every platform at the same time.

We hope that you have a better understanding of the general app architectures and how they work. This article is meant to be a broad overview.

Please listen to the project sponsor or owner regarding the needs of the project and business. These will typically steer your decision making towards something ideal for them. Every project will have different requirements. These requirements will inform your decision making. You may not even use any of the general architectures mentioned in this article.

What are your thoughts? Did we get anything wrong? Is there another app architecture you prefer? Do you have a solution to the Webview policy issues? If so, let us know in the comments!