1. What

We have made a significant change to how Pugpig Bolt apps handle network requests on iOS and Android. Previously, the internal component that manages network traffic inside a Bolt app operated from a different origin to the content being displayed. While this was essential for powering offline caching, it meant the app did not behave like a standard browser when loading external content. As a result, certain third-party scripts, advertising technologies, embeds, and widgets either failed to load, behaved unexpectedly, or required custom workarounds to function at all.

With this update, that internal component now operates from the same origin as the content, so the app behaves much more like a standard mobile browser. External scripts and embeds get the context and permissions they expect, making your app significantly more compatible with the broader web ecosystem.

2. Why

The previous approach created a conflict between two of the app's most important capabilities: robust offline reading and broad compatibility with external content. Because the internal component operated from a different origin, third-party scripts could not reliably identify the origin of the page they were running on. This is a fundamental requirement for many modern advertising, analytics, and embeddable content technologies. In practice, this meant that features such as header bidding (Prebid), pre-roll video ads, certain interscroller formats, and a range of third-party widgets either did not work at all or required significant bespoke engineering to get close. It was a long-standing constraint, and resolving it has been a priority for some time.

3. Why Now?

This change was only made possible by dropping support for older versions of iOS and Android. The previous architecture was a deliberate trade-off: at the time it was built, there was no way to support both offline caching and same-origin networking on older operating system versions. As we have progressively raised our minimum OS requirements, we were finally able to implement this change across both platforms simultaneously. We wanted to release it consistently everywhere at once rather than partially, so we waited until the conditions were right to do so properly.

4. What Does This Mean for Your Bolt Apps?

For most publishers, this is a positive and largely transparent change. Your existing content and features will continue to work as before. However, you will now find that a much wider range of third-party integrations work without the need for workarounds. This includes:

• Advertising: Header bidding solutions such as Prebid, pre-roll video ads, interscrollers, and other ad formats that previously struggled in Bolt should now function correctly.
• Third-party embeds and widgets: Scripts and embeds from external providers (analytics tools, content widgets, social embeds, and similar) will behave as they would in a standard browser.
• Improved consistency: The app's networking behaviour is now much closer to what web developers expect, meaning integrations that "just work" on mobile web should be far more likely to work in-app too.

There is one small technical note worth being aware of: URLs that include query parameters (such as cache-busting parameters like bob.css?version=123) will not be cached offline. For the vast majority of publishers this will make no practical difference, but if your content makes heavy use of cache-busting URLs for critical assets, it is worth testing.

When your app transitions to a version including these improvements, origin-linked front-end storage (including but not limited to localStorage, cookie…) will not be carried over. In practice, this means that any progress users have saved in features such as puzzles may be lost after updating. This is a one-time occurrence — progress saved after the update will be retained in future updates. If you use features that rely on local storage, it could be worth letting your users know ahead of time. This is not the case with our proprietary backed-up persistence layer, see Bolt bridge reference.

5. FAQs

Do I need to do anything?
In most cases, no. This change is delivered as part of a standard app update and does not require any action from your team. If you have existing third-party integrations that previously required workarounds due to embed compatibility issues, it is worth retesting them as they may now work without those workarounds. Equally, if you have any new requirements with your third-party integrations that you'd like us to explore, now is the time!

Which app versions include this change?
Bolt Android 5.1 and later
Bolt iOS 4.22 and later

Will my offline reading experience change?
No. Offline caching works the same as before. The same articles and content your readers have downloaded will continue to be available offline.

I was told certain ads or embeds "couldn't work" in a Bolt app. Is that still the case?
Many of those limitations were directly related to the way our internal networking component previously operated. We would encourage you to re-raise anything that was previously ruled out, as a significant number of ad formats and third-party embeds that were previously problematic should now work. Speak to your Customer Success Manager if you want to explore specific integrations.

Specifically, this also unblocks our work on Prebid and ATAM that we've been in contact with several customers about, so you can expect to hear from us again soon.

Are there any known limitations on iOS?
There is one known issue: if your apex domain has HSTS configured with the includeSubdomains directive, users may occasionally see an intermittent TLS connection error. This is an uncommon configuration, so your apps are unlikely to be affected. 

We have added protections in all web views we directly control, but third-party integrations such as push, in-app messaging, or ad frameworks that open their own web views may still introduce the issue. Force-quitting and relaunching the app resolves it in most cases. This stems from an Apple platform behaviour rather than Bolt itself. Apple may patch this issue, but have not committed to doing so.

We're including explicit tests for this in all of our pre-submission checks, and we'll notify you if we discover the issue before submitting. However, if you receive any reports on this, please reach out to support@pugpig.com so we can investigate further.