Even a cool mobile application can quickly become frustrating without decent network connectivity. How many times have you been stuck staring at a spinning wheel while in the subway? Even when coverage is available, the latency inherent to mobile networks can make responsiveness an issue. An application that runs smooth as silk on Wi-Fi can inspire a ragged feeling when connected to 3G—or even 4G.

Wouldn’t it be great if apps kept working, whatever the network conditions? Well, that’s definitely possible. Let’s see how!

Apps traditionally approach offline usage through two basic techniques: caching and prefetching.

Caching means saving content locally when the user accesses it online, so that it remains available while offline, or just loads faster, without the need for network access. A cache is usually limited in both size and lifespan. This is typically how your web browser handles images, for example.

Prefetching involves guessing what content the user might access later, and pre-downloading it so that it is readily available when needed. For example, a music app could download the next song in a playlist, or a news app could download today’s edition. Sometimes, the user explicitly chooses the content to synchronize—in Google Drive, for example, you can choose to pin documents for offline use; music apps typically sync favorite artists or albums.

Those techniques work well for direct access to content—you know which album you want to listen to, or which document you want to read—but what if directly accessing the content is too tedious? For example, you might not remember which folder the document is in. Or what if you don’t know exactly what you are looking for? For example, when browsing through your previous notes to try and recapture this great idea you had.

This is when you need offline search. Search makes content accessible, and is key to a great user experience—this is as true online as offline.

Solving the offline search problem isn’t easy.

Powerful search technologies are usually online only, while embedded technologies (like SQLite’s FTS extension) don’t provide the same experience for users (e.g. typo tolerance). And in any case, you need to code twice, once for online search, and a second time for offline search, with two different technologies, using different paradigms.

Today, great user experience comes at the cost of a rather painful (and costly) developer experience… Luckily, solving developer pains is Algolia’s raison d’être.

Quite simply, Algolia Offline is a full Algolia search engine embedded into your mobile app, directly on your users’ devices. We cross-compiled the same code that powers our SaaS product to iOS and Android, magically shrunk to fit in around 1MB (per CPU architecture), and made it available to all native applications. (“Hybrid” JavaScript-based applications are not yet supported by Algolia Offline.)

As you may know, Algolia started as an offline SDK, before we pivoted to a hosted cloud offering—this is a return to our roots.

All Algolia’s great features are now available without any network: typo tolerance, filtering, faceting, geosearch…

There are a few notable exceptions: in order to reduce data size, we have disabled some features, like plural dictionaries (which would incur over 4 MB of overhead), or segmentation for Asian languages (5 MB overhead). You still get the core of Algolia’s magic: powerful textual and business relevance combined with unparalleled speed.

Algolia Offline synchronizes your online indices (or a part of them—you decide) to your user’s device. Once they are synced, they can be queried just like online indices, using the same API Client that you already use to search online. In fact, Algolia will seamlessly transition from online to offline based on the responsiveness of the network. Alternatively, you can choose to explicitly search offline, which can be useful to build fast autocompletion, as we’ll see in the example below.

Our approach was centered around the idea that the developer should always be in control:

The first obvious benefit is that you just need to code once, with a consistent API. It saves time, and also saves the sweat of duct-taping together heterogeneous search technologies.

Secondly, all the synchronization happens in the background: your UI responsiveness is not impacted (did we mention milliseconds matter?). You can even search during a sync and still get consistent results.

For users who want to search content that isn’t available online (by design or by requirement), Algolia Offline lets you create indices directly on the user’s device, without syncing with an online index. This is useful if you have user-generated content that is input on the phone.

A good use case to start with is searching prefetched content, which we talked about earlier. Say you have a music app downloading favorite songs, or a news app fetching the latest articles before your user wakes up. With Algolia Offline, users can now search this content wherever they are—be it quietly sipping a coffee at home, backed up by a good Wi-Fi, or wandering through the subway, enduring an intermittent, laggy connection.

A second, more subtle use case, is to improve UI responsiveness. Even when network coverage is available, latency may be too high to accommodate instantaneous, as-you-type search experiences. But when your online index is synced locally, you can provide instant results at each keystroke. It doesn’t have to be the complete data: you may use the local index as an autocomplete source, for example. Any strategy is imaginable: you could provide offline as-you-type results, then go online when the user stops typing or presses the “Search” key.

We truly believe that the potentialities of Algolia Offline go well beyond what could be described in this article. You will probably come up with many more interesting use cases.

So, go ahead! Try it now, and share your feedback with the community, so that we can keep improving on this product. And stay tuned for updates: this is just v1; more awesome features are to be expected in the future.