What an App Update Can Change Without Asking
An automatic app update can change features, rework defaults, remove capabilities you were using, and adjust what each subscription tier includes — all without a prompt, and often without release notes that mention any of it. What it cannot do is grant itself new permissions on your device. That boundary is the one genuinely reliable protection in the whole arrangement, and it is worth knowing exactly where it falls.
Most of what feels like an app changing overnight is not an update at all, which is the other half of this.
What an update can change
The list is long because an app’s behaviour is almost entirely the developer’s to define.
Features, and their absence. A capability present last week can be gone this week, moved to a higher tier, or replaced with something different. There is no obligation to announce it.
Defaults. New settings arrive switched on, and existing settings can be reset by a migration. Notification preferences, data-sharing toggles, and personalisation options are all common casualties.
Interface and flow, including where a paywall sits and what it interrupts.
The model underneath. A conversational app’s behaviour depends on a model the operator selected, and swapping it changes the character of every reply. This does not even require an app update — it happens server-side, which is why an app can feel different on a morning when nothing was installed.
Tier contents and pricing, subject to store rules. Price increases on store subscriptions generally require notice and, in some cases, explicit consent; changing what a tier includes at the same price usually does not.
Its own privacy policy, which is a document, not code, and can be revised at any time.
What an update cannot change
The platform sandbox is not renegotiated by a version bump, and this is the part people underestimate.
It cannot grant itself permissions. A new version wanting microphone access has to prompt you, exactly as a fresh install would. Existing grants persist, but nothing is added silently. See what a permission prompt actually grants.
It cannot reach outside its sandbox into other apps’ data.
It cannot charge you outside the billing channel you agreed to. A store subscription remains governed by the store, and a new charge requires a new authorisation. See who you actually bought the subscription from.
It cannot un-revoke a permission you turned off. If you revoked photo access, an update does not restore it; the app can prompt again, and you can decline again.
That last point makes permission revocation genuinely durable, which is more than can be said for most settings.
Server changes are the invisible ones
This is the distinction that explains most confusion about apps in this category.
An app update is a versioned artefact you could in principle notice. It has a version number, a date, and release notes, and your store history records it.
A server-side change has none of those. The model, the safety filtering, the memory window, the retention policy, and the prompt configuration can all change without a single byte arriving on your phone. There is no record, no version, and no notification.
So when a companion app’s behaviour shifts — more cautious, differently worded, forgetting things it used to recall — the most likely explanation is not an update you installed. It is a change on the operator’s side. Checking your update history and finding nothing does not mean nothing changed. It means the change was somewhere you cannot see, which is the normal state of affairs for any service delivered from a server.
What to check after a noticeable change
A short list, in order of how often it turns something up.
Notification settings, which get reset more than anything else. Previews in particular are worth re-confirming; see notification previews and your lock screen.
Any data-sharing or personalisation toggles in the app’s privacy settings, checking for new ones as well as changed ones.
Your permission list, since an update is a good moment to revoke anything unused.
Your subscription screen, to confirm the tier and amount are what you expect.
Storage footprint, which is informative if it changed substantially — a large increase can mean new local data, and a large decrease can mean local history was migrated to a server.
Controlling when updates arrive
You have some control and it is a real tradeoff rather than an obvious win.
Automatic updates can be turned off per platform, which lets you read release notes before installing. The cost is that security fixes also wait, and for most people that cost is not worth paying.
A middle option is to leave automatic updates on and check the version history occasionally, which both stores expose. It will not tell you about server changes, but it establishes whether a client change is even a candidate explanation.
Staying on an old version indefinitely is not viable. Operators eventually require a minimum version, and an unsupported client stops working — usually abruptly.
What this does not tell you
Nothing here tells you why a change was made, and the honest answer is that you generally cannot know. Release notes in this category are frequently generic, and server-side changes are not documented at all.
It also does not help you predict changes. The reasonable posture is to expect the product you are using to be a moving target — that features can leave, defaults can reset, and the conversational character can shift without warning — and to keep the things you care about in forms that do not depend on the operator’s continued choices. That is what makes the permanence of a screenshot, discussed in what a screenshot becomes after you take it, a genuinely useful property rather than only a risk.