Offline is not just another mobile feature
Every discussion on mobile-first development misses out on one of its most important and least understood characteristics: Mobile apps need to work offline.
The fundamental premise of mobility is that the technology should work everywhere. And that means everywhere. Imagine if you couldn’t access iTunes on the subway, or look up your next meeting on your calendar in an elevator, or a phone number in your contacts while trying to make an urgent call from the road. And forget being able to access anything when you are 15,000 feet in the sky.
The apps you use every day, such as iTunes, Mail, Contacts, Calendar, Dropbox and Evernote share something in common: they sync data locally on the phone which enables them to work offline, even when the data connection is lost or spotty. For example, the Mail app syncs new emails locally when connected so you can read and reply to them even when your phone is in Airplane mode. Evernote and Dropbox work the same way. But surprisingly very few business apps work this way today. Of anyone, professionals are in the most need for efficiency, yet mobile apps that are designed to help with this don’t always work at critical times.
According to a recent Forrester report ("The Offline Mobile Challenge", September 26, 2014): "Of course offline services kick in when a network isn’t present, but they also improve overall app performance and user experience regardless of network connectivity. Unfortunately, the complexity of building offline support prevents many development teams from delivering its value".
Why does offline matter?
Here are three reasons why developers need to think offline-first, despite the added complexity involved:
- Mitigate the service issues caused by congestion -- We’ve all dropped calls, experienced bad connections or been out of service areas from time to time, but what most people don’t realize is that it’s not about how far you are from a cell tower, it’s about how many people are connected to that tower and the impact of distance and microcell density. The resulting congestion is why calls can drop in the middle of Manhattan, why everything is slow when you’re in a football stadium or people can’t get through to each other in times of emergency.
- Speed -- It’s not just about dropped calls -- it’s about latency. You may have a full signal, but everything can still be slow. When you develop offline-first, the app remains responsive through poor, intermittent or even good connections where the server is overloaded or responding slowly. It later synchronizes data when conditions are favorable without losing the intent of the user or corrupting data on the server. It’s simply a matter of physics. Mobile networks today are slower than wired networks. Streaming data is slower because of the latency involved in contacting servers and all the slowdowns in intermediary networks. It may improve someday but currently working from local disk is vastly superior.
- Battery life -- When you use a chatty app throughout the day that requires a constant internet connection, it drains your battery. Every time a mobile app transmits data back and forth, it requires a radio to be fired up to request a data connection to send data back and forth. If your app is going to be used constantly during the day, like your Mail app, this is an issue. Conversely, if most of the data is working locally, your app consumes less battery. This may not be an issue for some apps that aren’t used daily, but many business apps are.
If you want to provide the best mobile user experience -- one not only focused on looking pretty, but being fast and responsive -- you have to start from the ground up. Architecting an offline-first app that works with local data and syncs when connected is fundamentally different from architecting an online-only app that requires a constant data connection because it relies on the request/response nature of the Web. In other words, if you don’t start with offline first, you can’t fix it later. Take the time upfront to consider how the app will be used and the importance of speed and responsiveness in delivering the best possible experience.
Chuck Ganapathi is CEO and Founder of Tactile