Snafu – Wade Tregaskis

Bugs Apple Loves & Apps Apple Hates

Mon, 26 Jan 2026 01:48:06 +0000

It’s been a while since I’ve seen such a pithy and accurate representation of what it’s like being an Apple Mac & iPhone user these days (well done Nick Hodulik!).

The externalities cost estimates might be a little tongue-in-cheek, but honestly, are they all that wrong? One small irritation at the wrong moment can ricochet my happy mood off into the doldrums, and Apple’s products produce a hundred “small” irritations every day – which compound in their irritation when you see them software update after software update, year after year, product after product. It’s hard not to take it personally. Like Apple is deliberately being cruel.

Daniel Kennett wrote, in his memorial to Aperture, about how the Mac-using experience wasn’t actually rainbows and perfection even back in whatever you personally feel was the golden age (I’m with him that circa System 7.1 was glorious, though the early days of Mac OS X were also very special to me). Which is true – fire up your favourite old Mac on Infinite Mac and see the strength of your rose-tinted nostalgia glasses.

But, the big difference is that Apple back then was a relatively tiny company struggling just to survive in a brutal industry dominated by soulless, greedy monsters.

There is a point at which mere indifference or incompetence transitions into negligence, and it’s long before you become one of the wealthiest companies on the planet with a veritable army of engineers.

Having worked at Apple – among other big tech companies – I can say with confidence that there’s no valid reason why they cannot fix long-standing, infamous bugs. It’s. Not. That. Hard. One half-decent engineer could fix everything listed on Bugs Apple Loves in six months, single-handed.

It’s not apparent why that doesn’t happen, but it’s not that Apple are technically incapable of it, and it cannot be that they’re unaware, so it must be that they’re choosing not to.

Recording audio to an iPhone via a Tascam Portacapture X8

Thu, 22 Jan 2026 06:04:04 +0000

It is possible to use the Tascam Portacapture X8 as an ADC, input converter, and mixing board for an iPhone, but there’s a few things you’ll need to know.

Thankfully, any USB-C or USB-C-to-Lightning cable will do

You just connect one end of the USB-C cable to the Portacapture X8 (to its built-in USB port) and the other to your iPhone (USB-C or Lightning work, as suits your particular model of iPhone).

The Portacapture X8 can both record audio via USB and output it. It will automatically output it to any connected device that accepts it. As far as I can tell it uses the master track mix (there doesn’t seem to be any way to send multiple tracks simultaneously – I assume the USB audio protocol only allows a plain stereo transmission).

You must use 48kHz sampling

If you don’t, you’ll quickly get an error dialog on the Portacapture X8 saying “USB FS Mismatch”. That’s its daft way of trying to say that the receiving USB device won’t accept the sampling frequency it’s outputting. Why it can’t have a coherent error message, we’ll probably never know.

You can set the sampling rate in the “General Settings” app, under “Rec Settings” (along with the file format and bit depth / rate, though it doesn’t seem to matter what those are set to w.r.t. iPhone compatibility – they affect only recording to the microSD card).

You don’t have to use the iPhone to provide power

By default the Portacapture X8 will try to use the iPhone to provide power, rather than its batteries. But it doesn’t trust USB power sources – it will ask, via a dialog, “Is the AC adapter 1.5A or more?”. On USB-C iPhones you can power the Portacapture X8 over USB – by selecting “Yes” – although it will drain your iPhone’s battery. But whichever option you choose, the Portacapture X8 will then refuse to provide phantom power to your mics. If you’re not using phantom power then no worries, but if you are you must change the Portacapture’s settings – in “General Settings” app, under “Power/Display”, you must set “Power Source Select” to “Battery” instead of “Auto”. That will essentially turn off the Portacapture’s desire for power from USB, leaving USB as an audio channel only. With it powering itself from its batteries, the phantom outputs will work like normal.

You don’t have to record on the Portacapture X8

It passes audio through to the iPhone automatically, even if you’re not actively recording.

Note: I vaguely recall having some issues with this not happening if you change some settings… it’s possible that things like “Pre Rec”, “Auto Rec”, or “Rec Pause” affect this. I have all those off and it works as I’ve described.

How to make a macOS screen saver

Sat, 06 Dec 2025 22:46:22 +0000

First, make sure you really want to. macOS’s screen saver system is absurdly buggy and broken. It’s frustrating to work with and very difficult to make work right.

If you’re determined, read on.

Screen savers are basically just applications. Same bundle format and structure, just with a “saver” extension instead of “app”.

Setting up the Xcode project

In Xcode, create a new project using the Screen Saver template.

Delete the Objective-C code & header files it creates by default (unless, I suppose, you want to write your screen saver in Objective-C – woo, retro! 😆).

You need to import the ScreenSaver module (framework), subclass ScreenSaverView, and implement a couple of method overrides. Here’s the basic skeleton:

import ScreenSaver

class MyScreenSaver: ScreenSaverView {
    override init?(frame: NSRect, isPreview: Bool) {
        super.init(frame: frame, isPreview: isPreview)
        setup()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        setup()
    }

    private func setup() {
        // TODO
    }

    override func startAnimation() {
        super.startAnimation()

        // TODO
    }

    override func animateOneFrame() {  // Optional.
        // TODO
    }

    override func stopAnimation() { //  Only for the live preview in System Settings.
        // TODO

        super.stopAnimation()
    }

    override var hasConfigureSheet: Bool {
        true
    }

    private var configureSheetController: ConfigureSheetController?

    override var configureSheet: NSWindow? {
        configureSheetController = ConfigureSheetController(windowNibName: "ConfigureSheet")
        return configureSheetController?.window
    }
}

class ConfigureSheetController: NSWindowController {
    override var windowNibName: NSNib.Name? {
        return "ConfigureSheet"
    }

    override func windowDidLoad() {
        super.windowDidLoad()

        // TODO
    }

    @IBAction func okButtonClicked(_ sender: NSButton) {
        // TODO

        window!.sheetParent!.endSheet(window!, returnCode: .OK)
    }
}

import ScreenSaver

class MyScreenSaver: ScreenSaverView {
    override init?(frame: NSRect, isPreview: Bool) {
        super.init(frame: frame, isPreview: isPreview)
        setup()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        setup()
    }

    private func setup() {
        // TODO
    }

    override func startAnimation() {
        super.startAnimation()

        // TODO
    }

    override func animateOneFrame() {  // Optional.
        // TODO
    }

    override func stopAnimation() { //  Only for the live preview in System Settings.
        // TODO

        super.stopAnimation()
    }

    override var hasConfigureSheet: Bool {
        true
    }

    private var configureSheetController: ConfigureSheetController?

    override var configureSheet: NSWindow? {
        configureSheetController = ConfigureSheetController(windowNibName: "ConfigureSheet")
        return configureSheetController?.window
    }
}

class ConfigureSheetController: NSWindowController {
    override var windowNibName: NSNib.Name? {
        return "ConfigureSheet"
    }

    override func windowDidLoad() {
        super.windowDidLoad()

        // TODO
    }

    @IBAction func okButtonClicked(_ sender: NSButton) {
        // TODO

        window!.sheetParent!.endSheet(window!, returnCode: .OK)
    }
}

Providing a preferences sheet

If you don’t have any options to configure, you can of course change hasConfigureSheet to return false. Otherwise, you’ll need to create a “ConfigureSheet” xib file with a window in it containing your screen saver’s settings. You can use UserDefaults to save your settings (if you wish), same as any other app. And you’ll need to add an “Okay” or “Save” or similar button to dismiss the sheet.

Getting ready to render

The key methods to implement are setup, with any initial configuration you wish to do (e.g. allocate image or video views, load assets, set up the view hierarchy, etc).

ScreenSaverView is an NSView subclass with a flat black background by default, onto which you can add subviews. Typically for a screen saver you have a very simple view hierarchy – often just a single view or CoreAnimation layer that you’re rendering to – but you can load a xib and insert elements from it into the view if you like.

☝️ It’s wise to not render anything in setup, which includes accidentally – you might need to set views to hidden, layers to zero opacity, etc. This is basically because there can be an arbitrarily long gap between setup and startAnimation calls, and it’s often weird to render something initially, potentially not animate for a noticeable length of time, and then start actually working properly.

Alternatively, you might insert a placeholder image or text, e.g. “Loading…”, if you really want. But in my opinion it’s more graceful to just let the initial black screen stand for a moment.

Rendering

startAnimation is where you should actually start displaying things. e.g. if you’re using an AVPlayer, this is where you actually start it playing (after making it visible, e.g. setting its opacity to 1).

animateOneFrame is optional, and is only called if you set the animationTimeInterval property (on self) to a finite, non-zero value in setup (in which case it’ll be called at intervals at least that long – it might not be called as often as you desire if previous calls overrun or there’s other bottlenecks in the screen saver framework). It’s essentially just a minor convenience vs having to explicitly set up an NSTimer.

Given how buggy Apple’s screen saver framework is, I suggest not relying on animateOneFrame if you can at all avoid it. Even if that means setting up your own timer. That way when they likely break that too in some future macOS release, your screen saver won’t necessarily break as well.

Bonus topic: fading in

Unless your screen saver inherently appears gently (e.g. starts rendering with a flat black view and only slowly adds to it), it’s nice to add a fade-in. You can do that using CoreAnimation on the view’s layer:

override func startAnimation() {
    // Other code…
    
    if let layer {
        layer.opacity = 0.0  // Should already be zero from `setup`, but just to be sure.

        let fadeAnimation = CABasicAnimation(keyPath: "opacity")
        fadeAnimation.fromValue = 0.0
        fadeAnimation.toValue = 1.0
        fadeAnimation.duration = 5  // Seconds.

        // Essential settings to keep the final state
        fadeAnimation.fillMode = .forwards
        fadeAnimation.isRemovedOnCompletion = false

        layer.add(fadeAnimation, forKey: "fadeAnimation")
    }
    
    // Other code…
}

override func startAnimation() {
    // Other code…
    
    if let layer {
        layer.opacity = 0.0  // Should already be zero from `setup`, but just to be sure.

        let fadeAnimation = CABasicAnimation(keyPath: "opacity")
        fadeAnimation.fromValue = 0.0
        fadeAnimation.toValue = 1.0
        fadeAnimation.duration = 5  // Seconds.

        // Essential settings to keep the final state
        fadeAnimation.fillMode = .forwards
        fadeAnimation.isRemovedOnCompletion = false

        layer.add(fadeAnimation, forKey: "fadeAnimation")
    }
    
    // Other code…
}

Note that you cannot implement a fade-out when the screen saver exits, because macOS hides your screen saver immediately. Plus, the user might not want a fade-out as they may be in a rush to do something on their computer.

Previewing

You can determine if you’re running for real or only the preview via the isPreview property (on self). Many screen savers don’t care, but particularly if you save any persistent state, you might want to avoid doing that during preview. For example, in a screen saver which plays a looping video and resumes where it last left off, you probably don’t want the preview to quietly advance the video.

Stopping

stopAnimation is only used for the live preview thumbnail shown in the Screen Saver System Settings pane. It is never called in normal operation of the screen saver (contrary to what Apple’s documentation says – Apple broke that in macOS Sonoma and later).

And that leads to the first path off the official track. When the screen saver is dismissed by the user, nothing in Apple’s framework code does anything. Your view continues to exist, animateOneFrame continues getting called, etc. Your screen saver just runs in the background, its output not visible, but wasting CPU cycles and RAM. Worse, if you have sound, that keeps playing.

🙏 A big thanks to cwizou via StackOverflow for documenting the solution, which I’ve summarised below.

To get around that, you need to register for the com.apple.screensaver.willstop notification, in setup, like so:

  private func setup() {
    DistributedNotificationCenter.default.addObserver(self,
                                                      selector: #selector(willStop(_:)),
                                                      name: Notification.Name("com.apple.screensaver.willstop"),
                                                      object: nil)
}
    
@objc func willStop(_ notification: Notification) {
    stopAnimation()
}

  private func setup() {
    DistributedNotificationCenter.default.addObserver(self,
                                                      selector: #selector(willStop(_:)),
                                                      name: Notification.Name("com.apple.screensaver.willstop"),
                                                      object: nil)
}
    
@objc func willStop(_ notification: Notification) {
    stopAnimation()
}

Note that you still need stopAnimation specifically, because in the live preview in System Settings you won’t receive that com.apple.screensaver.willstop notification (from the system’s point of view, the screen saver isn’t running – it’s merely previewing).

Handling resumption

Here’s the second big bug in Apple’s screen saver framework – every time the screen saver starts, your ScreenSaverView subclass is created again. But the old one doesn’t go anywhere. So now you have two copies running simultaneously, which is at the very least wasteful, and can easily lead to gnarly bugs and weird behaviour (e.g. if both are playing sound, or both modify persistent state).

There are essentially two ways to handle this:

Kill your own process every time you stop animating.
Manually kill or lame-duck older views when a new one is initialised.

Note that you cannot simply check at MyScreenSaver initialisation time if an instance already exists and if so fail initialisation (as is prescribed by this otherwise excellent write-up of this problem), because if you don’t correctly initialise you’ll sometimes end up with nothing rendering or running (the screen saver framework appears to not gracefully handle initialisation failures).

Killing your own process can work but has some perils:

If you kill your process in stopAnimation the screen will flash black momentarily before actually exiting screen saver mode, which is visually annoying.
If the screen saver is restarted rapidly after being interrupted, sometimes you’ll end up with nothing but a black screen (with no screen saver running). There’s evidently some race condition in Apple’s screen saver system between screen saver processes exiting and being [re]launched.

So I recommend not taking that approach. Instead, you can lame-duck the old view instances. They’ll stick around, which is a little wasteful of RAM, but as long as they’re not rendering or otherwise doing anything, they’re benign.

There are various ways to implement that, but one of the simpler ones is simply a notification between instances:

static let NewInstanceNotification = "com.myapp.MyScreenSaver.NewInstance";

var lameDuck = false

private func setup() {
    // Initial setup…
    
    NotificationCenter.default.post(name: MyScreenSaver.NewInstanceNotification, object: self)

    NotificationCenter.default.addObserver(self,
                                           selector: #selector(neuter(_:)),
                                           name: MyScreenSaver.NewInstanceNotification,
                                           object: nil)

    // Further setup…
}

@objc func neuter(_ notification: Notification) {
    lameDuck = true

    stopAnimation()

    self.removeFromSuperview()

    // TODO: any additional cleanup you can, e.g. release image & video files, throw out transient models and state, etc.

    NotificationCenter.default.removeObserver(self)
    DistributedNotificationCenter.default().removeObserver(self)
}

static let NewInstanceNotification = "com.myapp.MyScreenSaver.NewInstance";

var lameDuck = false

private func setup() {
    // Initial setup…
    
    NotificationCenter.default.post(name: MyScreenSaver.NewInstanceNotification, object: self)

    NotificationCenter.default.addObserver(self,
                                           selector: #selector(neuter(_:)),
                                           name: MyScreenSaver.NewInstanceNotification,
                                           object: nil)

    // Further setup…
}

@objc func neuter(_ notification: Notification) {
    lameDuck = true

    stopAnimation()

    self.removeFromSuperview()

    // TODO: any additional cleanup you can, e.g. release image & video files, throw out transient models and state, etc.

    NotificationCenter.default.removeObserver(self)
    DistributedNotificationCenter.default().removeObserver(self)
}

