Now that going mobile isn’t a binary choice between native and web app, Zone’s head of .NET development, Andy Butland, considers the different approaches…
When considering a mobile offering, it doesn’t seem so long ago that there was a clear and binary choice to make when it came to the technology used to build and deliver the product to users. You either decided to go for a web application, optimised for mobile, through the build of a dedicated mobile website, or, more likely, by making use of mobile-first and responsive web design techniques to have the web application render appropriately on whatever device it was viewed on. Or you went native, building specific applications for the different device platforms such as iPhone and Android, instead of, or in addition to, a website.
Given the inexorable increase in mobile adoption for web browsing, at Zone helping our clients make this decision is often one of the first activities we undertake when beginning a new site or application build project. At first glance, the pros and cons of each platform are quite clear and distinct.
With the web application approach, we and our clients gain all the benefits that we’ve enjoyed for years since building and deploying applications to this environment. There’s tremendous ease of installation and update, allowing the continuous delivery of features and improvements over time. We rely only on the user having a browser and internet connection to access our site. Caching issues aside, we can be sure that a given user is using the most recent version of our application, which eases compatibility headaches with APIs and services. And of course, we can benefit from the open nature of the web, allowing the application to be discovered through search engines and shared links.
With native applications, we lose some of that, but gain in other areas. Native means running code directly on the device, which will normally lead to better performance when compared to a website running in a browser. This will be more or less apparent depending on the type of application; likely more obvious for a graphic intensive game, less so for an application focussed on information presentation. Features such as push notifications will help with retention and encouragement of users to come back to the application. What’s lost in web discoverability is arguably gained back through the ability to market via the platform app stores. And lastly of course there’s revenue — with the payment models in place via the app stores it’s likely easier to monetise the application if that is one of the aims.
So, given these costs and benefits, are quite we inevitably going to have to at least double our efforts — in the sense of producing both a web and one or more native applications — when it comes to delivering a product or service to the best effect to our users? Well, not necessarily. There are certainly ways we can look to obtain at least some of the benefits and mitigate the costs, which I’ll discuss in the rest of this article.
As a manager of a development project involving native applications, probably the primary concern is the diversity of technologies it’s necessary to work in. Developing for iPhone, Android and Windows Phone require different languages, software and development environments, all of which are in turn different to those used for web applications. It’s rare to find an individual, or even an agency, expertly skilled in all areas, so it’s quite likely to require a relatively large team. There’s a lot of code that’s potentially duplicated necessary to implement the same feature on the different devices.
A way to mitigate this spiralling complexity is to employ software or an application architecture that allows for writing code once and having it made available for consumption on the different devices, a technique that can be deployed at build/compile time, or at run time. Cordova and Xamarin are two software solutions for tackling the former. They allow for applications built in HTML/CSS/JavaScript and C# respectively to be packaged up as applications, from where they can be deployed to the app store and installed on devices in the same way that “true” native applications are. There’s still likely some compromise needed in terms of performance or application size, but for most cases the result will be largely indistinguishable from an application written in the native language to the user.
The application architecture approach is the one we took on a recent project for South West Trains, where among other things we designed and built a train ticketing application, available via the web, on iPhone and on Android. Here we developed a common service layer that all three applications utilised for retrieving data and submitting user requests. In designing and developing the solution we continually looked to push business logic and services such as session handling up into the service layer, where it could be written and maintained once and used by all the different client applications. In other words, we kept the applications as “dumb” as possible — ideally, they were just responsible for the user interface and making requests and handling responses from the service layer. In doing this we could reduce the problem of duplicated or re-implemented code and ensure business rules were consistent no matter how the user was interacting with the solution.
That describes a couple of methods we can use to reduce the costs of developing native applications, but we might also want to look to avoid this completely whilst still improving the experience of using our web based application on mobile devices. If the aim is to design, build and maintain one set of code, that all users access, then an application deployed on the open web is the way to go. The techniques of responsive design and progressive enhancement are likely a given here, utilising CSS and JavaScript to present the best experience we can to users whether they are accessing our web application through a desktop, tablet or mobile browser.
Whilst that approach handles the small screen-size issue, it doesn’t do much for the other often found limitation when browsing the web on mobile devices, which is bandwidth. A responsive web design approach will often serve all assets to all devices, even if in some cases a mobile device won’t even see then. Can we find ways to speed up our pages on mobile devices? With some caveats that I’ll discuss later, we might look at an initiative from Google — Accelerated Mobile Pages (AMP) — to help with this.
AMP works by asking developers to create a version of each page template using a restricted version of HTML which are then served direct from Google’s own servers. These two steps ensure the pages are lightweight and rendered quickly, whilst also gaining some SEO benefits as Google will promote AMP enabled web pages in its search results.
At Zone we’ve implemented these on a number of pages for the Swinton Insurance website. The new page templates were coupled with content management system control of custom content and the selection which pages will use the technique, which allowed for the results to be evaluated by comparison with “standard” pages. As expected, the performance of the clean and uncluttered pages was excellent. Once indexed by Google, they could be seen clearly as AMP content within the search results.
I mentioned some caveats earlier with the AMP approach and it’s important to be aware of them too when considering its use. As well as advocates, AMP has also had its vocal critics. In using the technique, quite a bit of control is given over to Google — they will serve your pages, via their own URL. Even when shared, the content looks to come from Google, not from the original source. Although some might argue a URL is relatively unimportant to your users, it is part of branding and an important part of how the web works is that content lives at a single location on the Internet. You also have to accept the AMP restrictions in terms of what types of content are allowed to be served and what analytics can be collected.
Rather than jumping straight to AMP as a solution to speed up pages on mobile devices, I’d recommend first taking a hard look at existing pages and seeing if they can be optimised using traditional techniques. One of the things that you are forced to give up using AMP is over-use of analytics, trackers and obtrusive advertising, so in any case the value of these will need to be assessed and could be removed without the need to go full AMP. And if delivery is slow, for relatively static pages, it’s worth investigating the use of a content delivery network (CDN) such as Cloudflare, which would provide fast delivery of your website assets to users on any device around the world, whilst retaining full ownership of the URL and content.
The final technique I’ll discuss is a means of providing more native app like features to web applications, via another Google initiative, progressive web applications (PWAs). Actually a collection of technologies, utilising techniques within this allows for features such as add to home screen, offline usage and push notifications to what are otherwise just standard websites. They key word here is “progressive” — they are websites enhanced with particularly capabilities that, if supported by the browser, adds these app-like features.
Offline capabilities are provided via service workers, which can be considered as a gateway between your application and the Internet. They allow you to handle when a device is offline much more gracefully, all the way from displaying a message indicating this to the user through to providing a full, albeit disconnected, experience to the user using assets and data saved from a previous, connected session.
The shell of the application — its core mark-up, styling and key functionality — can be cached locally, allowing for faster start-up in addition to the offline capabilities previously discussed. After a couple of uses, the user can be prompted to install the application to their home screen, from where it can be accessed just as native apps are, and presented in a way that looks like an app rather than a website running in a browser.
Although some browser limitations exist, most of the technologies that sit under the PWA umbrella are available on modern browsers, making a PWA enhanced website a very viable consideration as an alternative to building native applications.
In summary, when considering an approach to a mobile application there is now a lot of options to evaluate along the continuum from website through to native application, and no longer a relatively simple, binary choice. Just where a given project sits along that line, and which techniques described in this article are most appropriate, needs careful analysis of the product or service’s aims, features and users.
