In the first article of the series, I briefly introduced mobile app development technologies. Let's look at them in more detail now. Which factors are key for the mobile platform? How do the individual approaches we outlined last time stand up to scrutiny? Just to jog your memory, we’re comparing SPA/PWA, Native Wrapper and hybrid (Flutter) and native technologies. 

We take into account the basic factors our customers usually focus on and specifically ask about. These include the price (first and foremost), security, performance/optimization, access to device functions (bluetooth, NFC, camera, security storage, ...) and last but not least, platform coverage (Web, Android, iOS). As you go from SPA to native development, you will notice an increase in most factors including price. In some places, however, the differences are so subtle that the issue is not so clear-cut. 

However, all the parameters must be viewed in the context of your digital product, that is to say which stage your product is in, primarily. But we’ll explore that in the next paragraph.

How much will it cost?

Price is definitely one of the key factors as founders make their decisions primarily with regard to ROI optimization. This is absolutely understandable, whether we are talking about self-funding or external investment. The price for the development of mobile applications increases with the level of functional requirements and size of the development team.

The cheapest solution is to build a website or an SPA. This gives you a solid foundation, a bargain at twice the price. In addition, if you decide to go the SPA route, you will also have the backend ready for the future mobile app.

If we take a web application or an SPA and enrich it with service workers and a few other functionalities, we make the move to PWA. Sure, it will cost a little extra, but it gets us closer to native-like experience. Though a little pricier than with PWAs, the Native Wrapper is one alternative to consider.

The transition to hybrid technology means writing the whole application from scratch. There is not much to reuse. Here comes one key decision in terms of price: do we embark on the path of hybrid or native development? Remember that native development will always be about 1.5 times more expensive than its hybrid counterpart.

How about security?

You can read on the Internet that SPAs are worse off in terms of security than server-rendered web applications. This is because most of the source code is on the client side. However, if you follow all the established rules for cookies, authorization, and authentication, you are OK. In addition, when talking in the context of mobile applications, the client-side source code argument is relatively odd. And with PWAs, it's the same story.

Moving on to Native Wrapper, the use of limited code obfuscation or access to security storage devices is beyond the scope here. That gives us slightly better security.

On the other hand, faced with developing an app with special security demands, such as banking apps or just generally those working with sensitive user data, the decision between hybrid and native development comes again. We can use native code obfuscation or access to secure storage hardware in both cases. Thus, there is a significant increase in the possibilities of application security and backend communication. Again, you need to follow the authentication and authorization standards mentioned above. Hybrid technologies have slightly more limited options than native technologies, but it depends on how low-level we need to get concerning security. Last but not least, there is the possibility of using a native workaround in a hybrid codebase (which Flutter allows). This means writing specific parts of a hybrid application in native code, separately for each platform.

Make the app sexy

Honestly, this is a rather vague request that almost everyone makes. But what does a sexy app mean? First of all, quality UX/UI design. If you're going to experiment, do it with UI, but stick to familiar UX patterns depending on the platform.

Using all the proposed technologies allows us to customize the interface according to the platform. And therefore we always do it. The same pattern and better performance can be applied here, from SPAs to native applications. When animation and other heavy performance components come into play, Flutter or native development is the right choice. It will always work best on mobile devices. One such example is Spotify and PWA Spotify Lite.

Let's utilize all the features and sensors phones have

We should first investigate camera access. You can approach it with any solution, the only question is what it will look like and how deep you will get.

So it's worth thinking about how customized your approach will be. In addition, in the case of a web browser or a PWA, you may run into problems due to support on iOS devices. Some customization enabled on Android may not work automatically for iOS. You need to be careful and keep this in mind.

The further we move from a SPA to native development, the more low-level we get. The same applies to other features, such as NFC, Bluetooth, accelerometer or gyroscope.

Communication with other applications within the mobile ecosystem represents another problem with PWA. Case in point, accessing contacts on the device is not possible at the moment, but there is light at the end of the tunnel. This functionality should be released at least for Android anytime soon.

Full coverage is required

All approaches are equal here. Whether you decide to go with mobile-optimized web applications or PWAs, you will reach the main mobile platforms globally in both cases. With PWAs, you can even "install" the app and facilitate a relatively good user experience. When I say "install", I mean to download the app to your phone and add a launcher for faster access. Keep in mind that PWA support on iOS is still limited and not all features are available to the same degree as on Android. But you will definitely recall the lite versions of Facebook, Twitter or Spotify. They are all PWAs. At the same time, you don't have to worry about uploading your apps to Google Play and AppStore. But this is a fairly contradictory factor because just as it can make distribution easier for you due to no store fees, it can make it harder for you because you don't use a global distribution channel.

All these implementations allow you to publish the application separately on both platforms. In that respect, it’s a tie. But what is worth mentioning is the ability to choose only one platform and make it your market strategy. Do you want to validate your idea through a limited group of users? Is native the only option for you? Try starting out with one platform and extend the solution to another platform the moment you manage to validate the concept through a limited group of people. Did Clubhouse decide to go exclusively with iOS because of the "more affluent" users that make up a big portion of Apple customers? Or was it that limiting the number of users makes it easier to ensure and verify the stability of the product and the ecosystem? You can think about your product in a similar way.

Now you know the pros and cons of each technology, and all that's left is the right timing. We will dig into this together in the last article in our series on mobile development.

Webinar When, Why, and How to Go Mobile

Did you miss our webinar? No worries, we have a recording for you.

Questions?

Anything else you’d like to know? Or just interested in discussing your application and how we can help you out with it? Drop me a line at jan.hauser@applifting.io.