You should check lameDuck at the start of methods like startAnimation or animateOneFrame and exit immediately if it’s set to true. Unfortunately, Apple’s screen saver framework will still call those methods on old instances.

Exiting

Unfortunately Apple’s screen saver system will never terminate your screen saver process. Worse, even if you do nothing yourself, Apple’s screen saver framework code will run in an infinite loop, wasting [a small amount of] CPU time. So it’s not great to leave your screen saver process running indefinitely.

Thus, I implement an idle timeout in my screen savers, to have them exit if they’re not active for a while. This can be done like:

@MainActor var idleTimeoutWorkItem: DispatchWorkItem? = nil

override func startAnimation() {
    // Other code…
    
    DispatchQueue.main.async {
        if let idleTimeoutWorkItem {
            idleTimeoutWorkItem.cancel()
        }

        idleTimeoutWorkItem = nil
    }
    
    // Other code…
}

override func stopAnimation() {
    // Other code…
    
    if !lameDuck {
        DispatchQueue.main.async {
            idleTimeoutWorkItem?.cancel()

            let workItem = DispatchWorkItem(block: {
                NSApplication.shared.terminate(nil)
            })
            
            idleTimeoutWorkItem = workItem
            
            DispatchQueue.main.asyncAfter(wallDeadline: .now() + 65, execute: workItem)
        }
    }
    
    // Other code…
}

@MainActor var idleTimeoutWorkItem: DispatchWorkItem? = nil

override func startAnimation() {
    // Other code…
    
    DispatchQueue.main.async {
        if let idleTimeoutWorkItem {
            idleTimeoutWorkItem.cancel()
        }

        idleTimeoutWorkItem = nil
    }
    
    // Other code…
}

override func stopAnimation() {
    // Other code…
    
    if !lameDuck {
        DispatchQueue.main.async {
            idleTimeoutWorkItem?.cancel()

            let workItem = DispatchWorkItem(block: {
                NSApplication.shared.terminate(nil)
            })
            
            idleTimeoutWorkItem = workItem
            
            DispatchQueue.main.asyncAfter(wallDeadline: .now() + 65, execute: workItem)
        }
    }
    
    // Other code…
}

I chose the 65 second timeout somewhat arbitrarily. I figure there’s a reasonable chance a user will unlock their screen to do something quick, then engage the screen saver again – all in the less than a minute – and the cost of idling in the background for an extra minute is small, compared to the cost of relaunching the whole app and reinitialising your renderer.

I added five extra seconds to reduce the probability of aligning with some one-minute timer (e.g. a spurious wake with the screen saver set to start automatically after one minute of no user activity).

You can adjust it however you like.

Testing your screen saver

Double-clicking the built product (your “.saver” app) will prompt the user to install it, replacing an old version if necessary. So that works, though I find it faster to just manually copy the “.saver” app to ~/Library/Screen Savers. Just make sure to kill the existing legacyScreenSaver process, if necessary.

You can test it in System Settings, in the Screen Saver pane. That’s the only place you can test the live preview part.

But otherwise, I found it easiest to just set one of the screen hot corners to start the screen saver, and use that immediately after copying the new “.saver” file into place.

Just be aware that the first time any new copy of the screen saver runs, macOS runs a verification on the bundle, which can take a while if your screen saver is non-trivial in size (e.g. if you bundle large image or video resources). You’ll get a black screen with nothing happening, after invoking the screen saver, while that verification is running.

Distributing your screen saver

You don’t have to sign your screen saver, necessarily, but users will get some annoying error dialogs trying to run it, and will have to fiddle with things in System Settings – or, if they’re on a corporate Mac, they might not be able to run it at all. So it’s preferable to just sign it.

Xcode doesn’t support signing screen savers like it does for plain app targets and the like. So you have to do it manually via the command line, on the built product (your “.saver” app). Thankfully it’s just two commands (once you have the appropriate stuff set up in your developer account – note that you will need a paid Apple Developer account, at $99/year).

Follow the instructions here, but note that they’re missing the final step:

xcrun stapler staple -v MyScreenSaver.saver

Note that you run it against the screen saver itself, not the zip file. The zip file’s just a hack to get Apple’s notary tool to accept the submission. It’s the screen saver bundle itself that’s actually notarised and signed.

⚠️ notarytool uploads your screen saver to Apple. Be sure it doesn’t contain anything you’re not happy being potentially public (Apple will presumably try to keep your uploads private to Apple, and might not intentionally store them forever, but I wouldn’t bet my life on their confidentiality).

Conclusion

That’s “it” in a superficial sense – if you’ve followed all this so far, you have a roughly working screen saver.

But there are a lot more bugs and nuances thereof that may afflict you, depending on what you’re doing in your screen saver. So good luck. 😣

Addendum: SaveHollywood

I found that looking at existing open source screen savers was partially helpful, but also sometimes misleading. e.g. for my most recent screen saver I basically just play a video in a loop (which should be embarrassingly trivial but took two weeks to get working properly, thanks to the aforementioned bugs in Apple’s frameworks, among many others). In that case I looked at SaveHollywood, a similar screen saver, for aid and ideas.

Unfortunately, SaveHollywood is abandoned and doesn’t work on recent versions of macOS. The way it does some things is archaic and either not the best way or not functional at all.

Nonetheless, it did help with some of the higher-level aspects, above the screen saver machinery itself, like how to use AVPlayer in a screen saver.

So, do check out similar, existing screen savers (and of course just use them directly if they suit your needs!) but beware of obsolete or otherwise incorrect code.

Addendum: What this says about Apple

What really troubles me about the screen saver system is what it says about Apple’s approach to the Mac, software, and their users. Which is sadly just the same thing we’ve been seeing for years now.

Screen savers used to work fine. There was an API established long ago that was lightweight, straight-forward, and effective. All Apple had to do was not break it.

And how they broke it is troubling. Perhaps it was prompted by some otherwise unrelated but well-meaning refactor – pulling screen saver code out into a separate, sandboxed process, perhaps, for improved system security. Fine. But if it’s worth changing it’s worth changing properly. It’s very clear that whomever did the changes either (a) didn’t care that they broke things badly, or (b) didn’t care to check.

It’s that recurring theme of not caring that’s most disappointing in today’s Apple.

Calling Swift Concurrency async code synchronously in Swift

Wed, 21 Aug 2024 00:09:00 +0000

Sometimes you just need to shove a round peg into a square hole. Sometimes that genuinely is the best option (or perhaps more accurately: the least bad option).

I find my hand is often forced by APIs I don’t control (most often Apple’s APIs). e.g. data source or delegate callbacks that are synchronous¹ and require you to return a value, but in order to obtain that value you have to run async code (perhaps because yet again that’s all you’re given by 3rd parties, or because that code makes sense to be async and is used happily as such in other places and you don’t want to have to duplicate it in perpetuity just to have a sync version).

If that asynchronosity is achieved through e.g. GCD or NSRunLoop or NSProcess or NSTask or NSThread or pthreads, it’s easy. There are numerous ways to synchronously wait on their tasks. In contrast, Swift Concurrency really doesn’t want you to do this. The language and standard library take an adamant idealogical position on this – one which is unfortunately impractical; a spherical chicken in a vacuum².

Nonetheless, despite Swift’s best efforts to prevent me, I believe I’ve come up with a way to do this. It appears to work reliably, given fairly extensive testing. Nonetheless, I do not make any promises. Use at your own risk.

If you know of a better way, please do let me know (e.g. in the comments below).

import Dispatch

extension Task {
    /// Executes the given async closure synchronously, waiting for it to finish before returning.
    ///
    /// **Warning**: Do not call this from a thread used by Swift Concurrency (e.g. an actor, including global actors like MainActor) if the closure - or anything it calls transitively via `await` - might be bound to that same isolation context.  Doing so may result in deadlock.
    static func sync(_ code: sending () async throws(Failure) -> Success) throws(Failure) -> Success { // 1
        let semaphore = DispatchSemaphore(value: 0)

        nonisolated(unsafe) var result: Result? = nil // 2

        withoutActuallyEscaping(code) { // 3
            nonisolated(unsafe) let sendableCode = $0 // 4

            let coreTask = Task<Void, Never>.detached(priority: .userInitiated) { @Sendable () async -> Void in // 5
                do {
                    result = .success(try await sendableCode())
                } catch {
                    result = .failure(error as! Failure)
                }
            }

            Task<Void, Never>.detached(priority: .userInitiated) { // 6
                await coreTask.value
                semaphore.signal()
            }

            semaphore.wait()
        }

        return try result!.get() // 7
    }
}

Elaborating on some of the odder or less than self-explanatory aspects of this:

The closure parameter must be sending otherwise this deadlocks if e.g. you call it from the main thread (even if the closure, and all its transitive async calls, are not isolated to the main thread). I don’t understand why this happens – it’s possibly explicable and working as intended, but I wonder if it’s simply a bug. Nobody has been able to explain why it happens.

Note: in the initial version of this post I accidentally omitted this essential keyword. I apologise for the error, and hope it didn’t cause grief for anyone.
Since there’s no sync way to retrieve the result of a Task, the result has to be passed out through a side-channel. The nonisolated(unsafe) is to silence the Swift 6 compiler’s erroneous error diagnostics about concurrent mutation of shared state.
Task constructors only accept escaping closures, even though as they’re used here the closure never actually escapes. Fortunately the withoutActuallyEscaping escape hatch is available.
code isn’t @Sendable – since it doesn’t actually have to be sent in the sense of executing concurrently – so trying to use it in the Task closure below, which is @Sendable, results in an erroneous compiler error (“Capture of 'code' with non-sendable type '() async throws(Failure) -> Success' in a @Sendable closure“). Assigning to a variable lets us apply nonisolated(unsafe) to disable the incorrect compiler diagnostic.
Several key aspects happen on this line:
- It’s important to use a detached task, in case we’re already running in an isolated context (e.g. the MainActor) as we’re going to block the current thread waiting on the task to finish, via the semaphore.
- The task logically needs to be run at the current task’s priority (or higher) in order to ensure it does actually run (re. priority inversion problems), although I’m not sure that technically matters here since we’re blocking in a non-await way anyway. One could use Task.currentPriority here, but I’ve chosen to hard-code the highest priority (userInitiated) because it’s not great to block (in a non-await manner) on async code; although async code isn’t necessarily slow, I feel it’s wise to eliminate task prioritisation as a variable.
- This closure must be explicitly marked as @Sendable as by default the compiler mistakenly infers it to be not @Sendable, even though all closure arguments to Task initialisers have to be @Sendable. The compiler diagnostics in this case are frustratingly obtuse and misleading (although the sad saving grace is that this is a relatively common problem, so once you hit it enough times you start to develop a spidey sense for it).
This otherwise pointless second Task is critical to prevent withoutActuallyEscaping from crashing.

withoutActuallyEscaping basically relies on reference-counting – it records the retain count of its primary argument going in (code in this case) and compares that to the retain count going out – if they disagree, it crashes. There’s no way to disable or directly work around this³.

That’s a problem here because if we just signal the semaphore in the first task, right before exiting the task, we have a race – maybe the task will actually exit before the signal is acted on (semaphore.wait() returns and allows execution to exit the withoutActuallyEscaping block), but maybe it won’t. Since the task is retaining the closure, it must exit before we wake up from the semaphore and exit the withoutActuallyEscaping block, otherwise crash.

The only way I found to ensure the problematic task has fully exited – after hours of experimenting, covering numerous methods – is to wait for it in a second task. Surprisingly, the second task – despite having a strong reference to the first task – seemingly doesn’t prevent the first task from being cleaned up. This makes me suspicious, but despite extensive testing I’m unable to get withoutActuallyEscaping to crash when using this workaround.
There’s no practical way to avoid this forced unwrap, even though it’s impossible for it to fail unless something goes very wrong with Swift’s built-ins (like withoutActuallyEscaping and Task).

If you don’t wish to use typed throws, you could unwrap it more gently and throw an error of your own type if it’s nil, but it’s extra work and a loss of type safety for something that realistically cannot happen.

Specifically meaning “not run through Swift Concurrency, as async functions / closures”. Lots of APIs will execute the callback on the main thread, which is the most difficult case, but even those that execute on a user-specified GCD queue aren’t helpful here – at least, not until assumeIsolated actually works. ↩︎
Incidentally, Wikipedia seems to think the canonical version of the joke is about spherical cows, but I’ve only ever heard it about chickens. Indeed the very first known instance of the joke used chickens, and all the pop-culture uses of it that I could find use chickens (most notably the ninth episode of The Big Bang Theory). ↩︎
There’s no unsafeWithoutActuallyEscaping that forgoes the runtime checking, nor any environment variables or similar that influence it; the check is always included and cannot be disabled at runtime. Even when it’s unnecessary or – as in this case – outright erroneous.

Nor is there a way to replicate withoutActuallyEscaping‘s core functionality of merely adding @escaping to the closure’s signature (e.g. via unsafeBitCast or similar) because it’s a special interaction with the compiler’s escape checker which is evaluated purely at compile-time (whether a closure is escaping or not is not actually encoded into the output binary nor memory representation of closures – the only time escapingness ever leaks into the binary is when you use withoutActuallyEscaping and the compiler inserts the special runtime assertion). ↩︎

Bipolar customer support

Thu, 18 Jul 2024 22:37:30 +0000

Consider these two examples involving Flickr, that occurred within just one day of each other.

Nice gal Amanda

I submitted the following feedback, not really expecting much of it. In fact, I fully expected some useless, boilerplate response that completely ignored the point and directed me to the upload requirements page (despite it being the very first thing I myself pointed to) or was nothing but mail-merge platitudes.

And in retrospect I could have phrased this more respectfully, too. So I wasn’t even going in as a great customer.

Per https://www.flickrhelp.com/hc/en-us/articles/4404079649300-Flickr-upload-requirements, Flickr still doesn’t support modern, more efficient formats like HEIF, WebP, and AVIF (for images).

It’s also unclear what video codecs are actually supported, since they’re not specified – merely container formats. e.g. does AV1 work? Or even just HEVC?

Being relegated to JPEG makes my files way larger and therefore uploads take a lot longer, and also precludes use of high-quality images featuring e.g. greater than 8-bit depths and HDR support.

(I realise TIFF is nominally supported and does at least offer 16-bit support, but the article notes that it’s degraded to JPEG anyway on the server, plus even compressed TIFFs are still huge and particularly slow to upload)

On your end, you’d save a lot of storage space if you supported and prioritised modern, more efficient formats – not to mention bandwidth costs (every browser of note supports WebP & AVIF at the very least, so you could even transcode from older formats).

What I got surprised me greatly, in the best way:

Hi Wade,

Thank you for reaching out to us! My name is Amanda and I’m happy to help you.

I understand you would like to see more photo formats accepted on Flickr (namely: HEIF/HEIC, WebP, AVIF). I’ve passed a feature suggestion along to our product development team for review regarding this. Hopefully, being able to offer support for these newer file formats is something we can address in a future site update.

While I do not have a timeframe for if/when this would be put into effect, they are aware that this is something that members of Flickr would like to see as an option.

You also mentioned some specific video codecs. As these aren’t listed in that Help Center article you linked, I’m double checking with our team to see if these are supported or not. As soon as I hear back from them, I’ll follow up and let you know here.

In the meantime, please let me know if you have any other questions or suggestions. I’ll keep an eye out for your response!

Warmly,

Amanda
Flickr Support

Holy shit. A humane response from a real human. Better yet, a couple of hours later that was followed by (unprompted by me):

