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.

Thankfully the workaround is simple – disable tethering, or enable Airplane mode, while you’re using Image Capture.

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.

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.

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:

1. Kill your own process every time you stop animating.
2. 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.

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.

If any view in the [active] window contains a Toggle – even one that’s disabled or hidden – then Continuity Camera (re. ImportFromDevicesCommands and importableFromServices) doesn’t work; all the submenu items under “Import from iPhone or iPad” are disabled.

I don’t know if this is truly specific to Toggle, that’s just the example case I happen to have isolated [first?].

What’s really weird is that once a Toggle has ever been displayed, even if you subsequently remove it from the view hierarchy entirely the “Import from iPhone or iPad” submenu items all remain disabled.

import SwiftUI

@main
struct Example: App {
    @State var breakImportFromiDevice = true
    @State var text = ""

    var body: some Scene {
        WindowGroup {
            VStack {
                TextField("Input", text: $text) // Doesn't break anything.

                if breakImportFromiDevice {
                    Toggle("Break import from iDevice", isOn: $breakImportFromiDevice)
                }
            }
            .importableFromServices(action: { (images: [NSImage]) -> Bool in
                print("Load image!")
                return true
            })
        }.commands {
            ImportFromDevicesCommands()
        }
    }
}

There are some circumstances in which this gets “unbroken” during interactions with other views and so forth, which is 100% reproducible in my real app but I have no idea what the reason is. The steps involved in my real app are kinda ridiculous (and not in any way remotely a viable workaround) and make absolutely no sense – it only “unbreaks” when a specific view is in a specific weird state (itself kind of the result of a bug, albeit a benign one). And that weird state is merely whether it’s displaying one image or another – which as far as SwiftUI is concerned is not even a difference in view state, since I’m just swapping NSImages under the cover.

I figured it must be something to do with view focus, but after much experimentation I believe I can conclusively rule that out. No matter which view has focus, or how focus is configured, or which views are even focusable at all, the problem persists. Likewise for window focus and key state. And, [accessability-]focusable views other than Toggle – e.g. TextField – don’t cause any issues.

Frankly it’s baffling, and a mite infuriating. I can’t even conceive of how SwiftUI can be so incredibly broken regarding such basic functionality, and the apparent interaction of GUI elements that have absolutely no business together.

Tangentially, a few things I’ve noticed about this Continuity Camera feature:

• “Add Sketch” doesn’t do anything. Unlike the other options, which open the camera app on the target iDevice, it has no effect. 🤷‍♂️
• Within the Finder, you can right-click empty whitespace within a folder, and the contextual menu has this “Import from iPhone or iPad” option at the bottom. That’s pretty handy – until now I’d been doing it the “hard” way by taking a photo on my iPhone and AirDropping it across to my Mac.
  
  I’d never noticed that feature prior to debugging this problem (I wanted to confirm that multiple other apps worked just fine; that it wasn’t an issue with Continuity Camera system-wide).
• TextEdit has the same feature but tweaks the wording to “Insert…” rather than “Import…”, which I thought is both a nice touch and frustratingly not something you can do in your own apps (at least, not in SwiftUI). 😕

NSPasteboard mutates itself simultaneously from the main thread and the global concurrent Dispatch pool, w.r.t. to its internal type cache. This is surprisingly trivial to reproduce (sample code below) by just dropping, e.g. a file promise (such as by opening a PNG in Preview, revealing the thumbnails sidebar, and then dragging the thumbnail onto the sample project’s window).

import SwiftUI

struct ContentView: View {
    var body: some View {
        Rectangle().onDrop(of: NSImage.imageTypes, isTargeted: nil) { _ in
            let pb = NSPasteboard(name: .drag)

            _ = pb.pasteboardItems // Seems to be necessary for the crash.

            _ = NSImage.imageTypes // Not strictly necessary for the crash, but seems to make it more likely. 🤷‍♂️

            return true
        }
    }
}

Judging from the callstack that runs in the concurrent pool, this is specific to file promises (and that seems to match my experience – it only crashes for some test cases, all of which involve file promises being present in the drag pasteboard at the time of the drop).

Since this bug causes semi-random memory corruption, it manifests in a large number of ways – not all of which are all that helpful. But at least one case I’ve seen a few times is helpful, as it clearly shows the offending internal NSPasteboard code running concurrently with itself, e.g.:

Main queue / thread:
#0	0x00007ff80108dab5 in _platform_bzero$VARIANT$Haswell ()
#1	0x000000010df8774d in GuardMalloc_mallocInternal ()
#2	0x00007ff90792542f in stack_logging_lite_malloc ()
#3	0x00007ff800ea8733 in _malloc_zone_malloc_instrumented_or_legacy ()
#4	0x00007ff800f39a72 in _vasprintf ()
#5	0x00007ff800f16922 in asprintf ()
#6	0x00007ff80125655a in -[NSObject(NSObject) __dealloc_zombie] ()
#7	0x00007ff8020e039a in -[NSConcreteMapTable dealloc] ()
#8	0x00007ff804876983 in -[NSPasteboard _updateTypeCacheIfNeeded] ()
#9	0x00007ff8048763df in -[NSPasteboard _typesAtIndex:combinesItems:] ()
#10	0x00007ff804aad148 in NSCoreDragReceiveMessageProc ()
#11	0x00007ff807517b1a in CallReceiveMessageCollectionWithMessage ()
#12	0x00007ff8075124fa in DoMultipartDropMessage ()
#13	0x00007ff8075122ce in DoDropMessage ()
#14	0x00007ff8075159a9 in CoreDragMessageHandler ()
#15	0x00007ff8011d776b in __CFMessagePortPerform ()
#16	0x00007ff80113e5b7 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#17	0x00007ff80113e4ee in __CFRunLoopDoSource1 ()
#18	0x00007ff80113d166 in __CFRunLoopRun ()
#19	0x00007ff80113c112 in CFRunLoopRunSpecific ()
#20	0x00007ff80bb55a09 in RunCurrentEventLoopInMode ()
#21	0x00007ff80bb55646 in ReceiveNextEventCommon ()
#22	0x00007ff80bb55561 in _BlockUntilNextEventMatchingListInModeWithFilter ()
#23	0x00007ff8047acc61 in _DPSNextEvent ()
#24	0x00007ff8050c0dc0 in -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] ()
#25	0x00007ff80479e075 in -[NSApplication run] ()
#26	0x00007ff804771ff3 in NSApplicationMain ()
#27	0x00007ff90dc24557 in ___lldb_unnamed_symbol57096 ()
#28	0x00007ff90e31fe64 in ___lldb_unnamed_symbol104448 ()
#29	0x00007ff90e6e63ff in static SwiftUI.App.main() -> () ()
#30	0x000000010dfa5cce in static NSPasteboardItem_CrashApp.$main() ()
#31	0x000000010dfa5d69 in main at /Users/SadPanda/Documents/NSPasteboardItem Crash/NSPasteboardItem Crash/NSPasteboardItem_CrashApp.swift:11
#32	0x00007ff800cd5366 in start ()

