Cookies
Diese Website verwendet Cookies und ähnliche Technologien für Analyse- und Marketingzwecke. Durch Auswahl von Akzeptieren stimmen Sie der Nutzung zu, alternativ können Sie die Nutzung auch ablehnen. Details zur Verwendung Ihrer Daten finden Sie in unseren Datenschutz­hinweisen, dort können Sie Ihre Einstellungen auch jederzeit anpassen.
Digital Business

The Continuum of Mobile Development

Minuten Lesezeit

Notice: This article is written in German.

Blog Post - The Continuum of Mobile Development
Stephan Epping

In the early days of mobile development the only option was developing mobile apps natively using the tools provided by the manufacturers, e.g. developing iOS apps using Xcode provided by Apple and programming in Objective-C. But very quickly more approaches emerged, like mobile web or hybrid applications using a webview inside a native container (like Cordova). These approaches allow you to use a single codebase in order to create apps that run on almost every platform - which results in a faster time-to-market and easier maintenance. In the past these approaches felt very cumbersome and had many limitations (performance, user experience, storage etc.). Nowadays the technologies have matured and mitigated lots of their disadvantages - further enabled by increased device capabilities.

Continuum of Mobile Development

The figure above shows an overview of possibilities going along a continuum from mobile optimized websites to classic native apps - from left to right the technologies get more platform specific. What follows is a necessarily incomplete introduction to every mentioned option along this continuum. After reading, you should be in a position to decide which technology is worth having a deeper look at, based on your background and requirements.

Mobile Web

Developing for the mobile web generally consists of optimizing the desktop version of a website to look nice on smaller devices with different form factors (like phones or tablets). This is mostly done using CSS media queries, fluid sizing and a grid-like layout depending on the size of the viewing device - this approach is called responsive web design (RWD). There are two more options: One, having different URLs for different form factors. Two, dynamically serving different content depending on the target device. Both are reasonable, but maybe more difficult to maintain and extend.

Responsive web design is the most applied concept. It is easy to implement with existing skills in web development and requires maintaining only a single codebase. Mobile web pages can be accessed from every platform with a mobile browser and can utilize some device features using HTML5, like storage and camera access. However, integration with a mobile operating system, even taking HTML5 into account, is just starting to grow out of its infancy: Parallelism, security and offline behaviour of more native approaches can not be reached so far. Further, mobile web pages don’t feel native from a UX point of view: For example, you can try to mimic some native UI elements or interactions, but they mostly fail to achieve the fidelity of native elements. Another big drawback is, that you can not install the app. You can only pin the url of the website onto your homescreen on some mobile devices, but it will always be opened inside a browser. HTML5 is making progress on improving these drawbacks, but is dependent on the slow browser adoption of these features.

Progressive Web Apps (PWA)

Progressive Web Apps are an idea published by Google. They are pretty similar to normal responsive mobile apps, but present you a download banner whenever you visit the website hosting the app. After the installation, you can start the app, which is then shown full screen without the distracting browser controls, feeling more app-like. Further, PWAs focus on a few more HTML5 concepts to address the biggest issues of browser based mobile apps:

  • Installing the app to your homescreen using a manifest file as already mentioned, e.g. by presenting a download banner
  • Fast loading, background work and offline behavior making extensive use of service worker
  • Push notifications to re-engage with users even when the browser is closed

This provides a more app-like feeling to the user. Most of it's functionality depends on the support of service workers that is often still experimental or unavailable. Further, Apple doesn’t seem to plan on supporting the installation of PWAs on iOS. Since they are still web apps, they have the same limitations accessing all device capabilities as normal mobile websites and do not provide a native user experience. However, one big advantage of progressive web apps (or also mobile websites) is that no app store is involved in releasing your app - you have full control how often and what you release. But this might also make your app more difficult to discover by users of the platform, e.g. iOS user just might only look at Apple’s app store to find new apps. Hopefully, more and more HTML5 features get adopted by all browsers in the future, which would give more power to progressive web apps as well as mobile optimized websites.

Hybrid

Hybrid apps try to mitigate the disadvantages of browser based mobile apps while still preserving most of its advantages by embedding your website in a native app shell using webviews. Doing so has a couple of advantages:

  • The app can be installed using the official app store of the targeted platform
  • Most device capabilities can be used by accessing their native apis through a bridge between the app shell and the webview
  • Development can be done using web technologies (html, css, js) and all platforms can still be addressed using one codebase

While you can do the binding between app shell and webview on your own, like Basecamp does, mature frameworks like Cordova  provide a rich ecosystem for integration. For example, they have a huge plugin library to do the heavy lifting between the webview and the native apis. Further, they help you with setting up the app shell, which requires a lot of platform specific knowledge. Finally, they give you some nice tools to run an app on different platforms or giving you a preview in a browser window using a simple command line interface.

At this point, you still have to style your application by yourself - which is sometimes a good thing depending on your app. But often, you will end up trying to mimic the native elements on each platform. For this purpose there are frameworks like Ionic or Onsen that are based on Cordova - think of them as Bootstrap for mobile. These frameworks put a lot effort in giving your users the best mobile experience they can - having an eye on design, animations and performance. In the past, performance has always been a downside of hybrid apps, but nowadays the devices are faster and maintainers are doing a good job optimizing the user interface. Both frameworks focus on a neutral theme that looks decent on all platforms while allowing you to customize the look for each platform. Ionic2 goes one step further, it adapts the style automatically depending on the platform, e.g. compare the following example from their guides:

