Bolt Offline Behaviour

Content fetching and offline availability

The first, and most obvious, way to fetch new content in your Bolt app is simply to open it. We check for new content on every foregrounding of the app. During an app session, new content can be fetched by a pull to refresh on any timeline. 

Additionally, Bolt iOS uses background fetch in order to maximise the availability of fresh content. This means that the app periodically wakes up when backgrounded and fetches content from the server. What content we fetch is based on a heuristic which prioritises content from timelines the user frequently visits. This means that some timelines might not be refreshed in the background, particularly in the case of apps with a large number of timelines. To minimise the data usage and time required, the download doesn’t include assets such as images, PDFs or audio files. Furthermore, the operating system chooses the order in which the queued files are downloaded, hence the articles not necessarily being fetched in the same order as they’re listed on the timeline

The frequency and timing of this content refresh is dictated by the operating system, and is likely to happen more regularly the more a user engages with the app. The volume of content fetched is also controlled by the operating system, as the app is effectively given a certain amount of resource (time, storage and bandwidth) and we'll do the best we can in that time.

It’s also possible to proactively trigger a background content fetch via a silent push notification, this will have the same effect described above, just at a time of your choosing. 

Bolt Android is in the process of moving to align with the behaviour described above, but does not as yet support background content fetch. As such, content updates for Android only happen when the app is foregrounded, at which time the app will prefetch content from all timelines the user has selected for display in the app. The number of articles fetched in this way is configurable, but defaults to 50. This should be reduced in the case of apps with a large number of timelines.

All content fetched in any of the above scenarios is cached and should be available the next time the user opens the app regardless of connectivity.

Content the user has previously read is held in the app cache indefinitely and should be available for some time. The reason we can’t specify exactly how long is due to the way app storage is managed. We maintain a specific size for the cache, which means heavy users are more likely to reach this capacity, upon which the app will begin removing older content from the cache. Additionally, mobile operating systems retain the ability to reduce or remove an app’s stored data when device storage runs low. 

If a user has opened an article, the entire contents of that article will be cached, not just the text as described above in the background fetch scenario.