Hi Wade,

Thank you for your patience! I checked with our team and it appears AV1 and HEVC are not currently supported. I have added these along to the other formats you had already asked about in our feedback to the Product Development team.

If there is anything else I can help with, please do feel free to reach out!

Warmly,

Amanda
Flickr Support

Even though these responses made no conclusive promises (regarding support for these file formats), I was thrilled. Beyond the pleasant tone and clear demonstration that Amanda actually read and comprehended my feedback, just knowing that my feedback actually got to the intended recipients (the dev team) is heartening; it made me feel good about choosing to use Flickr for all these years.

But then…

Bad guy Marc

Coincidentally, while Amanda was getting back to me I ran into a bug in Flickr’s file upload API. It was apparent from the logs that Flickr was the cause of the issue, but nonetheless I took the time to first confirm that with the Photo Upload plug-in’s author. Then, I submitted the bug report to Flickr:

When trying to upload some (but not all) files, the upload ostensibly fails – it hangs for a while after the transfer is complete before finally concluding with a 504 error from CloudFront. e.g.:

Log

Matching prefixes in Swift strings

Thu, 02 May 2024 01:46:02 +0000

How do you determine if one string starts with another, in Swift?

Surely that’s exactly what the hasPrefix(_:) method is for:

let greeting = "Hello"
let sentence = "hello, this is dog."


if sentence.hasPrefix(greeting) {
    print("Hi!  Nice to meet you!")
} else {
    print("No can haz etiquette?")
}

No can haz etiquette?

Wot?

The problem is that hasPrefix is not meant for general use with human text; it’s barely better than a byte-wise comparison. It only guarantees that it won’t be fooled by mere differences in Unicode encoding, which is a good start, but not remotely sufficient for general use.

Let’s step back a bit, and first consider the slightly simpler case of just comparing two whole strings. We can worry about the prefix-matching aspect later.

NSString (from Foundation) provides Swift Strings with a variety of more powerful comparison methods, such as caseInsensitiveCompare(_:) (which is really just an alias for compare(_:options:range:locale:) with the caseInsensitive option).

let a = "hello"
let b = "Hello"

if a.caseInsensitiveCompare(b) {
    print("Hello indeed.")
} else {
    print("Hmph… rude.")
}

Hello indeed.

So that works. For case sensitivity. But what about other situations?

let plain = "cafe"
let fancy = "café"

if plain.caseInsensitiveCompare(fancy) {
    print("Right, either way it's a shop that sells coffee.")
} else {
    print("So… no coffee, then?")
}

So… no coffee, then?

Well, shit.

It may vary in other languages, but in English “café” is just an alternative spelling of “cafe”, and you almost always want to consider them equal. In fact, in English it’s basically never really required that you observe accents on letters – some are technically required, such as blasé, but English speakers are very blase about such things. Unlike e.g. Spanish, with n vs ñ, accented letters are not considered distinct letters in English.

But, letter accents may creep into English text anyway (just like spoken accents). Some people prefer them, for any of numerous reasons, like:

In proper nouns out of respect for the so-named.
To honour words’ roots in other languages.
For technical correctness of pronunciation.
Just aesthetically.

So you do need to support them, which means accepting and preserving them, but (usually) otherwise ignoring them.

Ah, but wait, the documentation for caseInsensitiveCompare(_:) has a footnote which surely addresses exactly this problem, albeit obliquely:

Important

When working with text that’s presented to the user, use the localizedCaseInsensitiveCompare(_:) method instead.

No worries – we’ll just use that instead:

let plain = "cafe"
let fancy = "café"

if plain.localizedCaseInsensitiveCompare(fancy) {
    print("Finally!")
} else {
    print("Oh come on!")
}

Oh come on!

It turns out this mistake is made by most of the String / NSString methods of similar ilk. And the discrepancies are inscrutable – e.g. localizedStandardCompare(_:) doesn’t handle accents correctly but localizedStandardRange(of:) does.

Long story short, you need to base most (if not all) your string comparison on compare(_:options:range:locale:) or its sibling range(of:options:range:locale:), because the other string methods don’t work properly.

So, with compare(…) you can do e.g.:

let plain = "cafe"
let fancy = "Café"

if .orderedSame == plain.compare(fancy,
                                 options: [.caseInsensitive,
                                           .diacriticInsensitive],
                                 locale: .current) {
    print("Finally!")
} else {
    print("😤")
}

Finally.

But there’s two other options you should almost always use, which are easy to overlook:

widthInsensitive.

In all the Latin-alphabet languages of which I’m aware, there is no notion of “width” and therefore no issues with width [in]sensitivity. It seems it most-often comes up in Japanese, where for historical reasons there were multiple versions of the same character that merely different in their visual dimensions. e.g. “カ” and “ｶ”. They are semantically the exact same character, even moreso than “a” is to “A”.

Even if the locale uses a Latin alphabet, there may still be mixed character sets and languages in the text your app processes – e.g. someone writing mostly in English but including Japanese names.
numeric.

There are more numeric systems than just the modern Arabic numerals as used in English. e.g. “٤٢” is 42 in Eastern Arabic. What matters is usually their meaning (i.e. numeric value), not their representation, just like the other factors we’ve already covered.

So, incorporating all that, the magic incantation required to correctly compare two human pieces of English text, in Swift, is:

let plain = "cafe カ 42"
let fancy = "Café ｶ ٤٢"

if .orderedSame == plain.compare(fancy,
                                 options: [.caseInsensitive,
                                           .diacriticInsensitive,
                                           .numeric,
                                           .widthInsensitive],
                                 locale: .current) {
    print("Actually equivalent.")
} else {
    print("Not equivalent")
}

Actually equivalent.

Note that the explicit locale argument may be important for some use-cases, for two reasons:

Generally it seems to turn on some – but not all – locale-appropriate options, in addition to any you specify explicitly.

While that may be redundant when you’re explicitly turning them on anyway, it’s possible it will have additional effects that aren’t expressible with the options parameter. You’ll probably want those too, as if they exist they’ll be things like special handling of unusual cases and exceptions to the rules.
Sometimes it turns hidden options off, such as whether to consider superscripts & subscripts equivalent. This might be a reason to not use it sometimes, if you don’t like the end result.

It’s less clear, even just considering English, what the correct default behaviour is regarding superscripts and subscripts, or “baseline sensitivity”. It’s quite conceivable that a user might intend to match a superscript or subscript even though they entered a plain digit, because most people don’t know how to actually type superscripts and subscripts (it’s not easy on most computers, at least not without 3rd party utilities like Rocket, and practically impossible on mobile devices).

And plenty of programs – particularly those not written in Swift, that might not handle Unicode correctly even at the most basic levels – erroneously devolve superscripts and subscripts to plain digits, which ideally wouldn’t prevent subsequent tools from still working with them (e.g. still finding “but1” when looking for “but¹”).

Yet in some contexts the differences very much do matter – e.g. in mathematical notation, x² is very different to x₂.

For reference, here’s a breakdown of the behaviour of some key String / NSString methods (as tested in the en_AU locale), to help you decide what specific incantation you need in a given situation:

Method	Case insensitive (“Hello” vs “hello”)	Diacritic insensitive (“cafe” vs “café”)	Width insensitive (“カ” vs “ｶ”)	Numerals insensitive (“42” vs “٤٢”)	Baseline insensitive (“but1” vs “but¹”)
`==`	❌	❌	❌	❌	❌
`hasPrefix`	❌	❌	❌	❌	❌
`commonPrefix(…, options: .caseInsensitive)`	✅	❌	❌	❌	❌
`commonPrefix(…, options: .diacriticInsensitive)`	❌	✅	❌	❌	❌
`commonPrefix(…, options: .widthInsensitive)`	❌	❌	✅	❌	❌
`commonPrefix(…, options: .numeric)`	❌	❌	❌	❌¹	✅
`localizedCompare`	❌	❌	✅	✅	❌
`localizedCaseInsensitiveCompare`	✅	❌	✅	✅	❌
`localizedStandardCompare`	❌	❌	❌	❌	❌
`localizedStandardRange(of:)`	✅	✅	❌	❌	❌
`compare(…, options: .caseInsensitive)`	✅	❌	❌	❌	❌
`compare(…, options: .caseInsensitive, locale: .current)`	✅	❌	✅	✅	✅
`compare(…, options: .diacriticInsensitive)`	❌	✅	❌	❌	❌
`compare(…, options: .diacriticInsensitive, locale: .current)`	❌	✅	✅	✅	✅
`compare(…, options: .widthInsensitive)`	❌	❌	✅	❌	❌
`compare(…, options: .widthInsensitive, locale: .current)`	❌	❌	✅	✅	✅
`compare(…, options: .numeric)`	❌	❌	❌	✅	✅
`compare(…, options: .numeric, locale: .current)`	❌	❌	✅	✅	❌²
`compare(…, options: [.caseInsensitive, .diacriticInsensitive, .numeric, .widthInsensitive])`	✅	✅	✅	✅	✅
`compare(…, options: [.caseInsensitive, .diacriticInsensitive, .numeric, .widthInsensitive], locale: .current)`	✅	✅	✅	✅	❌

Now, the real challenge is making code that works across all locales. In a nutshell, that’s practically impossible with Swift’s standard libraries today – they just don’t support it. To do it right, you’d have to determine what the appropriate comparison options are for every possible locale, manually, and bundle that database with your app.

But, given it’s usually better anyway to err on the side of matching rather than not matching, you can get pretty far by just assuming insensitivity to the above five factors.

Even in cases where this does cause mistakes – e.g. conflating “Maßen” (in moderation) with “Massen” (en masse) in German – it’s potentially unavoidable without deeper, context-specific knowledge anyway (since “ß” is normally equivalent to “ss” in German, just not regarding those specific two words – you can read more about this unpleasant situation on e.g. Wikipedia).

So, back to prefixes…

Fortunately, compare(_:options:range:locale:) and range(of:options:range:locale:) have a couple of additional options which make them easier to apply to situations other than just comparing whole strings.

Checking for a specific prefix

There is an anchored option which is perfect for this – it restricts the match to the start of the receiving string. e.g.:

let reaction = "😁👍"

if nil != reaction.range(of: "😁",
                         options: [.anchored,
                                   .caseInsensitive,
                                   .diacriticInsensitive,
                                   .numeric,
                                   .widthInsensitive],
                         locale: .current)) {
    print("Happy!")
} else {
    print("Sad¡")
}

Happy!

Note that you must use the range(of:…) variant, not compare(…), because the latter essentially requires that the two strings fully match, not merely that one is a prefix of the other (more on that later, in case you’re not convinced).

Finding common prefixes

Fortunately, there’s a convenience method for exactly this, commonPrefix(with:options:):

let happy = "😁👍"
let party = "😁🎉"

print("Similarities:", happy.commonPrefix(with: party,
                                          options: [.caseInsensitive,
                                                    .diacriticInsensitive,
                                                    .numeric,
                                                    .widthInsensitive]))

Similarities: 😁

Do not use this if you merely want to see if they share a specific prefix, because:

It’s more efficient to just check that directly on each string separately (rather than allocating and returning an intermediary string).
You still have to use compare(…) with the full set of options to check the result.

Note also that it does not have a locale parameter, so you cannot opt in to any system-default options defined for the current locale; you must explicitly specify every option you need.

⚠️ Beware: it doesn’t honour the numeric option.

Working with suffixes

You can of course reverse both strings and then compare what are now their prefixes, but this is expensive and awkward, since the result of String‘s reversed() method is a ReversedCollection, not a String or even a Substring, and it does not have the necessary comparison methods, so you have to convert it to a real String first.

Far easier and more efficient is to make use the backwards option to range(of:…). e.g.:

let word = "doing"

if nil != word.range(of: "ing",
                     options: [.anchored,
                               .backwards,
                               .caseInsensitive,
                               .diacriticInsensitive,
                               .numeric,
                               .widthInsensitive],
                     locale: .current)) {
    print("It's an 'ing' word.")
} else {
    print("Nyet.")
}

It's an 'ing' word.

Note how – conveniently – it does not require reversal of the argument string (“ing” in the above example).

Beware the `range` parameter

The compare(…) and range(of:…) methods also have a range parameter. This seems like a great idea – you can specify which specific subset of a string you care about, without having to actually break it out into a whole new String instance.

However, the range parameter is both a little unintuitive in its behaviour and fundamentally hard to use correctly.

On the first aspect, it’s critical to realise that it specifies the range within only the receiver (“happy” in the example below). It has no effect on the argument string (“party” in the example below). So you might innocently write the following:

let happy = "😁👍"
let party = "😁🎉"

if .orderedSame == happy.compare(party,
                                 options: [.caseInsensitive,
                                           .diacriticInsensitive,
                                           .numeric,
                                           .widthInsensitive],
                                 range: happy.startIndex ..< happy.index(after: happy.startIndex),
                                 locale: .current)) {
    print("Grins all round.")
} else {
    print("…not happy?")
}

…not happy?

If you want to compare subsets of both strings, you need to explicitly slice the second string, e.g.:

let happy = "😁👍"
let party = "😁🎉"

if .orderedSame == happy.compare(party.prefix(1),
                                 options: [.caseInsensitive,
                                           .diacriticInsensitive,
                                           .numeric,
                                           .widthInsensitive],
                                 range: happy.startIndex ..< happy.index(after: happy.startIndex),
                                 locale: .current)) {
    print("Grins all round.")
} else {
    print("…not happy?")
}

Grins all round.

Or, more simply:

let happy = "😁👍"
let party = "😁🎉"

if .orderedSame == happy.prefix(1).compare(party.prefix(1),
                                           options: [.caseInsensitive,
                                                     .diacriticInsensitive,
                                                     .numeric,
                                                     .widthInsensitive],
                                           locale: .current)) {
    print("Grins all round.")
} else {
    print("…not happy?")
}

Grins all round.

But, you should rarely if ever actually do the above, because of the second aspect: slicing strings is actually really hard. Not technically, obviously, but if you want to do it correctly. The crux of the challenge is that two strings can have different lengths but still be equivalent (e.g. “ß” and “ss” in German), so slicing them independently is error-prone, unless you somehow account for the specific differences in their encoding. If you naively assume things like a specific length for a target string (e.g. the single character of “ß”) and apply that length to the input string, you might get incorrect results. e.g.:

let input = "Füssen"
let target = "Füß"

if .orderedSame == input.prefix(target.count).compare(target,
                                                      options: [.caseInsensitive,
                                                                .diacriticInsensitive,
                                                                .numeric,
                                                                .widthInsensitive],
                                                      locale: .current)) {
    print("Something about feet.")
} else {
    print("Nothing afoot.")
}

Nothing afoot.

(in case you don’t speak German, that’s the wrong result logically – Füß is a prefix of Füssen)

Yes, really. I have no idea why commonPrefix(with:options:) doesn’t work correctly with the numeric option, given it presumably uses compare(_:options:range:locale:) or range(of:options:range:locale:) under the hood. Possibly some bad interaction with locale-specific settings, given it doesn’t let you specify the locale and it doesn’t document what it hard-codes it to. ↩︎
Yes, really. I don’t know why using the current locale (en_AU in this case) turns off baseline insensitivity when the numeric option is used, whereas it turns it on otherwise. Seems like a bug in Apple’s framework. ↩︎

A hint that the Mac Messages app is not native

Wed, 20 Mar 2024 00:33:43 +0000

