At Shortcut, we love great user experiences! But we know that the journey from an idea for a digital service to a finished project that brings a smile to users’ faces can be long.

‍

You need to develop a strategy, set budgets, and find skilled people to help you. You also have to make technological choices. These choices are difficult for several reasons. To make good decisions, you have to be able to "look into a crystal ball," both in terms of the service you're developing and how technology will evolve. It's also hard to know whom to trust when asking for advice. Usually, people recommend the framework or language they're familiar with, regardless of the use case.

At Shortcut, we’ve worked with different app technologies for over 13 years. We try most new solutions that come out because we want to be reliable when people ask us which technology they should use.

Before diving into specific technologies, let’s start with this: There is no one-size-fits-all answer that’s right for everyone! You need to consider what your service is, what it will be, and what it could become, and then evaluate based on that.

‍

‍

What do you want to achieve?

‍To make a good technological choice, you need to think through your strategy and ambitions. The first thing you need to know is whether this first version is to test a concept or if it's something you’re sure you want. If you only want to test a concept, you might consider launching on one platform first (iOS, Android, or web) to see if it’s something worth continuing, or if you need to change direction.

You also need to think about the lifespan of the app. If the app succeeds, how important will it be? How painful will it be if you have to rewrite the app entirely? You must also consider the technical components you’ll need. How critical is access to sensors in the phone—like GPS, camera, or something else?

‍

‍

Web or app

‍Since apps entered the scene in 2008, there has been much discussion about what makes an app a “real” app and why you need an app instead of, or in addition to, a website. Let’s start with this—sometimes a website is enough! The great thing about web services is that they are accessible on any device with a browser, from phones to refrigerators. However, this is also a challenge because you need to develop something that works on all browsers and screen sizes.

There has never been much debate about where it's easier to create a good user experience. Developing a simple and understandable app is easier than developing a simple and understandable website. In interaction design, there’s something called "mental models." By using an established standard (usually quite logical) when designing things, people expect it to work similarly elsewhere. For example, if you see a door handle on one side of the door, about halfway up, you expect to be able to push it down. The same applies to digital products.

There are established conventions for navigating in an app, so people quickly know how to use an app before they even start pressing buttons. These mental models are why toddlers can easily navigate tablets. The web doesn’t have as well-established design language, which can make navigation more difficult, especially on mobile. In addition, you don’t have as much control over how things behave on different devices.

The biggest issue people have had with apps is that they need to be downloaded. This problem seems to be disappearing with instant apps. Instant apps, called App Clips on iOS and Instant Apps on Android, are parts of apps that download super quickly. You get an app-like experience as fast as you can load a website. You can also share these apps via messages, websites, QR codes, or NFC tags.

‍

‍

A quick comment on PWAs

‍Since the concept was launched five years ago, Progressive Web Apps (PWA) have been suggested as an alternative when choosing app technology. A PWA is a modern website, not a type of app. PWAs have very few native features. They can access some native functions, like the camera and location, but generally lack most. How PWAs request access to native functionality is also challenging when trying to create a good user experience. The dealbreaker for most is that PWAs don’t support push notifications on iOS devices.

‍

‍

Native or hybrid app

‍To create iOS and Android apps, there is a standard way to make apps. For native iOS apps, you use Xcode, and for native Android apps, you use Android Studio. Since the first native development tools for apps were launched, people have tried to create apps using other languages and technologies. There are two main reasons why people have developed these frameworks:

1. People want one codebase instead of one for iOS and one for Android.
2. People want to code in the language they know.

This is called abstraction. It’s technology developed so you don’t have to deal with all the system-level details. This often allows you to get started more quickly with these solutions because they simplify creating standard components.

React Native (created by Facebook) and Flutter (created by Google) are perhaps the most popular and well-known examples of this type of framework. With these frameworks, you can write in other languages (Dart and JavaScript, respectively) and get an app that works on both iOS and Android.

‍

‍

Native technology in hybrids

‍Since hybrid apps abstract away direct access to native components, you can't expect the same access to functionality as with a native app. Widgets, Apple/Google Pay, instant app functionality, access to health data, "Sign in with Apple," augmented reality, machine learning, beacons, passes (tickets), and Bluetooth are all things that are either difficult or impossible to implement in hybrid apps.

When Apple or Google launch new functionality, it won’t be available in hybrid apps until the framework maintainers implement it or someone creates a supporting library.

‍

‍

Where native is hybrid

‍Different hybrid solutions use native technology differently. While React Native translates code to real native components, Flutter only draws something that looks similar. A text element in React Native should behave the same as a text element in a fully native app because it is the same. However, there are elements in these solutions that don't rely on native code in the same way, like navigation.

‍

‍

Conclusion

‍You might think we’ll conclude by saying you should make an app in native code, but we won’t. You know what you’re creating, so you know more than we do about what you need. However, we can say that the only reason to choose a hybrid solution is development cost and access to expertise.

It’s exciting to work with apps. People spend an average of 4.5 hours daily on their phones. 90% of that time is spent in native apps. Just 20 minutes of these 4.5 hours per day, on average globally, are spent on mobile web.

If you can overcome the hurdles of developing a strategy, setting budgets, and finding skilled people, you can end up with a service people truly enjoy using. Getting through all of that and seeing the end users enjoy your service is a long journey—but worth it.

‍

1 App Annie, “The State of Mobile 2020”: https://www.appannie.com/en/go/state-of-mobile-2020/ App Annie, “How Covid-19 has changed consumer behavior on mobile forever”: https://go.appannie.com/COVID-19-Mobile-Report-H1-2020.html?