8 Tips to Make Your Website Feel Like an iOS App

Very nice video by Sam Selikoff in which he sets up a web manifest to make his site feel more app-like. Great production quality.

There are some tweaks I’d suggest though:

  1. Fixate the header using position: sticky; instead of position: fixed;. No need for that extra margin on the content then. Update: See note below

  2. Don’t set the header height to a fixed number, as not all devices have (equally sized) notches. Use the User Agent Variable safe-area-inset-top instead, and apply it as the top padding:

    header {
  padding-top: env(safe-area-inset-top);
}

  3. Don’t disable scaling in case your app does not follow the system font sizing — which it does not by default. To make it do follow the system font sizing, use this snippet:

    @supports (font: -apple-system-body) {
  html {
    font: -apple-system-body;
  }
}

    💡 You can still override the font-family after that. That way you can have your custom font and also follow the preferred system Text Size

As an extra: to prevent that long-press behavior when the app is not added to the home screen, set -webkit-touch-callout: none; on the links.

On Twitter Sam pointed me out that when using position: sticky; there’s an issue with overscroll/bounce: The header will shift down along with the body as you do so.

In theory one could easily fix this by applying some overscroll-behavior on the body. However, as Safari does not support overscroll-behavior you’ll have to resort to a hack to prevent overscrolling in Safari. But, as that hack relies on 100vh — which Safari also doesn’t understand properly — you’ll have to use another hack to make Safari use the correct value for 100vh.

(* mumbles something about Safari being the new IE6 *)

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Progressive Web Apps The Superpowers of the Web and Native Apps Combined

Free e-book by Google & Awwards on PWAs:

We return to take a closer look at Progressive Web Apps (PWAs) and how they combine the reach of the web with the device integrations of installed software. In this ebook, Volume 2 in the series, you will learn:

  • The capabilities of Progressive Web Apps
  • Product strategies for deploying PWAs
  • Promotional patterns for driving installs of PWAs
  • UX best practices for designing installed experiences that work reliably offline
  • How to implement analytics to measure business impact.

Progressive Web Apps The Superpowers of the Web and Native Apps Combined →

Offline Storage: When 7 KB Equals 7 MB

Gerardo Rodriguez from Cloudfour:

While testing a progressive web app for one of our clients, I bumped into a suspicious error in the browser console: DOMException: Quota exceeded.

After browsing the app a few more times, it became clear the error would occur after a small number of images were added to the cache storage by the service worker. Looking in the Chrome DevTools Application tab, the cache storage was indeed over capacity.

How could this be? There were only ~15 images in the cache storage. Something was off.

The culprit? Opaque Responses.

When 7 KB Equals 7 MB →

Progressive Web Apps – PWA Roadshow

If you’ve totally missed out on PWAs, then this summarising video by Pete LePage is a good start. If you know what PWAs are then you might want to skip forward to the 8:30 mark, where details on the Twitter PWA (which might come to macOS soon?) are shared.

In the first part of the Progressive Web App video series, you’ll find out how others have successfully used PWAs to improve their user experience and learn some of the key concepts behind PWAs.

When you’re done with this one, go check out the rest of the videos in this series.

PWAs are coming to iOS 11.3: Cupertino, we have a problem

Recently it was announced that iOS 11.3 and macOS 10.13.4 will include Service Workers, opening up the way for PWAs on iOS (and potentially macOS too, following lead of Microsoft here).

☝️ If you don’t want to download the macOS 10.13.4 beta you can alternatively download Safari Technology Preview (> 48) for use with your current macOS install.

Great news indeed, yet as Maximiliano Firtman documented there are quite a few caveats right now. Some might get fixed, yet some others won’t. One of the bigger issues I find worrying is the fact that you can end up with different versions of one and the same PWA, depending on the context you are running it in:

On Safari, on each app’s Web view, and home screen web apps, the engine doesn’t share Service Workers nor the Cache Storage, which means the user might end with several copies of all the files for the PWA on the same device.

PWAs are coming to iOS 11.3: Cupertino, we have a problem →

On a sidenote: Twitter recently announced they’ll no longer be shipping the Twitter app to macOS …

A Tinder Progressive Web App Performance Case Study

Addy Osmani:

Tinder recently swiped right on the web. Their new responsive Progressive Web App — Tinder Online — is available to 100% of users on desktop and mobile, employing techniques for JavaScript performance optimization, Service Workers for network resilience and Push Notifications for chat engagement. Today we’ll walk through some of their web perf learnings.

Their PWA is also built using React and Redux.

A Tinder Progressive Web App Performance Case Study →

sw-toolbox – A Collection of Tools for Service Workers

Service Worker Toolbox provides some simple helpers for use in creating your own service workers. Specifically, it provides common caching strategies for dynamic content, such as API calls, third-party resources, and large or infrequently used local resources that you don’t want precached.

The code itself is very readable I must say:

importScripts('sw-toolbox.js');

toolbox.precache([
  '/css/app.css',
  '/img/logo.png'
]);

toolbox.router.get('/css*', toolbox.cacheFirst);
toolbox.router.get('/img*', toolbox.cacheFirst);
toolbox.router.get('/(.*)', toolbox.networkFirst, { networkTimeoutSeconds: 5});

A bit more advanced is to precache a “you’re offline” page first, and return that in case a user is offline (src):

importScripts('sw-toolbox.js');

toolbox.precache([
  '/offline',
  '/img/offline.png',
   // …
]);

// …

toolbox.router.get('/(.*)', function(request, values, options) {
  // networkFirst will attempt to return a response from the network,
  // then attempt to return a response from the cache.
  return toolbox.networkFirst(request, values, options).catch(function(error) {
    // If both the network and the cache fail, then `.catch()` will be triggered,
    // and we get a chance to respond with our cached fallback page.
    if (request.method === 'GET' && request.headers.get('accept').includes('text/html')) {
      return toolbox.cacheOnly(new Request('/offline'), values, options);
    }
    throw error;
  });
});

sw-toolbox →
sw-toolbox (GitHub) →

A beginner’s guide to making Progressive Web Apps forms a nice introduction to implementing Service Workers using sw-toolbox.

If you’re looking for a non-library version I’d recommend starting with Implementing “Save For Offline” with Service Workers.

Progressive Web Apps with React

Great set of articles by Addy Osmani:

In this series of posts I’ll share my experience turning React-based web apps into PWAs. We’ll also cover why shipping just what users need for a route & throwing out all other scripts are good ideas for fast perf.

As with all articles by Addy: well-written, accurate, and complete.

Part 1 — Introduction →
Part 2 — Page Load Performance →
Part 3 — Offline support and network resilience →
Part 4 — Progressive Enhancement →