I must admit, the Messages team have done a somewhat good job of making Messages pretend to be a native Mac app, at least in my experience – most of the time it works as it should. But then it’s a very simple app which I use in a pretty limited fashion.

Even so, there are things which just scream “I’m actually an iOS app”, like when you right-click a message or attachment while the Messages window is on a secondary display, and the contextual menu appears in the top-left corner of the main display. And disappears when you click on any item in it, without activating the item. Because it’s reacting to the mouse location as if it were in the correct place on the secondary display. But if you click on the secondary display, it just dismisses the pop-up menu without activating the selected item – I don’t know how they managed to get that discontinuity between mouse move events and mouse down events, but there you go, the miracle that is Catalyst.

Sigh.

Also, keyboard navigation doesn’t work correctly in the contextual menu – it’s fine for the plain text items, but it’s impossible to select any of the reactions.

Fortunately, for reactions specifically, there’s a workaround! ⌘T brings up a special contextual menu just for reactions, and you can then just hit a number key, from 1 through 6, to apply the corresponding reaction. It only works on the most recently received message in the selected conversation, but then that’s usually the one you want.

Of course, the GUI for that special contextual menu is ripped directly out of iOS, further emphasising Message’s unnatural nature.

Genuinely chosen as the example merely because it was the first impersonal message I came across in my recent conversations – but, a sign, perhaps? 😄

SwiftUI drag & drop does not support file promises

Sun, 04 Feb 2024 19:04:31 +0000

SwiftUI doesn’t offer anything equivalent to NSFilePromiseProvider, i.e. to write data to the drop destination. You have to ditch SwiftUI and use AppKit’s drag & drop APIs instead.

FB13583826.

Is that it?

I know that’s not a very helpful in some sense, but I wasted days trying to figure out how to implement this very basic drag and drop functionality, in SwiftUI. From what I found online, I’m not the only person who’s struggled with this. So hopefully this post saves others from long and frustrating searches.

A big part of the difficulty in answering this simple question – does SwiftUI support this or not – is that a lot of documentation (first & third party) around SwiftUI’s APIs uses the word “promise” but not in the same way. They merely mean that the pasteboard data is populated on first access, not that it actually follows the file promise protocol.

Best alternative (other than ditching SwiftUI)

The closest you can get is to write data into some arbitrary location that you have to choose blindly (not having any idea where the actual destination is), and then rely on the receiving app to move or copy the file from there. It doesn’t matter, in this regard, whether you use the Transferable-based APIs or the NSItemProvider-based APIs.

view.onDrag {
    let provider = NSItemProvider()
    
    provider.registerDataRepresentation(for: UTType.fileURL) {
        do {
            let tmpDir = try FileManager.default.url(for: .itemReplacementDirectory,
                                                     in: .userDomainMask,
                                                     appropriateFor: URL.temporaryDirectory,
                                                     create: true)

            // You'll need to provide the `suggestedFileName` based on the particulars of your use-case.
            let file = tmpDir.appending(component: suggestedFileName)

            try bytes.write(to: file, options: .withoutOverwriting)

            $0(file.dataRepresentation, nil)
        } catch {
            $0(nil, error)
        }

        return nil
    }
    
    return provider
}

This makes it impossible to avoid unnecessary file copies, and requires you to keep the file around permanently, since you have no idea when the receiver is done with it.

e.g. if the Finder is the drop destination, you have no idea what volume the promised file was dropped on, so you don’t know which volume to create it on. If you guess wrong, the Finder is forced to copy the file. Not only does this confuse the user (by showing a copy badge on the mouse pointer) but it wastes time (in performing the copy) and the original file is left in place, requiring manual clean-up (which is impossible to do correctly because you have no idea when the receiving application is done with the temporary file – and the receiver might hold a reference to it permanently).

Understanding the SwiftUI drag & drop APIs

Tangentially, I found most documentation on SwiftUI’s drag & drop APIs – especially Apple’s – to be very poorly written, which is particularly frustrating in this case because the APIs are not intuitive in the slightest.

And most code / usage examples focus exclusively on trivial, disinteresting cases (e.g. dragging images around within a single window).

Only after I’d spend days reverse-engineering the APIs to figure out how they actually work and how they’re supposed to be used, did I stumble upon Dave Rahardja‘s All about Item Providers. It’s by far the best documentation I’ve found on drag & drop in SwiftUI. Note though that Dave also uses the word “promise” a lot even though he’s never actually talking about actual file promises.

Also, I found that the newer and ostensibly better Transferable-based API was harder to understand and harder to use than the NSItemProvider-based APIs. I recommend going straight to, and sticking with, the latter. Your code will be simpler and more reliable.

Mac app sandboxing interferes with drag & drop

Sat, 06 Jan 2024 02:06:10 +0000

Failed to get a sandbox extension

Right from there, you know you’re going to have a bad day. 😔

Then you try to actually use the file dropped on your app, and you get:

Upload preparation for claim 1C0F9013-4DEB-4E5D-8896-F522AA979BA6 completed with error: Error Domain=NSCocoaErrorDomain Code=513 "“Example.jpg” couldn’t be copied because you don’t have permission to access “CoordinatedZipFilejxc2lC”." UserInfo={NSSourceFilePathErrorKey=/Users/SadPanda/Pictures/Example.jpg, NSUserStringVariant=(
    Copy
), NSDestinationFilePath=/Users/SadPanda/Library/Containers/com.me.MyApp/Data/tmp/CoordinatedZipFilejxc2lC/Example.jpg, NSFilePath=/Users/SadPanda/Pictures/Example.jpg, NSUnderlyingError=0x600000ad0cf0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

There’s a variety of ways to run afoul of this. Here’s a particular one, for illustration.

Noticing when drag & drop operations start

Say you want to have a drop zone in your app that draws attention to itself whenever the user starts dragging a relevant file. Merely intelligent, courteous UI.

There’s no built-in facility for this – both AppKit and SwiftUI drag & drop APIs only start functioning once the dragged item enters the drop zone itself (the view, or at best window, that you’ve made a drop receiver).

There is a convention on how to work around this – you can deduce that a drag is occurring by watching mouse events and the drag pasteboard.

Drag & drop implementation detail

macOS uses pasteboards to share data between applications (represented in AppKit by NSPasteboard), not just for copy & paste as you’re probably already familiar, but for drag & drop as well, among several other things. You can also create your own custom pasteboards, namespaced to be completely independent of the ‘built-in’ ones, for your own purposes.

Pasteboard implementation detail

The standard system pasteboards are always accessible to your application, even when they’re nominally not relevant (such as when no drag is actually occurring). In fact the contents of the last drag are left indefinitely on the pasteboard (by default, unless an app explicitly clears it). Which is an annoyance as it complicates the following…

Deducing what’s going on by spying on global mouse events

When you see a drag event you don’t immediately know anything more than that the mouse moved with the left mouse button held down. That can mean anything – the user might be pulling out a selection rectangle, or drawing in a graphics application, or just randomly dragging the mouse around.

Since the contents of the drag pasteboard are left there indefinitely after a drag concludes, you can’t just use the existence of something on the drag pasteboard as an indication that a drag is in progress.

However, pasteboards have a “change count”. What this is actually counting is ill-defined and seemingly not about the actual contents of the pasteboard, but in a nutshell it can be used to mean essentially that – the count might change even if the contents don’t change, but it seems it will always change if the contents do change. So, some false positives, but no false negatives, which is the important thing.

So, when you see a mouse drag event, you can look at the drag pasteboard’s change count and see if it changed since the last mouse drag event. If it did, that’s a pretty strong suggestion – although admittedly not a guarantee – that the user is performing a drag & drop operation.

There is a race condition here. Mouse events are handled by the WindowServer which runs at very high priority and completely asynchronous to app activity like loading up the pasteboard with dragged items – and it does actually take some time for an app like the Finder to populate the pasteboard when the drag is initiated. Only tens of milliseconds, typically, but that’s an eon in computer terms.

So you might observe the key events – the pasteboard changing and the first mouse down of a drag – in any order.

Fortunately, it’s rare to lose the race in a way that matters, because you’ll get a mouse dragged event virtually every time the mouse moves, even if just by a single pixel. So even if you get the first mouse dragged event before the source app has actually populated the pasteboard – which is in fact common, in my experience – you’ll invariably get a bunch more practically immediately as the user continues the drag. Sooner or later the pasteboard will be updated, so you’ll eventually notice. Technically you’re late in recognising that a drag & drop operation has started, but in general the delay is imperceptible.

The essential code is:

let dragPasteboard = NSPasteboard(name: .drag)
var lastDragPasteboardChangeCount: Int = dragPasteboard.changeCount

let mouseDragWatcher = NSEvent.addGlobalMonitorForEvents(matching: [.leftMouseDragged],
                                                         handler: { event in
    let currentChangeCount = dragPasteboard.changeCount

    if lastDragPasteboardChangeCount != currentChangeCount {
        // The user very likely just started dragging something.
    }

    lastDragPasteboardChangeCount = currentChangeCount
}

let mouseUpWatcher = NSEvent.addGlobalMonitorForEvents(matching: [.leftMouseUp],
                                                       handler: { event in
    // The drag ended.
}

Note that I’ve omitted various ancillary details, such as avoiding strong retains of self (where applicable), error handling (addGlobalMonitorForEvents can return nil), removing the monitors when you’re done with them, etc.

Also, NSEvent‘s monitoring implicitly relies on RunLoop, so actually using the above – and actually getting your handler called – is predicated on having a suitable runloop going (in my experience it has to be the main runloop, but maybe it’s possible to use a different runloop in the right mode – presumably eventTracking). In a typical GUI application that’s all set up for you automagically, but in other cases you have to do it yourself – refer to this for more details and suggestions.

And the above code works fine as presented. The problem arises if & when you start actually looking at the pasteboard during the drag…

You get only one look at the dragged files

Files, when dragged, are represented mainly as their paths (technically, NSURLs). That’s the “public.file-url” UTI (and the Apple URL pasteboard type for backwards compatibility). Though you’ll also see a bunch of other types reported if you ask the pasteboard what it’s carrying, e.g.:

Apple URL pasteboard type
CorePasteboardFlavorType 0x6675726C
NSFilenamesPboardType
com.apple.finder.node
dyn.ah62d4rv4gu8y6y4grf0gn5xbrzw1gydcr7u1e3cytf2gn
dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu
public.file-url

Merely inspecting the UTIs in the pasteboard is fine – that doesn’t interfere with anything. So if all you care about is if any kind of file (or folder) is being dragged, you’re set. But if you want to only react to some types of files or folders, you need to know more.

If you ask for the URL – even without actually using it – you trigger some behind the scenes activity involving app sandboxing. This prevents the file being made accessible to your app if & when it actually is dropped into your app.

When things are working correctly, when a file is dragged and dropped onto a receptive view in your app a link to that file is created inside your own app’s container. It’s that link that you actually have access to – the original file cannot be accessed directly. That link seems to persist for a while – perhaps until your app is quit – so once you have it you’re set.

I don’t know why merely peeking at the file path (URL) prevents this link being created, but it does.

Sigh.

FB13520048.

Failed workarounds

Sadly the only meaningful existing documentation of this problem that Bing or Google can find is this one StackOverflow question. Which is unresolved – the claimed hacks & workarounds don’t actually work, at least not anymore.

Supposedly on some older versions of macOS you could create a bookmark of the file (presumably a security-scoped one) and that would implicitly secure your access to it. But that seems pretty clearly to no longer work – assuming it ever did – because you can’t create a bookmark for files you can’t read, and until the drop occurs you don’t have read access to the file.

Similarly, you can supposedly use startAccessingSecurityScopedResource to indefinitely lock in your access to the file, but this doesn’t apply if you don’t have access to it to begin with. So, again, not useful here.

Partial workaround

While I knew that using canReadObject(forClasses: [NSImage.self]) ran afoul of this, I happened to notice there’s a logically equivalent method on NSImage itself – NSImage.canInit(with:) – which I tried, and lo and behold it works! No sandboxing issues.

I disassembled it (thanks Hopper!) and saw that it’s basically just doing some UTI pre-checks – already known to be safe – to see if there’s a file URL in the pasteboard, and then it fetches that file URL using readObjects(forClasses: [NSURL.self]), the same method that if you or I call results in this bug surfacing. The difference is it uses a secret reading option key – “NSPasteboardURLReadingSecurityScopedFileURLsKey”! Apparently that’s the magic sauce which allows you to read the URL without triggering the bug. You still can’t actually access the file, but at least you can e.g. examine its file extension (which is essentially what NSImage.canInit(with:) does).

if let URLs = dragPasteboard.readObjects(forClasses: [NSURL.self],
                                         options: [NSPasteboard.ReadingOptionKey(rawValue: "NSPasteboardURLReadingSecurityScopedFileURLsKey") : kCFBooleanTrue]) {
    for u in URLs {
        // Go nuts!
    }
}

Incidentally, I noticed it also calls startAccessingSecurityScopedResource but in my testing it always gets a failure response from it too. So that apparently is irrelevant.

Addendum: Michael Tsai’s Blog

I was reading through articles in NetNewsWire, including a few of the latest from Michael Tsai, and for one in particular I thought, “this sounds really familiar for some reason”. Hah, because he was quoting part of this post.

I’m very flattered to be linked to by Michael – I have no idea how he found my obscure website to begin with – as his blog is one of my favourite Apple developer news / discussion feeds. He does such a great job of collecting valuable links and collating them together on timely and/or valuable topics. His own commentary – if he adds any – is concise and valuable. If you’re not following his blog, you should rectify that. 🙂

I also now wish I’d written this post better. 😝

Secret Sonoma design lead: Barbie

Tue, 12 Dec 2023 21:13:50 +0000

macOS Sonoma is in so many ways a dumpster fire. It’s the worst Apple OS update I can remember (although admittedly there’s been some real stinkers over the years, so maybe I’m overlooking some repressed memories).

There was of course the bug whereby encrypted external drives no longer mounted automatically. That was pretty special, because it reveals that Apple doesn’t test encrypted external drives anywhere in their QA process – possibly not even ad-hoc internally, since it’s hard to image that an Apple employee stumbling on this bug by accident would not bother to report it. Or maybe they did but even Apple’s own employees’ bug reports are ignored. Consistent, at least.

Since virtually every external drive should be encrypted, this suggests Apple either believes nobody actually uses external drives, or that they don’t care. At least that bug was mostly fixed in 14.1, although it took Apple a full month to get around to it.

Radical pink redesign

But perhaps the most glaring bug, in a very literal sense, was the rampant pinkification of the GUI.

Safari website thumbnails

Random GUI controls in web pages

…not to mention many actual images on web pages.

Even Apple’s own apps – and most poetically of all Quartz Debug – are afflicted.

As you can see, Sonoma brought with it a penchant for tinting things a gross light pink colour, including the rectangular extents of images that are otherwise invisible because they’re transparent.

WTF?!

I spent a lot of time debugging this. Over days, weeks, and months. Trying out new avenues as they came to me, even repeating some web & forum searches over and over again in frustrated desperation.

I only just today figured out what’s going on. 84 days later.

One of my first instincts – right on day 0 – was that it was some Quartz Debug thing, because it looks a lot like some of the tinting options Quartz Debug has for things like flashing screen updates or showing opaque regions. But the Quartz Debug app insisted everything was disabled. I enabled everything anyway, and then disabled it all again, in case that would jog something free. No bueno.

I then spent the better part of three months trying every superstition, every rumour or snippet of hearsay online, that might in any way related to this problem or conceivably fix it. Nothing helped.

Epiphany

It was last night, when I was fiddling with some images in a gallery here on my website, that I discovered that adjusting the CSS dimensions of an image by just a single pixel could pinkify them. Most importantly, restoring the dimensions to the actual image dimensions would fix them. I’d already observed something similar to that, in various apps and websites, but it felt different to be directly triggering the problem myself.

That kept me up half the night, tossing and turning in bed, highly suspicious that this was a pivotal clue, but unsure what it pointed to.

Eventually, it led me right back to my very first instinct – Quartz Debug – and the tentative conclusion that this was in fact a Quartz Debug problem even if Quartz Debug claimed otherwise. I become suspicious that the app was either not showing me the full range of settings, or just plain wrong about them.

And that was the insight I needed – right on the very first page of search results for “quartz debug defaults” was a link to Testing and Troubleshooting High-Resolution Content. Buried behind a disclosure triangle near the bottom is the magic string:

CGContextHighlight2xScaledImages

That was set to YES, on my system.

Deleting it fixes the issue once affected apps are restarted (something Apple’s own documentation fails to mention – kind of an important step, Apple!).

defaults delete -g CGContextHighlight2xScaledImages
The magic incantation to exorcise Barbie

In theory you can also disable this from the Quartz Debug app itself, it’s just hidden – in the Tools menu, not the actual settings window, is an item labelled “Color 1x Artwork”. Note how the setting applies even when Quartz Debugging is disabled.

So, wait, how did this come about?

I have no idea why this only cropped up when Sonoma was installed. Either Sonoma turned this on (unlikely…?) or it was already on yet wasn’t having any effect in prior OS releases (from 2017 onwards, at least, since my iMac Pro never exhibited this issue before Sonoma).

I know for sure that this setting did work at least going back over a decade, as I remember using this – on a different computer – for doing then-new-fangled Retina development… but I’m pretty sure I’ve never set this on my iMac Pro since it way post-dates the introduction of Retina. Conceivably it was pulled across by Apple’s Migration Assistant. Though, again, why did no earlier version of the OS, going back over a decade, exhibit this behaviour if it was supposedly enabled the whole time?

I know it’s not just me that’s been afflicted by this to date, as I found a sporadic few reports of this going back years, e.g. Highly abnormal graphic glitch on yosemite / retina: all white backgrounds appear pink. It pisses me off immensely that this page has exactly the keywords I was searching for right from the start – right in its title! – yet neither Bing nor Google can find it.

Apple’s response? “Fuck you” in mime.

I actually filed a pretty detailed bug report with Apple about this, the day I discovered it (September 19th, 2023). FB13190068.

Of course, they never responded in the slightest.

I provided a bunch of example images, even a screen recording to show how the pink comes and goes in certain circumstances.

I studiously tested every new macOS update and updated the bug report to note that they each had not fixed it.

The morale of this is, as always, that filing bug reports with Apple is an infuriating waste of time. Mea culpa.

SwiftData pitfalls

Wed, 15 Nov 2023 21:04:36 +0000

I’ve been exploring SwiftData lately, and I’ve been unpleasantly surprised by how many sharp edges it has. I’m going to try to describe some of them here, so that hopefully others can avoid them (or perhaps be dissuaded from using SwiftData to begin with).

I’m using Xcode 15.0.1 (Swift 5.9) on macOS 14.1 (Sonoma).

Background

I’ve dabbled in Core Data over the years – mostly pre-Swift – and have a kind of begrudging, distant respect. I understand what it’s trying to do and I can appreciate some of the ways in which it makes that easier, but I’m also all too familiar with its limitations and caveats. So mostly I’ve ignored it, preferring to use other approaches – whether that be JSON or plists for simple cases, or just directly using a SQL database when that feature-set genuinely is warranted.

When SwiftData was introduced, I was intrigued. On the surface it seemed like it greatly reduced the boilerplate and some of the complexity of using Core Data. It at least seemed like an appealing option for light use, with relatively simple models and especially with SwiftUI. It seems pretty obviously targeted at the typical, pretty trivial patterns that most iOS apps have – i.e. not much more than lists of objects.

But it’s only recently that I actually tried using SwiftData for more than just some trivial toy cases. I had a textbook case of a hierarchical type tree, with fairly simple 1-to-1 or many-to-1 relationships, the need for cascade deletes in some cases but not others, and a dataset a little larger than what I could get away with just stuffing into User Defaults.

Alas, what I’ve found is that SwiftData has so many glaring bugs and limitations, that even for this textbook example case, it just doesn’t make any sense to use it.

Example use case

My model is fairly simple – a root object called House which can contain multiple Floors each of which has multiple Rooms. Each of those has a few other attributes – simple strings and numbers – and the Rooms can reference a few other model types, like Weapons and Monsters, as 1-to-1 relationships.

The order of floors and rooms matters – they correspond to top to bottom (attic to basement) and left to right as will be rendered in the GUI.

Design flaws

Auto-save doesn’t work

By default, model containers are supposed to auto-save. That’s what the documentation says, both in the API reference and the tutorials:

In both instances, the returned context periodically checks whether it contains unsaved changes, and if so, implicitly saves those changes on your behalf. For contexts you create manually, set the autosaveEnabled property to true to get the same behavior [sic].
Apple’s Save models for later use (subsection of Preserving your app’s model data across launches)

I suppose it hinges on the word “periodically”. In my testing, that period must be tens of seconds, or worse. It’s trivial to see that it doesn’t work – just make some changes and close the window, or quit your app. Virtually all the time – even if you wait several seconds – those changes are silently lost!

It’s clear that SwiftData has no hooks into deinitialisation, view / window closure, app exit, etc. You would think it has to, in order to save things reliably even in the happy-path cases (as opposed to e.g. app crashes). But it simply does not, and thus it does not.

Workarounds

If you want full resilience to unexpected app termination (e.g. crashes) then any time you make a change to any SwiftData-managed object, you have to immediately call context.save() manually. Which is especially annoying since that method throws, so you have to figure out some sane way to handle that failure possibility in every situation in which you make any changes to your models.

For non-trivial applications, this leads to your code being riddled with save-management code. Think about every SwiftUI field which reflects an element of your model and enables mutation of it. Every button that adds or removes or reorders anything. Every editable list view. Etc.

It’s easy to miss a spot where you make a modification, leading to silent data loss.

If you’re willing to lose data when your app crashes (which you really shouldn’t be willing to do so easily do), you can limit your saves to certain key paths – e.g. window closure, app exit, etc. But you have to find and hook into all those things manually.

This is nominally no different to some SwiftData alternatives (e.g. NSCoding), although below par compared to User Defaults and most other SQL database frameworks.

Arrays of `@Model` objects are randomly shuffled

Array in Swift is very explicitly an ordered collection, in the sense that the elements within have a specific albeit arbitrary order, based on how they’re inserted. This is the same as arrays / vectors / lists in practically every programming language.

SwiftData violates this by randomly reordering elements at various times, such as when [re]loading model objects from persist storage.

The reason is pretty simple – it fails to record the order of elements in its underlying SQLite database, instead using a randomly-assigned, arbitrary integer as a uniquing key, and nothing else.

This is a pretty startling design flaw. I’m not sure how SwiftData got out the door with this.

Workarounds

I haven’t found any good workarounds. The advice you’ll generally see online (e.g. on StackOverflow) is to manually load the objects in the array, specifying a sort order as part of the query. But this basically has you manually reimplementing the relational aspects of SwiftData:

You have to add a member variable to the target class in question just to store its index in the array. You need one of these variables for every many-to relationship it can be a part of.
You have to then somehow populate those variables and keep them in sync with any changes to the arrays.
You can’t actually use the array member variables – since the objects are in random order – and instead have to manually query the database separately. Or, you can sort the array member variables at some point, but it’s difficult to do that efficiently (you can’t really be sure when SwiftData is going to mangle the sort order, so you basically have to do the sorting on the fly every single time you access the array).

Rather than going through all that hassle, it’s easier to just not use SwiftData – e.g. you can simply use a normal object graph that’s persisted to disk as JSON, or in property list form, or using NSCoding, etc.

`let` cannot be used for bidirectional relationships

All member variables (of @Model classes) that refer bidirectionally to other model classes must be variables (var), not constants (let). Irrespective of their actual intended semantics.

This is seemingly just an inherent part of SwiftData (and Core Data underneath) – the presumption that all relationships are optional and can change arbitrarily. It worked okay in Objective-C because that was closer to the reality of Objective-C objects, but it flies in the face of Swift’s much stronger controls and expectations on mutability and optionality.

It would be a relatively minor annoyance – losing compile-time protection of immutability is frustrating but not technically a show-stopper – except that there are no warnings or indications otherwise, of any kind, that you’re “holding it wrong”. If you declare the member with let, everything will compile without so much as a warning, but you’ll run into obtuse runtime errors and crashes, e.g.:

💣 Could not cast value of type 'Swift.KeyPath>' (0x12e00cc98) to 'Swift.ReferenceWritableKeyPath>' (0x13e0b4198).

What that error message is trying but failing to convey is that you cannot (outside of initialisation) write to a let, of course, so its attempt to modify the property failed. So it crashed your app.

Workarounds

None, really. You just have to remember, every time, to avoid let. Possibly you could obtain & configure some linter to check this for you.

Relationships are secretly implicitly unwrapped by default

@Model
final class Room {
    let monster: Monster

    …
}

That’s fine, right – every room has a Monster. Simple.

Except it’s not, if Monster is a @Model. In that case, despite the fact you’ve declared it as non-optional, it actually is optional. @Model essentially makes it implicitly unwrapped without telling you (and without the important ! character after the type to warn you).

The technical reason it’s implicitly and unavoidably optional is because Room and Monster are stored in separate SQLite tables, with a nullable foreign key relationship between them. SwiftData does not support non-nullable foreign keys. So it’s totally valid, as far as the actual database layer and persistent storage are concerned, for the relevant Monster to disappear entirely. But that means your model instance is basically corrupt when you load it, which can have a variety of ill-defined effects such as crashing your app.

You might think this is largely hypothetical, or academic – SwiftData’s not going to erroneously delete your Monster out from under the Room (you assume), and you’re not going to do it yourself, so it’ll never happen, right? Well, maybe. Consider what happens as your app evolves, undergoes refactors, etc. It’s quite possible you unwittingly create a situation in which what was previously valid data is no longer valid to your app.

Or, you might run into a SwiftData design flaw or bug which causes the data to be corrupted on save, such as is detailed in the next section. Even if the root cause is that your data was corrupted at save time, it’s frustrating to have that manifest only through obtuse crashes at some ill-defined time in the future after your app is relaunched.

Workarounds

None, really.

At the very least, you can explicitly make all relationships optional. That way you can code defensively around them, by putting in appropriate unwrapping code and guards. If nothing else you can at the very least crash with a clear failure message (there is no log message at all when SwiftData crashes your app via implicit unwrapping).

You cannot directly initialise bidirectional relationship properties

@Model
final class House {
    @Relationship(deleteRule: .cascade,
                  inverse: \Floor.house)
    let floors: [Floor]

    init(floors: [Floor]) {
        self.floors = floors
    }
}

If you do something like the above – making use of Xcode to generate your initialiser for you, like you normally would for classes – you’ll get the wonderful behaviour that everything works fine until you quit your app and reload it. Then you’ll discover that floors is empty.

There are no error messages, neither at compile time nor runtime. No warnings. Nothing.

Looking at the underlying SQLite database, its apparent that something is seriously broken because while it does save the Floor instances, their foreign key back to House is NULL (even if logically that should be impossible – refer back to the prior point on how SwiftData forces all relationships to be optional).

What’s happening is that the initialisation of floors in init is in some sense bypassing SwiftData’s custom hooks; it’s “directly” setting the value in memory without SwiftData updating its corresponding Core Data model underneath (this is another place SwiftData’s abstraction is leaky – your @Model classes aren’t the real model classes, they’re merely a layer atop the actual Core Data models).

Workarounds

Thankfully this does have a simple workaround (iff you know it and can remember to always use it): never assign the relationship in init. You can append to it, and you can assign it outside of init. So e.g.:

@Model
final class House {
    @Relationship(deleteRule: .cascade,
                  inverse: \Floor.house)
    let floors: [Floor] = []

    init(floors: [Floor]) {
        self.floors.append(contentsOf: floors)
    }
}

Relationship constraints are only enforced at save time

@Relationship lets you specify the arity of a relationship – the minimum and maximum number of related objects that are permitted. However, this is not actually enforced at any time except save time (when you explicitly call context.save()).

Arguably this is better than nothing – vanilla Array member variables provide no way to constrain the array’s contents – but it can lead to mistakes if you unwittingly rely on more rigorous enforcement.

Workarounds

None, really, that I’ve been able to come up with.

It sort of helps to think of these ‘constraints’ as actually just ‘guidelines’; to not actually rely on them being enforced. That may mean you have to do manual validation, that’s in principle redundant, in order to ensure the rules are enforced.

That said, since you need to manually save aggressively anyway (since auto-save doesn’t work), you might be able to conjoin the two workarounds.

Singletons are unsupported

In some use-cases your root object is a singleton – you don’t ever actually want to have multiple instances of it, it’s merely the top-level of your object graph, the object which organises all other objects.

Unfortunately SwiftData doesn’t support this. Every @Model class can have multiple instances.

This can make things pretty awkward when dealing with your singleton, as you cannot do intuitive and simple things like:

struct Map: View {
    @Environment(\.modelContext) private var context
    @Query var house: House

    var body: some View {
        VStack {
            ForEach(house.floors) {
                …
            }
        }
    }
}

Workarounds

Basically you have three choices:

Remove all your singletons, redesigning your model and app to accomodate. This might make some contrived sense if you rationalise it as a way to have multiple game sessions concurrently, or to facilitate concurrent unit testing, or somesuch. But you’ll know in your heart that it’s not real.
Use force-unwrapping (or equivalent), making your app crash or otherwise fail if your singleton expectations are violated by SwiftData.
Silently ignore all but an arbitrary instance of the model class in question.

These are all pretty flawed. And no matter which approach you choose, they introduce some significant boilerplate into your code. e.g.:

struct Map: View {
    @Environment(\.modelContext) private var context
    @Query var houses: [House]

    var body: some View {
        VStack {
            ForEach(house[0].floors) { // Silently ignore other houses.
                …
            }
        }
    }
}

In the above example, which house is chosen is arbitrary and may change between view updates. You can do extra work to pick a house deterministically – e.g. sort by some unique attribute and pick the first – and you probably should if you’re going to use this hack, but you’ll still be operating in a messed-up state.

You cannot create model objects outside of SwiftData contexts

This limitation is explicable and reasonable on the face of it, but does limit your app architecture in ways that can be annoying. e.g. you cannot initialise your views with test models like you normally would:

#Preview {
    MapView(house: House.default())
}

That will compile without any complaints, but when you try to actually view the preview in Xcode you’ll get the dreaded “Cannot preview in this file” error, with absolutely no indication why.

If you happen to try a similar thing in your app initialisation, e.g.:

@main
struct Game: App {
    var body: some Scene {
        WindowGroup {
            Overview(house: House.default())
                .modelContainer(for: [House.self])
        }
    }
}

…then you can at least run your app and will see an error message before it crashes, like:

💣 SwiftData/ModelContainer.swift:144: Fatal error: failed to find a currently active container for Room
Failed to find any currently loaded container for Room) [sic]

So far as Apple error messages go, this is practically perfect – it at least does mention almost the pertinent object (the [SwiftData] container is similar to the SwiftData context) and provide some explanation of the genuine problem.

Workarounds

I haven’t explored this in great detail, so there might be other options, but the best I could promptly come up with is to move initialisation inside your SwiftUI views. Whether that be through explicit user interaction (e.g. a “New Game” GUI in my use case, when there’s no existing House in the database), or in a suitable onAppear handler, etc.

That’s reasonable for actual app execution, but doesn’t immediately help you for SwiftUI previews. However, if you attach a suitable model container to your preview instance:

#Preview {
    MapView()
        .modelContainer(for: [House.self])
}

