A reader who treats the residual as a single deletable object and hunts for an "Other folder" that does not exist.
iPhone Storage Full: What's Actually Taking the Space
Storage is a static inventory — a stock of what occupies space right now — not a rate you can throttle, and the catch-all "Other" bucket is a residual, not a single thing you can delete. Here is the stock-is-not-a-flow reframe, the on-device-versus-in-cloud split, the storage-audit sequence, the storage anatomy, and the offload-versus-delete fork. The page is an inventory, not a data-erasure task (120) and not a speed booster; the device's own settings are the authoritative surface, the freed space refills so the audit is a routine, and the discipline is to read the breakdown by category rather than to purge the biggest-looking thing — and to know that a licensed download (115) is a licence occupying space, not a file to delete freely.
General information only — not a statement of any universal category breakdown, not a data-erasure guide, not a "speed up your phone" booster, and not a device-specific menu path. This page explains the shape of a storage inventory — the stock-is-not-a-flow reframe, the on-device-versus-in-cloud split, the storage-audit sequence, the storage anatomy, and the offload-versus-delete fork — in broad terms. What occupies space, the category names, the size of each category, the behaviour of the "Other"/System Data residual, the cache-regeneration rate, the offload-versus-delete availability, the iCloud local-copy behaviour, and the licence-download access route vary by OS version, device, account, app, and region, and they change over time; they belong to the device's own storage settings, the OS vendor's support documentation, and the platform's local Help for licensed content — not a guide page. And the load-bearing limits: storage is a static inventory (a stock), not a rate (a flow), so you cannot throttle it — you can only remove items, and some items regrow; the catch-all "Other"/System Data bucket is a residual, not a single deletable object; a cache frees space only temporarily because it soaks back as you use the app; offloading an app keeps its data while deleting removes it, and the fork is a reversibility decision; a licensed download (115) occupies device space but is a licence in your account library, not a file you own, so deleting the local copy severs offline access until you re-download and the re-download depends on the licence still being valid; and the page does not recommend third-party "cleaner" or "booster" apps, because the device's own settings are the authoritative surface and a "cleaner" may request permissions beyond what the OS asks for or delete things you wanted. The freed space refills, so the audit is a routine, not a one-time purge.
The Stock and the Flow
The Most Common Loss Is Not the Full Drive — It Is the "Other" Bucket You Treated Like a Single Thing You Could Delete
The mental image of "storage full" is a single culprit: it must be the photos, or that one app, or the mysterious "Other" folder, and the instinct is to delete the biggest-looking thing and be done. The image is tidy and it is exactly what fails, because storage is a *stock* — a static inventory of everything occupying space *right now* — not a *flow* you can throttle. The breakdown is several named categories, and the catch-all "Other" / "System Data" bucket is a *residual*, not a thing: it is whatever the operating system did not classify, it commonly holds caches, logs, temporary files, and fragments of app data, and it regrows on its own as the device and apps run. The most common loss is not the full drive. It is treating "Other" as a single deletable object and hunting for a folder that does not exist; it is clearing a cache that soaks back by the next afternoon; it is deleting a licensed movie (115) and losing offline access to something you still pay for; it is offloading an app expecting the data back and finding it gone because you deleted instead; and it is installing a third-party "cleaner" that asks for permissions the OS never asked for and "optimizes" by removing things you wanted. The stock does not throttle; it must be read, category by category.
This page is the inventory half of the Apple device cluster; its companions, the lost-device guide and the battery guide, deal with the locate and the decay. The stock-is-not-a-flow reframe below imports the rate-times-time discipline our data-usage guide built and *inverts it for a static object*: 104 taught that data usage is a flow — a rate multiplied by time, a cumulative counter that ticks up and can be capped; 122 teaches that storage is a stock — what occupies space now, which does not tick and must be read as a breakdown rather than throttled. And it ends where 104 did not have to: with the **on-device-versus-in-cloud split** (what's on the phone vs the account vs both as a local copy), the **cache-regeneration tell**, the **offload-versus-delete fork**, and the **licence-occupies-space consequence** imported from 115, because the most common purge deletes a licence or a document the reader meant to keep.
The stock-is-not-a-flow reframe — storage is a static inventory of what occupies space now, not a rate you can throttle, and the "Other" bucket is a residual, not a single object. Storage is full, so one big thing is eating it — delete the "Other" folder and clear the cache and I'm done. Storage is a stock across several named categories. The "Other"/System Data bucket is a residual the OS did not classify, and it regrows. A cache frees space only temporarily. Offloading keeps an app's data; deleting removes it. A licensed download (115) is a licence occupying space, not a file to delete freely. The discipline is to read the breakdown by category, not to purge the biggest-looking thing. This is the reframe the page exists to make, and it is the most carefully hedged line in the batch, because the naive version — "delete the big thing" — leads a reader to hunt for a non-existent "Other folder," to clear a cache that soaks back, to delete a paid licence, or to install a "cleaner" that overreaches.
The honest position is neither paralysis nor purge: most storage is legible once you read the device's own breakdown, and the largest named categories are usually where the real space is, not the residual. But the stock refills, the cache regrows, and the licence is not a file, so the discipline is a routine audit — read, distinguish cache from data from documents, choose offload over delete where the data matters, handle the residual with a restart and an update rather than a hunt, and verify the freed space. The page teaches the inventory; it does not assert your category sizes, and it refuses third-party "cleaners," because the device's own settings are the authoritative surface. The most common loss is the "Other" treated as one thing, and the second is the purge that deletes a licence or a document.
The stackbar is the page's entire method compressed into one schematic, and its power is that it converts a single number ("storage full") into a breakdown plus a residual. The reader's instinct is to see the bar as "one thing too big"; the discipline is to see it as *several* categories, each with a different remedy, plus a residual that is not a thing at all. The `.s5` residual segment is deliberately the smallest and the vaguest, because the "Other" bucket is exactly that — whatever did not classify — and the most common loss is the reader who treats the smallest, vaguest segment as the single culprit. The widths are not your numbers; the device's own settings are, and the page routes the specifics there rather than asserting a universal breakdown.
On the device — occupies space now
- Local copies — photos and videos downloaded in full, not just optimized thumbnails
- App binaries and data — the app itself plus its saved state and documents
- Caches — the speed copies that regrow after you clear them
- Licensed downloads — the movie or e-book held locally (115), which is a licence occupying space
- Message attachments — the photos and files piled up in conversations
- These occupy device space; removing them frees the stock
The dividing line is the local copy: some items exist in three states, not two — on the device only, in the account/cloud only, or in both as a local copy. An optimized photo holds only a thumbnail locally and the full file in the cloud; a downloaded licensed movie holds the full file locally and the licence in the account; an offloaded app holds its data but not its binary. The discipline is to know which of the three states each big item is in before you delete, because deleting the local copy of a cloud item frees space harmlessly, while deleting the local copy of a licence severs access until you re-download, and the re-download depends on the licence still being valid.
In the cloud / account — does not occupy device space
- Optimized media — full files in the cloud, thumbnails on the device
- Offloaded app data — the state retained while the binary is removed
- Account library — the licensed items you can re-download (115)
- Backups — the copy in the account, not on the phone
- The re-download route — the access that survives deleting the local copy
- These do not occupy device space; they are the safety net for the local copy
The two bands and the divider are the page's method in one distinction, and its power is that it converts a purge into a routing decision. The failure mode the split prevents is the well-meaning one: a reader who, seeing "storage full," deletes the local copy of a licensed movie and then cannot re-watch it on a flight because the title rotated out or the licence lapsed (115), or who deletes an optimized photo's local copy and panics when the full file is still in the cloud and the device was never the only copy. The discipline is to name the state — device, cloud, or both — before you delete, and to remember that the cloud/account is the safety net that makes deleting the local copy safe for most items and unsafe for a licence whose access route is the account, not the file. And the honest limit is that the iCloud local-copy behaviour, the offload availability, and the licence re-download rules are the device's and the platform's to state on your own settings; the page teaches the split, not the content.
The storage-audit sequence — read the breakdown, distinguish the categories, choose the remedy, verify, and repeat
1
Read the device's own breakdown before you delete anythingOpen the device's storage settings and read the category list — the named categories plus the residual. Do not start by deleting; start by reading which categories are large. The stock is legible here, and the biggest named categories are usually where the real space is, not the "Other" residual.
The 104 inversion in action: a flow is capped at the source; a stock is read by category. The device's own settings are the authoritative surface, not a third-party cleaner.
2
Identify the largest named categories, not the residualPhotos & videos, apps, and system data are usually the large segments. The "Other"/System Data residual is usually smaller and vaguer, and it is the last place to look, not the first. The discipline is to attack the big named categories before hunting the residual.
The stackbar's shape in practice: the smallest, vaguest segment is the least productive target, and the most common loss is the reader who inverts the priority.
3
Distinguish cache from app data from documentsFor each large app, ask: is this space a cache (regrows, safe to clear, temporary relief), app data (the app's saved state, stays gone when removed, sometimes what you want to keep), or documents (your own files, never a cache)? The remedy differs by type, and the most common purge confuses them.
The cache-regeneration tell: clearing a cache is a temporary move, not a fix, because the app rebuilds it as you use it.
4
Choose offload over delete where the data mattersOffloading removes the app binary but keeps its documents and data, so reinstalling later restores your state; deleting removes both. Offload the apps you use rarely but do not want to lose the data of; delete only where you are willing to lose the data. The fork is a reversibility decision, and the device's own settings state which apps offer offload.
The offload-versus-delete fork: the most common irreversible loss is the reader who deleted an app expecting the data to survive, because they meant to offload.
5
Handle the "Other"/System residual with a restart and an update, not a huntThe residual is not a single deletable object. The disciplined moves are to restart the device (clears some transient system data), to install pending OS updates (reclaims space and fixes accounting), and to offload-and-reinstall the single app hoarding the most data — rather than to hunt for an "Other folder" that does not exist.
The residual tell: "Other" regrows because it is a residual, not a thing; the restart-and-update move addresses it honestly, and the hunt addresses a fiction.
6
Treat a licensed download (115) as a cache of a licence, not a file to delete freelyA downloaded movie or e-book occupies device space but is a licence in your account library. Deleting the local copy frees space and severs offline access until you re-download, and the re-download depends on the licence still being valid and the title still available. Free the space if you need it, but know the access route is the account, not the file.
The 115 licence-occupies-space consequence: a licence is not a file you own, so deleting the local copy is a decision about access, not just space.
7
Verify the freed space, and repeat, because the stock refillsAfter the audit, re-read the breakdown to confirm the space actually freed (a cache may have already begun to regrow; an update may still be processing). Then diary the audit as a routine, because storage refills as you use the device — the audit is not a one-time purge but a recurring read.
The stock-refills discipline: a flow can be capped once; a stock must be read repeatedly, because it grows back by its nature.
The sequence's logic is the inventory discipline, ordered and repeated: read the breakdown, attack the big named categories, distinguish cache from data from documents, choose offload over delete where the data matters, handle the residual with a restart and an update, treat a licensed download as a cache of a licence, verify, and repeat — because the most common failure is a reader who purged the biggest-looking thing, deleted a licence or a document, cleared a cache that soaked back, and wondered why storage was full again a week later. The discipline is to read the stock by category, to choose the reversible remedy where the data matters, and to treat the audit as a routine rather than a one-time event. And the honest limit is that the category names, the offload availability, the cache behaviour, and the licence re-download rules are the device's and the platform's to state on your own settings; the page teaches the audit, not the content.
The storage anatomy — the category, what it is, and the catch
The "Other" / System Data residual
The vector
The catch
It is a residual — caches, logs, temp files, unclassified fragments — and it regrows. Address it with a restart, an update, and an offload-and-reinstall of the worst offender, not a hunt.
The cache
The vector
A reader who clears a cache, sees the space free, and assumes the problem is solved.
The catch
The cache soaks back as you use the app. Clearing it is temporary relief, not a fix; the real space is in the named categories, and the cache is the least productive target.
App data vs documents
The vector
A reader who deletes an app to free space and loses the saved state or the documents they meant to keep.
The catch
App data is the saved state; documents are your own files. Offload keeps both; delete removes both. The fork is a reversibility decision, and the most common irreversible loss is the delete that meant to offload.
Photos — local vs optimized
The vector
A reader who deletes local photos to free space and panics when the full file is still in the cloud, or who assumes optimization freed space it only deferred.
The catch
Optimization holds a thumbnail locally and the full file in the cloud. Deleting the local copy of an optimized photo is harmless if the cloud copy exists; the access route is the account, not the device.
Licensed downloads (115)
The vector
A reader who deletes a downloaded movie or e-book as if it were a file they own, then cannot re-download it on a flight.
The catch
It is a licence in your account library, not a file. Deleting the local copy severs offline access until you re-download, and the re-download depends on the licence still being valid and the title still available.
Message attachments
The vector
A reader who never looks at the messages category and wonders why "Other" and "apps" are large.
The catch
Conversation attachments pile up silently and often classify under the messaging app or the residual. Reviewing and clearing old attachments is a legitimate, often-overlooked source of freed space.
System & updates
The vector
A reader who ignores pending OS updates and wonders why system data is large and the accounting looks wrong.
The catch
Pending updates and old system caches inflate the residual. Installing updates reclaims space and fixes accounting; the restart-and-update move is the honest address for the residual.
The third-party "cleaner"
The vector
A reader who installs a "cleaner" or "booster" app to fix storage and grants it the permissions it asks for.
The catch
The device's own settings are the authoritative surface. A "cleaner" may request permissions beyond what the OS asks for and may delete things you wanted — the same official-route discipline the download, reduce-data, buffering, and permission guides hold.
| Category | What it is | Frees space by | The catch |
|---|---|---|---|
| "Other" / System | The unclassified residual | Restart, update, offload-and-reinstall the offender | Regrows; not a single deletable object |
| Cache | Speed copies the app rebuilds | Clear (temporary) | Soaks back; least productive target |
| App data | The saved state | Offload (keeps) or delete (removes) | Delete loses the state you may want |
| Documents | Your own files | Move to cloud, then remove local | Never a cache; back up before removing |
| Photos (optimized) | Thumbnail local, full in cloud | Optimization defers; delete local copy is harmless if cloud exists | Access route is the account, not the device |
| Licensed downloads | A licence held locally (115) | Delete local copy frees space | Severs access until re-download; licence may lapse |
| Message attachments | Piled-up conversation files | Review and clear old attachments | Often overlooked; classifies under the app or residual |
| System / updates | Pending updates, old caches | Install pending updates | Inflates the residual; fixes accounting |
The anatomy is the same claims-vs-mechanism habit the payslip, bill, and quality guides taught, applied to a stock where the claim is "delete the big thing" and the mechanism is the category, the remedy, and the catch. The "Other" is not a thing. A cache is not a fix. App data is not a document. An optimized photo is not a local file. A licensed download is not a file you own. A message attachment is not invisible. A pending update is not nothing. A "cleaner" is not the authoritative surface. The discipline is the anatomy: read the category, name the remedy, respect the catch — because the most common loss is the "Other" treated as one thing, and the second is the purge that deletes a licence or a document the reader meant to keep.
The offload-versus-delete and cache tells — the reversibility fork and the regrowth
offload keeps the data; delete removes it
a cache soaks back after you clear it
app data is the saved state, not a cache
documents are your files, never a cache
a licensed download is a cache of a licence (115)
an optimized photo's full file is in the cloud
the "Other" residual regrows
a restart and an update address the residual
message attachments pile up silently
a third-party "cleaner" overreaches
the stock refills, so the audit is a routine
The tells are the reversibility and regrowth signals that convert a purge into an audit, and the discipline is to read them as the difference between a temporary free and a permanent loss. The offload-versus-delete fork is the load-bearing guardrail: offloading keeps the data and is reversible, deleting removes it and is not, and the most common irreversible loss is the delete that meant to offload. The cache-regeneration tell is the second: clearing a cache is temporary relief because it soaks back, so the real space is in the named categories, not the cache. The licence tell (115) is the third: a licensed download is a cache of a licence, so deleting the local copy is a decision about access, not just space. And the "cleaner" tell is the reciprocal guardrail: the device's own settings are the authoritative surface, and a third-party tool may overreach. The safe posture is the routine audit — read, distinguish, choose the reversible remedy, verify, repeat — because the stock refills by its nature.
A worked example: the two readers, and the one who read the stock
Concretely, the stock-is-not-a-flow reframe, the on-device-versus-in-cloud split, the storage-audit sequence, the storage anatomy, and the offload-versus-delete tells meeting two readers whose device reports "storage almost full."
Reader one purges the biggest-looking thing and loses a licence. They open storage, see a large "Other" and a large "movies" entry, search for an "Other folder" that does not exist, fail, then delete the downloaded movie to free space and install a third-party "cleaner" to attack the rest. The cleaner asks for broad permissions and "optimizes" by removing old message attachments reader one wanted. The movie's local copy is gone, and on the flight home reader one cannot re-download it because the title rotated out (115). The "Other" regrows within a week because it was a residual, not a thing. The loss is not the full drive; it is the purge that deleted a licence, overreached through a cleaner, and never read the named categories where the real space was.
Reader two reads the stock and chooses the reversible remedy. The same report, the same instinct to purge — but reader two opens the device's own storage settings and reads the breakdown first. The largest named category is photos & videos, so they turn on optimization (full files to the cloud, thumbnails local) rather than deleting. The next is a single app hoarding data they rarely use, so they offload it (keeping the data) rather than delete. They clear the messaging app's old attachments deliberately, keeping the ones they want, rather than letting a cleaner decide. They treat the downloaded movie as a licence (115): they delete the local copy only because they know the title is still in their account library and re-downloadable, and they note the access route is the account. They address the "Other" residual with a restart and a pending OS update rather than a hunt. They verify the freed space, diary the audit as a routine, and do not install a cleaner. The stock refills in a month, and reader two reads it again — because a stock is a routine, not a one-time purge.
The lesson is the whole page. Both readers had the same report and the same instinct; the difference was not the device but the read. Reader one purged the biggest-looking thing, deleted a licence, overreached through a cleaner, and never distinguished cache from data from documents. Reader two read the stock by category, chose the reversible remedy (offload over delete, optimization over deletion), treated the licence as a licence (115), addressed the residual honestly, verified, and diaried the routine. The stock-is-not-a-flow reframe is what prevented the purge — a stock is read by category, not throttled — and the honest limit is that the page cannot assert your category sizes or your device's offload availability, because those are your own settings' to show. The most common loss is the "Other" treated as one thing, and the discipline is to read the stock, choose the reversible remedy, and repeat.
The Check
A Sensible Default
- Hold the reframe: storage is a static inventory (a stock), not a rate (a flow) — you cannot throttle it, only remove items, and some items regrow.
- Read the device's own breakdown before you delete; the largest named categories are usually where the real space is, not the residual.
- Respect the "Other" as a residual: it is not a single deletable object, it regrows, and the honest address is a restart, an update, and an offload-and-reinstall of the worst offender — not a hunt.
- Distinguish cache from app data from documents: a cache soaks back (temporary relief), app data is the saved state (offload keeps, delete removes), documents are your files (never a cache; back up before removing).
- Choose offload over delete where the data matters, because the fork is a reversibility decision and the most common irreversible loss is the delete that meant to offload.
- Know the on-device / in-cloud / both local-copy states before you delete: deleting a cloud item's local copy is harmless; deleting a licence's local copy severs access until re-download (115).
- Treat a licensed download (115) as a cache of a licence, not a file to delete freely — the access route is the account, and the re-download depends on the licence still being valid.
- Refuse the third-party "cleaner" or "booster": the device's own settings are the authoritative surface, and a cleaner may overreach permissions or delete what you wanted.
- Verify the freed space and repeat the audit, because the stock refills by its nature — a flow can be capped once; a stock must be read repeatedly.
The honest takeaway is that storage is a stock read by category rather than a flow throttled at the source, and the discipline that frees space without loss is the inventory: read the device's own breakdown, attack the big named categories, distinguish cache from data from documents, choose offload over delete where the data matters, know the local-copy state before you delete, treat a licence as a licence (115), address the residual with a restart and an update, refuse the cleaner, verify, and repeat. For the flow decoder this page inverts, see our data-usage guide; for the licence-occupies-space consequence this page imports, see our digital-purchases guide; for the account-data cascade this page must not duplicate, see our export-or-delete guide; for the permission doors this page does not touch, see our app-permissions guide; for the decay curve this page contrasts with, see our battery-health guide; and for the actual category names, sizes, offload availability, cache behaviour, and licence re-download rules of your device, see the device's own storage settings and the OS vendor's support documentation — the authorities this page keeps routing you to, because the shape of the stock-is-not-a-flow is durable, the specifics are not ours to assert, and the "Other" treated as one thing is the loss.
Common Questions
Frequently Asked Questions
Why is my "Other" or system storage so large?
Because the catch-all bucket is a residual, not a single object — it is whatever the operating system did not classify into a named category, and it commonly holds caches, logs, temporary files, system data, and fragments of app data. It is not one thing you can select and delete, and it regrows on its own as the device and apps run. The disciplined moves are to restart the device (which clears some transient system data), to install pending updates (which can reclaim space and fix accounting), and to offload-and-reinstall the single app that is hoarding the most data, rather than to hunt for an "Other folder" that does not exist as a deletable object.
Does clearing an app's cache free space permanently?
Usually not, and the cache-regeneration tell is the load-bearing distinction of the page. A cache is a copy the app keeps to load faster, and it soaks back after you clear it, because the app rebuilds it as you use it. The discipline is to distinguish cache (regrows, safe to clear, temporary relief) from app data (the app's saved state, stays gone when removed, sometimes the thing you actually want to keep) from documents (your own files, never a cache). Clearing cache is a temporary move, not a fix, and the real space is usually in the largest named categories, not the cache.
What is the difference between offloading and deleting an app?
Offloading removes the app's binary but keeps its documents and data on the device or in the account, so reinstalling later restores your state; deleting removes both the app and its data, and the data is gone. The discipline is to offload the apps you use rarely but do not want to lose the data of, and to delete only the apps whose data you are willing to lose. The fork is a reversibility decision, and the device's own storage settings state which apps offer offload; the page does not assert a universal behaviour.
I deleted a downloaded movie to free space. Did I lose what I paid for?
Not necessarily the purchase, but possibly the access, and this is the licence-occupies-space consequence the digital-purchases guide names. A downloaded movie or e-book is usually a licence held in your account library, not a file you own, so deleting the local copy frees device space and severs offline access until you re-download — and the re-download depends on the licence still being valid and the title still being available. The discipline is to treat a licensed download as a cache of a licence rather than a file to delete freely: freeing the space is fine, but know that the access route is the account, not the file, and that a lapsed licence or a rotated-out title may not re-download.
Will a third-party "cleaner" or "booster" app fix my storage?
The page does not recommend one, and the official-route discipline the download, reduce-data, buffering, and permission guides all hold applies here. The device's own storage settings are the authoritative surface for what occupies space and what can be offloaded or cleared; a third-party "cleaner" may request permissions beyond what the OS asks for, may "optimize" by deleting message attachments or documents you wanted to keep, and may itself become a new category of storage to audit. The disciplined moves are the read-the-breakdown, the offload-versus-delete fork, the restart-and-update for the residual, and the optimization for media — all inside the device's own settings. If a cleaner claims to "restore" space the OS cannot account for, that is the tell to decline it rather than to grant it access.
Does turning on iCloud photo optimization actually free space?
It defers it, and the on-device-versus-in-cloud split is the point. Optimization holds a thumbnail on the device and the full file in the cloud, so the device space is freed for the local copy while the full file remains in the account — which is harmless as long as the cloud copy exists and your account has the storage for it. The discipline is to know that optimization is a local-copy decision, not a deletion of your photos: the access route becomes the account, so a lost account or a full cloud storage is a different problem than a full device. And the catch is the reverse of the purge error: a reader who deletes local photos thinking optimization will save them, when optimization was never turned on, loses the only copy. Turn it on deliberately, confirm the upload completed, and then the local-copy decision is safe.
Why did my storage fill up again right after I cleaned it?
Because a stock refills by its nature, and the cache-regeneration tell is the most likely immediate cause. The cache you cleared soaks back as the apps rebuild it; the message attachments and photos you did not address keep accumulating; the "Other" residual regrows as the device logs and caches; and a pending OS update that was processing may have completed and reclaimed space you did not see reflected. The discipline is to treat the audit as a routine rather than a one-time purge: re-read the breakdown, confirm which category refilled, and address the named category (optimization for media, offload for the hoarding app, attachment review for messages) rather than re-clearing the same cache. A flow can be capped once; a stock must be read repeatedly, and the refill is the evidence that you cleared a cache instead of reading a stock.
Ask our AI. Auditing a stock or choosing offload over delete? Tap the chat icon and tell us the device's own breakdown — the largest named categories, the size of the "Other" residual, and which apps hold the data you care about — and it can walk the storage-audit sequence, apply the cache-versus-data-versus-documents distinction, and flag the licence-occupies-space consequence (115) and the offload-versus-delete fork — and it will never assert your category sizes, recommend a third-party cleaner, or tell you to delete a licence as if it were a file. It will route the category names, the offload availability, and the cache behaviour to the device's own storage settings and the OS vendor's support documentation.
More device & storage guides like this
We treat storage as a static inventory read by category rather than a flow throttled at the source — so the discipline is the audit: read the device's own breakdown, attack the big named categories, distinguish cache from data from documents, choose offload over delete where the data matters, know the local-copy state, treat a licence as a licence (115), address the residual with a restart and an update, refuse the cleaner, verify, and repeat.
Explore All GuidesKeep Reading
Sources:
Other Projects
More from the creator
Explore two other projects from the same creator.