my first real mac app, built with swiftui and a lot of ai help (not gonna lie, im a webdev not a swift dev lol)

i got way to little storage in my mac and kept running out of space without a clear why. disk tools show a big chart of whats on disk, not what changed. so i wanted something that just tells me what grew and when (caches, docker images, downloads, installs, whatever)

prunr sits in the menu bar and keeps a simple list of what grew on your disk, by day and by app. click a row to see the folders, open them in finder. nothing leaves your mac.

its open source (MIT) if anyone wants to poke around or open prs

https://github.com/merlinkraemer/prunr

a dmg is also avaliable here:
https://merlinkraemer.github.io/prunr/

still in early testing so any help is appreciated! lmk what you think :)

Hi everyone.

Is there a way in SwiftUI to change list row color without killing all interaction highlights stuff?

Example:

List row has some default background color for iOS view. On tap, it highlights. On iPad or in sidebar in general, it has no background until the item is selected, then it has capsule shaped background. When interacting with row using swipe actions, it adds another highlight + rounded corners to the row.

What I tried:

- Simple .listRowBackground kills all interaction highlights and transparency for sidebar Lists.

- I tried replacing NavigationLink with Button and creating my own custom button style. This allowed me to bring highlight-on-tap back, but it introduced more problems. I failed to properly control swipe gesture highlight and rounded corners, sidebar transparency and such. Every time I tried custom solutions, something else broke or did not work as intended. I also realized with this approach, that List component does not have same default row insets for all screen sizes. iPhone Max has bigger insets than small iPhone, iPad even bigger. They are also orientation dependant.

Is there a way to change row background color without loosing all of default system interaction stuff? GitHub app for example has custom color and still has interaction highlights and so on. Do they use UIKit for this and would I need to rework my Lists in UIKit to get same possibility?

I wrote a technical walkthrough of a subtle Swift Concurrency issue I wanted to explore.

Imagine a task writing data into a buffered writer. The task gets cancelled, defer runs, and close() gets called. But if close()invokes a cancellation-aware flush(), that flush can throw CancellationError. If the error is swallowed and the writer is marked closed anyway, the cleanup path has run without achieving its intended postcondition.

The article explores two Swift Evolution proposals:

• SE-0493: Async calls in defer bodies
• SE-0504: Task Cancellation Shields

It covers a minimal reproduction, the limits of using Task.detached for cleanup, a narrowly scoped cancellation shield, and a Swift Testing example that checks whether the data was actually flushed rather than merely checking whether close() was called.

One important caveat: the example demonstrates a cancellation-aware cleanup failure, not a claim that every real file API corrupts data when cancelled.

I'd be interested in feedback on the cancellation-shield approach, especially around resource ownership and cleanup guarantees in production code.

I can check VoiceOver labels and traits on a static screen fairly easily. The part I still find harder to verify is what happens immediately after a state change.

For example, after a toggle is switched, a list is filtered or reordered, or the language and reading direction change, I want to know three things: where does focus land, in what order are the items then spoken, and does an announcement happen at all — or does VoiceOver simply go quiet while the screen has changed underneath it?

What I am trying to separate is the announcement from the journey. A correct announcement does not necessarily mean focus landed somewhere sensible, and a sensible landing spot does not necessarily mean the new order makes sense when it is spoken from there.

So I am curious how other SwiftUI developers actually check this in practice:

• Do you test mainly on a real device, and if so, what do you do differently there compared with the simulator or Accessibility Inspector?
• After a change, do you deliberately move focus, or do you check where VoiceOver takes you without touching anything first?
• How do you check spoken order when items have been reordered or filtered — by stepping through the whole list again, or by checking the changed region only?
• What do you record for each case? I have been noting the starting element, the action, the element focus lands on, the spoken sequence, and whether any announcement fired at all, but I am not sure that is the right set.

One clear question, then: what is your repeatable method for verifying focus landing and spoken order after a state change, and what does it catch that a simple label check misses?

For the past few months I’ve been building Lumen, a native macOS browser written in Swift and SwiftUI on top of WKWebView. I wanted to learn Swift properly, and a browser touches everything: UI, performance, storage and security. It’s taught me more than any tutorial.

All the releases are from today because I’d already built the whole browser but never put it on GitHub, so I just uploaded all the versions I’d made. (If you see gaps between the uploads, it’s because I was running the tests, building the DMGs and so on.)

Some things I ran into:

• SwiftUI redraws: every tab row was observing the whole browser state, so loading progress on one tab redrew the entire sidebar. Fixed it with .equatable() rows that take plain values, and by moving fast-changing state (load progress, pull-to-refresh) into separate small ObservableObjects.
• Profiles with WKWebsiteDataStore(forIdentifier:): removing a store while the app is running fails with “in use”, and calling it before WebKit has initialised crashed the app. So I erase the data immediately and remove the folder at the next launch.
• Resumable downloads: resumeDownload(fromResumeData:) works well, but decide(destination:) is not called again on resume, so you have to keep track of the destination yourself.
• History moved from JSON to SQLite: I was rewriting a 10k-entry JSON file on every visit. Now it’s SQLite in WAL mode with writes on a background serial queue, so one visit is one INSERT OR REPLACE.
• Battery and memory: idle background tabs hibernate in Low Power Mode (NSProcessInfoPowerStateDidChange) and on memory pressure (DispatchSource.makeMemoryPressureSource).
• Self-updating without Sparkle: it downloads from GitHub Releases and checks the file with a SHA256 (CryptoKit) and codesign --verify --deep --strict before replacing itself.

Tech: Swift, SwiftUI, WKWebView, SQLite. No Electron, no third-party dependencies.
It’s completely free and open source.
Download it from: scadavide55.github.io/Lumen
Code: github.com/scadavide55/Lumen

It’s still a work in progress (latest pre-release is 1.5.2), so code review and criticism are very welcome. What would you have done differently?

Hey everyone! I wanted a purely native, zero-cloud heads-up display that turns an iPad next to my Mac into an active control surface.

I ended up building Cockpit (MIT licensed, Swift 5.10 + SwiftUI): - Peer-to-peer encryption via Network.framework (zero cloud telemetry) - Contextual hotkeys adapting to active apps (Xcode, Safari, Notion) - 120Hz ProMotion SwiftUI quadrant architecture

Homebrew: brew install --cask Yvsleyen00941/tap/cockpit Live showcase: https://yorben.me/#cockpit GitHub: https://github.com/Yvsleyen00941/Cockpit