…then your preview will actually use the real app data. This can actually be handy sometimes, as you can manipulate the state – either in the preview or your actual app execution – which can be handy for debugging view problems (e.g. you’re running your app, playing around, and you notice a rendering error – you can quit your app and its saved state will be used in your Xcode previews, automatically showing you the view in its broken state).

Alternatively, you can go through a more laborious process of [more-]manually creating the SwiftData context, in order to allow you to use a distinct database and to create test objects, e.g.:

#Preview {
    let container = try! ModelContainer(for: House.self,
                                         configurations: ModelConfiguration(isStoredInMemoryOnly: true))

    MapView(house: House.forPreviewing())
        .modelContainer(container)
}

I believe using an in-memory-only store will prevent it touching your actual app’s saved state, but I haven’t poked at it much. I also believe you can use the more complicated configuration initialiser to explicitly specify a URL, if you want a persistent test dataset that’s nonetheless separate from your app’s real dataset, but I haven’t played with it myself.

There are various tutorials online that go into more detail, e.g. Paul Hudson‘s How to use SwiftData in SwiftUI previews.

Apple’s documentation is wrong

This one barely rates a mention since Apple’s documentation is pretty infamously unreliable (what little of it exists at all). Still, it’s important to point out a couple of particularly glaring errors that will hit most SwiftData newbies:

@Model
class Trip {
    var name: String
    var destination: String
    var startDate: Date
    var endDate: Date
    var accommodation: Accommodation?
}

Apple’s Preserving your app’s model data across launches

That is Apple’s very first code example in introducing SwiftData, and it’s wrong. It has no initialiser, therefore you cannot actually use this Trip class.

Now, you might say that’s pedantic, but it’s actually quite pertinent – Apple never show a complete example of a @Model class, so they never show you how you’re supposed to initialise one, and thus they never even try to prevent people falling into pits such as the aforementioned issues with arrays.

Another poignant example:

@Relationship(.cascade) var accommodation: Accommodation?
Apple’s Preserving your app’s model data across launches

That’s not valid; it doesn’t even compile. The syntax actually is:

@Relationship(deleteRule: .cascade) var accommodation: Accommodation?

Workarounds

There are quite a few tutorials available online which provide an alternative onboarding guide, to Apple’s official documentation. I did find a broad perusal of them useful in gleaning bits and pieces that Apple themselves don’t cover (or are wrong about). Unfortunately many are essentially just copy-pastes or paraphrases of Apple’s documentation, and even those that aren’t tend to make the same mistakes.

But, since you’ve now read this post, you’re better equipped than most to try diving into SwiftData.

Non-pitfalls

Just as a bit of a bonus section, I want to call out one aspect of SwiftData which actually works as you might expect.

You only need to register the root(s) of your model graph

When setting up your model container, you don’t have to manually enumerate every model object you use, merely some root(s). SwiftData automatically walks your class(es) member variables to find relationships to other @Model classes, and implicitly registers those too. So e.g.:

@main
struct Game: App {
    var body: some Scene {
        WindowGroup {
            Map()
                .modelContainer(for: [House.self])
        }
    }
}

You don’t need to list Floor.self, Room.self, etc. You can – it doesn’t hurt anything, and might make your app a little more robust against future refactors – but it’s nice that you don’t have to.

Bonus: TablePlus recommendation

It’s unfortunately critical, when working with SwiftData (or Core Data), to be able to view & edit the underlying SQLite database. You can do that out-of-the-box on your Mac using just the built-in sqlite3 CLI, but that’s pretty awkward.

There are many GUI apps for working with SQLite databases. Quite a few are free. Most are functional but clumsy.

Years ago – when I was mostly working with MySQL – I came across TablePlus. It’s a bit pricey at $90 up front – plus $50 per subsequent year if you want to keep getting software updates – but it’s by far the best database client I’ve found, on any platform. It’s easily the most native-feeling on a Mac, even though it’s cross-platform (macOS, iOS / iPadOS, Linux, and Windows!), and one of the fastest. It doesn’t quite have all the features – I do sometimes fire up MySQL Workbench to access its query performance visualisation – but it covers 99% of what I need.

My only notable complaint with it is that it has historically been a tad buggy. Not dramatically, but consistently. That said, I only just got back into it as a result of this SwiftData work – and it’s worked flawlessly so far – so it may well have upped its game since I last properly used it a couple of years ago. 🤞

iPhone emergency satellite communication is geolocked

Fri, 06 Jan 2023 22:14:48 +0000

Hardly news at this point, I guess, but just in case you’ve missed it: you cannot use the iPhone 14 Pro’s satellite communication functionality outside a very limited number of geographical regions (mainly the U.S. mainland).

e.g. I thought I’d give it a whirl as I was flying out of Houston, out over the Gulf of Mexico. Alas all I got was a blunt denial:

So don’t actually travel to remote places and expect this feature to work. 😔

Swift on Raspberry Pi (in 2019)

Tue, 15 Oct 2019 20:31:24 +0000

After the horrible experience just acquiring, installing, & configuring a basic Raspberry Pi, I was anticipating much effort – likely ending in failure – to get Swift working.

I was pleasantly surprised.

There are multiple ways to do it, apparently. One would think that there’d be the correct & working packages already available through apt, but just as with Docker, one would be wrong. In the case of Swift, there is the Swift-ARM site & group that does provide a package repo with pre-built binaries (and various tutorials on using them), but oddly they don’t provide the current version of Swift.

An alternative is the buildSwiftOnARM Github repo. They merely provide tarballs, which is slightly suboptimal, but very straightforward and they have tarballs for essentially every version – major and minor – of Swift to date. The git history also indicates that they’re very prompt about building tarballs as new versions are released.

Better yet, they provide a couple of shell scripts to build Swift from scratch from source. Only a couple of dependencies (e.g. clang) need be pre-installed, which can be done quickly & painlessly via apt.

Installing from source is presumably the least reliable approach, but since I had already resigned myself to a miserable experience, I figured I might as well go all in.

However, it works. Perfectly. Sure, it takes some time to pull down the huge source base for Swift and all its core dependencies, and some time to build it (though not that long – hours, not days, contrary to what I read online). But the end result was a working toolchain.

It remains to be seen exactly how good or bad Swift development on Linux is, given the absence of the numerous Apple system libraries which are what actually distinguish macOS development above other platforms, but at least getting Swift itself installed is painless.

Sidenote: SATA to USB

The only real speedbump in the whole process, for me, had nothing actually to do with installing Swift itself, but rather the external storage situation on the Raspberry Pi.

The Raspberry Pi doesn’t offer SATA directly, unfortunately (let-alone any form of pluggable PCIe). MicroSD is a low-performance, low-reliability, and high-cost option. So to attach any significant storage you’re basically going either through Ethernet (e.g. NAS) or USB.

USB to SATA adaptors are a shitshow. I’ve tried at least half a dozen different vendors’ offerings over the years, and every single one has been super buggy. The one I newly acquired for my Raspberry Pi use proved to be no exception.

Long story short on that, the symptoms were I/Os taking incredibly long times to complete (many seconds each, serialised), and generally unusable performance. /var/log/messages contained countless pages of:

Oct 13 11:13:45 applepi kernel: [  234.087294] sd 0:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
Oct 13 11:13:45 applepi kernel: [  234.087306] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x28 28 00 77 3b ce 00 00 00 d0 00
Oct 13 11:13:45 applepi kernel: [  234.126541] scsi host0: uas_eh_device_reset_handler start
Oct 13 11:13:45 applepi kernel: [  234.277450] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Oct 13 11:13:45 applepi kernel: [  234.312541] scsi host0: uas_eh_device_reset_handler success
Oct 13 11:14:15 applepi kernel: [  264.805760] sd 0:0:0:0: [sda] tag#7 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
Oct 13 11:14:15 applepi kernel: [  264.805778] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x28 28 00 77 3b d1 b8 00 00 48 00

Turns out this is an incredibly common problem with USB to SATA adaptor chipsets, that’s documented as such all over the web. Finding how to solve it was less trivial, because a lot of the advice given is either outright wrong or at least doesn’t work on Raspbian. The solution I found, via this random thread, was to simply add:

usb-storage.quirks=152d:1561:u

…to the end of the existing line in /boot/cmdline.txt (where 152d:1561 is the vendor & device IDs for the particular chipset used in my case). All other variations on this, involving adding similar magic incantations to files in /etc/modprobe.d etc, simply do not do anything on Raspbian.

The dumpster fire that is the Raspberry Pi

Sun, 13 Oct 2019 23:19:09 +0000

The Raspberry Pi 4 (image courtesy of Michael Henzler via Wikimedia Commons)

For a couple of little home projects I need an always-on computer. In an ideal world, perhaps, this would be something like a Mac Mini. Powerful [enough], easy to install & maintain, runs anything & everything (including anything Linux through Docker or at worst a straight VM). Unfortunately, Mac Minis are surprisingly expensive – even nine year old models are a couple of hundred dollars at a minimum.

So, I decided to instead explore this Raspberry Pi thing.

I very quickly started wishing I hadn’t.

The whole process thus far has just been a series of absurd errors & frustration.

Acquiring a Raspberry Pi

Step zero, of merely buying a Raspberry Pi, is stupidly difficult. Virtually all the retailers officially listed on raspberrypi.org did not actually have the Raspberry Pi 4 in stock. Later I discovered that some of these same retailers, that list no stock on their own websites, are actively selling the Pi on Amazon. So I bought one through there, which is fine, but why doesn’t raspberrypi.org just say to use Amazon, if that’s really the only way to get them?

Next up was all the peripherals – the Pi by default doesn’t even come with a power supply, so it’s useless out of the box. A cursory internet search reveals a huge amount of FUD about power supplies for the Pi. I have no idea if it’s accurate or not, but given some relevant, egregious design flaws in the Raspberry Pi 4, it seems plausible.

Plus you need at a minimum some stand-offs, if not a full case, to prevent the Pi damaging the surface it’s placed on, or damaging itself through shorts.

And addressing those bootstrapping problems ended up sending me down a rabbit hole trying to find a cooling solution too, since it turns out the Raspberry Pi 4 is infamous for overheating and suffering severe performance – and presumably reliability – problems as a result.

In the end, I spent several hours just figuring out how & what to buy, and what is nominally “the $35 computer” cost over $100. Still without a case, even.

Sidenote: the Pimoroni Fan Shim for Raspberry Pi, while a little fiddly to assemble, does seem to work very well, and is quite quiet.

Booting a Raspberry Pi

This is the one part of the process thus far that’s actually worked mostly as it should. I downloaded the full Raspbian Buster image, following the installation guide, and using balenaEtcher to plop the image onto an SD card. It all worked, even with the Etcher app being a tad dodgy (e.g. it lets you select non-removable volumes, which you cannot possibly intend to flash Raspbian onto, which is unnecessarily dangerous). The Raspberry Pi 4 booted first time.

I tried to discern whether booting it headless from its birth would work. Officially it does not, but I found that baffling and dug further, reading countless online guides (e.g.), which seemed to suggest it is possible.

I learnt that there exists the raspi-config tool for headless setup, but it was unclear if it would really work, fully. Though I did the GUI set up process to be conservative, I’ve since used raspi-config quite a bit. Turns out, it not only does work just fine, but it’s actually necessary because the GUI install doesn’t do some important things (like resize the root file system to fill the SD card).

One thing which nearly blew the whole enterprise was when it came to join a wifi network. I have multiple wifi networks, all with [different] emoji for names. The GUI set up tool can’t handle emoji, rendering them as octal escape sequences. I don’t happen to have memorised the four-character byte codes of each emoji, so it was a tedious game of trial-and-error in which I tried every permutation of unreadable SSID & password.

Worse, it took multiple attempts, too, before it finally worked – I have no idea why it failed to join the network the first time or two, despite using the right password. To this day it still arbitrarily fails to join one of the networks, yet joins the other just fine – both are in the same frequency bands from the exact same router.

Aside: Raspberry Pi 4 as a desktop computer

Since my intended use is as a headless, touchless server, I played only briefly with it in the GUI, using a makeshift setup involving my TV (the only HDMI viewing device I’ve ever owned – lucky I had that at least!). It’s fine, but very sluggish – it was immediately apparent that nobody with any other options would ever try to actually use a Raspberry Pi 4 as a desktop machine. Just [cold] launching the web browser, before you even navigate to a website, takes up to a minute. And everything is uncomfortably small, with no apparent system configuration options available to adjust render scaling. Clearly Raspbian is not really intended to be operated at UHD resolutions.

Enabling Remote Access

Though I ultimately intended to use only SSH to interact with the Pi, I did want to have VNC available as an option in case I ran into anything which required using the GUI (again, based on the heavy bias in all the official documentation, and the uncertainty created by that as to whether GUI interaction is required or merely an option).

Turns out, VNC doesn’t work out of the box on a Raspberry Pi, unless you buy commercial, proprietary VNC software. A baffling collusion on the part of the Raspberry Pi / Raspbian people. You have to do additional work to make it actually work – work that’s completely undocumented in any official Raspberry Pi / Raspbian documentation. (at best you’ll find the interwebs littered with accounts & instructions on installing a non-proprietary VNC server in replacement, which presumably also works to solve this problem)

Installing Homebridge

It wasn’t actually my purpose in buying the Raspberry Pi, but I decided that – before I go down the meat grinder that is presumably getting Swift to work on the Pi, since the Pi sadly lacks support for Swift out of the box – I figured I’d just real quickly install Homebridge, since I do have a couple of devices I’ve long wished would work with HomeKit.

Ugh.

What a fucking dumpster fire.

You can install Homebridge raw, but since it’s written in Node.js, I didn’t want it going into my real, bare system – infecting it with npn and JavaScript and all that horror.

This would be a perfect opportunity for Docker, and as one might expect there are many guides on how to install Homebridge via Docker.

Installing Homebridge Docker

Sadly – and frankly bizarrely – running Homebridge through Docker isn’t officially supported.

This 3rd party guide appeared to be the best, based on this third party project to support Homebridge in Docker. Step zero, of course, is to install Docker itself. Surely that’s trivial. It’s Docker. What doesn’t run Docker these days? Hell, macOS runs Docker and it doesn’t even support containers. I was baffled that Raspbian didn’t include Docker pre-installed.

Many, many hours later, it still wasn’t working. One would think that Docker, of all things, would be a seamless thing to sudo apt install, but far from it. For example, the official Docker apt repo for Raspbian tries to install some ‘aufs-kdms’ as a dependency, even though – turns out – it’s not a real dependency and doesn’t even compile on Raspbian. WTF?!

So that wasted hours, in figuring that out – predominately consumed in trawling the interwebs for a solution. After many hours and reading through dozens if not hundreds of StackOverflow, blog, and similar sources quoting similar issues and offering bogus remedies, I finally found a thread that’s actually helpful.

