Understanding the different types of changes to your Pugpig app
The different types of changes to a Pugpig app (content, styling, timeline versions, configuration, Bolt app releases and app store listings), how each is released and when readers see it.
Written by Steve Farrugia
Updated at November 4th, 2026
Table of Contents
A Pugpig app is made up of several layers. Each layer has its own release mechanism, and changes to each reach your readers in different ways and at different speeds.
Understanding which layer a change belongs to helps you plan releases, set expectations about timing, and avoid one group of changes being held up while waiting for another. Changes to different layers can usually be released independently.
At a glance
| Type of change | Examples | How it is released | When readers see it | Applies to existing app versions? |
|---|---|---|---|---|
| Content and CMS changes | Articles, editions, timelines, filters, timeline layouts | Published in the CMS | Almost immediately | Yes |
| Custom styling | Timeline, card and article styling | Deployed by Pugpig to the server | Almost immediately | Yes |
| Bolt timeline versions | Timeline features, fixes and improvements | Deployed by Pugpig through the Distribution Service | Next app session | Yes |
| Configuration changes | Tabs, colours, copy, subscription settings | New configuration version activated by Pugpig | Next app session | Yes, with some limits |
| Bolt versions (native app) | App icon, onboarding, native features, third-party SDKs | New app release through the App Store and Google Play | When readers update their app | No |
| App store listings | Screenshots, descriptions, keywords | App Store: with a new build. Google Play: mostly independent of app updates | Once the listing update is approved | Not applicable |
1. Content and CMS changes
These are changes your editorial and content teams make in the CMS, such as Pugpig Express. They include:
- Publishing, updating or removing articles and editions
- Adding, removing, renaming or reordering timelines within existing timeline groups
- Adding editions to existing storefronts
- Storefront and timeline filters
- Timeline layouts and card layouts chosen in the CMS
- Cover images and other content imagery
- Adding or renaming podcasts and newsletters
Content changes go live once they are published, and apply to every version of the app. There is no app release or configuration change involved.
Changes may take a short time to appear because of feed processing and caching. Adding a new timeline group or storefront, rather than adding to an existing one, requires a configuration change (see section 4).
2. Custom styling
Custom styling controls how your content looks inside the app. It includes:
- Timeline and card styling, such as article cards, audio cards and image cards
- Article page styling
- Styling for other content-driven screens, such as Discover
Custom styling is delivered from Pugpig's servers rather than built into the app. This means it:
- Can be reviewed in Stage before being deployed to Production
- Can be deployed independently of any app release
- Applies to existing versions of the app as well as newer ones
- Takes effect almost immediately once deployed, subject to caching
3. Bolt timeline versions
The Bolt timeline is the component that displays your timelines, cards and storefronts inside the app. It is versioned and released separately from the native app.
New timeline versions can include new timeline features, layout options, performance improvements and bug fixes. They are deployed by Pugpig through the Pugpig Distribution Service, so they do not require an app store release and are available to readers on existing app versions.
Readers pick up a new timeline version the next time they start a new app session. The timeline version in use is shown in the app's Settings screen and recorded in the app logs.
4. Configuration changes
Configuration controls the structure, appearance and behaviour of the app, without requiring a new app release. Examples include:
- Tabs, tab order, toolbar logos and tab icons
- Colours, font sizes and text styling
- Labels and in-app copy
- Settings screen layout and content
- Adding new timeline groups or storefronts
- Authentication and subscription settings
Configuration changes are made by Pugpig, previewed with you, and then activated. Readers pick up a newly activated configuration the next time they start a new app session.
Some settings must also be included in the configuration that is built into the app, so that new users see them from first launch. For full details, including what can and cannot be changed through configuration, see Understanding configuration versions in Pugpig Bolt.
5. Bolt versions (native app releases)
Bolt versions are the native iOS and Android apps that readers download from the App Store and Google Play. A new Bolt version is needed for any change to the app itself.
What needs a new app release
- New native functionality: features that need new code in the app, such as new native screens, players or platform features
- Platform design updates: for example, Liquid Glass on iOS or Material 3 on Android
- Third-party SDK integrations: adding a new analytics, push notification, advertising, consent or authentication provider. These SDKs are only included in your app if they are configured at build time, which keeps the app as small as possible
- Third-party SDK updates: updating an existing SDK to a newer version, for example to gain new features or fixes, or to meet app store or provider requirements
- App identity and first-launch elements: app icon, app name, splash screen (if not already included), onboarding screens, and the bundled fonts and assets
- Platform permissions and entitlements: for example, App Tracking Transparency on iOS, new linking domains, or background audio
- Operating system support: supporting new operating system versions and dropping support for older ones
Types of Bolt release
Bolt releases range from feature releases that add new functionality, to maintenance releases with bug fixes, performance improvements, SDK updates and compatibility changes for new operating system versions. See the Bolt release notes for details of each release.
How app releases reach readers
A new Bolt version only reaches readers once they download and install the updated app:
- Each release must be reviewed and approved by Apple and Google before it is available.
- App updates are normally distributed gradually. Automatic updates typically run overnight, but it can take several days for a majority of readers to move to the new version.
- Some readers will stay on older versions for longer, for example because automatic updates are switched off or because their device can no longer run the latest version. See Pugpig Bolt Supported Operating Systems.
Because of this, we recommend keeping your app on the latest Bolt version. It ensures your readers benefit from the latest features and fixes, and gives the best compatibility with new timeline versions and configurations.
6. App store listings
Your app store listings, including screenshots, descriptions and keywords, are managed in App Store Connect and the Google Play Console. The two stores handle listing changes differently:
- App Store (iOS): changes to your App Store listing require a new build to be submitted to Apple.
- Google Play (Android): most listing changes can be made independently of an app update.
Note: changes to subscriptions, such as subscription products and pricing, are independent of app releases and store listing updates.
Other changes that do not need an app release
Some changes happen outside the app entirely and do not require a Pugpig release:
- Your own systems: changes to your identity provider, subscription platform, content feeds or ad server take effect without an app update, but may affect how the app behaves. Please let us know in advance about any changes that could affect the app, such as authentication changes.
- Bolt web reader: changes to content, styling and configuration apply to the web reader when the page is next loaded. There is no app store involved.
Planning a release with several types of change
Larger projects, such as a redesign, often involve several types of change at once. Because each type has its own release mechanism, we usually recommend releasing them separately rather than waiting to release everything together.
A typical approach is:
- Make content and CMS changes as and when they are ready. These can go live straight away.
- Release styling, timeline and configuration changes next. These apply to existing app versions almost immediately, so you can confirm they work correctly in your current production app before anything else changes.
- Follow with the iOS and Android app update for any native changes, such as a new app icon, onboarding screens or platform design updates.
Although these releases can happen around the same time, they will not reach readers at the same speed. Content, styling, timeline and configuration changes apply almost immediately, whereas app updates reach readers gradually over several days. Releasing in stages lets you validate the reader-facing changes before readers begin moving to the new app version.
When planning changes that depend on each other, for example a configuration change that relies on a feature in a new Bolt version, Pugpig will advise on the right order and timing.