The Blog


“The true measure of an app is not how it performs over the fastest, most reliable Wi-Fi networks, but how much functionality it retains when a network connection is either unstable or unavailable.” (Anonymous, 2016)

We live in a world where connectivity is becoming increasingly ubiquitous with each passing day. But constant connectivity also leads to (impossibly) high user expectations that web and mobile apps will function all the time, despite (very common) network lapses and downtime.

As a developer, it’s dangerous to begin with the assumption that your users will always be online. It just won’t happen. But by designing and developing with offline scenarios in mind, you’ll build apps that are resistant to downtime and are less likely to trip up and frustrate your users. This is where an Offline First approach comes in.

Offline First and Mobile First

Offline First is a concept that borrows both a surname and a development process from a predecessor – Mobile First. The goal of Mobile First is to develop for the most constrained environment a user will experience – a small screen on a mobile device – and then add progressive enhancements (i.e. additional features and attractions) for when a user is engaging with an application or service on a larger screen.

Offline First is similar in that you develop first for the constrained environment – no network connection – and make sure the app is functional, then offer additional features for when a network connection is available.

In an interview with The New Builders Podcast, Gregor Martynus, developer on the open source project Hoodie and part of the team behind the Offline First community, explained that when developers follow an Offline First approach, they create better experiences for their users, whether they’re offline or on. Listen to the interview.

Offline First in action

Even though the concept of Offline First development is relatively new – first coined in 2013 by Hoodie’s Alex Feyerke – some services actually handle offline scenarios quite well.

Some of my favorite examples include a trio of sample applications built by the IBM Cloud Data Services Developer Advocacy team, usually leveraging IBM Cloudant:

And then of course there’s Google’s offline dinosaur – a nice distraction for being offline, even though all core functionality of the browser is gone.

Unfortunately – because we’ve all been on a subway or airplane, wandered through that inexplicable dead zone near our apartment, or traveled to parts of the world with less connectivity – we know that being offline is still an error condition for most apps. The good news is that the tide is turning, thanks in part to the efforts of a growing group of Offline First advocates.

A community of offliners

In June, the Offline First community held its first ever Offline Camp, a three-day “unconference” in a house big enough for 30-plus campers, set amidst the backdrop of the Catskill Mountains. The Offline Camp blog has a full recap of the weekend, which included sessions and passionate talks around UX design patterns, APIs, offline maps, security and encryption, and much more.

If you missed Offline Camp but are interested in getting involved in the movement, no worries, because the IBM and the Offline First community are road-tripping to California this fall for West Coast Offline Camp, Nov. 4-7 in Santa Margarita!

And if you want to hear what you missed in the Catskills, the Offline Camp team allowed the New Builders to record interviews with some of the campers, including representatives from Mapzen, Cure International and IBM.