The worst was yet to come.

At some point in this process something also screwed with my Pi’s boot settings to force the root directory to be mounted – at boot – as an overlay with writes going to tmpfs (i.e. nowhere). That wasted yet more hours as I painstakingly root-caused why my Raspberry Pi suddenly had alzheimers (and lost a lot of progress otherwise on installing Homebridge, too).

The web utterly failed in this case, as I couldn’t even find how to disable overlayfs. All I got, mockingly, was endless articles explaining how to enable it and voluntarily ruin your day.

Even just figuring out that it was overlayfs that was screwing me took quite some time, since the first failure symptom was a baffling error message when trying to start dockerd:

failed to start daemon: rename /var/lib/docker/runtimes /var/lib/docker/runtimes-old: invalid cross-device link
With love and fuck you, dockerd

Ultimately I found a fix, in part thanks to this forum post which had enough transparency on enabling this bullshit situation that I could deduce how to disable it – long story short you need to mount the SD card on another, working computer and remove ‘boot=overlay‘ from /boot/cmdline.txt and ‘initramfs initrd.img-4.19.75-v7l+-overlay‘ from /boot/config.txt.

How that ever got enabled I have no idea. Absolutely no commands I ran had anything to do with that at all. Evidently something buried inside Docker installation and/or execution performs this system lobotomy. Even then, I’ve since reviewed every single command I ran, and nothing seems even remotely like it could nor should have caused that.

Despite ultimately defeating all this failure, I was greeted by merely another fatal failure, just as inscrutable as the last:

$ docker-compose up -d
ERROR: Couldn't connect to Docker daemon at http+docker://localhost - is it running?

If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.
$ ps auxww | grep docker
root       427  0.6  1.4 966720 58856 ?        Ssl  15:42   0:01 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
pi        1942  0.0  0.0   7348   472 pts/0    S+   15:46   0:00 grep --color=auto docker

Turns out this was because my user (‘pi’, the default) wasn’t a member of the ‘docker’ group. I’d added it previously, but it must have been under the tyrannical overlayfs regime, and all memory of that event purged. Adding it again (then logging out & back in) fixed it (sudo usermod -aG docker pi btw).

This is why Linux can’t have nice things

In summary, Linux in general, and certainly Raspbian specifically, continues to be the same giant clusterfuck it’s always been. I’m no Linux novice – I’ve been writing software for Linux for over a decade as my day job. I’ve just had the luxury of teams of dozens if not hundreds of other engineers to insulate me from the bare wiring that is installing, configuring, & maintaining a Linux installation.

At this point I’m two days in and have only just gotten Docker working. For all the time I’ve wasted I’ve completely blown the price savings between a Raspberry Pi and even a brand new, $800 Mac Mini.

And I still haven’t even started installing Swift, let-alone actually running my Swift app on the Raspberry Pi, which – contrary to where all my time has gone on this project – is the actual purpose of this whole sad enterprise.

iCloud ‘Optimize Mac Storage’ breaks the Mojave installer

Fri, 01 Feb 2019 19:42:00 +0000

Yet another example of a really bizarre macOS bug that’s pretty inexcusable as a test escape, given it occurs with the default installation settings on a completely clean OS install.

In short, the Mojave update installer does not work (on High Sierra at least) if you have ‘Optimize Mac Storage’ enabled for iCloud Drive (System Preferences > iCloud pane > iCloud Drive Options… button > Documents tab > Optimize Mac Storage checkbox).

Specifically, the installer reports:

Installation requires downloading important content. That content can’t be downloaded at this time. Try again later.

…and indeed fails to download the actual Mojave update files (the installer app as ‘installed’ via the App Store is merely a 22 MB bootstrapping app, that downloads the actual image only after you run it & start the installation).

Even more obnoxiously, if you use the dosdude1 Mojave Patcher Tool to force-download the entire installer, as soon as it completes the 6.5 GB download and produces the ‘Install macOS Mojave’ app in /Applications, the system deletes the downloaded installation files out from under that app, rendering it just as broken as the official App Store version. Infuriating.

Aside: to be clear, turning off ‘Optimize Mac Storage’ enabled me to produce – and keep – a working installer as downloaded by dosdude1’s tool. I did not verify that it also fixes the regular installer as downloaded via the App Store.

I also ran into the “The recovery server could not be contacted” error message even before all the above, but thankfully that was fixable via the means normally prescribed online – running “sudo ntpdate -u time.apple.com”.

Full Disk Access is required to access Time Machine backups in Mojave

Thu, 27 Dec 2018 17:51:51 +0000

I’ve been struggling since Mojave came out to deal with it’s over-bearing expansion of SIP (“System Integrity Protection”), which is basically a super-root notion that blocks access – even to root – to lots of basic parts of the system, including obvious & mostly sensible ones like /System and /Library, but also less usefully things like any & all Time Machine backups.

Blocking access to Time Machine makes it very difficult to actually use Time Machine, since it’s then difficult to retrieve files from a backup (you have to then use the stupid ‘warp’ Time Machine interface, which is slow, ugly, and buggy).

Luckily, it turns out there is a fairly simple solution that isn’t disabling SIP entirely (which requires multiple reboots in order to do, so is typically quite disruptive & slow). It appears that any application granted Full Disk Access (System Preferences → Security & Privacy → Full Disk Access) can read Time Machine backups.

In case you’re unfamiliar, the symptoms of this problem include:

Being unable to navigate into Time Machine backups in the Open / Save / etc dialogs.
Being unable to see – through ls or similar tools – the contents of Time Machine backups via Terminal.
Apps reporting errors like “The file “Foo” couldn’t be opened because you don’t have permission to view it” or bluntly “Operation not permitted” when trying to read something in a Time Machine backup.

There’s a strange & ironically very bad security quirk though – curiously, any tools run via Terminal inherit Terminal’s access (or lack thereof) to Full Disk Access. They don’t use whatever setting might be specified for them in the Security & Privacy preferences. This is pretty baffling, as it means to give Full Disk Access to anything you run via Terminal, you have to give it to everything you run via Terminal. Anything you specifically give Full Disk Access won’t actually receive it if it happens to be launched via the Terminal (which confused me for a while, since it’s so unintuitive).

I’m guessing whatever mechanism enforces all this so-called security is based in LaunchServices or somesuch – while the Finder and most things in general will launch apps via LaunchServices, as detached & independent process sessions, Terminal doesn’t – everything it runs, from the shells down, run under it in the process hierarchy, and seemingly share its security & privacy settings.

ffmpeg can produce pseudo-corrupt audio when ‘copy’ing to an MP4 container

Wed, 01 Aug 2018 15:56:08 +0000

I’ve been using ffmpeg to trim clips from a trail camera, as most of the time there’s only a few seconds of anything interesting in frame out of the 30+ seconds of video it records each time, but I don’t want to re-encode them and lose video quality as a result (or balloon file sizes tremendously with a lossless video coding). Keeping the whole 30 seconds is not just unnecessary and makes viewing the videos much more tedious, but wasteful of storage space as the encoding quality from the trail camera is very inefficient (file sizes are many times larger than they should be for the quality – clearly the H.264 encoder used in the trail camera is very cheap and very bad at its job).

I was originally doing something like:

ffmpeg -ss 00:07 -t 00:03 -i "IMG_0164.MP4" -async 1 -c copy "IMG_0164_TRIMMED.MP4"

The resulting trimmed MP4s play just fine in Quicktime, the Finder – anywhere that uses Apple’s decoding libraries (though I didn’t test iOS).

However, in VLC, or Lightroom, the audio is completely corrupt – just incoherent noise. In Lightroom the video doesn’t even play correctly, because of Lightroom’s stupid habit of re-encoding the video & audio into internal caches – apparently their video decoder is somehow thrown off by the audio channel issues, too.

After much trial and error and many dead-ends (thank you completely bogus & wrong Stack Overflow threads… sigh) I eventually realised that the problem is apparently simply that Lightroom, VLC, etc get offended when you include pcm_s16le audio in an MP4. ffmpeg itself says that’s not a valid audio codec for the MP4 container, iff you explicitly tell it to use that as the codec. If you’re just copying from an existing audio / video file, however, it makes no mention at all of the concern. Sigh.

So the apparent solution is simply to switch to the MOV container format instead.

ffmpeg -ss 00:07 -t 00:03 -i "IMG_0164.MP4" -async 1 -c copy "IMG_0164_TRIMMED.MOV"

The encoded bits remain identical, but the MOV container apparently accepts PCM audio where MP4 does not. VLC, Lightroom, etc are now happy (and Quicktime et al remain happy).

(another possibility is that the ‘incompatibility’ is related to MP4 levels or some other such junk… I didn’t try deciphering or exploring that)

It’s frustrating that VLC & Lightroom can’t handle this when clearly it’s technically possible (witness Quicktime), and worse they don’t even properly recognise that they’re not handling it properly – they just play completely corrupt audio that’s literally painful on the ears.

It’s also very curious that the trail camera uses PCM audio if that’s not valid in an MP4 container. It’s downright bizarre that VLC & Lightroom can play the unmodified MP4s straight from the trail camera, even though they use the same purportedly invalid audio codec… somehow something ffmpeg is doing during its transmutation is making them angry. I was unable to determine what that might be, though, through trial-and-error with ffmpeg command line options & rudimentary examination of the input & output files.

P.S. An alternative is to bitwise-copy only the video stream (i.e. change -c copy to -c:v copy), and let VLC transcode the audio into its default AAC for the MP4 container. That probably wouldn’t be a problem for me in my case – the audio from trail cameras is pretty crappy to begin with – but at the same time the audio tracks in these files are insignificant in size, so re-encoding them (and lossy as AAC) is pointless to saving disk space.

Adobe Photoshop Lightroom doesn’t support Adobe Photoshop files

Mon, 29 May 2017 05:20:31 +0000

I need a ‘facepalm’ category apparently. There’s been a lot of that lately.

You cannot import, let-alone work on, Photoshop files (“PSB” file extension) in Lightroom. It flat-out doesn’t support them. That’s such a weird limitation & oversight, for a program that Adobe now officially names ‘Adobe Photoshop Lightroom’.

See also this six year old thread on Adobe’s website, asking for this feature.

iOS Family Sharing users cannot mix authentication schemes

Sat, 15 Apr 2017 19:51:04 +0000

Apple supports two styles of two-factor authentication, that they call (and distinguish as) “two-step” vs “two-factor”. “Two-step” is their older method, though functionally they’re basically equivalent.

If you have multiple accounts on a Family Sharing arrangement, and some use “two-factor” while others use “two-step”, you’re in for a bag of hurt.

For example, any time you change the password on any of the non-master accounts, you’ll have to reauthorise all devices on that account with the master purchaser. You’ll be prompted, when trying to download apps or purchase anything etc, with a dialog saying “Your Family Organizer, [foo], must enter the security code for their payment method”, asking for some kind of input. There is literally nothing you can enter there that will make it work. Not the password for any of the relevant Apple IDs, not any security codes for any credit cards, nada.

The problem is that it’s asking for a verification code that you can only create on a device which has “two-factor” authentication enabled. Compare for example what you see with “two-factor” authentication enabled on your iDevice:

Versus what you see with “two-step”:

That “Get Verification Code” “button” is what you’re looking for. As you can see, it simply doesn’t exist with “two-step” authentication enabled.

The only solution – to allow your family members to download apps, purchase music / videos / books / etc, or pretty much do anything else on their iDevices – is to force the master account over to “two-factor” authentication.

To do this, you have to go to https://appleid.apple.com/ and turn off “two-step” authentication (which will require you to complete some stupid ‘security’ questions). You cannot turn off “two-step” authentication from any of your actual iDevices’ Settings apps.

Then, stupidly, you can’t actually enable “two-factor” authentication from that same website. That can only be done in the Settings app on one of your iDevices – by (in iOS 10.3 or later) going into Settings ➜ ➜ Password & Security.

There’s no way to enable “two-step” authentication anymore. And not having any form of two-factor authentication enabled is a very bad idea. So if any of your family’s accounts have “two-factor” authentication enabled, you basically have to switch to “two-factor” on all of them.

Which would be broadly fine, if Apple hadn’t made it so needlessly complicated, and the two systems so incompatible that their own software can’t figure out what’s going on.

EXIF metadata stores random gibberish for dates & times

Sun, 08 Jan 2017 19:06:19 +0000

I hadn’t ’til yesterday realised that EXIF metadata doesn’t actually store dates & times correctly. Whoever came up with the spec all those decades ago clearly didn’t know how to work with dates & times correctly. This is immensely frustrating since now we have countless images taken with timestamps that are collectively gibberish.

The problem is that the standard doesn’t specify time zones in almost all cases (the sole exception being for GPS timestamps, which are in UTC). Which means if you see the date & time “2016-02-03T10:36:33.40” in your photo, that could be any actual time give or take ~25 hours to either side of that.

I realise now, in hindsight, that programs like Aperture & Lightroom manage this by implicitly associating a time zone with photos as they’re imported (and both have controls of varying degrees for ‘correcting’ the time of the photos, in cases where the camera’s clock is set wrong – including being set to the wrong time zone). They leave it to the user to ensure the time zone that’s set for import matches what was on the camera at the time the photos were recorded.

However, if you’re processing images at scale and don’t have that explicit information from the user(s), you’re SOL.

Additionally, I don’t know anyone with a DSLR who hasn’t at least occasionally forgotten to change the date & time on their camera to account for changes in daylight savings time, or movement to a new time zone. If the time zone were recorded, this wouldn’t really matter since you could reliable change it later. But since it’s not, it’s impossible to tell programatically when and where the time zone changes, in a given series of photos.

Now, you might think that since the GPS timestamp is actually recorded as a real, definitive time, that you could just use that to determine the time zone of other dates & times in the metadata (by simply looking at the difference between them). Unfortunately, in this case, the GPS timestamp is defined as the time at which the GPS data was recorded, not when the photo was created (or edited, or any of the other types of timestamps recorded in EXIF metadata). Which means that in practice the GPS timestamp can be an unspecified & unpredictable amount of time older than the other timestamps¹.

If it were just a matter of a few minutes difference then this wouldn’t be an issue, since the vast majority of the world only acknowledges half hour increments in time zone steps² and thus you could just round and get things right most of the time. Unfortunately, at least some notable GPS implementations in popular cameras have potentially huge deltas (hours or more) – e.g. all of Nikon’s SnapBridge cameras, including the D500, D5600, & D3400.

And that’s assuming the camera’s clock isn’t set wrong anyway – it’s possible to include GPS data in your photos but not sync the camera’s clock, in at least some popular cameras like Nikon’s. ↩︎
Wikipedia reports that there are a couple of small regions of Australia & New Zealand which use 15 minute offsets, and the entirety of Nepal does too, but those are the only exceptions. And only a small minority use half hour offsets, as opposed to hour offsets, to begin with. ↩︎

Building John The Ripper Jumbo for macOS Sierra

Sat, 12 Nov 2016 02:42:40 +0000

It’s quickly apparent that John The Ripper Jumbo doesn’t build out of the box on macOS, and probably hasn’t for a long time, due to its complaint about missing OpenSSL headers.

This guide was almost helpful, except it’s out of date – e.g. the Makefile.in patch it provides no longer applies cleanly – and simply doesn’t work – once you get the John The Ripper configure script to see the OpenSSL devel headers, it then just complains that it can’t find a valid libssl anyway.

