A bit off topic: delivery options for mobile offerings

Short quick series on mobile development


I am realtively new to the board and Wappler, but i thought I could add some value to the mobile side of development

(Background information: I am a full time product manager and developer for web and mobile experiences and app development)

If this is usefull for the wider group, I am happy to share some bits and pieces around mobile app and web development over the time. If so, let me know and I add more basic information around this topic.

Lets start first with the different options we have to deliver mobile experiences to the customer.

When I say “mobile experience”, I mean specially designed experiences for mobile usage, like shorter user journeys for mobile (think of simplified sign up forms, replacing passwords with pins, push and in app notifications, animations and transistions to support communication) or targeted features like biometrical login or widgets for the home screen, to name a few.

Responsive Web

  • Single Codebase for Desktop and mobile web (iOS, Android …)
  • Not Distributable via App Stores

Usually one website that addapts between desktop and mobile views with little to no mobile experience.

(Historically, „responsive“ was used to adapt web sites for different desktop screen sizes or to support smaller window sizes and full screen windows. It was not really planned to use „responsive“ as a technology to scale down desktop full hd to a mobile mini screen. Bootstrap specifially with it’s „mobile first“ appraoch changed this.)

Mobile Web

  • Two Codebases, one for desktop, one for mobile web (iOS, Android)
  • Not Distributable via App Stores

Websites designed and build for mobile with targeted user experience, e.g. UI and user flows adapted for mobile users.

PWA

  • Single Codebase for mobile web (iOS, Android)
  • Not Distributable via App Stores (except TWA/Trusted Web Apps on Android)

A user „installable“ version (“add to home screen”) of the site with some offline capabilities and dedicated caching to get as close as possible to a mobile user experience with limited hardware support, like biometric login or camera access. PWAs run full screen without any browser ui and support a launch screen.

Apple has some limitations with regards to the PWA implementation, e.g. no notifications or deep linking into the PWA.

Wrapped PWA

  • Single Codebase
  • Distributable via App Stores
  • Two native builds required (iOS, Android)
  • Mac or remote build service required to support iOS

A PWA wrapped in a native core application (very thin layer, actually a web view without any UI). Wrapped PWA’s can be submitted to the App Stores, however Apple is not keen allowing browser based apps in the store, as Apple can’t control the content.

Google allows PWA directly in their stores (TWA, “Trusted Web Activities”). Publishing to a store allows a better user experience for distribution.

Hybrid (Capacitor, Cordova)

  • Single Codebase for iOS and Android
  • Access to device hardware through native wrappers
  • Distributable via App Stores
  • Two native builds required (iOS, Android)
  • Mac or remote build service required to support iOS

Apps build using web technologies (HTML5, CSS, JavaScript), bundled together with a native application layer. Depending on the UI framework (Ionic, Konsta, Onsen, Framework7…) hybrids can look, behave and act like native applications and have access to the underlaying hardware by using native cross platform runtimes like Capacitor and Cordova. The final bundle is a fully native application.

Transpiled / Cross Compiled (React Native, Flutter, Xamarin, Codename One)

  • Single Codebase
  • Distributable via App Stores
  • Synergy effects to backend development team (due to shared technologies, especially for Microsoft environments)
  • Two native builds required (iOS, Android)
  • Mac or remote build service required to support iOS

Cross compiler / transpiler allow to port, for example, C# or Java into runtime code for a native applilcation. Similar to Hybrids, they come with a runtime layer to execute the compiled bytecode on the mobile.

Native iOS / Android (Swift, Kotlin, Java)

  • Two Codebases (iOS, Android)
  • Distributable via App Stores
  • Full native support of underlaying hardware
  • Two native builds required (iOS, Android)
  • Mac or remote build service required to support iOS

Full native development for iOS and Android. Typically used for applications that require access to specific device features or performance sensitive developments like 3D or VR games.

10 Likes

Kudos!
I have searched far and wide for some years over hundreds & hundreds of forums, websites, videos, etc. always trying to break down these categories of what was “doable”, feasible, best practice with what current technologies on this whole issue of APPS.

This is the BEST Categorization of the divergent platforms available in 2023 that I have seen with the clearest explanation of each.

Too often even the most explanatory sites only mention 3 basic Mobile app categories and use inconsistent terminology that conflicts with another source’s descriptions.

This information is REALLY helpful, and, yes, does raise other questions for me in specifics … but, for now, I just want to express my great appreciation, Heiko.

This should be your special category of Documentation at Wappler Forums and I would love to see some tutorials later when you have the time or inclination.

1 Like

Thank you @NewMedia, glad you liked it / it was usefull to you.

To be honest, I left out the the “best practise” or “this is the best use case for” as all requirements are different for everybody.

But from my experience, I can say:

  • For a tailored mobile experience (not just a responsive small web), for many customers, espcially local / small business, a properly designed mobile web site is sufficient.
  • PWA are a good compromise, but it’s challenging to get the user to “install” it locally. Believe it or not: many people have no idea how to bookmark a page (and thus trigger the installation of the PWA) on their mobile web browser.
  • A submittable app, no matter if its a wrapped PWA, a Capacitor app or pure native, has some benefits with regards to the user experience, to name a few:
    – the app stores are building trust, the customers trust your app automatically (especially on iOS). This is important for any e-commerce related offering.
    – Ccustomers know how to use the app stores, to download and install an app.
    – Deeplinking (opening a specific screen / page in the app from a URL) across all platforms is only possible via native submissions;
    – Native acces to the hardware layer, such as databases, bluetooth, biometric login (latter is actually also possible via web), access to compass, native screen rotation,… is only possible on native apps / capacitor / cordova or any other plugin driven runtime.
1 Like

You can actually do this on a Cordova app. I’ve used branch.io in a couple use cases.

I use currently for a forgot password magic link that logs the user into the mobile app or the web app depending on where they click the link. This is not so much of a deep link, but easily could be.

And in an earlier app I built, we generated branch links that would prompt users for app install (if not already installed), and then direct them to a specific content page all based on the branch link.

2 Likes

100% percent!

With regards to „deep linking is not supported“, I referred to PWA. Cordova/Capacitor is already native (except Cordova Web, but that’s a different story)

2 Likes

Hi… what is the best tool to do this?
i have a PWA… or can i create a mobile project inside of wappler? and use something like “webview” to wrap my website… or would you recommend a different tool or way to go about this… I’m hoping its as easy as pie in wappler… but could not find anything in the search.

Please can you see my question here

You insight will be much appreciated. Thank you

Think what you want to do can be done in capacitor with wappler. Never tried it though.

If you look at the docs at

Then look fo the server section and then the url option. Think it might just b a case of put your url in here and then build and submit in the normal way.

This post might give you a idea of how the config should look https://forum.ionicframework.com/t/ionic-url-vs-webdir-how-to-run-app-from-webdir/222624

1 Like

Hi Mozzi.

If you have a full working PWA that meets all requirements, deploy it to the web and head over to PWABuilder. It’s a handy (and free) tool that creates the required sources for you to build a native app around your PWA. I used for a couple of smaller projects, and had no problems with app submissions to Apple.

Please also have a read here, that’s the second part of the series.

You still need a Apple and / or Google Play Account in order to release an app to the stores! You also need a Mac to build for iOS.

/heiko

1 Like

Thank you for the great response… i did use PWA Builder before.
I guess ill just use it again :slight_smile:
Was hoping for a simple solution in Wappler… but seems the best solution for now is just to revert to PWA Builder… thank you for the help. and thanks for all the information you provided in your series… its great.