Dispatch concurrent queue (default QoS):
#0	0x00007ff80111b45c in -[__NSSetM addObject:] ()
#1	0x00007ff80487692e in -[NSPasteboard _updateTypeCacheIfNeeded] ()
#2	0x00007ff8048763df in -[NSPasteboard _typesAtIndex:combinesItems:] ()
#3	0x00007ff804aa9597 in -[NSPasteboard _canRequestDataForType:index:usesPboardTypes:combinesItems:] ()
#4	0x00007ff804fdd161 in -[NSPasteboard _dataForType:index:usesPboardTypes:combinesItems:securityScoped:] ()
#5	0x00007ff804aa7c4b in -[NSPasteboardItem dataForType:] ()
#6	0x00007ff8055804af in -[NSFilePromiseReceiver receivePromisedFilesAtDestination:options:operationQueue:reader:] ()
#7	0x00007ff90e787b51 in ___lldb_unnamed_symbol131674 ()
#8	0x00007ff90e9bc340 in ___lldb_unnamed_symbol148147 ()
#9	0x00007ff8020d00ba in __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ ()
#10	0x00007ff8020cffb8 in -[NSBlockOperation main] ()
#11	0x00007ff8020cff4b in __NSOPERATION_IS_INVOKING_MAIN__ ()
#12	0x00007ff8020cf1ec in -[NSOperation start] ()
#13	0x00007ff8020cef0d in __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ ()
#14	0x00007ff8020cedde in __NSOQSchedule_f ()
#15	0x000000010e68ce7d in _dispatch_block_async_invoke2 ()
#16	0x000000010e67ca7b in _dispatch_client_callout ()
#17	0x000000010e67fa09 in _dispatch_continuation_pop ()
#18	0x000000010e67eae8 in _dispatch_async_redirect_invoke ()
#19	0x000000010e6906a9 in _dispatch_root_queue_drain ()
#20	0x000000010e6911ba in _dispatch_worker_thread2 ()
#21	0x000000010dfb832f in _pthread_wqthread ()
#22	0x000000010dfbebeb in start_wqthread ()

There doesn’t appear to be any workaround (short of not supporting drops at all!).

The more complicated the drop handler the more likely it is to promptly crash upon drop – in my real code with a non-trivial handler, it’s virtually guaranteed to crash on the second drop containing a file promise, while in the vastly reduced sample code (above) it can take dozens of drops before it finally crashes outright.

I have not directly tested whether this NSPasteboard bug occurs in the absence of SwiftUI, so I don’t strictly know if the root cause is in AppKit or SwiftUI. However, since most SwiftUI apps don’t support drag-and-drop, but plenty of AppKit ones do and manage to not crash when given the exact same test cases, I do strongly suspect SwiftUI is causing this somehow.

Follow-up (September 12th, 2024)

I actually received a response from Apple, from a real human (or at least a convincing AI). Ultimately their response didn’t help as it contained some mistakes, but I’m hopeful there’ll be more follow-up and a productive conclusion. And in the interim, they did assert a few things which are important to know, and are not otherwise documented by Apple:

• SwiftUI’s onDrop(of:isTargeted:perform:) method makes no claims or promises as to what thread / queue it executes the closure on, and in fact according to the anonymous Apple engineer it never executes the closure on the main thread.
  
  Now, while that may be the intent, the reality of that is wrong – in my experience it always executes the closure on the main thread (which makes a lot of sense to me as drag-and-drop event handling in AppKit has always been on the main thread in practice).
  
  Nonetheless, Apple says one cannot rely on the current behaviour and should in fact assume it never executes on the main thread (though in practice that means you have to check, not assume, since if you blindly do something like DispatchQueue.main.sync { … } in your drop handler your code will deadlock, today).
• NSPasteboard is not safe to use outside the main thread / queue.
  
  This isn’t documented anywhere public – not in NSPasteboard‘s documentation itself, nor the ancient Application Kit Framework Thread Safety documentation.
  
  I wouldn’t be surprised if it’s broadly true, as the AppKit APIs involving it always seemed main-thread centric anyway (all the handlers and delegate methods involving pasteboards are invoked on the main thread, in my experience). And it’s generally best to assume everything in AppKit is main-thread-only unless it’s explicitly documented otherwise.
  
  However, it’s important to note that Apple’s own code doesn’t follow this rule – e.g. NSFilePromiseReceiver, internally, uses NSPasteboard from the global concurrent queue.

Even though Apple’s initial response to this bug report hasn’t been all that fruitful, I do want to emphasise the fact that they did respond, which was a pleasant surprise and very much appreciated.

This AI behaviour would be merely eccentric if it didn’t cause major performance issues with the game.

For the case of too many science ships, the effect seems subtle – just a small, evenly-spread slow-down of the game. Probably not worth worrying about generally, though if you happen to notice an AI empire spamming science ships, it may be worth addressing.

For the case of too many construction ships, the effect is much more pronounced. Every AI construction ship triggers an expensive script periodically, and all aligned together in time, which can result in noticeable hangs every seven in-game days if there’s many of them.

And “too many” is a surprisingly small number – as few as ten can cause five-second-long hangs every seven in-game days, in my experience. I suspect their detrimental effect is superlinear to their number (because the AI having only a couple seems to incur no noticeable overhead). It’s likely also contingent on some other factor, that I have not yet identified, as the hangs only manifest themselves in some games.

I’m very thankful to Confident_Chance_770 for pinning the periodic hangs down to this cause.

Confirming the too-many-construction-ships diagnosis

Since this can be caused by a mere few construction ships – as little as four or five, which is not otherwise remarkable – one way to confirm this is the issue is to profile the game’s script execution:

