For: entrepreneurs that need to decide what technology to use for their future app

Mobile first. Everybody does it, wants it, needs it. Simply because your phone’s front
camera probably sees your face more than your spouse. It’s easy, it’s fun and addictive. So usually going for a mobile-first approach seems like a good thing to do.

It’s – as an entrepreneur – very hard to decide which technology to use. You could be non-technical, but you still would have to make a well-informed decision on this technical matter and you want what’s best for the company. This blog post attempts to give you some insight (boxing gloves) in what options you have, and how they might affect you in the short and long run.

Progressive web apps

pros

• The app can be developed in a  well-known stack. Most developers in this world are webdevelopers.
• Quicker iterations in development, easier to work with each other
• Quicker iterations on client-side, codebase can pull the latest version ad hoc, instead of having to wait for store approval
• No store denial, apple google and others cannot curate your app based on its content. Not only the app, but also the update itself doesn’t have to be reconsidered against policies
• Cross platform, any browser that supports it, on any platform, will be able to show and serve (there’s a caveat here, read for cons later on)
• Fallback for non-compliant browsers, the browser will simply see a website without the offline benefits
• It’s really (really) fast
• The app can be visited by browser, but also installed (become chromeless for a perfect UX. There is no reason your user shouldn’t be able to have the exact experience he or she would have like on native technologies).
• Not only cross-platform, but also re-usability of components cross-ui (reuse business logic for different experiences on mobile, tablet, desktop, television).
• Easy to apply lean / agile methodology (determine MVP, test / experiment, pivot or accept and enhance)
• Forcing of https
  • security against eavesdropping and modifications with proxies
  • security all-throughout the communication platform
  • enablement of https2 (more performance!)
  • more services become active (like GPS) since having them on http would infringe on personal security
• Progressive compliance with device interfacing rights (e.g. the user will only be asked to allow camera access, when the camera is actually used by the app)
• All major browser vendors (Google, Microsoft, Firefox, Samsung-web) are actively supporting the adoption of this technology

cons

• Not all hardware and native functionalities can be accessed as easily as through a native app, though browsers are making a real effort to mitigate this issue. Think of the recent work that’s done in:
  • gps
  • camera
  • push notifications
  • run as a service
  • vibrate
  • multi-touch
  • etc..
• Not all browsers on mobile fully support this, but it is coming (as spoken of on the google PWA summit 2016 Amsterdam).
  • Safari is currently not actively pursuing PWA, but recently announced they will start making effort (no solid promises there). This probably has everything to do with losing grip on the app ecosystem and possible loss of market share.
• Some native look and feel for default behavior may differ from the native experience
• Optimized for 2d web apps. Web Assembly and 3D are coming, but for now one can expect to get highest 3d performance on native.

When to apply

• Do this if you have an informative app. PWA isn’t really suitable for gaming. It’s not that you can’t, it’s just that usually native apps are better at this or have nicer tools to quickly and effectively approach your goal.
• Do this when all animations and visual elements are designed and accounted for.
• Do this when your MVP has best chance of surviving when it’s rolled out on more than one device type

Cordova

Cordova might be a good fallback for PWA on IOS to get maximal coverage on all platforms. Cordova basically shows a webview in an app and loads your web-app from it’s static cache.

Pros

• It mitigates possible current platform issues, since the entire PWA built app can be wrapped in a native container.
• There are tonnes of plugins that enable direct usage of hardware or other device features
• Extendable per operating-system (e.g. when a sync-adapter should be shipped with the app)

Cons

• Webviews use software rendering and are degraded versions of browsers. Therefore the app will never be as fast as a native or PWA.
• Publishing to markets comes with all rigidity of publishing to markets e.g.
  • maintain backwards compatibility on all interfacing endpoints, expect users not to update / upgrade
  • slow iterations and bundling of features (release trains to prevent flooding of updates). Also introduced slowness in acceptance by market
  • having accounts for all platforms, compiling against all platforms
• mandatory compliance with permissions and updates of these policies

When to apply

• As a fallback wrapper for PWA. I wouldn’t apply this anymore without PWA as foundation t.b.h.

Native technologies (per platform)

Pros

• fast when operational (usually slower boot speeds than PWA), especially for high performance apps like games
• when standard device interaction is preferred (like how pulldowns look and how some animations are), this is the best way to go.

Cons

• you need intricate knowledge on the specific
  • languages
  • development processes
  • device capabilities
  • market rules
  • platform updates
• codebase is not reusable for other platforms
  • that means that the effort will have to be made twice
  • discrepancies in functionalities between platforms will form
  • you’ll need more people in order to maintain multiple platforms / versions
  • double maintenance, updates will become cumbersome and expensive
• mandatory installing through appstore, no ‘checking out’ through browser before installing
• slow iterations in releasing, mandatory release train orchestration
• mandatory compliance with permissions and updates of these policies

When to apply

• when developing an MVP, a specific device could be targeted. This can only be done if the success and KPIs of the MVP are not dependent on this factor. Do this only when you are sure enough that the other platform either doesn’t matter, or enough resources will be available to also develop for the other platform
• when developing for e.g. mobile watch technologies
• when developing a game

Cross-platform technologies (like xamarin)

Pros

• one language to rule all app-based platforms

Cons

• no portability to desktop
• unfamiliar development process. I’ve never seen many people work on this at the same time
• harder to find people for, thus creating a strong human dependency (SPOF)
• there’s a transpilation process. Since native technologies are moving very rapidly, it’s only the question of these technologies can keep up with the pace of multiple OS Vendors.
• the longevity of native OSses is high, but there is no guarantee on technologies that depend on these OSses.

When to apply

• When native is preferred over PWA, but cross-device (excluding desktop usage through browser) is really important
• When a performant application on IOS is key (since the Cordova fallback webview for PWA doesn’t perform that well)
• When you develop a game and found people that are dedicated and skilled in developing for these technologies.