# Sunflower: my disk was full and macOS would not say why | Gjorge Karakabakov > System Settings says System Data and stops there. So I had Claude build me a Mac disk analyser that names what is inside it, sizes Xcode by what it really costs, and never counts a byte it cannot prove. I do not know Swift. Free. Source: https://karakabakov.com/posts/sunflower/ --- [← All posts](https://karakabakov.com/posts) # Sunflower: my disk was full and macOS would not say why Gjorge Karakabakov 2026-08-30 - sunflower - macos - swift - claude - xcode The warning came up while I was in the middle of something, the way it always does. I opened System Settings, went to Storage, and looked at the bar. Applications, a slice. Documents, a slice. Then one grey block wider than everything next to it, called System Data, and clicking it does nothing at all. I had a guess, because I write software on this machine and everybody who does has the same guess. Xcode. But a guess is not a number, and nothing on the Mac was going to give me one. So there is now a Mac app that gives me the number. I should say up front that I do not know Swift. I described what I wanted to Claude, ran what came back, and told it when the app was wrong. That was the whole method, and half of this post is about what that turns out to be like. **Get it: [sunflower.idad.fyi](https://sunflower.idad.fyi/)** free, macOS 15 or later, Apple silicon, notarized by Apple. There is no licence to buy and no account to make. ![A ring of coloured wedges with one ruled wedge lifted clear of it, tied by lines to six rows beside it, the last of them ruled rather than filled](https://karakabakov.com/images/sunflower.webp) ## Why the apps that already exist did not help DaisyDisk is lovely. GrandPerspective and OmniDiskSweeper are free and do the job they say they do. All of them walk your folders and draw you the result, and all of them go quiet at exactly the point you are stuck, because the space you are looking for is not in your folders. It is snapshots, Time Machine’s local backups, old iPhone backups, caches, and iCloud files that came down onto the disk without anybody asking. Sunflower draws rings too, because a picture of a disk is a good picture. The rings were never the reason. The grey block was. ## What is actually in there Xcode’s build leftovers, ordinary caches and old iPhone backups are the easy ones. They sit at plain paths in your home folder, nothing guards them, and you can size them exactly. Build leftovers are also the only category on the list that is unambiguously safe to bin, because Xcode rebuilds them next time you open a project and knows how. The rest is a mess of half answers. Some system cache folders refuse to open even to a program that only wants to count, so the app adds up what it can see, says how much it could not, and never offers to delete any of it. Mail gets a size and is still marked as space you cannot reclaim, because from outside there is no telling which files in there are downloaded attachments and which are the mailbox itself. Mail should prune Mail. The command that lists Time Machine’s local backups comes back with an error that could equally mean “none configured” or “you are not allowed to look”, so that row says unknown, because reporting a folder you cannot read as zero is the easiest way to lie to somebody in an app like this. Then the real gap. Snapshots can be listed, and macOS will tell you whether each one is disposable, but nothing available to me will say how many bytes any individual snapshot is holding. There is exactly one number for it, and it is a single lump covering everything disposable on the disk at once, with no way to split it back apart. Putting that in the snapshots row would mean either counting the same bytes twice or inventing a split. So snapshots get a count and no size, and those bytes land in a row that says plainly it cannot account for them. Every other analyser I have used will show you a confident number there. I would rather have one honest row than a confident wrong one, and that turned out to be the decision the rest of the app kept coming back to. Which is roughly the shape of everything I contributed. Not how any of it works. What it is allowed to claim. ## Xcode, since that is what started this Finder says Xcode is twelve gigabytes. On my machine it is twenty three, once you add the support folders and caches carrying Xcode’s name, most of it build leftovers. The applications screen does that for every app you have, biggest first. The part I use constantly is not the uninstall button. It is that you can take the eleven and keep the app. Clearing a build cache while keeping the tool you build with is what you want nine times out of ten, and it is oddly hard to do from Finder without a folder path you looked up once and now paste from a note. Apps you already deleted get their own section, for the preference files and support folders they left behind. Matching those back to whatever they came from is guesswork, so the section says it is guessing, names what it thinks it found, and never ticks anything for you. ## Six and a half minutes The first honest measurement of a full scan on my own machine: 397 seconds, 4.6 GB of memory, 5.3 million files, 239 GB counted. Nobody opens that twice. I could not read the code well enough to know why. What I could do was measure it, describe the shape of the problem, and refuse to accept “it should be better now” without a new number. Three causes turned up, unrelated to each other, which is why the total was so bad. Some internal bookkeeping was getting in the way of the actual work. The scan was splitting the disk into chunks so uneven that one of them, my home folder at 122 of the 239 GB, ran alone for the entire six and a half minutes while everything else finished in seconds and then sat there. And the app was quietly holding on to about ten small objects per file, for nothing, five million times over. Fixing all three got a full scan to a little under a minute, and memory to about 1.4 GB. I wanted thirty seconds. It is not thirty seconds. I would rather write that down than quietly stop mentioning it. ## The numbers have to be true If the app tells you that you will get 40 GB back and you get 12, you delete the app, and you are right to. So iCloud files that are not really on your disk count as zero, and never get downloaded in order to be weighed. Copies that share their bytes with something else get counted once. Both of those nearly broke, and it is my favourite thing that happened in the whole project. A speed change took the scan from 89 seconds to 58, which is a real win. It also took the number of cloud-only files found from 4,849 down to 1,911, which is not. Same machine, same disk, nothing had moved. The byte totals from the two runs agreed to within a quarter of a percent, so the summary screen looked completely fine. Three thousand files had just stopped being seen. The cheap shortcut only recognises the modern kind of cloud file, and older iCloud syncing and some third-party providers do not use it. This is what reviewing work looks like when you cannot read it. You run the same thing twice and stare at the numbers that should not have moved. If I had only been checking the total, that one ships. A later change nearly ate the same files again for a different reason. To keep memory down, a folder’s tiniest items get folded into a single “and 40 more items” line, and cloud-only files count as zero bytes by definition, which makes them the smallest things on the disk and the first to disappear. They are exempt now. That is the only problem in this post that got caught before it ran rather than after. ## Things I only found by opening the app Three defects, none of which a test would have caught, all of which took about four seconds of looking at the running app. Mid-scan, macOS put up a dialog asking whether Sunflower could get at my music library. Permission popups during a scan are the exact thing the scan is written to avoid, and the list of things it steps around only knew about the photo library. It knows about music and TV now. That list is guesswork rather than anything Apple publishes, and it has grown by an entry nearly every time somebody has run a scan on a machine with something new on it, so I assume it is still incomplete. The banner that tells you how much of the disk the app was not allowed to see only appeared if you had not granted Full Disk Access. But Full Disk Access does nothing about plain file ownership. So the one person who had granted it, still could not read another account’s home folder, and had a genuine shortfall on screen, was the only person who could never reach the control that fixes it. ## Reading a disk you do not own When a scan comes back short, what people ask for is to run it as administrator. That does not do what they think. Most of the popups are consent, and administrator is subject to consent too. What it actually buys you is file ownership, which means sizing another account’s home folder instead of showing a hole where it should be. So there is a small helper with those rights, and it can do exactly two things: read a folder, and answer a ping. No delete, no write, nothing else, and there never will be. There is a check that fails if anyone ever adds one, because a guarantee nobody enforces is a comment. DaisyDisk’s admin mode will happily remove root-owned files for you. This one cannot. Every deletion still happens as you, with your permissions. ## Not on the App Store The sandbox blocks reading anything you did not hand over in a file picker, which rules out scanning a disk. It blocks the system commands behind most of the System Data screen. It blocks touching another app’s files, which rules out the uninstaller. Every part of this app that is a reason to install it is a part the store cannot ship. So it is a notarized disk image from its own site instead. Two megabytes. ## What is not done - Snapshots are still in nobody’s row. They get listed, and their bytes sit in the honest remainder rather than next to their own name. - A full scan is under a minute and I wanted thirty seconds. - Leftover matching misses apps that scattered their files under a name resembling nothing about them. There is no clever fix, only a longer list of special cases, and I have not decided how much of that I am willing to carry. - It opens on the disk picker every single time, including when it has a perfectly good saved scan sitting there. That is deliberate and I still change my mind about it once a week. - English only. ## Was it worth it I have a number now. The grey block on my machine is mostly Xcode build leftovers, and I can see the figure, and clear it, and keep Xcode, without opening a terminal or trusting a folder path copied out of a forum thread. That is a smaller claim than the one I set out with. I wanted to explain all of System Data, and one category of it genuinely cannot be explained from where I am standing. What I can say is that the app never pretends otherwise, which turned out to be the harder half. And I have an app written in a language I do not know. The part I actually did was run it, use it, and pay attention on the day 4,849 turned into 1,911. ## Keep reading [![Seven loose clip cards lying at angles on cream paper, thin lines gathering from each of them into a single upright film strip holding one frame and a play triangle](https://karakabakov.com/images/openmontage.webp) August 23, 2026 ### A trailer for Cadence, made by an agent for $6.13](https://karakabakov.com/posts/openmontage-trailer) [![PocketBase running as the backend for a web and mobile project](https://karakabakov.com/images/pocketbase.webp) January 14, 2024 ### Using PocketBase.io as your backend for your next project](https://karakabakov.com/posts/using-pocketbase-as-backend) [← All posts](https://karakabakov.com/posts) [Get in touch](https://karakabakov.com/contact)