Even the Pro version of John The Ripper, which isn’t cheap, doesn’t look like a good option since its web page has the hallmarks of something that hasn’t been updated in many, many years. e.g. talk about support for Mac OS X 10.7 Lion being planned.

And although it appears to support using CommonCrypto instead of the now deprecated OpenSSL, that doesn’t work – even when configured that way it still compiles in code that requires OpenSSL, for SHA1. Sigh.

Trying to get it to use a fresh build of OpenSSL (1.1.0) also seems an intractable failure – OpenSSL 1.1.0 out of the box produces libraries which don’t contain SSL_library_init, which is of course necessary for any OpenSSL user and foils any attempt to use the built libraries by way of missing symbol errors in the link phase.

And OpenSSL 0.9.8zh’s build system is just screwy. By default it builds only 32-bit and only static libraries (no matter how hard you tell it to build shared ones). You have to bypass its first layer of configery and do it ‘manually’, like so:

./configure --prefix= darwin64-x86_64-cc -no-shared enable-camellia

You can then configure JohnTheRipper to point to that version of OpenSSL, like so:

./configure CPPFLAGS='-I /include' LDFLAGS='-L /lib' OPENSSL_LIBS="-lcrypto"

Now it’ll finally get past the OpenSSL issues, and build successfully.

Note: don’t use the Makefile.in patch provided in the aforelinked guide. That actually breaks the build now, even if you properly apply it manually.

Silent data corruption

Wed, 06 Jul 2016 05:23:36 +0000

Alternate title: Apple’s file system engineers are sadly naive.

I was quite disappointed to see that APFS isn’t even trying to provide data integrity. Data integrity is kind of step 0 of any file system, and checksums or use of ECC is pretty much standard in modern & leading-edge file systems. APFS doesn’t want to be one of those, it seems.

Case in point why this matters:

I have a bunch of old backup drives, because drives are cheap and until recently I could just buy a new one once the current one filled, instead of ever deleting a backup. Periodically I go back through these old backup drives and do some basic integrity checks (S.M.A.R.T. bad block scans, file system checks, etc).

I also run a comparison of key data between those backups and the current versions on my computer, for files which generally shouldn’t change nor disappear – e.g. photos, videos, key documents, etc.

And today I found that at least half a dozen valuable personal videos (and a few photos) were corrupt, in the versions on my computer. Luckily, the versions in the ancient backups were still good, so I could replace the corrupt ones.

This corruption was completely silent, until my ‘paranoid’ and time-consuming checks discovered it.

It’s far from the first time. A failing drive years back corrupted a huge portion of my music library – silently, as far as the file system & OS were concerned. Periodically I’ve discovered photos (of which I have huge numbers – the majority of my data) which have become corrupt at some indeterminate point. And I’ve of course had file system [metadata] corruption occur many times, sometimes requiring complete erasure of the disk, and recovery or rebuilds from backup (a few times I’ve had to use data recovery software, where backups weren’t available).

Most, if not all, of these issues would have been discovered by even the most trivial file integrity protections, in the file system.

The notion that modern disks somehow magically protect against all silent data corruption is abject poppycock. They’re more likely to suffer from it than older disks – a byproduct of higher densities and market demand for cheaper, crappier storage products.

And the implicit assertion that Apple’s file system driver, and kernel overall, are somehow completely free of bugs… is just batshit crazy.

Addendum

Since Apple aren’t interested in protecting anyone’s valuable personal data, I’m on the look-out for other options. Manual use of shasum is one, for now, but a more streamlined and fool-proof system would be better. Alas, none seems to exist[1. There is chkbit, but it relies on MD5… probably acceptable for this use case, but needless in the face of decades of better hash algorithms. And it’s written in JavaScript. Ew.]. Yet.

Lightroom’s flaws & limitations

Thu, 11 Feb 2016 18:04:55 +0000

I’m attempting to switch to Lightroom, from Aperture, given lack of better alternatives. I’ve attempted this switch a couple of times before, without success.

I’m finding that it’s still kind of annoying. Here’s the start of my laundry list against it:

It’s very slow. I am already so very tired of seeing that blasted “Loading…” floater.
- I’m running it off of a pair of SATA-connected SSDs – one for the library, one for the originals. It has enough usable bandwidth to read in dozens of photos a second. But it still takes three to five seconds to show just one.
It’s also a bit slow to actually show adjustments as you make them, a lot of the time. Aperture, despite not being updated for many years to take advantage of all sorts of new technologies, is still much more responsive and fluid, and consequently faster to use.
- I did notice that Capture One is also a bit sluggish sometimes, in this respect. Sad panda – everyone’s screwing this up, it seems.
When you scroll around in the grid view, it’s a bit janky – see prior point on Lightroom just generally being sluggish – but even worse, it doesn’t show the photo’s metadata reliably. A lot of it is invisible for a while, ‘loading in’ some time later. It’s really annoying to have to frequently wait for Lightroom to get around to actually showing me the grid view properly. And it’s also very distracting to see the metadata popping in at random intervals for random photos.
Its search & filtering tools are kinda piss-weak. e.g. you can do a text search of metadata for only one thing at a time. And you can’t even specify what metadata you want to search, with very few exceptions.
As I’d shown previously, its RAW renderer is not very good. Image quality out of the box is very poor – mainly that even bright, ISO 100 shots have unacceptably high noise visible and require strong noise reduction. This is unnecessary in every other RAW renderer I’ve ever used (Aperture wasn’t great either, granted, but at least it erred on the side of not noisy-as-heck by default; it’s much easier to add sharpening as necessary than to have to noise reduce every time).
- And its noise reduction tool isn’t great either – much like Aperture’s, it’s ham-fisted and often requires painstaking brush-work to selectively apply it to each photo.
Its sharpening tool is not very good either. It introduces grittiness and nasty edge haloes really quickly, relative to how much actual sharpness & detail it’s revealing. Now I understand why so many Lightroom users seem to use 3rd-party sharpening (and noise reduction) plug-ins.
- On the upside, vs Aperture, it does let you set a detail-sensitive ‘mask’, which helps reduce brushwork somewhat. Unfortunately it lacks the corresponding slider for its noise reduction tool, which reintroduces the need to do painstaking brushwork.
Its system for managing brush masks is surprisingly awkward. Aperture was much more straightforward (though not without its own foibles, like not letting you share masks between adjustment tools). e.g. to see an overlay of where the mask actually is, you have to however the mouse over a tiny little dot – and there may be several on the photo, if you’ve added several different masks, with no way to distinguish them other than their arbitrary locations. And worse, you have to wait a couple of seconds, every time, for the mask overlay to actually appear. And then as soon as you move off the dot – e.g. to actually modify the mask – it disappears! Ridiculous!
- Capture One has the best implementation of this that I’ve seen, so far. There’s a couple of things about Capture One’s that I find a little awkward, compared to Aperture’s, but overall it’s still the best.
It’s possible to have filters applied but the filter bar hidden. Very confusing – it took me quite some time to figure out why a bunch of photos simply weren’t showing up. It’d make much more sense, IMHO, to have the ‘hide the filter bar’ option only apply when there aren’t any filters actually applied. Though I do recognise the counter-opinion.
Deleting photos is unnecessarily difficult. If you’re viewing a collection, there’s no way to do it directly. The least sucky way I’ve found is to mark target photos as ‘Rejected’, and then go to the “All Photographs” view and hit command-delete. Lots of unnecessary steps and distracting from the workflow.
Its built-in Flickr export forces all photos to sRGB. Sad, blunt fail.
- There is a popular third-party plug-in, Photo Upload, which I’m using for now, but I keep finding it rubs me a bit the wrong way. Hopefully just a matter of getting used to it – FlickrExport for Aperture, which I’d relied on previously, wasn’t perfect either. And on the upside, the author seems very responsive and courteous, which is refreshing and encouraging.
Import from SD cards is a little sluggish. Not terrible – I’m talking ~60 MB/s on a card & reader combo capable of ≥80 MB/s – but it’s still a bit disappointing. Aperture is faster.
Its metadata editing interface is certainly better than Capture One’s horrible & buggy one, but still a far cry from Aperture’s. I miss being able to customise the metadata view, but beyond that, even basic things are a bit awkward, like the ‘Title’ and ‘Caption’ fields being tiny and thrown arbitrarily down towards the end of the list.
- Though it does have one handy thing – clicking on the field name shows a pop-up menu listing recently used values, which is actually a thoughtful touch. Auto-completion is also available, but it’s nice to avoid the keyboard <-> mouse shift.
I still don’t like its modality. I find I have to shift between ‘Library’ and ‘Develop’ modes a lot, which’d be tedious enough even without the fact that a whole bunch of keyboard shortcuts are different between the two. Super annoying. I keep hitting keys expecting some predictable result, and instead just get NSBeeps, or totally undesired effects, or worse – just a flash of a menubar item with no indication of what the #%@! just happened, or how to undo it. Gah!

And I could go on. And probably will in future – I need somewhere to vent and mind-bogglingly Adobe offer no way to actually file bug reports & feature requests with them directly.

I really get the impression that Adobe haven’t paid due attention to their [former] competition, Aperture. There’s just so many things that Aperture has done better for nearly a decade now. If they were holding off ‘copying’ it out of some sense of honour, that’s respectable, but the time for it has long passed, given Aperture’s demise.

Why I cancelled Backblaze

Sun, 24 Jan 2016 02:44:31 +0000

This is the feedback I sent to Backblaze shortly before I cancelled my account with them.

For the additional context – the restore failure I alluded to was basically that:

Over the course of more than a week and repeated attempts, they were unable to restore 99.7% of my data.
They sent me 685 spammy emails telling me the restore failed. Six hundred and eighty five.
Their tech support was at least fairly open, and admitted to the problem without fuss, but were unable to actually do anything to get the data back. Which is, after all, the most important thing.

So, the departing ‘support’ ticket I filed with them (#167833):

Maybe this’ll help your future would-be customers.

The main reason is that when I tried to actually restore data a month or two ago, I was unable to. Epic fail on your part. (Support request #162743, FYI)

That alone is a deal-breaker. The lacklustre customer support and idiotic email spam bugs add icing on that horrible cake.

There are other reasons too, however:

There’s no secure way to restore. You require me to provide my private key password to your web site. So many ways that can go wrong. I want something more akin to Crashplan’s ability to restore through a local app [once it’s given the private key password]. I should never, *ever* have to transmit my private key password over the internet.
30 day inactivity window. I recently travelled away from home for nearly 30 days, and realised that if I’d been gone a little longer, you would have thrown out all my backups. If I’m still paying you, you should still be retaining my backups. (and since *all* my drives are external, including my boot drive, this applies to *all* my data. Even if my boot drive weren’t external, the vast majority of my valuable data is on [permanently connected] external drives)
30 day restore window. I’m somewhat on the fence with this one, but other backup services offer retention horizons much longer, or alternative schemes where you have up to N (typically 30) *versions*, regardless of how old those are. Both are preferable to a fixed time window. Since the vast majority of my data is write-once, or thereabouts, I don’t actually have multiple versions of most, but for those that do it’d be comforting to know that I could go back months or years to the prior version(s). I’d be willing to pay extra for this.
The Backblaze daemon takes an unduly long time to notice new files. Even if I manually tell it to hurry up (i.e. option-click ‘Restore options…’) it still sometimes doesn’t notice new files. I see good reason to not be too hyperactive with backups – it’s true I don’t need every minute’s version of some random file I’m working in – but most of my data is photos & videos, which are import-once-and-never-change (or maybe delete, later). I’d really like to just see Backblaze immediately start backing up newly imported photos & photos as soon as they hit the disk.

I’ve realised that I need all these things, and as it happens Crashplan offers them, so I’m switching.

To your advantage, uploads are much faster than many of the alternative services I tested (particularly Crashplan), and I otherwise like your native app and it’s relatively minimal system impact. So I’m a little sad to see that go. But simple, fast uploads are quite pointless if, when all is said and done, they’re essentially going to /dev/null.

Dealing with Nikon Technical Support (a.k.a. pulling teeth)

Mon, 03 Nov 2014 15:29:34 +0000

Me: Hey, the D7100 with these particular lenses over-exposes by exactly one stop when not wide open.
Nikon’s Support Website: Cool story bro. Got any pics?
Me: Sure, here they are…
Nikon’s Support Website: Sorry, all attachments have to be 10 MB or less.
Me: U wot mate?
…
Me: Okay, I put them up on a HTTP server. Here are the links.
Nikon’s Support Drone: We don’t accept modified images. You have to provide the images straight from the camera.
Me: Those were copied directly from the SD card.
…
Nikon’s Support Drone: Please email them to us.
Me: Your email gateway doesn’t accept attachments that large.
…
Nikon’s Support Drone: Please retake the images at a smaller size.
Me: I have no words.

Or… you could update your stupid Support site to accept attachments larger than 10 MB. What Nikon camera produces JPEGs less than 10 MB in size, let alone raws? @#%$!

Snafu – Wade Tregaskis

Bugs Apple Loves & Apps Apple Hates

Recording audio to an iPhone via a Tascam Portacapture X8

Thankfully, any USB-C or USB-C-to-Lightning cable will do

You must use 48kHz sampling

You don’t have to use the iPhone to provide power

You don’t have to record on the Portacapture X8

How to make a macOS screen saver

Setting up the Xcode project

Providing a preferences sheet

Getting ready to render

Rendering

Bonus topic: fading in

Previewing

Stopping

Handling resumption

Exiting

Testing your screen saver

Distributing your screen saver

Conclusion

Addendum: SaveHollywood

Addendum: What this says about Apple

Calling Swift Concurrency async code synchronously in Swift

Bipolar customer support

Nice gal Amanda

Bad guy Marc

Matching prefixes in Swift strings

So, back to prefixes…

Checking for a specific prefix

Finding common prefixes

Working with suffixes

Beware the range parameter

A hint that the Mac Messages app is not native

SwiftUI drag & drop does not support file promises

Is that it?

Best alternative (other than ditching SwiftUI)

Understanding the SwiftUI drag & drop APIs

Mac app sandboxing interferes with drag & drop

Noticing when drag & drop operations start

Drag & drop implementation detail

Pasteboard implementation detail

Deducing what’s going on by spying on global mouse events

You get only one look at the dragged files

Failed workarounds

Partial workaround

Addendum: Michael Tsai’s Blog

Secret Sonoma design lead: Barbie

Radical pink redesign

WTF?!

Epiphany

So, wait, how did this come about?

Apple’s response? “Fuck you” in mime.

SwiftData pitfalls

Background

Example use case

Design flaws

Auto-save doesn’t work

Workarounds

Arrays of @Model objects are randomly shuffled

Workarounds

let cannot be used for bidirectional relationships

Workarounds

Relationships are secretly implicitly unwrapped by default

Workarounds

You cannot directly initialise bidirectional relationship properties

Workarounds

Relationship constraints are only enforced at save time

Workarounds

Singletons are unsupported

Workarounds

You cannot create model objects outside of SwiftData contexts

Workarounds

Apple’s documentation is wrong

Workarounds

Non-pitfalls

You only need to register the root(s) of your model graph

Bonus: TablePlus recommendation

iPhone emergency satellite communication is geolocked

Swift on Raspberry Pi (in 2019)

Sidenote: SATA to USB

Beware the `range` parameter

Arrays of `@Model` objects are randomly shuffled

`let` cannot be used for bidirectional relationships