Hybrid Apps

Source: http://ionicframework.com/docs/v3/components/#tabs-icon-text

These frameworks provide you with styles that look more native, but they aren’t a pixel perfect copy and don’t mimic all behavioural aspects of native elements - which is not their goal. However, if you chose the custom approach (like Basecamp) you are free to use native elements by connecting them to logic in your webview container and vice-versa. For example, you could create a native tab-controller where the content is served by separate webviews. Moreover, Microsoft introduced a project called Ace that allows you to mix native UI with HTML and integrates well with Cordova based frameworks like Ionic. Further, it allows you to use cross-platform UI code as well as platform-specific UI code depending on your requirements. Here is an example code snippet:

Cross-Platform vs. Platform Specific

Source: http://microsoft.github.io/ace/

This approach allows you to selectively enhance your app with real native elements. One drawback though is that you are moving away from the web developer’s happy path - you have to acquire platform specific knowledge and use platform specific tools. Overall, hybrid apps give you a lot of flexibility to build fully fledged native-like apps while using your existing knowledge and tools from web development. The following sections describe more possibilities to develop mobile apps with a complete native user interface while still using a good amount of web technologies.

Runtime

In this case your app specific code gets executed inside a runtime that allows you to communicate with the underlying platform, e.g. using a JavaScript or Mono runtime. We chose the term runtime as it fits nicely into our mental model, but may not be adopted widely. The basic idea is to create specific apps for each platform with a native user interface while allowing for some code reuse (mainly business logic).

Popular frameworks are NativeScript, React Native or Xamarin (on Android), that allow you to use familiar technologies and tools for development like JavaScript (Titanium, NativeScript, React Native) or C# (Xamarin). All these frameworks work pretty similar from a bird's-eye view, but differ in how they communicate with the underlying platform or how to define the user interface, e.g. NativeScript uses an angularJS approach while React Native, as the name implies, follows the react paradigm. Most of the frameworks allow you to write platform agnostic UI code, but do not force you to do so. The following picture shows an example of a DatePicker written with NativeScript:

Native Component

Source: https://docs.nativescript.org/ui/date-picker

Obviously, the biggest advantages are the completely native UI and the performance gains of using a runtime instead of a webview. But as a developer you are more and more involved with the properties of each platform you want to target, e.g. some frameworks even have their own layout description language that is neither HTML nor the native counterpart. Additionally, more intermediate steps to access native functionality might result in slower development - in case you have to wait until the newest features are being adopted by the maintainers.

Cross-Compiled

In this category the app code is compiled ahead of time, which yields to approximately native performance. The most popular frameworks are Xamarin (for iOS) and RubyMotion, both focusing on developing different user interfaces for each platform - but provide addons to use cross-platform UI code.

Besides the better performance this technology provides the same benefits and caveats as runtime based frameworks, e.g. it requires some kind of wrapper to integrate 3rd party native libraries (using cocoapods).

Native

The last option is to develop a custom app for each platform that results in completely different codebases:

  • Android with Java or Kotlin
  • iOS with Objective-C or Swift
  • WindowsPhone with C#

The advantage is that you can really focus on one platform and leverage all its tools with few levels of indirection. But from another point of view all these advantages can also be considered as serious drawbacks. The developer must know all paradigms and can not reuse most of the code, which yields higher education, maintenance and development costs. In the end it all depends on your requirements and priorities. The next section tries to give some guidance when to choose a specific technology.

Conclusion

Mobile Development offers a lot of possibilities nowadays. It’s not black and white anymore, gray seems to be pretty solid and good enough most of the time. There is so much more to say about each technology, but that would be out of the scope of this post. Before making a decision you should definitely have a deeper look at each technology and compare the properties of each solution to your current and future requirements. For example, check out how testing and deployment works with each technology. Maybe it’s favorable to start on the left side of the continuum and then work your way to the right - thereby you can be very efficient, what might be sufficient too. There will always be some kind of tradeoff with every technology, choose the one that hurts you least.

(Progressive) Web App is a minimum must have nowadays, simple to build with existing workforce and flexible to release. One codebase. Drawbacks in app-ness and device api access.

Hybrid is a starting point for real mobile apps that are installable and can access most of the device api. It provides a decent interfaces for all platform, e.g. by using Ionic. Development is efficient and cheap, due to the reuse of web development knowledge and tools. Further, it allows you to incrementally add native elements when required.

Runtime is a good fit if a native experience is important. It provides native UI elements and offers deep integration with the platform. Additionally, it still provides a good amount of code reuse.

Cross-compiled is similar to runtime based apps, but more useful when performance is critical and your team is already familiar with the programming language and tools.

Native gives you the complete power of the platform, but requires deep knowledge of every platform, which has also to be maintained separately.

Continuum of Mobile Development

Hopefully, we could give you a good overview about the available technologies and gave some advice when to use which technology. While we tried to mention the most popular frameworks, there are many more out there. Stay tuned for future posts about mobile development, where we’ll have a deeper look at the mentioned frameworks.

Partner für digitale Geschäftsmodelles

Ihr sucht den richtigen Partner für eure digitalen Vorhaben?

Lasst uns reden.