1. Pause the game (e.g. hit the spacebar). Ideally a day or so before the next hang day, and clear of the first day of the in-game month.
2. Hit the backtick (`) key (top-left on most keyboard layouts, above tab and left of 1) to bring up the game’s debugger / cheat console.
3. Type “script_profiler” and hit return.
4. Unpause the game (e.g. close the console by hitting the backtick key again, then hit the spacebar).
5. Let the game run until one of the hang days is encountered. Note that the game will run slower than normal while profiling is enabled, especially on the hang days.
6. Pause the game.
7. Open the console again.
8. Type “script_profiler” again and hit return. This concludes the profiling and dumps the results to two files.
9. Open the summary results from ~/Documents/Paradox Interactive/Stellaris/logs/script_profiling_summary.log.
10. Check if “planet_possible.find_planet” is the topmost item and listed as consuming significant amounts of CPU time (e.g. 5s, for a single hang day). If it is, you’re likely experiencing the construction ship bug.
    
    If it’s not, it’s possible it’s still the same bug, but possibly not. You could try the usual diagnostic routine – e.g. websearch for the symptoms and top script names from the profile, contact the author of any suspicious or newly-added plug-ins you’re using, contact Paradox Interactive, etc.

Remedying the bugs

If you determine that it likely is the construction / science ship spam bug, you can rectify it via these steps:

1. Save your game. Just in case something goes wrong with this process.
2. Pause the game. This is very important – if you don’t, the AI is likely to complete screw with your empire while you’re away (during steps 4 through 6).
3. Open the console.
4. Type “play N” where N is an integer starting at one. Not all integers are used – just keep incrementing until you get a correct result, which is that it switches your control to one of the AI empires.
5. Close the console.
6. Check the civilian ships list to see if there are absurd numbers of science ships, or more than a couple of construction ships. If there are, kill them. Usually when this bug occurs most of the ships are together in one system, so you can accelerate this process by finding those big group(s) of construction & science ships, drag-selecting them within the system view, then hitting the Delete key (and return to confirm decommissioning). It’s pretty safe to just delete all the AI empire’s construction & science ships, since the AI can cheaply and quickly build new ones if they actually want them (in my experience they often don’t, at least not promptly, suggesting the ships were unnecessary to begin with).
   
   If there are not, go back to step 4 and try subsequent integers, to check other AI empires.
7. Once you’ve found and destroyed the offending ships, type “play 0” into the console to restore control to your own empire.
8. Unpause the game and continue playing – hopefully now without the noticeable hangs every seven in-game days.

Repeat as necessary when the problem recurs (and perhaps focus your in-game efforts on wiping out the offending AIs, as a more permanent solution).

However, I seem to have found a fairly reliable workaround:

1. If you’re directly plugging in a removable SSD, as your means of moving files between computers, then skip to step 2.
   
   Copy the catalog-to-be-imported, along with all the original files it references, to local storage on the target computer. You must preserve their relative paths, so it’s easiest if you pre-arrange your source catalog’s files (the “.lrcat” file and its entourage) to be in the same root folder as your original files (images etc)¹.
   
   Any attempt to import directly from a network drive will fail, always.
   
   All the following steps are performed on the target computer.
2. Open the catalog-to-be-imported in Lightroom on the target computer.
   
   This will automatically close whatever other catalog you have open, first.
3. Choose “Export as catalog…” from the File menu.
4. Adjust settings to suit, and export to a new catalog.
   
   Note that this will duplicate all the files referenced by the catalog, into the new catalog. So it might take a while even though it’s all localised to the one computer (and even if it’s on the same volume – Lightroom is not smart enough to perform APFS COW clones).
5. Open the target catalog.
6. Import the catalog you just exported (“Import from Another Catalog…” in the File menu). Make sure to choose to copy the files to a new destination, not just reference them.
7. Delete the temporary catalog.

In my experience you must perform the export-to-an-otherwise-pointless-new-catalog after copying everything to the target computer. Somehow, something about copying Lightroom’s files from one computer to another [over a network] “breaks” them such that Lightroom will refuse to import them.

1. You can do this by – on the source computer – selecting all the photos in the catalog and using the “Folders” subsection of the left panel to adjust their location on disk. Typically by selecting an existing location, right-clicking, and selecting “Move Selected Photos to this Folder”. If necessary, you can first add the desired location by clicking the ‘plus’ icon to the right of the “Folders” section header, and choosing “Add Folder…”.
   
   Yes, Lightroom’s file management UI is a pain in the arse, and badly designed. ↩︎

1234.formatted(.byteCount(style: .decimal))

This is just a small subset of Swift’s FormatStyle-based formatting capabilities, with which I have a bit of a love-hate relationship even when they’re working correctly.

Alas, they don’t always work correctly; some of these formatters contain egregious bugs.

In particular, ByteCountFormatStyle pretends to support multiple numeric bases – decimal and binary – but it doesn’t, because what it renders for binary is:

1234.formatted(.byteCount(style: .binary))

Note how it still uses decimal units, “kB”. Decimal is not binary. I mean, duh, right? But apparently Apple don’t know this.

So what?

While the above example is tolerable because, given the rounding applied, the numeric result (“1”) is technically corrected in both bases, see what happens when you use larger values:

Once you get up to non-trivial byte counts, you start to get different results even with the heavy rounding that’s applied by default. By the time you’re talking about GBs the error is on the order of 10%. And the error just gets proportionately larger as the input number increases. Wikipedia has a neat little table showing this.

Okay, but that’s just binary, what about file and memory?

Those are just aliases to decimal and binary, respectively. So memory is right out.

You might think file is still okay, because it essentially means decimal. But that’s only currently. The entire point of its existence is to allow its behaviour to change over time, following whatever convention Apple believes is most appropriate for files. In the past that was in fact binary, as noted previously (pre-Snow Leopard). It might be binary again in future. So it’s dangerous to use since you can neither know what units it’s going to use nor whether Apple will have fixed their formatters by the time it switches off of decimal.

But context will save us!

Probably not. Go look at file sizes in the macOS Finder. Can you tell whether they’re actual decimal (as they appear) or binary?

They’re decimal, but they used to be binary, up until Mac OS X Snow Leopard (10.6). And the Finder used the same (decimal) unit abbreviations throughout. So at least it’s using the correct units now – almost by accident – but it created a confused transition and history.

Worse and more presently pertinent, not everything Finder-like uses decimal, nor correct units when they don’t. e.g. Synology’s products, not to mention countless websites. That creates a lot of confusion which bleeds across into even well-behaved software.

Point being, you both can’t rely on context to help, because context includes things you can’t control like other software, and by getting the units wrong you’re making it worse for everyone, not just yourself.

Why is this still happening?

Going back twenty years, this kind of error – confusing decimal with binary w.r.t. unit prefixes – was both the norm and somewhat excusable – binary prefixes were only formally standardised upon in 1999, so it’s only to be expected that it will take some time for everyone to adopt them.

But it’s been a quarter of a century already. There is absolutely no excuse anymore for getting this wrong.

1. If you’re paying attention you’ll have noticed “k” vs “K”, i.e. the difference in case. This is not arbitrary – it’s because units have to be distinct to be functional, and “K” is the abbreviation for Kelvin (and apparently wins because it’s one of the seven base physical units, from which pretty much all other physical units are derived).
   
   “Ki” is fine because it’s a distinct prefix (and “i” is not a valid abbreviation by itself so there’s no potential confusion about whether it means “Kelvin • i” or “kibi”). ↩︎

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?")
}

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.")
}

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?")
}

Well, shit.

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!")
}

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("😤")
}

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")
}

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.

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:

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¡")
}

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]))

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.

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<String>, 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.")
}

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?")
}

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?")
}

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?")
}

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.")
}

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

1. 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. ↩︎
2. 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. ↩︎

Long story short, on at least some bitmap images, as soon as you call getBitmapDataPlanes it somehow permanently breaks that NSImage and NSBitmapImageRep. The telltale sign of this – aside from the image rendering incorrectly – is the stderr message from AppKit:

Failed to extract pixel data from NSBitmapImageRep. Error: -21778

This definitely occurs with 10-bit AVIFs, but it’s not limited to that bit depth nor that file format, because I found the one other mention of this error message online, where the source image was 1-bit.

I’ve never seen this happen with 8-bit, 12-bit, or 16-bit images, AVIF or otherwise.

This makes me suspect it’s tied to the internal pixel format – 10-bit AVIFs always load as 10 / 40 (bits per sample / bits per pixel), irrespective of whether they have an alpha channel. 8-bit AVIFs are always 8 / 32, 12-bit are always 12 / 48. Maybe NSBitmapImageRep has a bug when the bits per pixel isn’t a multiple of 16?

If you call bitmapData instead you get the same error message but it does not stop the NSImage / NSBitmapImageRep from rendering correctly. But the pointer returned from bitmapData points to opaque black. It’s particularly weird that it returns a pointer to a valid memory allocation, of at least the expected size, yet the contents are nothing but zeroes. Seems like it pre-allocates some output buffer, as zeroed memory, and then fails to actually write to that buffer. Yet it returns it anyway, instead of returning nil. 😕

FB13693411.

Partial workaround

If you call recache on the NSImage afterwards, the image is capable of rendering correctly again. That doesn’t help if your objective is to access the bitmap bytes, but at least if you don’t – e.g. you’re encountering this only because some library code is triggering the bug – you might be able to work around it through recache.

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.

👾 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld -v
@(#)PROGRAM:ld PROJECT:ld-1053.12
BUILD 15:44:24 Feb  3 2024
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.3.2.2)

👾 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld-classic -v
@(#)PROGRAM:ld-classic  PROJECT:ld64-951.9
BUILD 15:44:42 Feb  3 2024
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.3.2.2)

Apple’s new linker appears to be much more pedantic than the old one – it warns about a lot of things that the old one didn’t care about. One of these is missing platform load commands:

/Users/SadPanda/Documents/vmaf/libvmaf/ld:1:1: no platform load command found in 'src/libvmaf.a[62](cpuid.obj)', assuming: macOS

This doesn’t technically break anything – assuming it guessed the platform correctly, which I suspect it just takes as being the host’s platform – but it’s super annoying because it’s emitted for every afflicted object file the linker sees (that’s individual files, even if they’re buried in archive files – e.g. libfoo.a). You can have hundreds or even thousands of these warnings for a single library. Worse, they’re emitted when you link against the library, not just when you build it. And with nested static libraries they can propagate up a build chain endlessly.

If we look at the offending file with otool, we see that indeed it has no platform load command:

👾 otool -vl cpuid.obj
Load command 0
      cmd LC_SEGMENT_64
  cmdsize 152
  segname 
   vmaddr 0x0000000000000000
   vmsize 0x000000000000002d
  fileoff 208
 filesize 45
  maxprot rwx
 initprot rwx
   nsects 1
    flags (none)
Section
  sectname __text
   segname __TEXT
      addr 0x0000000000000000
      size 0x000000000000002d
    offset 208
     align 2^4 (16)
    reloff 0
    nreloc 0
      type S_REGULAR
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS
 reserved1 0
 reserved2 0
Load command 1
     cmd LC_SYMTAB
 cmdsize 24
  symoff 256
   nsyms 4
  stroff 320
 strsize 56

For reference, here’s an example of the load command it’s looking for:

Load command 1
      cmd LC_BUILD_VERSION
  cmdsize 24
 platform MACOS
    minos 14.2
      sdk 14.4
   ntools 0

Why is it missing?

There’s likely many reasons for this, but they all come down to the same general reason: something is wrong with one [or more] of the tools in the toolchain that created the object file. All object files should contain this load command, on Apple platforms. Though the linker currently treats it as optional, the warning is likely a hint from Apple that it may become required in future. More importantly, without it the linker cannot know which SDK the file is compatible with, and therefore cannot validate that it’s linking the right things.

In the example case above, the problem tool is nasm. It’s an open-source, non-Apple x86-family assembler. It’s been around for nearly thirty years – its first platform was DOS. Though it supports Apple’s platforms, it is predominately focused on Linux & Windows. So it’s not entirely surprising that it’s causing issues.

It also hasn’t released even a minor patch update since 2022 (with version 2.16.01), so nominally it predates and doesn’t support Xcode 15 (announced & released mid-2023).

However, the absence of the LC_BUILD_VERSION command was in fact a problem even before the new Apple linker in Xcode 15, because of cross-compiling (e.g. targeting the iOS simulator on a Mac). There was even a patch to address the problem, submitted by Byoungchan Lee way back in 2021, which was never accepted (it seems to have been completely ignored – not even a response on the mailing list).

Workarounds?

No good ones, that I can find. Stoically ignoring the warning for now is probably the best option.

It is still possible (in Xcode 15, at least) to switch to using the old linker instead, using the -Wl,-ld_classic flags, although that’s not a long-term solution and may have downsides (e.g. some folks report significantly smaller object files with the new linker).

It’s probably possible to manually insert the missing load command – if your build process is amenable to that – although it’s not apparent to me what tool or command invocation you would use to do that. Possibly ld itself, though its documentation provides no insight into this.

For some projects, you might be able to switch to a different assembler (e.g. Apple’s native as from Clang, or Yasm, etc). Apple’s toolchains don’t have this problem (so far as I’ve seen) but are of course not available on other platforms (though, being based on Clang, you can probably get essentially the same thing direct from Clang). I haven’t tested whether Yasm has the issue.

Sometime during each day I get a follow-up notification telling me that Private Relay is now active. Even though by all appearances it already was.

This is frustrating on multiple levels – obviously there’s the question of why this notification is appearing to begin with, and lying¹ about the support status of Private Relay, but it’s also concerning that it’s sending mixed messages about whether Private Relay is working or not.

1. I mean, I assume it’s lying about the status – I suppose it’s possible that Apple, headquartered in the San Francisco bay area, might have revoked support for Private Relay in their own region. Seems like an odd decision, though. ↩︎

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.

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.

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<Game.House, Swift.Array<Game.Floor>>' (0x12e00cc98) to 'Swift.ReferenceWritableKeyPath<Game.House, Swift.Array<Floor.Region>>' (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. 🤞

According to man 3 getifaddrs:

The ifa_dstaddr field references the destination address on a P2P interface, if one exists, otherwise it contains the broadcast address.

In my testing the ifa_dstaddr field is never non-null. I’m not sure I have any suitably configured P2P interfaces, but I definitely have interfaces with broadcast capabilities and getifaddrs reports them as having no broadcast address (even though it correctly notes they support broadcasting, in ifa_flags).

This is on macOS Ventura 13.3.1. I have no idea if this applies to other versions of macOS, or other OS’s.

It appears there’s a workaround, though – the broadcast address is deterministic based on the IP address & netmask, according to Wikipedia, so you don’t technically need getifaddrs to spell it out for you. That’s for AF_INET (IPv4) networks. IPv6 doesn’t really have the same notion of a broadcast address anyway, and for other network types I have no idea if the concept applies or if there’s workarounds for this getifaddr bug.

Some netmasks returned by getifaddrs have family of AF_INET yet a length less than sizeof(sockaddr_in), e.g. 5, 6, 7, or 8. On macOS Ventura 13.3.1, at least.

It looks like it’s actually allocating only eight bytes for the ifa_netmask (not the 16 that is the size of sockaddr_in per MacOSX13.3.sdk/usr/include/netinet/in.h), as it clearly has a different sockaddr_in immediately after it, e.g.:

sockaddr
  - sa_len : 5
  - sa_family : 2
  ▿ sa_data : 14 elements
    - .0 : 0
    - .1 : 0
    - .2 : 255
    - .3 : 0
    - .4 : 0
    - .5 : 0
    - .6 : 16 // This is obviously the start of the next sockaddr_in; a correct entry with length of 16.
    - .7 : 2
    - .8 : 0
    - .9 : 0
    - .10 : 127
    - .11 : 0
    - .12 : 0
    - .13 : 1

It’s thus clear that it’s both wrong about the actual length in memory and it is indeed truncating the sockaddr_in structure, although it looks like it’s actually including the full address (the lo0 netmask in the above example is indeed 255.0.0.0).

Here’s another example, where the netmask is 255.255.255.0:

▿ sockaddr
  - sa_len : 7
  - sa_family : 2
  ▿ sa_data : 14 elements
    - .0 : 0
    - .1 : 0
    - .2 : 255
    - .3 : 255
    - .4 : 255
    - .5 : 0
    - .6 : 16 // Again, clearly the start of the next sockaddr_in.
    - .7 : 2
    - .8 : 0
    - .9 : 0
    - .10 : 192
    - .11 : 168
    - .12 : 0
    - .13 : 24

So you can see it’s:

• Only allocating up to the address of sockaddr_in, not counting the padding (so sizeof(sockaddr_in), MemoryLayout<sockaddr_in>.size, etc disagree with what getifaddrs is doing), and
• Weirdly truncating the stated length (sin_len) to the end of the non-zero bytes in the netmask.

This is undocumented (well, all these data structures are completely undocumented 😔) and is all very messy. getifaddrs should just provide the full sockaddr_in without any of this weirdness, so that users which blindly cast to sockaddr_in (without checking sin_len) don’t risk segmentation faults or reading corrupt data.

I have no idea why it does this only for ifa_netmask, not ifa_addr or ifa_dstaddr. That discrepancy just makes it even more troublesome.

As far as I can tell there are no similar issues with AF_INET6 netmasks, although without knowing under what criteria it’s truncating, I can’t be sure I have all relevant examples covered on the happenstance networks of my laptop.

For these systems, there’s seemingly not much you can do… it seems you have to hard-code the assumption that ifa_netmask contains exactly & only the first eight bytes of the sockaddr_in. You have to completely ignore sin_len (at least if it’s less than eight).

A major reason I purchased an Apple Watch Ultra was for its loudly advertised ability to function as a dive computer, much like some Garmins.

It’s been a rough and disappointing road.

Right out of the gate, it didn’t work. It requires a 3rd-party application, Oceanic+, which didn’t exist at Apple Watch Ultra release time. It was over two months before Oceanic+ was finally released, on November 28th.

As it happens, my dive trip plans were delayed a bit anyway, resulting in my first dive [since purchasing the Apple Watch Ultra] being on that exact day. Hallelujah, I thought. I was able to hastily install the app in the morning, before leaving for a remote, internet-less island for a week.

But then there was the surprise that it basically requires an expensive subscription ($80/year, or even more if you commit to less than a whole year). Without it you don’t get tissue load and NDL tracking – critical functions of a dive computer. I was not aware before purchase, from any of the Apple Watch Ultra advertising or product pages on Apple’s website, that this subscription would be required. It feels surprisingly shifty and dishonest from a company like Apple.

Arguably the above frustrations (and costs) could be overlooked if it actually worked well. Unfortunately, it does not.

I discovered serious flaws with Oceanic+ right from the first dive. Flaws that any qualified diver would immediately recognise, which begs the question of why Apple & Oceanic+ somehow haven’t.

There are two major design flaws in its most basic function, the recording of dives:

1. It doesn’t start recording automatically.
   
   You have to hit the “Action” button to acknowledge a lawyer-smelling disclaimer that you’re “fit to dive”. If you forget, it doesn’t record.
   
   I’m not aware of any other dive computer that does this. e.g. my Shearwater Peregrine autodetects submersion below one metre even if it’s not on. It turns itself on and starts recording automatically.
2. If you ascend above one metre, even just for a split second, it immediately ends recording.
   
   This makes shore entries, in particular, likely to go unrecorded (unless you’re able to swim out to deep water and descend rapidly, which isn’t always an option or the best dive plan). Descents in significant swell, currents, or surge could also fall victim to this design flaw.
   
   So on my first dive I got five “dives” recorded, representing the four times where the swell floated me up to just above one metre (I never actually broke the surface). Even just reaching up momentarily with your watch hand, such as to grab a line or brush away a fin, could trigger it to fail.
   
   Furthermore, there’s no way to merge these together in Oceanic+ – you can either keep them, messing up your dive counts and stats, or delete them, throwing away [parts of] actual dive records.
   
   And on later dives I didn’t always notice it had failed and stopped recording, so it basically didn’t record the dive at all. This will be less of an issue if you’re using it as your only computer, since you’ll be looking at it periodically throughout your dive (I was using a separate dive computer as my primary, since I wisely didn’t trust the Apple Watch Ultra untested).
   
   Again, I’m not aware of any other dive computer that has this flaw. e.g. my Peregrine allows a sixty second grace period before ending the dive (configurable for up to ten minutes).

These two combine to make it unsafe for diving. It might be better than nothing, or acceptable as a backup computer (as long as you’re religious about ensuring it’s recording all the time), but it’s arguably worse than no dive computer at all in that it provides a false sense of security – you might plan many dives in one day, relying on the Apple Watch Ultra to precisely track your tissue loading, but have it fail midway and leave you with a dangerous decision to make.

What makes this all the more frustrating is that there’s a lot of things to like about it otherwise:

• The Apple Watch Ultra screen is so much better than what you find on most dive watches – clear and readable, with relatively low glare, even in harsh daylight. Not to mention that it’s a touch screen, so [when dry, on the surface] it’s faster to change your settings, review your dive log, etc.
• The Apple Watch Ultra is a lot smaller than most dive computers. Even those that are nominally intended to dual-purpose as watches.
• The information display during diving is well-designed and user-friendly (certainly not as powerful as what you can get on other dive computers, but quite sufficient for basic recreational diving).

• The iPhone integration is smoother and easier than with other dive computers – dives appear on your phone automatically (albeit sometimes after a short delay).
• It records the geographic location of the dive, which many dive computers do not.
• Its configurable alerts – e.g. for depth, dive duration, etc – are nice and clear when they trigger underwater, with a clear and prominent visual display and strong vibration. I find that its alert vibration is much more likely to actually get my attention than that of my Peregrine.

It feels like it’s actually close to being a pretty good dive computer & companion app, if not for a handful of bizarrely obvious, serious flaws.

It feels, in fact, like it was very rushed – from the obviously daft design flaws noted above, to even just simple things like bad grammar, poor alignment, and broken layout in the GUI (it smells like they’re using SwiftUI and haven’t figure out how to work around all its layout problems). It seems they put more time into their slick website than their actual product.

And of course there’s the other hint that maybe real-world testing was skipped – the fact that the iOS Oceanic+ app crashes on launch if you don’t have a good internet connection. On a boat, far from land? Or a remote island? Or in Airplane mode? Or just in an area with poor internet connectivity? No app for you. Crash on launch, every time. Forget about entering your dive details into the log while you actually remember them.

This remains the case even after six app updates over a month. Apparently Oceanic+ either don’t care that their app usually crashes on launch, or are incapable of fixing it.

Maybe there’s hope that in time they’ll be able to straighten all this out. But until then, I cannot in good conscience recommend the Apple Watch Ultra for diving. (it remains a fantastic watch for health-tracking and hiking, though)

For completeness, a list of other miscellaneous flaws and limitations:

• Any time you ascend past six metres, it throws up an alert about a safety stop. Which keeps buzzing at you forever, until you hit the action button. It’s hard to overstate how annoying this is when doing shallow dives. It is super distracting and may put you in harms way (e.g. if you’re constantly having to fiddle with the Apple Watch Ultra instead of paying attention to the reef around you).
  
  I simply can’t fathom why they feel the need to alert for this at all. An alert would be warranted for skipping your safety stop, yet it doesn’t do that.
• It vibrates the Apple Watch Ultra frequently without any indication why (nothing changes on the display). Observationally, I suspect it’s something to do with ascending “too fast”, but if so then it’s way too sensitive to small depth changes – it vibrates at me when simply ascending less than a metre (even when tens of metres deep, where a metre makes very little difference in pressure).
  
  Overall, the Apple Watch Ultra is too chatty. It’s a classic boy-who-cried wolf problem waiting to happen.
• It doesn’t show CNS, current PPO₂, [surface] GF, etc. Especially when using enriched air (Nitrox), nearing no-decompression limits, or deep diving, these are important for safety. They are purely software features so it’s especially odd that they’re not included.
  
  Surface GF is arguably the most important of these – it basically tells you how dangerous it is to surface immediately. When everything goes smoothly – and assuming you’re planning safe, conservative dives – you don’t need to worry much about it. But when things go awry it can be critical in helping you make the right decision under pressure.
• There’s no Oceanic+ Mac app, or even a web version, which strongly discourages actually using Oceanic+ as your full dive log. Entering all the details of your dive – gear, notes, etc – is very tedious on an iPhone.
  
  Some other dive computer manufacturers do have Mac apps (e.g. Shearwater, albeit one that’s clearly made in some janky cross-platform framework and looks like something you’d find in X11 in the 90s), and there are a few viable 3rd party options (e.g. MacDive, Subsurface).
• The map it shows, of your entry & exit points, is useless most of the time, because it just shows as flat blue (for water) with no identifying geography. There’s no way to switch it to anything useful, like a satellite view that would actually reveal the reefs, sand bars, atolls, etc.
  
  This is exacerbated by Apple Maps’ limitations. Google Maps, for example, often does show atolls & islands at least, and other surface features. Apple Maps simply lacks actual maps for most of the world’s oceans.

• The iOS Oceanic+ app lets you record what gear you were using, but bizarrely requires you to pick from a pre-defined list and that list is missing gear from major brands (e.g. Aqua Lung, Cressi). Another reason why it won’t be your real dive log.
• There’s no way to import or export dive data. This is both a lock-in concern – your dive data will be deleted if you end your subscription – and also a roadblock to using the Oceanic+ app as your real dive log, unless you have never and will never dive without an Apple Watch Ultra.
• You can’t change the activity type – dive vs snorkelling – underwater, nor after the fact. So if you forget to change it before going for a snorkel, you’ll forever have a bogus “dive” in your log (or you can delete the record entirely, but then you lose record of any free diving you do).
• There’s five entries in the main menu in the Oceanic+ watch app, which are arranged as a scrolling carousel… which is just weird and annoying since they’d fit all on one screen as simple buttons, which would make navigation much faster and easier.
• A lot of actions on the Oceanic+ watch app require more steps than seem necessary. e.g. changing numeric values requires not just selecting a different value but also tapping back to the previous screen (which also feels unnatural, like I’m backing out of the change without applying it). There are menus trees five or more levels deep, whereas it seems like they could be flattened into just two or three levels.

• Relatedly, you can’t edit any of your settings on your iPhone, only the watch. You can view the settings on the iPhone, which just makes it even more baffling why you can’t edit them there. Editing them on the watch is great in a pinch – you might not have your phone with you – but it’s a pain compared to on an iPhone.
• The Oceanic+ iPhone app “Home” screen – what’s displayed when you launch the app – just shows a handful of stats of dubious merit. Minimum temperature over the last four weeks? Who cares. Cumulative total max depth? That clearly has no purpose. It seems like they knew they needed to show the most basic numbers – total dive count and duration – and felt compelled to stuff in a bunch more numbers for some reason. It’s also unclear why they think these are more important than your actual dive logs, or the dive planner.

• There’s supposedly seven watch complications available once you have Oceanic+ installed, but on my watch only two are available (“Max altitude” and “Oceanic Launcher”). This might be because I use a digital time display (the “Modular” face), something Apple seems to hate.
• The battery life is surprisingly short – about five hours of dive time. Given that the Apple Watch Ultra can record workarounds that are 16 hours long (at least – longer if you use energy-saving features), it’s a bit of a mystery to me why it chews through the battery so fast while diving. It’s not even monitoring your heart rate or other health metrics – just water pressure – and the screen brightness tends to be low since you’re underwater in low light.

Here’s a few things which are more just wishlist items (or: things you can get from some other dive computers, though you usually pay a lot more for those than you do an Apple Watch Ultra):

• Gas usage recording. Upmarket dive computers support wireless communication with a dongle that attaches to your first stage regulator. This means you can forgo a whole separate hose and dangly, annoying air gauge, and have a unified view of your dive status. It also means you get more accurate tracking of tissue loading, and more advanced functionality like gas consumption rates (great for extra safety – know if you’re going to run out of air too early – and for optimising your gas consumption over time).
  
  Radio protocols like Bluetooth don’t work underwater – lower frequencies are required. So the Apple Watch Ultra would require an additional built-in antenna. It’s arguably reasonable to omit this in a watch that’s not intended solely for diving, given the cost or other trade-offs it might require.
  
  That said, some air-integrated dive computers use sound instead of electromagnetism, and I suspect it’s not hard to support the necessary, inaudible frequencies in the Apple Watch Ultra’s microphone(s). Maybe this support is already present in hardware, and a transmitter dongle will be released later?
• Multi-gas support. Most dive computers support this, even those that are much cheaper than an Apple Watch Ultra. This is arguably a more “serious” or “technical” feature, that most recreational divers won’t ever need, but it’s also easy to do – it’s purely a software feature.
• The ability to enter key dive details on the Apple Watch Ultra (as opposed to an iPhone), such as gas start & end pressures. It’s all too easy to forget these in-between the dive itself and when you get back to land and your iPhone.
• The dive planner functionality is pretty rudimentary. e.g. you can’t do anything like actually enter a dive depth profile (whether as a squiggle with your finger, to give the rough idea, or importing it from a previous dive at the same site). The GUI is also a bit obtuse, especially in the Oceanic+ iOS app, as rather than showing a simple table or chart of depth vs no-deco times it makes you pick a single depth and gives you a single no-deco time. For planning you often want to consider multiple depth options and pick the right trade-off against dive (or at least bottom) duration.
• It might actually be nice to have some “social” functionality. Not for bragging and other vanity purposes – I’m not talking about inane integrations with Facebook or whatever – but for sharing amongst dive buddies and the like. I suspect there’s some neat, innovative possibilities here (e.g. automatically detect physically- & temporally-nearby dive friends, and be able to automagically see their photos & notes on what they saw on what’s presumably the same dive with you – maybe even add your own notes on theirs like “don’t forget about that Whale Shark eating that Orca!”).

And lastly just some miscellanea:

• Apple / Oceanic say that it won’t record below forty metres, but it does. Thankfully – the last thing you want if you do a deep dive, intentionally or especially unintentionally, is for your dive computer to not record your dive profile correctly.

I don’t regret getting my Apple Watch Ultra – it’s proven a worthwhile upgrade even just for its other features like battery life and a relatively large screen – but I am sad that I can’t actually rely on it for diving. And that I had to spend a lot of extra money to get a dive computer – the Peregrine – that I can rely on.

For reference, I’ve completed about fifty dives with the Apple Watch Ultra.

Addendum (May 2023)

I’ve now had the Apple Watch Ultra accompany me on about 150 dives. Sadly, despite it being a long six months later, little has changed. The Oceanic+ app is still awkward and very rudimentary, with the same data and platform lock-in problems. The Apple Watch component is almost unchanged – same limitations and GUI frustrations.

Two things which did improve at some point:

• Recording now happens when submerged even if you haven’t clicked through the lawyer screen. This is a significant safety improvement.
  
  However, if you go the entire dive and return to the surface without clicking through the lawyer screen, the recording is discarded. So there’s still danger here. You just get (a lot) more time to realise the watch is being obstinate (and you really should be looking at your Apple Watch Ultra at least once during the whole dive anyway, even if it’s just your backup, to ensure it’s working and to check its data against your primary).
• The Oceanic+ app seems to have fixed many of the glaring GUI bugs – e.g. the charts that rendered in the wrong places on the screen (or not at all), inconsistent font sizes and baselines, etc.

I haven’t systematically re-reviewed the Oceanic+ app, so perhaps there’s been additional fixes or improvements too. I’ve barely used it since my initial review, since I can only rely on my primary dive computer (Shearwater Peregrine) anyway. For what it’s worth, I use MacDive on my iPhone & Mac and am reasonably happy with it.

I wish I’d just bought the Shearwater Teric, though – the Peregrine was me hedging my bets and hoping that the Apple Watch Ultra would prove sufficient alone. The Peregrine is good but the Teric is much nicer (and for clear reason by far the most popular dive computer on the six boats I’ve dived from).

However, Final Cut Pro has a design flaw which causes data loss. You see, Final Cut Pro never merely copies the files. It extracts their audiovisual contents and puts it into a new file. You might have noticed this already from the fact that Final Cut Pro’s copied version of the files is always a MOV container, whereas your inputs are more likely an MP4 container.

This would be annoying enough in itself – it means you can’t do simple bitwise comparisons of the files to e.g. ensure the imported copy is actually valid and not corrupt, before you erase the original from your memory card. But it gets worse.

Final Cut Pro doesn’t copy all the contents. It only copies some types of tracks – i.e. audio, video, and timestamp tracks. It does not copy tracks such as GoPro’s metadata track (GPMD). Final Cut Pro just silently discards those.

Those tracks can contain important information. GPMD tracks, for example, contain a whole host of telemetry from the GoPro including its location during recording, rotation & movement data, and much more. Even if you think you don’t care about things like geotagging, consider this: that rotation & movement data can be used to enhance image stabilisation. By losing the data at import, you’re losing the ability to ever utilise that enhanced image stabilisation.

So never let Final Cut Pro “copy” your files – always copy them yourself first, as needed, and then import them into Final Cut Pro by reference only (the “Leave files in place” option). Thankfully Final Cut Pro doesn’t mangle the files when you use them that way (underlining the question: why does it force a lossy conversion to MOV to begin with, since it clearly works just fine with MP4 originals).

Otherwise, it refuses to function – showing a “Shutter release disabled. Recharge battery” message in the viewfinder for a second or two before turning itself off again.

I know of no technical reason why this has to be. And it’s contrary to Nikon’s documentation.

(it also refuses to show this message on the LCD, just like for the 24-70/4 error message about extending the lens, making it challenging to figure out why the camera’s not functioning correctly)

I don’t know how much charge the battery needs before it will allow the camera to operate on USB power, but it’s more than one minute of charging and ≤20% charge (my two current data points).

This is pretty annoying. If I leave the camera on accidentally, as I did yesterday, then even on a fully charged battery it’ll be flat within eight hours or so. So it’s not actually uncommon to pick it up and realise it’s dead flat. And in that situation it’s a complete paperweight for some unspecified amount of time, until you’ve managed to trickle enough juice into the battery.

Just now I was reviewing some and was surprised to realise there were no GPS coordinates. In any from that day. Where I was outdoors for hours in a flat grass field.

I then discovered that none of my photos from the Z9 have included their geolocation for a couple of weeks.

Lo and behold, in the settings on the Z9 I now find that recording location data is turned off. I did not turn it off.

I don’t have much idea how it could have turned itself off. About the only thing I can think of is that it might relate to configuring or switching between setting banks. That’s the only thing I can think of that might coincide timing-wise.

In any case, there’s no valid reason for it to have disabled itself. Rather frustrating.

As far as I can tell no other settings have been reset or otherwise modified from what I set them to.

It’s a long shot, but if anyone else sees this behaviour in their Z9 (or knows why it happens), please do leave a comment.

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”.

Sorry, we are unable to accept reviews for this product. This product has limitations on submitting reviews. There can be a number of reasons for this, including unusual reviewing activity.

Hmmm… curious.  I tried revising my star rating from 2 to 5 to see if it were so blatantly influenced by that, but it did not make a difference.

Anyway, FWIW here’s my review:

First up, the Blink XT cameras do not work with normal batteries – you have to buy quite expensive Lithium batteries.  Use of any other types of AAs will result in the camera not triggering reliably, failing to record full videos (or at all), etc.  So factor in about $20 extra per camera for a pair of such batteries.  Also, the two year quoted battery life appears to be a joke – I had to replace the first set of batteries after only a month or so.

Second, the video quality is not great.  They’re ostensibly 1080p but it looks both upscaled (probably from 720p) and it appears the video is recorded on the sync dongle, not the camera itself, so it’s subject to any radio interference issues that might exist, which will result in noticeably degraded video quality – or recording corrupting or cutting out entirely.  Overall the video quality, even in the best case, is like that of a very cheap smartphone (as of 2018), or say a 2010 iPhone.

Third, the only way to remotely control the cameras, and view recorded videos, is via mobile apps.  No desktop apps, no website, nothing.  So it’s very tedious to view the recordings, manage them, etc.

Fourth, the mobile app for iOS is not great.  It’s very slow – Cloud-saved videos are never loaded in advance, only on demand, and can take up to a minute to start playing.  It’s also a bit buggy.  e.g. a lot of the time it’ll fail to do whatever you asked, responding instead with a long delay ended with an error message along the lines of “the camera is busy”.

Fifth, wireless range is limited – I have one camera only about ten metres from both my wireless router & the sync module, through one exterior wall, and the video quality is noticeably degraded sometimes.  I tried placing one camera with line of sight about 30 metres away, and it worked (barely) for an hour or two and then never again, until I moved it much closer.

Sixth, motion triggering is inconsistent and lacks important configuration options (like zoning to denote areas to ignore or conversely to focus on).  e.g. for one video looking out the front of my place, it unavoidably has the street in view, which means that even on minimal sensitivity, we get a video & notification every single time a car goes by on the street.  Yet it still won’t reliably trigger when a human walks up to the front door, until they’re right in front of the camera.  Yet it’s nonetheless sometimes triggered by squirrels up to 10 metres away.

So, solidly not recommended.  Not the worst thing ever – the system does function in a very minimal sense, and I’ve managed to get some utility out of it, but it’s definitely disappointing – and many of these errors could surely be easily fixed by better software, firmware, or hardware design (e.g. support for normal batteries).

50mm F1.4 DG HSM | Art:  When starting to shoot with the subject completely out of focus, the response to the AF operation is intermittent. It is necessary to release several times or to turn the focus ring once to release. It is planned to be resolved by a firmware update.

I have seen what might be that issue, but I’ve also seen the same symptoms with the kit 24-70/4, and Nikon’s own F-mount lenses, so, I’m curious what the distinction is between the Nikon Z7’s general autofocus issue of this nature, and this specific issue that’s supposedly only applicable to the Sigma 50/1.4 Art.