For the price of one Apple Pro Display XDR you can get four Asus ProArt 6k displays.

I suspect there’s only three 6k panel models in existence – the one used by Apple, the AUO one used by Asus², and the LG one used by LG, Dell, & Kuycon.

It’s strange to me that Dell haven’t dropped the price of their 6k display given that LG are offering the same panel in a much svelter package for 15% less (and you can get the very similar Asus display for 45% less!).

1. Apple don’t appear to have ever published a brightness spec for the original Retina iMac, but Tom’s Guide measured their review model at 382 lumens.
   
   The comparison to the original Retina iMac is apt because it was the first of the retina [desktop] displays, of which these 6k displays are all members. It also had the exact same pixel density – 218 PPI – as the Apple and Asus displays – i.e. each individual pixel is the exact same size – so it’s a very fair point of comparison despite the overall differences in resolution. ↩︎
2. Speculation is that the Asus uses an AUO panel (the same one that’s popular with Chinese display manufacturers, because it’s very cheap). I wouldn’t normally give this much weight, except it is interesting that both the Asus and the Chinese displays are frequently reported as making an annoying whining noise at certain brightness levels, and have identical panel specifications, and were released at similar times (notably, many years after the Pro Display XDR). ↩︎
3. This is what LG states in the monitor’s specifications. Yet, LG also states that this monitor is DisplayHDR 600 certified, which means it’s required to have a static contrast ratio of at least 8,000 : 1. ↩︎
4. As with the LG, Dell states a 2,000 : 1 contrast ratio even though DisplayHDR 600 conformance requires at least 8,000 : 1. ↩︎
5. Asus states a 1,500 : 1 contrast ratio even though DisplayHDR 600 conformance requires at least 8,000 : 1. Though they also describe the 1,500 : 1 as “typical” while also listing 3,000 : 1 as the maximum. ↩︎
6. LG says “typical” brightness is 450, with minimum being 360, without explaining the difference – e.g. whether that’s for a white patch vs full-screen white, or perhaps depending on ambient temperature. I’m choosing to be generous and assume it’s merely a temperature thing, and not likely to be a concern in a typical indoor environment, because 360 is ridiculously dim. ↩︎
7. LG don’t explicitly state this, but it’s a requirement of the DisplayHDR 600 conformance. ↩︎
8. Dell don’t explicitly state this, but it’s a requirement of the DisplayHDR 600 conformance. ↩︎
9. Asus don’t explicitly state this, but it’s a requirement of the DisplayHDR 600 conformance. ↩︎
10. Apple don’t state the actual coverage – just vaguely reference the various colour gamut standards – so these are the figures as actually tested by PCMag. ↩︎
11. Only when used with Macs which support DSC (Display Stream Compression), otherwise the USB-C ports are limited to USB 2.0 (400 Mb/s). ↩︎
12. The tech specs claim it has a built-in KVM, but there’s no mention of that anywhere else in the marketing materials nor the user manual. It does have a USB hub, which you can manually switch between the Thunderbolt or USB upstream ports by diving into the on-screen display, but there’s no apparent support for (a) doing this automatically when the input source changes nor (b) switching input sources & USB routing via keypress. ↩︎
13. Meaning the simple product of the three maximal dimensions. Some of these displays have curved backs, so their actual volume will be substantially less. ↩︎

All in all… meh.

28% fewer pixels for 34% 42% fewer dollars (47% if you’re talking nano-textured) – so technically better value, if you don’t really care about screen real-estate. But that extra real estate is really valuable, and Apple have now apparently ceded the large display market to… well, mostly the tumbleweeds. Sure, there’s technically other 6k displays, like the LG, the Dell, or the Asus, but while they have some advantages – less than half the price, most notably – they have real big disadvantages – like low brightness and poor contrast ratios.

4⨉ the backlight zones is a significant improvement, I’ll grant Apple that. But it doesn’t eliminate the blooming that was problematic with the Pro Display XDR, merely reduces it. In an era of OLED displays – hell, my old LG TV from nearly a decade ago has an OLED display; this ain’t new technology – a brand new, ostensibly-high-end “studio” display still running on LED backlighting is just sad.

The extra brightness of the Studio Display XDR is merely nice – an extra 25% isn’t a big difference (certainly nothing like the +200% or so in going from a competing 6k display to the Apple Pro Display XDR). Props to Apple for the improvement, but it’s minor.

It’s interesting that the new, smaller, lower-resolution Studio Display XDR is nearly the same spatial volume as its big sister (and not as much lighter as its reduced resolution and screen dimensions would suggest). I wonder if that’s dictated by thermals?

I didn’t bother including the audio & camera aspects because I’m genuinely confused as to who, in the market for an expensive display, would care? If you’re doing photography there’s no sound anyway, and if you’re doing videography in this price range you should be using real speakers or headphones.

And the camera… sigh… I miss the iSight, which gave you a much better camera – thanks to physics – that you could optionally buy and use. And look at it – it was a beautiful design that functioned really well, that would have fit in perfectly with the Pro Display XDR!

I’m also choosing to overlook the firmware, which I assume uses the same weird, bastardised, glitchy version of iOS as the prior Studio Display model.

After more than six years, I was hoping for an improved Pro Display XDR, not merely a small version.

1. Only when used with Macs which support DSC (Display Stream Compression), otherwise the USB-C ports are limited to USB 2.0 (400 Mb/s). ↩︎

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.

Steps:

1. Duplicate the clip (option-drag it in the timeline view) and place the duplicate above¹ the original. Ensure it’s perfectly aligned on the timeline’s X (time) axis, otherwise it won’t show up as a tracking source in step 3.2.
2. On the duplicate clip (make sure it’s selected and your playback position is within it so that you can see what you’re doing!):
   1. Invert the scale (e.g. make it -100% instead of the default 100%).
   2. Invert the X & Y offsets (if necessary – if they were non-zero beforehand).
   3. Add an Object Tracker (the + icon to the right of the “Tracker” titlebar at the bottom of the Video Inspector (right-hand pane)).
   4. A white grid – your anchor section – should appear over your clip. Move and resize it to have it cover an appropriate part of the clip (a subsection that’s contrasty and contains object(s) that are stable – in appearance and position – within the world space of the scene, and ideally are never obscured by anything during the clip).
      • ☝️ You can adjust the timeline position of the clip to find the optimum frame in which to identify your anchor section.
   5. Click Analyze.
      • ⚠️ This will sometimes not work if certain other operations are outstanding, such as dominant motion analysis for the clip – you have to either cancel those background tasks or wait for them to finish. One of Final Cut Pro’s many irritating bugs.
      • ⚠️ Watch carefully as it works through the clip (forwards from your starting point, then backwards, as necessary), for:
        • Your anchor section being intruded upon by any moving objects within the scene. If that happens, try to go back and refine your anchor section placement so that it won’t be intruded upon. If that’s impossible, you can proceed but be aware that the results may be subpar.
        • The anchor section changing in position and size – the more it ‘wobbles’, the worse the final results are likely to be. Consider different anchor section placement, or try a different analysis method (in the Video Inspector, for your Object Track, change the Analysis Method from the default, “Automatic”, to another option – note that you must click Analyze again after changing this, for it to take effect).
3. On the original clip:
   1. Open the Transform viewer (the rectangle icon in the “Transform” titlebar in the Video Inspector).
   2. Click the downward chevron next to “Tracker” text on the Tracker tab button (at the top of the video preview view), to bring up the configuration pop-up:
      • Set Tracker Source to your duplicate clip.
      • Set Tracker to the Object Tracker (or whatever you renamed it to).
      • Set the axes you want stabilisation to apply to (the Apply Tracker To checkboxes).
4. Disable the duplicate (e.g. V key while it’s selected).
   • ☝️ You cannot have it disabled before you select it as the Tracker Source, as it won’t show up in the pop-up menu while disabled.
5. On the original clip:
   1. Set the scale to -100%.
   2. Adjust the X & Y positions to correct the framing, if necessary (if your X & Y position were both 0 on the original clip, this shouldn’t be necessary). Note that this usually isn’t a simple sign inversion as in similar previous steps.

Optional sixth step: file a bug report or suggestion with Apple asking for them to make their built-in image stabilisation work better, and/or make the object tracker GUI easier to use (it could be just one or two clicks, to enable it and say “lock this part of the scene in place”).

1. Technically it doesn’t matter if it’s above or below, I just find it slightly more convenient when it’s above as usually it’ll be disabled (showing the original, now-stabilised version from below) but I access it easily by simply enabling it (V key), such as if I want to adjust the tracking. ↩︎

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.

What’s the difference between presentedWindowStyle(_:) and windowStyle(_:)?

Well, one does something, the other doesn’t, basically.

I tried using the former, and observed that it never has any effect. I filed FB14892608 about it, a month ago. While the long delay isn’t great, the response I got today was actually pretty helpful:

We’re sorry you ran into trouble with that API.

To adjust the style of a window group’s windows, you have a couple of options. If all of the windows in the group should have the same style, then using the windowStyle() scene modifier is what you want:

struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .windowStyle(.hiddenTitleBar)
    }
}

If you need to adjust the style on an individual basis using state for that window, there are also some related view modifiers:
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .toolbar(removing: .title)
                .toolbarBackgroundVisibility(.hidden, for: .windowToolbar)
        }
    }
}

A simple apology followed by clear and specific instructions on how to actually achieve what I wanted. I genuinely applaud Apple – or perhaps I should more specifically thank the individual(s) within DTS that actually provided this response. Either way, it was a very pleasant surprise.

Now, it still leaves unanswered the question of what presentedWindowStyle(_:) is supposed to be for, and in what situations it actually does anything. So not a perfect reply, per se, but really the proper solution for that is either:

1. Fix the API to not have such confusingly similar modifiers.
2. Improve the documentation to:
   • Explicitly point out the other, similarly-named modifier.
   • Distinguish them.

Currently the documentation is just:

Versus:

The latter might technically convey something important here, in the created by interacting with this view part, but so much in SwiftUI is modifiers stuck haphazardly in weird and arbitrary places, that I’m been conditioned to ignore the fact that I’m often applying modifiers to views that don’t actually affect those views. And for all I know in SwiftUI parlance views do “create” and/or “interact” with their parent windows (a lot about SwiftUI is backwards, part of its nature as a declarative API).

Especially if that’s the first candidate API you stumble across, when searching for a way to style a window, it’s very easy to presume it’s the right API. Why would there be multiple APIs for styling the window; why would you continue searching after finding one?

Similarly, the presentedWindowStyle(_:) variant is the only one that appears in Xcode’s auto-complete if you try to add the modifier to your main view, which is both where you sometimes have to add window-level modifiers and also just a really easy mistake to make (instead of adding the modifier to the WindowGroup, one indentation level up).

Lastly, it doesn’t help that I can’t find any situation in which presentedWindowStyle(_:) has any effect, even knowing it’s not intended to style the parent window. One might assume it’s somehow related to sheets or somesuch, but apparently not? Presumably I’m overlooking some use-case – or maybe it doesn’t actually do anything on macOS, only iDevices? I welcome clues or tips.

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.

What NSCopyObject does

Its implementation currently starts with essentially:

id NSCopyObject(id object, NSUInteger extraBytes, NSZone *zone) {
    if (nil == object) {
        return nil;
    }
    
    id copy = object_copy(object, extraBytes);
    object_setClass(copy, objc_opt_class(object));
    return copy;
}

…where object_copy et al are part of the Objective-C runtime. object_copy and its callees are not trivial, so I won’t repeat them here. The key parts are:

1. The malloc in _class_createInstance (allocate space for the copy).
2. The memmove in object_copy (naively copy the raw bytes over).
3. The call from object_copy to fixupCopiedIvars (half-heartedly attempt to fix the damage).

fixupCopiedIvars is notable. It was added by necessity when ARC was introduced to the Objective-C runtime, in Mac OS X 10.6 (Snow Leopard) in 2006. ARC added metadata to Objective-C classes to convey which instance variables were retain-counted object references, so that it could manage them automagically at runtime (not just for copying objects, but more importantly for deallocating them). fixupCopiedIvars uses that metadata to identify things it has to retain (strongly or weakly) in the new copy.

So that should work great, right? The copy operation increments the retain count of all shared objects the new copy references, like you’d expect?

That metadata is incomplete. It only works for Objective-C ivars managed by ARC. i.e. not C++ ivars or Swift stored properties, nor even Objective-C ivars that aren’t using ARC¹.

But I don’t use NSCopyObject…?

Almost nobody intentionally uses NSCopyObject, but your superclass might, and therefore you might. Ever subclassed NSCell or NSAnimation, for example?

I happened to hit this when subclassing NSBitmapImageRep (and I’m very grateful to Kyle Sluder for so quickly identifying the problem – it could have taken me forever to figure it out, otherwise).

If your superclass uses NSCopyObject, it’s now your problem just as much as if you’d used NSCopyObject directly, whether you like it or not.

And even more problematically, whether you know it or not. If your superclass is defined by a 3rd party framework / library, or anything that’s closed source, you might have no idea whether it uses NSCopyObject currently. Worse, you have no control over whether it will or will not use it in future (though anyone that adds a use of NSCopyObject at this point had better hope the atheists are right).

So how do I defend against NSCopyObject?

Objective-C

Pre-ARC it used to be relatively easy to work around this, in Objective-C. You “just” had to manually retain all your subclasses’ reference ivars – and manually copy some others, like non-ref-counted mutable or mortal buffers, etc.

But that generally isn’t possible with ARC – under which you cannot explicitly call retain. Worse:

• There’s still prominent guides scattered about the web that push you unequivocally to use retain, which is not just impossible to do directly under ARC, but flat-out wrong even if you do figure out one of the “clever” ways to do it (you’ll end up over-retaining your ARC-managed references, causing memory leaks).
• There’s also pages lingering on the web that claim that merely turning on ARC will magically solve the problem (it might, but it’s not a panacea).

Some guides specify a better method, which is to manually zero out the copied object’s ivars and then repopulate them via formal property setters. That actually works with or without ARC, although it may break – causing memory leaks – if the superclass ever stops using NSCopyObject (or if NSCopyObject ever gets upgraded to understand reference-counted ivars that it currently does not). It’s also only possible in Objective-C because Swift doesn’t provide direct access to instance variables.

Keep in mind that any reference-typed ivars which are not strong or weak Objective-C objects managed by ARC will still, always need to be handled manually. e.g. pointers to manually-managed memory buffers.

Swift

Ironically, Swift’s attempts to prevent incorrect code actually make it harder to write correct code in this case. What you want to do is – like the Objective-C implementation – to just zero out the references and re-assign them like normal properties. Zeroing them out without triggering a release basically undoes the mistaken memcpy that NSCopyObject did. But Swift won’t let you.

Worse, this has been known for most of Swift’s existence and nothing has been done about it.

Simply setting the property to nil will cause it to be erroneously released, which may immediately deallocate the object and ultimately cause a crash or memory corruption. Even if it doesn’t happen to deallocate the object, it’ll negate the retain you do during the assignment, making all your effort moot.

That’s pretty heavy-handed, though, and not always possible (e.g. NSImageRep, as used by e.g. NSBitmapImageRep, does some special magic in its copy implementation which you cannot practically replicate).

It appears that the best you can do is assume the superclass will always use NSCopyObject, if it does currently, and just manually increment the retain count. Like Objective-C with ARC, the language & standard library really don’t want you to actually do this, but at least in Swift it’s relatively straightforward:

override func copy(with zone: NSZone? = nil) -> Any {
    let result = super.copy(with: zone)
    
    if result.myProperty === self.myProperty {
        _ = Unmanaged.passRetained(myProperty)
    } else {
        result.myProperty = self.myProperty
    }
}

The conditional might help protect you if the superclass stops using NSCopyObject in future – in that case, it’ll probably cause myProperty to default to nil (or to be assigned to some other instance, which you can discard), in which case you just want to assign to it normally.

In the interim – while NSCopyObject is in use, at least – the myProperty pointer will be copied verbatim and you have to assume it requires the extra, manual retain. It’s not future-proof – it’s possible for the superclass to copy the pointer verbatim and increment the retain count for you – but at least in that case you “merely” get a memory leak, rather than a crash or memory corruption.

Do as Apple says, not as Apple does

The most frustrating part of all of this is that this is entirely Apple’s fault. Sure, you can argue it’s not their fault that NeXT added this vile function to Foundation; that Apple “merely” inherited it and were “forced” to keep for backwards compatibility. But it’s entirely Apple’s choice to have kept using it all this time, in their core frameworks, even while they’ve been telling everyone else to never use it.

NSCopyObject has been a known problem-maker pretty much forever – it was a terrible idea right from the outset. Blindly copying the bytes of an object instance, and just hoping that somehow that works correctly – in an object-oriented language derived from Smalltalk where even numbers are often reference types – is farcical.

The introduction of ARC (in 2008) didn’t really help anything, as although it changed NSCopyObject to properly retain ARC-managed ivars, it did nothing for non-ARC-managed ivars (remember that ARC can be enabled in one library but not in another, and libraries can subclass each others’ classes).

NSCopyObject has been officially deprecated since 2012:

The NSCopyObject() function has been deprecated. It has always been a dangerous function to use, except in the implementation of copy methods², and only then with care.

Foundation Release Notes for OS X 10.8 Mountain Lion and iOS 6

…though Apple officially told everyone not to use it in 2008:

This function is dangerous and very difficult to use correctly. It’s [sic] use as part of -copyWithZone: by any class that can be subclassed, is highly error prone. This function is known to fail for objects with embedded retain count ivars, singletons, and C++ ivars, and other circumstances.

Foundation Release Notes for Mac OS X 10.6 Snow Leopard

And this was all still a decade or more after it was known that NSCopyObject was fundamentally evil, e.g. NSCell, and GnuStep’s broken NSControl.

And yet, Apple still use NSCopyObject themselves to this very day, in their own applications and frameworks – including major frameworks like AppKit that almost all 3rd party developers rely on. NSCell is still broken, three decades later, as is NSImage & NSImageRep, and NSAnimation. Most of those are explicitly designed to be subclassed, despite Apple’s own very clear instructions to never mix subclassing with NSCopyObject.

Admittedly it’s not trivial for Apple to remove the NSCopyObject use – alas, because people have had to code myriad hacky workarounds to it, Apple now has to be careful not to break those workarounds. That might even preclude fixing the existing code paths; it might require a replacement copy mechanism. Which leads to…

Tangent: NSCopying considered harmful

The big driver of NSCopyObject use has long been NSCopying. Classes that intend to be subclassed – but also semantically should support copying i.e. NSCopying – have long been making the mistake of thinking that means using NSCopyObject. One need only read the NSCopying documentation, even from before Mac OS X was even publicly released, to see how dangerously fragile and error-prone NSCopying has always been.

Compounding the problem is that NSCopying doesn’t work, by default, on subclasses. You have to override copy(with:) in every subclass³, but the compiler does not enforce this, because in Objective-C (and alas Swift) protocol conformance is assumed inherited even when it cannot correctly be without explicit, extra work by the subclass.

1. Yes, it’s still possible to this day to write Objective-C without using ARC – -fno-objc-arc / CLANG_ENABLE_OBJC_ARC. There might even be valid (albeit unfortunate) use-cases for having to do so, such as for performance.
   
   And even with ARC, it’s of course possible to have pointers to things which aren’t NSObjects and therefore aren’t handled by ARC, such as raw malloc allocations. ↩︎
2. This is false and always has been (that it was safe to use in copy methods). Apple’s false statements in the deprecation notices may ironically have caused even more instances of people using NSCopyObject. ↩︎
3. Any and all that add retain-counted ivars, Swift stored properties, or ivars of C++ types that have destructors. ↩︎

I don’t really remember the timing – sometime between 2006 and 2010 – but presumably around 2006 as I recall it was when Core Data was still relatively new. For whatever reason, there was a huge push internal to Apple to use Core Data everywhere. People were running around all over the place asking “can it be made to use Core Data?”, for Apple’s frameworks and applications.

Keep in mind that Core Data at that time was similar to SwiftData now – very limited functionality, and chock full of bugs. But of course it’s the nature of ‘shiny’ new things that their proponents think it’s the second coming and the cure for all ills.

So, I recall sitting down with a couple of folks from the Core Data team, that were there to see if Shark could adopt Core Data. A little like letting the missionaries in, if only out of morbid curiosity.

Have you heard the good news? Core Data is here to save your very data. It’s effortless and divine and its unintuitive, thread-unsafe API will definitely not be the bane of all its users for the next fifteen years.

Jokes aside, they were in fact earnestly curious if Shark could use Core Data, instead of its own purpose-built binary formats, for storing & querying its profiling data. It was perhaps the classic case of naively underestimating the complexity of a foreign domain. By my recollection, they assumed our profiling data was just a small handful of homogenous, relatively trivial records. “At second N, the program ran the function named XYZ” or somesuch.

I think we (Shark engineers) tried to be open-minded and kind. We were sceptical, but you never know until you actually look. We could see some potential for a more general query capability, for example. But of course the first and most obvious hurdle was: how well does Core Data handle sizeable numbers of records? Oh yes, was the response, it’s great even with tens of thousands of records.

We asked how it did with tens of millions of records, and that was pretty much the end of the conversation.

It wasn’t just the volume of data, it was also the dramatic difference in representation efficiency. The in-memory representation in Shark was basically as efficient as it could be – basically just arrays of compact structs, sometimes with pointers to other arrays (which might share a malloc block to avoid the overhead of small allocations) which were usually just of uint32_t or uint64_t. The most important operations – indexing to an arbitrary point in the profile’s timeline, then scanning forward over the data – were about as fast as they can possibly be.

In contrast, Core Data would have required an entire object (NSManagedObject subclass) for at least every sample, if not every uintXX_t in the callstack (depending on how ‘pure’ you wanted the design to be). It would have increased memory usage by at least an order of magnitude – and Shark already struggled with big profiles on the hardware of the day, which typically had just a couple of GiB of RAM. Even the most trivial operations – like reading the data in from disk and iterating it sequentially would have been thousands of times slower.

In defence of the Core Data folks in the meeting – and I don’t remember who specifically it was – they never tried to misrepresent or exaggerate what Core Data could do. I seem to recall them being quite nice people. But as soon as we started explaining the type and volume of data that we worked with, they clearly gave up on any kind of pitch. Core Data was designed for developer convenience, not runtime efficiency or performance.

It’s never ceased to surprise and disappoint me how many folks try to arbitrarily apply generalised data storage systems – particularly SQLite and MySQL, or wrappers thereover. Usually for the same reasons – perceived convenience to them, right now, not necessarily efficiency (nor the convenience of their successors).

I guess by modern standards SQLite is considered efficient and fast, but – hah – back in my day SQLite was what you used when you didn’t have time to write your own, efficient and fast persistent data management system.

See also JSON and its older sister XML. 😔

If you’re too young to have personally lived that time, just know this key point: back then, buying or streaming music online was basically not a thing¹. You bought CDs in physical stores, or maybe by mail order from an online retailer if you were on the bleeding edge. Or you listened to the radio. Or, you traded pirated copies of CD rips via a plethora of file sharing apps, most famously Napster.

It was the opinion of quite a few people – my younger, more ignorant self among them – that if the music industry wasn’t willing to provide us the songs we wanted by the means we wanted and at the price we wanted, then it was their fault that we pirated their product.

Talk about entitlement.

Computer game pirates had – and seemingly still have – a similar attitude. “$70 for a game? Outrageous! I have no choice but to pirate it!”

Bullshit. You have plenty of choice: you can pay for it, or you can not have it. You’re not entitled to the work of others. That used to be believed, but not anymore.

A similar sense of entitlement seems to underpin many critiques of Apple’s business practices. While I’m no fan of some of Apple’s business practices – because it’s always a shame to see flaws in an otherwise good or promising product – I’m under no delusion that I’m somehow entitled to have Apple’s products at all, let-alone on purely my own terms.

1. I think it’s now largely forgotten just how big a deal it was when the iTunes Music Store was announced in April 2003, with five of the biggest western music labels onboard. ↩︎

I had intended to just buy an Apple Vision Pro on release day, but by the time I woke up and went to Apple’s online store – a couple of hours after pre-orders opened – they were showing a nearly two month shipping delay (and no in-store pick-ups at all). So I figured there was no point ordering then; like it or not I’d have plenty of time to see what others think first.

Of course, it turns out it was not in fact massively out of stock. I later found out that people had ordered theirs later that day, or even the next day, and were still included in the very first shipment. Nobody had to wait two months for theirs, even if they ordered weeks later. Apple’s online store was full of shit.

But I’m glad for it, because as soon as I was resigned to not ordering one, I was at ease with that decision. I felt oddly relieved. Having since read & listened to many people’s impressions & commentary, over the last month, my confidence in that decision only increased. And now that I’ve tried one for real, I am certain of it.

The Good

Ease of use

I found the interface to be pretty intuitive. Eye tracking worked very well, and gesture recognition was fairly reliable – neither were perfect, but then mouse tracking and “the key I meant to press” tracking isn’t perfect either. 😉

It’s hard to say with any confidence from such a short use of the Vision Pro, but my impression is that its eye & gesture tracking is at least as accurate as touch on iPhones, iPads, and Apple Watches. My Apple Watch & iPhone routinely reject my taps just to spite me (they animate the GUI to show that they know that I did tap, yet they refuse to accept it).

Which is to say, I suspect it would annoy me at times with its errors but I don’t think it’d be a barrier to long-term use.

Sound

One thing which I did not remotely anticipate is how good the sound isolation is – even more astounding given there’s nothing in or on your ear to provide a physical barrier. There were dozens of people in the Apple Store, including several pairs right around me going through their own Vision Pro demos or iPhone upgrades, and with the headset on I barely registered any of their conversations.

I find it hard to believe it’s due to traditional noise cancellation methods, just given the physical position and arrangement of the speakers, so this might be as much a psychological ‘trick’ as anything. In any case, it is effective.

I was also impressed by how well 3D audio worked (and how good the sound quality was in general). Better than AirPods (and Beats Pros) in my experience, although that’s a low bar.

I’m less sure how the Vision Pro’s speakers stack up against real headphones – even my aging Sony MDR-ZX780DCs – but it’s at least a reasonable comparison, which is impressive given the Vision Pro’s speaker’s form factor.

Real world view

When the Vision Pro was first announced I was a little disappointed that it uses cameras to ‘fake’ transparency, rather than using genuine optical transparency. Nonetheless, I was happy to see that the effect is mostly sufficient.

It wasn’t hard to find flaws if you looked – the cameras are not correctly placed to actually see what you see, for example, so any objects closer than about a metre have noticeable parallax errors. That’s very noticeable if you do something as simple as move your hands in front of you, even at arms length.

Yet, looking around the real world worked fine in practice. There is perceptible lag, but only barely – not enough to really cause any issues; you’re not going to accidentally walk into moving objects, for example, and you could probably even play [real] sports with the Vision Pro on (although you wouldn’t be doing yourself any favours).

I should note that it was in no way realistic because you’re clearly looking at a resolution-limited computer screen (more on that later). And I didn’t even test things like dynamic range or optical aberrations of the lenses, as I was in a very evenly lit and low-contrast Apple Store.

Immersive experiences

I didn’t get to do the butterfly & dinosaur one, which is a shame because by all accounts it’s particularly good, but I got the quick demo reel of spherical videos (along with a couple of “3D” photos & videos). It was a bit hit & miss (more on that in later sections), but there were a few moments where I was actually pretty pleased with the experience. I’ve visited Haleakalā a few times but never seen the crater – the weather has always conspired against me – so I actually got lost for a minute or so just enjoying that view. The subtle animation of the mist drifting up & down the crater walls was a sublime touch. Likewise the gentle rain on the lake near Mount Hood.

The 3D video of a kid blowing out the candles on their birthday cake worked relatively well. The feeling of depth was nice – aided by the cake being very close to the camera and the use of a wide angle lens. I suspect wide-angle photos are much more amenable to the “3D photo” effect (they’re often described as more immersive even in plain 2D – although I think that effect is exaggerated by many people).

Human intrusions

The way people very subtly appear when you look in their direction while in full VR mode was quite nice. I like that they are visible but remain faint apparitions. I had received the mistaken impression from second-hand accounts that intruders appeared largely opaquely; much more obtrusively. The implementation strikes a good balance in providing awareness – and facilitating communication – without interrupting more than necessary.

Physical comfort

It’s of course very hard to deduce the real-world comfort of the Vision Pro from a mere fifteen minute session, but for whatever it’s worth I didn’t have any issues regarding weight, size, or contact. The headset certainly wasn’t unnoticeable, but I had no issues forgetting about those aspects while using it.

Also, it wasn’t until I was mostly done writing this article that I even remembered that the Vision Pro has a cable sticking out of it. The battery pack stayed on the table in front of me, and the only time I noticed the cable – even in the slightest – was when putting the unit on (merely because I had to make sure the cable wasn’t tangled around my head). I was expecting to feel the cable tugging and pushing on the headset during use, but did not.

This is in stark contrast to the power cable on my MacBook Air which is constantly getting snagged and yanked by my apparently villainous couch. So I’m very curious how the Vision Pro would work in a more typical environment, rather than at the Apple Store with basically nothing but empty space around me as I sat on a stool.

Minimal internal lens flare & reflection

At least in the bright Apple Store, I didn’t find the lens flare & reflections to be distracting. They are present, but I really only noticed them on the very first screen, where you’re in a black void and thus of course any such optical imperfections are most visible.

This is pretty good, by my estimation, since I find sunglasses to be irritating due to seeing the reflection of my own eyeballs in them. The Vision Pro has the big benefit of the [mostly] enclosed mask, to largely eliminate external sources of light. So it should have far fewer issues with flare & reflections, as a matter of principle.

The main reflection I did notice – and had a slightly harder time ignoring – was the glow of the screen on the inside of the light shield. It’s a pity Apple used a grey, textured material for the interior, rather than something dark like Musou black fabric.

Still, unless you plan to work in a very dark or high-contrast VR environment – perhaps the moonscape that I tried briefly during the demo – you should be fine in this respect.

Real world geometry is no limit

Folks have unanimously stated that – surprising or not – there’s no visual incongruence with pushing AR elements “through” real-world ones. One of the first tests I did was to grab a window and shove it through the table in front of me. Despite clearly violating all logic, my eyes & brain apparently had no issue with it – it didn’t feel wrong, or weird, or uncomfortable.

So – while I didn’t test it – I can easily believe that you can indeed watch a movie on a [virtually] cinema-sized screen despite being stuck in cattle class on a plane. And I can imagine it would be a genuine emotional benefit to have that feeling of so much more personal space, even though it’s “fake”.

Honestly, if I were to get a Vision Pro its use as an aid to commercial air travel might actually be one of the most justifiable reasons.

The Bad

Buggy demo units

My time actually using the Vision Pro was significantly shortened by the demo unit refusing to reset properly. It took three attempts – and a consultation between Apple Store staff – before they finally got it to work properly.

On the first two usage attempts it went straight from the “hold down the crown button to shift the lenses” to the home screen, bypassing eye tracking calibration. It didn’t seem particularly unusable without proper calibration, but my Apple handler refused to start the demo without it.

Bad light seal

Perhaps it’s just me and my apparently tiny nose, but there was a big gap between the unit and my nose. I could easily look through and see the table in front of me, my own lap, etc. This surprised me given Apple themselves have put a lot of emphasis on the importance of a good fit and no light leaks in order to have the proper experience.

However, in use I didn’t find it much of an issue – I wasn’t distracted nor blinded by the light leaking in. I think as long as my focus was actually on the screens of the Vision Pro, and my attention on whatever I was looking at within them, it was okay. Although, just like the glare & reflections within the lenses, it may not be so easy to ignore in a dark VR environment.

Non-immersive experiences

Most of the 3D photos & videos I saw didn’t do much for me. I can clearly see the appeal in theory, but the implementation on the Vision Pro is frustrated by several factors.

For a start a lot of the 3D photos – and especially videos – were blurry outside of the centre¹. Really blurry, in the case of the Alicia Keys clip – she was reasonably in focus but almost everything else was way out of focus. I think in the original recording, although I guess I can’t be sure that it wasn’t buggy foveated rendering or somesuch.

Second, even when they weren’t blurry, they were often low resolution. Hard to say whether this is because of the Vision Pro itself (more on this later) or with the source materials.

I was hoping that the panoramas would be a big (pleasant) experience, as I’m quite a fan of taking panoramic photos (and photo spheres) even though you can’t really view them well on fixed displays. In a way I’ve been waiting and preparing for VR goggles for decades. Heck, I was super excited when Quicktime VR was released, even though it turned out to unfortunately be decades ahead of its time.

Yet, I was a bit disappointed with the panorama experience on the Vision Pro. I’m not entirely sure why, although I know one obvious reason was that you can see the edges. Any illusion of being there is rattled when the edge of the photo appears in view. Photo spheres are the better way to go.

Seeing the edges might sound trite – after all, we see the edges of photos and videos all the time on our existing displays; what’s the problem? It’s a good question – I don’t know if I can explain it, I just know what I felt. Perhaps it’s an uncanny valley sort of problem – because you are in a nominally immersive, VR environment, it matters so much more when the illusion is shattered. Perhaps it’s something you get used to?

In any case, even for photo spheres the feeling of immersion is compromised by the field of view being way too small…

Limited field of view

I had heard that the Vision Pro has a limited field of view – even compared to its contemporaries – but I was still surprised to see what that’s actually like. It’s even more limited than I expected. It’s like wearing bad goggles – blinkers, perhaps. A kind of tunnel vision. I’ve heard it said that you “just” need to keep your eyes centred and move only your head instead, but even looking dead ahead I clearly perceived the outline of the screens, and it took some effort to ignore that (mostly successfully).

As noted earlier, this kinda ruined any would-be feeling of immersion for me, in most cases. You’re not much more “there” than you are viewing a photo in a picture frame (or on a traditional screen), or watching a video on a TV placed too far away.

Everything’s too close & big by default

I was surprised that windows open way too close (in perceived depth) and too big (in field of view) by default. I was constantly manually resizing things and pushing them away from me, in order to actually be able to see them [fully] and comfortably.

I do not like having to move my head just to look around a single window, it turns out.

I also found it quite unintuitive that windows enlarge as you push them away, maintaining the same angle of view. It was not only annoying – since the whole point of pushing them away was to make them smaller and feel less claustrophobic – but it made it hard to actually judge if & to what degree they were moving. More than once I repeated a “get back” window movement because it seemed like the first try was silently ignored (and honestly, I can’t be sure it wasn’t – that’s the point).

3D movies

I watched the brief trailer for Super Mario Bros. I didn’t really get much of a 3D effect, but I did get the very limited field of view (see prior point) and poor visual quality (see below). I’m actually a bit bullish on 3D movies, but I think we’re still just not there technologically².

I do like to have a big screen – such that my vision is pretty filled by a movie – but apparently I really don’t like it when there’s a black mask over the outskirts of the movie. Even if it’s only visible in my peripheral vision.

Possibly I’d get used to this in time, but of course I don’t really want to – I should be able to see the whole movie. Otherwise, what’s the point? If the director wanted me to see only a subset of the view, they’d have filmed it that way.

I presumably could also have manually moved the window back – and I did for some of the other videos I watched – but it’s just not practical to have to do that for every video I ever watch.

Perhaps the problem is in taking existing movies – designed for a relatively tiny field of view (≤40° typically) – and naively shoving them in your face in the name of immersion. Maybe what we need is to add new content around the existing frame. Despite our huge angle of vision, our focus area is actually quite small. It’s uncomfortable and confusing to have to look around frequently and rapidly just to make sense of a movie.

The Ugly

Very blurry & low resolution

I was really surprised to see pixels. Immediately. Even though I was already aware – mainly from John’s stumbling over the topic on ATP – that the PPD (Pixels per Degree) is actually quite poor on the Vision Pro, at just 34³. A “Retina display” at typical viewing distances is around 100. Even an ancient non-Retina Apple display is about 50.

In fact, 34 is about the same as an original Macintosh from 1984. 😳

I found this handy calculator for determining PPD, in case you want to estimate for your own devices. If you have a 5k 27″ monitor, for example, but typically sit with your nose about 4cm from it, then you’re already used to the Vision Pro’s display resolution⁴.

Furthermore, unlike the original Macintosh’s screen – which at least had quite crisp pixels – the Vision Pro is blurry as well. That surprised me less – I figured there might be some calibration required, which was perhaps unintentionally skipped by the buggy demo unit. But my Apple Store handler didn’t seem to think so, yet seemed surprised by my comments (that the view was pixelated and blurry). He had no real answer to that. He implied (by omission) that my experience was normal. 😕

Jittery

The other thing I noticed within a literal second of using the unit is that the artificial visuals jitter – jump randomly about by a pixel or two. All the time. It’s less noticeable in full VR mode where you have no objective reference in the form of real world objects, but in AR mode everything displayed by the Vision Pro is shaking. I was able to mostly ignore it throughout the demo – but only with conscious effort. Any time I let my mind or vision wander in the slightest, the shaking immediately bothered me once more.

To be clear, this was while sitting perfectly still. I didn’t really test actual lateral movement of the headset, as I was asked to stay seated for the entire demo.

Since everything you see in the Vision Pro is technically artificial – it’s all from opaque LED screens, even the view of the real world that’s piped in view cameras – this jitteriness is baffling. I’m pretty sure it was the virtual objects that were moving, not the feed from the real world – just based on my own perception of what was and wasn’t moving – but I have no explanation for why that would be the case. While I could sense a tiny bit of a lag in the real world view, it seemed to remain correctly positioned (and stably positioned, more to the point) relative to objective reality.

It’s hard to say from just fifteen minutes of use, but I suspect this jittering would contribute significantly to eye strain.

Eye strain

When I took the Vision Pro off, my eyes were immediately assaulted by [comparatively] bright light and much sharper everything. It was both uncomfortable and a relief.

It took several minutes for my vision to de-blur. It’s a very similar experience to looking through the viewfinder on my Z9 for an extended period. And similarly it took a good couple of hours for my eyes to get fully back to normal, and to stop feeling strained.

Based on that parallel experience, it seems very clear that I cannot use a Vision Pro for any significant amount of time, without serious eye strain that causes lasting blurry vision and headaches. 😣

I’m assured by my optometrist that my vision is actually excellent – much better than average for my age, and I’m not that old yet anyway – and I’ve never needed glasses for anything⁵. So I don’t think the problem is me. I think the problem is quite apparent from the facts: the Vision Pro simply has a very low-resolution, unstable display that is uncomfortable to look at.

So now what?

Now I wait.

If I’d decided to develop apps for the Vision Pro, as a business choice, then it’d make sense to own one – it could be considered a dev kit; an early prototype. But for now I’m content not to. There doesn’t seem to be a rush – the app market is comparatively tiny.

For personal use it makes no sense to get a Vision Pro. Aside from its novelty factor and some very limited uses, it’s inferior to a Mac for almost all purposes (like productivity tasks, watching movies, reading books, video calls, etc).

Yet I’m hopeful that the AR and VR headsets’ times will come, eventually. Still at least several years from now, based on what I’m seeing with the Vision Pro. But one day.

I’ve been trying to discern if the Vision Pro is an iPhone moment or an iPad moment, since it was announced. I was bearish on the iPhone and bullish on the iPad, apparently at odds with the entire rest of the planet. And I’ve since conceded defeat entirely on the iPad – when I replaced my iPad Pro 13″ with a MacBook Air, it was such a relief – I finally had a device which I could use freely and broadly, rather than a glorified iPhone for web browsing and watching video. So I’m leery about getting too enthusiastic about a new class of device which clearly has some of the same existential challenges as the iPad.

One thing seems clear – it’s not a Mac moment. I don’t see anything with the Vision Pro that fundamentally changes the nature of computing, let-alone day-to-day life. But then, I don’t think it’s fair to expect it to – there’s only been one Mac moment so far.

1. This might be just flaws in the demo material, although it’s hard to imagine Apple letting that fly. I have to assume the Vision Pro itself is the limitation here.
   
   That said, in the “3D” video of the girl popping bubbles I saw what looked exactly like JPEG or MPEG compression artefacts (mainly blocking and over-smoothing). I can’t be certain whether that’s an issue in the video file or in its playback by the Vision Pro, but I would assume that graphical rendering glitches would appear somewhat differently…? ↩︎
2. Most immediately, we lack the display technology to show a 4K (or better) video in 3D, whether via a headset like the Vision Pro or traditional means like coloured or polarised glasses. But that’s merely the easy part – we also need real-time rendering of the movie itself, in order to do proper foveated depth rendering – i.e. so that if you look at something in the foreground or background you can actually bring it into focus, even if the director hadn’t planned on that. As best I can tell practically nobody is even working on that yet. 😕 ↩︎
3. Tangentially, it’s baffling how news media outlets like The Verge can shamelessly try to spin that as in any way good. Talk about drinking the Apple koolaid. 😠 ↩︎
4. And if you can actually focus at that distance, then I applaud & hate you, because I can only reminisce fondly about those days. Stupid aging. 😔 ↩︎
5. Although admittedly I can no longer focus on the end of my nose like I used to be able to do when I was a few years younger, so I know my descent into old-age far-sightedness has begun; I’m told I will need reading glasses at some point in my life (barring an unfortunate early exit). ↩︎

It’s easy to see how some UI designer thought this was a good idea. Surely if you move the mouse near the edge of the window (or the screen, in fullscreen mode) and rest it there, it’s because you’re looking forlornly for your lost sidebar? What could be more helpful and delightful than your missing sidebar popping into view?!

Unfortunately, they have ignored that fact that there is usually already other GUI controls at the edge of the window, not the least of which being the window edge itself (for drag-resizing of the window). Scrollbars are another common inhabitant of window edges.

“Proactive Peek” is the worst of these two because not only does it change what’s under the mouse cursor just as you’re likely to click, stealing the click away from its true target, but it actually shrinks the window’s visible contents. This leads to layout changes and motion noise, particularly in web pages where it can have knock-on effects like mucking with the scroll position or causing major changes by crossing some “responsive design” threshold.

Unfortunately there’s no way to turn this poorly-considered ‘feature’ off completely, although you can effectively disable the “Reveal on Edge Hover” piece:

If you’re an app developer it looks like (I haven’t tested it) you can disable these ‘features’ within your own app, at least, by implementing the private NSSplitView delegate method _splitView:canProactivePeekArrangedView: and setting the NSSplitView revealsOnEdgeHoverInFullscreen property to NO (or the NSSplitViewController private property  _hasItemToRevealOnEdgeHover to NO, if you’re using NSSplitViewController). Or subclassing NSSplitView and overriding _canDoSidebarProactivePeek and _canDoInspectorProactivePeek to return NO – though that only applies to Proactive Peek.

Universal Clipboard basically just means you can copy something on one device and paste it on another, as long as they’re physically near each other and signed into the same Apple ID. There is no step 3.

It’s such a beautiful feature, in concept and execution. Admittedly most of the time I use it merely to shuffle authentication codes from my iPhone to my Mac, but still – I love not having to temporarily memorise arbitrary numbers and then type them in manually.

I think what really elevates it to perfection is that it works. It sounds like such a vapid point, but it really makes all the difference. Nominally Universal Clipboard is just one of a family of similar features, under the Continuity moniker, but it’s the only one that actually works reliably and predictably. The only one!

Many of the other Continuity features are similarly great in concept, but just don’t work reliably. SMSes sometimes don’t sync to my Macs. AirPlay sometimes just won’t connect, or the video quality is comically bad. Unlocking my Macs with my Watch is a guessing game as to whether it feels like working today. AirDrop is so fussy and unreliable that it actually gives me anxiety if I even think of using it.

I wish Apple’s products had more features like Universal Clipboard.

The question was raised whether an official Swift backtracer should try to support code that doesn’t use frame pointers. Which immediately raised the question – in my mind – of if anyone is still using the “optimisation” of omitting frame pointers, anyway. And perhaps more importantly, whether they should still be omitting frame pointers.

What is a frame pointer?

A pointer to a stack frame, held in a well-known location. That location can be in the stack itself (forming a linked-list of the stack frames) or in registers (e.g. the x29 register on AArch64, or RBP register on x86-64).

The controversial part – insofar as there is any controversy – is in dedicating a CPU register to hold a frame pointer (to point to the start of the current stack frame). It’s super convenient for a lot of things, but particularly for debuggers and profilers as it gives them a reliable and very fast way to find the top of the current callstack. But it’s not technically required for the program to function.

No live CPU architectures, that I’m aware of, have a dedicated hardware register for frame pointers. So you nominally have to “give up” a GPR (general-purpose register) in order to have a frame pointer.

Franz Busch pointed out that some notable software still ships with frame pointers omitted, e.g. apparently some major Linux distros. I suspect it’s merely some inertia (or simply oversight) that’s delaying getting people off of that old crutch. I’m not remotely surprised that some big Linux distros are in this bucket – they tend to be absurdly conservative and slow to change¹. And it’s mind-boggling how much vitriol restoring frame pointers generates from the peanut gallery.

From watches to servers these days – and frankly most of the embedded space, since it’s mostly ARM – everything generally has an ISA with sufficiently many GPRs to negate any big benefit from omitting frame pointers. Giving up one of 31 GPRs (for e.g. AArch64, the dominant CPU architecture family today) is pretty insignificant for the vast majority of code, because almost nothing actually uses all 31 GPRs anyway. It only makes a significant difference² when the CPU design is register-starved to begin with, like i386. And those architectures are largely dead, in museums, or restricted to very tiny CPUs as used in some microcontrollers (“embedded” systems).

Even back when i386 et al were still a concern, the proponents of -fomit-frame-pointer often argued not on the potential merits of the trade-off, but rather that it was a “free” performance boost, so even if it was only by a percentage point or two, why not? They of course were either naively or deliberately overlooking the detrimental effects.

There may still be software for which omitting frame pointers is the right trade-off, even on modern CPUs. But I find it hard to believe there’s enough cases like that to warrant accomodation in standard tools.

A brief trip back to Apple circa 2007

Back in the brief window of time when i386 was a thing for the Mac (32-bit Intel, e.g. Core Duos³ as used in the first MacBooks), I was at Apple in the Performance Tools teams (Shark & Instruments), and it was a frustration of ours that -fomit-frame-pointer was a noticeable performance-booster on the register-starved i386⁴ architecture⁵, so it was hard to just bluntly tell people not to use it… yet, by breaking the ability to profile their code, people who used it often left even bigger performance gains on the table (or otherwise had to invest much more labour into identifying & resolving performance problems).

At one point there was even an Apple-internal debate about whether to abandon kernel-based profiling in favour of user-space profiling⁶ because implementing backtracing without frame pointers is possible but very expensive and requires masses of debug metadata (e.g. DWARF), making it highly unpalatable to put in the kernel. Thankfully there were too many obvious problems with user-space profiling, so that notion never really got its legs, and then x86-64 finally arrived⁷ and it was mooted.

1. e.g. Ubuntu still not officially supporting ImageMagick 7 even though it’s been out for nearly a decade. ↩︎
2. Aside from the question of register space, there is additional cost to implementing frame pointers, as additional instructions are required around function entry & exit in order to maintain the frame pointers – to push & pop them off the stack, etc. The cost of those is usually insignificant – especially in superscalar microarchitectures, as is the norm – so that aspect is not typically the focus of the controversy. ↩︎
3. Tangentially, I vaguely recall us Apple engineers kinda hating the Core Duo (Yonah), or more specifically Apple’s choice to use it. Apple used them only for a tiny window of time, from May 2006 to about November 2006 when the Core 2 Duo (Merom) finally replaced them across the line. I don’t recall all the reasons that the Core 2 Duo was superior, but they included that Core 2 Duo corrected the 32-bit regression (for Macs) and performed much better. Anytime Apple releases a Mac with a dud processor in it, like those Core Duos, a lot of Apple engineers die a little inside because they know they’re going to be stuck supporting the damn things for many years even after the last cursed one rolls off the assembly line.
   
   It’s still a mystery to me why Apple rushed the Intel transition in this regard. They only had to wait six more months and they could have had a clean start on Intel, with no 32-bit to burden on them for the next seven years. ↩︎
4. Why do I keep calling it “i386”? Isn’t it officially “IA-32”? Well, yes, but that’s (a) only retroactively and (b) only ever used by Intel. Though I guess “x86” is probably the more common name? Yet “i386” is in my mental muscle memory. Maybe that’s just how we used to refer to it, at Apple? Maybe just because that’s the name used in gcc / clang arch & target flags?
   
   Incidentally, clang -arch i386 -print-supported-cpus on my M2 MacBook Air still lists Yonah (those damn Core Duos) as supported. Gah! They won’t die! 😆 ↩︎
5. It’s funny how the Intel transition is now heralded as being amazing and how much better Intel Macs were than PPC Macs, but for a while there we lost a lot of things, like a 64-bit architecture, an excellent SIMD implementation, and the notion of more than [effectively] six GPRs.  ↩︎
6. There were at the time already some Apple developer tools that did user-space profiling, most notably Sampler (now a niche feature in Activity Monitor) and early versions of Instruments (in fact Instruments still has the Sampler plug-in which does this, although I can’t really fathom why anyone would ever intentionally use it over the Time Profiler plug-in). ↩︎
7. In the sense of all Macs adopting it, not just the Mac Pro. It was easy to ignore i386 at that point because it was then all but officially a dead architecture as far as Apple were concerned. ↩︎

The following classes and functions are generally not thread-safe. In most cases, you can use these classes from any thread as long as you use them from only one thread at a time. Check the class documentation for additional details.

Apple’s Threading Programming Guide > Appendix A: Thread Safety Summary, subsection Application Kit Framework Thread Safety

What “in most cases” means is left to the reader’s imagination. Apple adds a little addendum for NSImage specifically:

One thread can create an NSImage object, draw to the image buffer, and pass it off to the main thread for drawing. The underlying image cache is shared among all threads. For more information about images and how caching works, see Cocoa Drawing Guide.

NSImage Restrictions

For a start, it’s talking only about creating an NSImage from scratch, not loading it from serialised form (e.g. a file, a pasteboard, etc). It doesn’t even deign to mention those other, much more common cases.

And even for that one mentioned use case, what does it mean, exactly? What “image cache” is it referring to?

I don’t have authoritative answers. The documentation is so infuriatingly vague that Apple could do basically anything to the implementation, between macOS updates, and claim to have broken no promises.

What I do have is some empirical data and the results of some reverse engineering (shout out to Hopper), from macOS 14.2 Sonoma.

NSImage 101

NSImages can represent a wide range of imagery. Most uses of them are probably for bitmap data (i.e. what you find in common image formats like WebP & AVIF), but NSImage also supports ‘raw’ images (e.g. Nikon NEF) as well as vector data (e.g. SVG & PDF). It also has a plug-in mechanism of sorts, so the supported image formats can be extended dynamically at runtime.

You can fetch the full list of supported types from NSImage.imageTypes – although it doesn’t distinguish between those it can read vs those it can write. Fortunately, sips --formats in Terminal gives you the same list with additional metadata. On my machine that list happens to be:

Supported Formats:
-------------------------------------------
com.adobe.pdf                pdf   Writable
com.adobe.photoshop-image    psd   Writable
com.adobe.raw-image          dng   
com.apple.atx                --    Writable
com.apple.icns               icns  Writable
com.apple.pict               pict  
com.canon.cr2-raw-image      cr2   
com.canon.cr3-raw-image      cr3   
com.canon.crw-raw-image      crw   
com.canon.tif-raw-image      tif   
com.compuserve.gif           gif   Writable
com.dxo.raw-image            dxo   
com.epson.raw-image          erf   
com.fuji.raw-image           raf   
com.hasselblad.3fr-raw-image 3fr   
com.hasselblad.fff-raw-image fff   
com.ilm.openexr-image        exr   Writable
com.kodak.raw-image          dcr   
com.konicaminolta.raw-image  mrw   
com.leafamerica.raw-image    mos   
com.leica.raw-image          raw   
com.leica.rwl-raw-image      rwl   
com.microsoft.bmp            bmp   Writable
com.microsoft.cur            --    
com.microsoft.dds            dds   Writable
com.microsoft.ico            ico   Writable
com.nikon.nrw-raw-image      nrw   
com.nikon.raw-image          nef   
com.olympus.or-raw-image     orf   
com.olympus.raw-image        orf   
com.olympus.sr-raw-image     orf   
com.panasonic.raw-image      raw   
com.panasonic.rw2-raw-image  rw2   
com.pentax.raw-image         pef   
com.phaseone.raw-image       iiq   
com.samsung.raw-image        srw   
com.sgi.sgi-image            sgi   
com.sony.arw-raw-image       arw   
com.sony.raw-image           srf   
com.sony.sr2-raw-image       sr2   
com.truevision.tga-image     tga   Writable
org.khronos.astc             astc  Writable
org.khronos.ktx              ktx   Writable
org.khronos.ktx2             --    Writable
org.webmproject.webp         webp  
public.avci                  avci  
public.avif                  avif  
public.avis                  --    
public.heic                  heic  Writable
public.heics                 heics Writable
public.heif                  heif  
public.jpeg                  jpeg  Writable
public.jpeg-2000             jp2   Writable
public.jpeg-xl               jxl   
public.mpo-image             mpo   
public.pbm                   pbm   Writable
public.png                   png   Writable
public.pvr                   pvr   Writable
public.radiance              pic   
public.svg-image             svg   
public.tiff                  tiff  Writable

An NSImage can have multiple ‘representations‘. These are essentially just different versions of the image. One representation might be the original vector form (e.g. an NSPDFImageRep). Another might be a rasterisation of that at a certain resolution. Yet another might be a rasterisation at a different resolution.

It gets more complicated, however, because some representations are merely proxies for other frameworks’ representations, like CGImage, CIImage or somesuch.

Nonetheless, for the simple case of a static bitmap image read from a file, generally NSImage produces just one representation, which is the full bitmap (as an NSBitmapImageRep). That’s the only case I’m going to discuss here, for simplicity’s sake (though likely the lessons apply to the other cases too).

Accessing / using an NSImage

Generally to use an NSImage you need a bitmap representation. e.g. to actually draw it to the screen.

Unless you manually create an NSImage from an in-memory bitmap, the bitmap representation is not loaded initially, but rather only when first needed.

Ultimately the load is triggered when something asks for the raw bytes of the bitmap (either you, directly in your code, or indirectly when you e.g. ask AppKit to draw the image).

Fetching the raw bytes of a bitmap from NSBitmapImageRep is not a trivial exercise. I’m going to gloss over the complexities (like planar data formats) and just talk about the common case of single-plane (“interleaved channels”) bitmaps.

For those, you can access the raw bytes via the bitmapData property.

Nominally, bitmapData just returns a uint8_t*.

In fact, bitmapData calls a lot of internal methods in a complicated fashion, with many possible code paths. What exactly it does depends on the underlying source of data, but in a nutshell it checks if the desired data has already been created / loaded (it’s cached in an instance variable) and if not it loads it, e.g. by calling CGImageSourceCreateImageAtIndex.

That’s what makes NSImage dangerous to use from multiple threads simultaneously.

Reading the cached bitmap data is essentially read-only (just some retain/autorelease traffic) so it’s safe to call from multiple threads concurrently (as long as something ensures the NSBitmapImageRep is kept alive the whole time and not mutated)

But loading or modifying it is not. As such, if you call bitmapData from multiple threads concurrently, and you don’t know for sure that it’s already fully loaded, you get a data race (also known as a “WTF does my app crash randomly?!” condition).

The consequences of that race vary. Maybe you “win” the race – one thread happens to run virtually to completion of bitmapData first, storing the fresh backing data into the caching instance member, and then all the other threads run and just return that same value – the ideal situation as everything works as intended.

Maybe you “lose” the race: every concurrent thread checks simultaneously and sees there’s no cached value, so they all – in parallel and redundant to each other – load the bitmap data and store it into the cache. They each return the one they created, even though ultimately only one thread wins – the last one to write into the cache – and the duplicate bitmap data that all the earlier threads created is deallocated. Even though pointers to them have been returned to you. And you might be in the middle of using them. Causing you to crash with a memory protection fault (or worse, read from some random other memory allocation that happened to be placed at the same address afterwards, reading essentially garbage).

Hypocritically, this is because Apple don’t follow their own rules on escaping pointers:

The pointer you pass to the function is only guaranteed to be valid for the duration of the function call. Do not persist the pointer and access it after the function has returned.

Apple’s Swift Standard Library > Manual Memory Management > Calling Functions With Pointer Parameters, subsection Pass a Constant Pointer as a Parameter.

The source code for the relevant NSBitmapImageRep methods is essentially:

- (uint8_t*)bitmapData {
    uint8_t **result = nil;
    [self getBitmapDataPlanes:&result];
    return *result;
}

- (void)getBitmapDataPlanes:(uint8_t***)output {
    [self _performBlockUsingBackingMutableData:^void (uint8_t* dataPlanes[5]) {
        *output = dataPlanes;
    }];
}

🤦‍♂️

Unfortunately, while _performBlockUsingBackingMutableData and its many similar siblings can be made safe, they are (a) all private and (b) not currently enforcing the necessary mutual exclusion. This could be corrected by Apple in future (although I wouldn’t hold your breath).

Why does it matter that NSImage is not thread-safe?

The crux of the problem is that you often have no good choice about it, because NSImage is a currency type used widely throughout Apple’s own frameworks, and you often have no control over what thread it’s created or used on.

For example, even using the very latest Apple APIs such as SwiftUI’s dropDestination(for:action:isTargeted:), you cannot control which thread the NSImages are created on (it appears to be the main thread, although that API provides no guarantees).

Similarly you have no control over where those images are used if you pass them to 3rd party code – including Apple’s. e.g. Image(nsImage:); possibly that only uses them on the main thread, but it might be pre-rendered the image a separate thread for better performance (to avoid blocking the main thread and causing the app to hang). In fact it should, in principle.

Loading an image – actually reading it from a file or URL and decompressing it into a raw bitmap suitable for drawing to the screen – should never be done on the main thread, because it can take a long time. A 1 GiB TIFF takes nearly 30 seconds on my iMac Pro, for example (and TIFF uses very lightweight compression, so it’s a relatively fast-to-read format). Anything involving the network could take an unbounded amount of time. Even small files – like a 20 MiB NEF – can take seconds to render because they are non-trivial to decode and/or decompress.

So you’re screwed on multiple levels: not only can you generally not guarantee what thread NSImage is born on nor used on, you can’t use it exclusively on the main thread because that will cause a terrible user experience.

What can you do?

In simple terms, the best you can realistically do is try ensure that all modifications to the NSImage (including implicit ones, such as loading a bitmap representation upon first use) happen exclusively in one thread [at a time]. For example, in my experiments, putting a lock around otherwise concurrent calls to bitmapData is enough to prevent any data races. Although I am mystified as to how I can still let the main thread draw the image concurrently without any apparent problems. 🤔

If you want to play it really safe, you have to create & pre-load each NSImage on a single thread (not the main thread), before ever sending it to another isolation domain. That means manually reimplementing things like drag and drop of images (because you can no longer work directly with NSImage with any drag & drop APIs, you have to instead use only – and all – the things that could potentially be images, like URLs or data blobs, and then translate those to & from NSImages manually).

Complicating all this is that NSImage is unclear about how its caching works. For starters, does this caching apply to the representations or is it a hidden, orthogonal system? Is it thread-safe? Etc.

You can supposedly modify the caching behaviour via the cacheMode property, but in my experience there is no apparent effect no matter what it is set it to (not on the image’s representations nor on render performance in the GUI).

It’s a shame that NSImage has been so neglected, and has so many glaring problems. Over the years Apple have seemingly tried to replace it, introducing new image types over and over again, but all that’s done is made everything more complicated.

$ ls -lh /System/Library/Frameworks/AppKit.framework/Versions/Current/AppKit
ls: /System/Library/Frameworks/AppKit.framework/Versions/Current/AppKit: No such file or directory

WTF, mate?

Invariably I spend half an hour websearching around to try to figure out how the hell my system got so broken, and how it’s possible to even boot macOS in such a corrupt state, until finally I chance upon Michael Tsai’s excellent summary of how Apple broke their frameworks starting in Big Sur.

The good news for Hopper is that it has since been updated to work around this – you can access the Apple framework binaries through File > Read File from DYLD Cache… There’s also tools like dyld-shared-cache-extractor which can resurrect the binaries from the cache.

Note also that in Sonoma, at least, the cache lives at /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/ (in previous macOS releases it was apparently in /System/Library/dyld/).

It immediately reminded me of the Shark 5 re-implementation of the profiling interface between the kernel and Shark. Shark 5 of course didn’t actually survive to birth – it was snuffed out by politics and, admittedly, a bit of our own hubris in the Shark team – but that underlying infrastructure did, as the guts of Instruments‘ Time Profiler and System Trace features.

In Shark 4 and earlier, userspace would allocate a single big buffer of memory for the profiling data, hand it [back] to the kernel¹, the kernel – specifically the Shark kernel extension – would write into that buffer, then when the buffer was full profiling would end². The userspace driver – Shark – could technically start profiling again immediately, but of course you’d often have a gap in your profiling – potentially a big one, for the more expensive profiling modes (e.g. System Trace) or on heavily-loaded machines. Shark didn’t run with elevated priority, as far as I recall, so it could get crowded off the CPU(s) by other programs. All communication between user & kernel spaces was via Mach messages, which are ultimately syscalls, and was time-sensitive since kernel- & user-space had to be in lock-step all the time.

For Shark 5, we wanted to up the ante and remove limitations. We wanted to be able to record indefinitely, limited only by disk space. More importantly, we also wanted to be able show profiling results live.

So, we – and I use the term loosely, as I think it was mostly Rick Altherr with possibly the help of Ryan du Bois – came up with a mechanism that’s very similar to io_uring, but years earlier, in ~2008. Userspace would allocate multiple smaller buffers – also easier to acquire given the requirement to be physically contiguous – and hand those to the kernel somewhat as needed. Userspace merely needed to stay ahead of the kernel’s use, which didn’t necessarily mean pre-allocating all the buffers. When each of those individual buffers filled up with profiling data from the kernel, they’d be made available back to the userspace side³. Shark (in userspace) would optionally – if in ‘live’ mode or if running short on empty buffers – process those buffers while profiling was still actively occurring, freeing them up to go back into the ring for the kernel’s use. It did mean you slightly increased the probability of perturbing the program(s) under profiling, but that was mostly just a matter of ensuring the buffers were large enough to sufficiently amortise the cost of their processing & handling. I don’t recall the extent of the processing, but I think it was not necessarily much more than copying the data out into non-wired memory (maybe even a memory-mapped file?). That was cheaper than allocating and wiring new buffers.

It worked really well, and is possibly still the implementation used to date – while it appears a lot of the frameworks (e.g. CoreProfile) have disappeared from macOS, presumably rewritten somewhere else, I’d be surprised if the kernel-user interface itself has changed much. It was pretty much perfect.

The creation of this new, superior profiling system also spurred me to create rample, a CLI tool kind of like top which showed you what your CPUs were doing in real time⁴ as a heavy tree, much like you’d get in a Time Profile in Shark (and later Instruments). It was super quick to write – just a day or two, I believe – and yet I unexpectedly found that it was more useful than Shark itself. Being able to see – practically instantly by virtue of how lightweight it is to launch a simple CLI program – what’s chewing on the CPU, including inside the kernel, was incredibly useful. Instruments is the closest you can get today on a Mac, but it’s super slow and clunky in comparison. It’s one of my top regrets, of my time at Apple, that I didn’t get rample into Mac OS X, or at least into the Dev Tools.

1. I don’t recall precisely why, but it was apparently better (or only possible?) to allocate the buffer in userspace, even though that was ultimately done with syscalls serviced by the kernel. I think it had something to do with being easier to handle failures, like being out of memory, in particular contiguous memory – the memory was wired during use to ensure the kernel wouldn’t have to deal with the practical nor performance problems of page faults while recording profiling data. ↩︎
2. Which was a problem because generally profiling sessions were specified to run for a specific time duration, by the end-user. So the buffer had to be sized to avoid filling prematurely, which meant wasting memory. ↩︎
3. Technically they were always available – we didn’t bother changing access permissions – but the userspace app would coordinate with the kernel via an elegant lockfree state machine. That state machine was a superb design – it deserves its own detailed nostalgia trip. ↩︎
4. Well, updated every second or so, like top. ↩︎

macOS keyboard shortcuts quiz

⌃⌥⇧⌘🤔

1 / 32

Some important notes before we begin:

• This quiz assumes default system settings on macOS 14 Sonoma with a generic Apple English keyboard and locale.

• This quiz considers only native Mac behaviour.

• You can click ‘Next’ without selecting an answer, but that skips the question and counts as a wrong answer in your final score.

• You cannot change your choice after clicking / tapping an answer.

 

Now, before we begin for real, let’s make sure you understand how quizzes work.  Do you understand how quizzes work?

Yes

No

This is going to be fun for you, then. 😝

2 / 32

What does this symbol mean:

⌘

Command

Apple

Function

Option

Place of interest

Control

A little bit of history

The Command key symbol, also known as the “looped square”, “Saint John’s Arms”, “Bowen knot”, “clover”, or “propeller” symbol, first appeared on the keyboard & in the menus of the original Macintosh (1984).

It replaced the use of the Apple logo () on the Apple keys that were present on the keyboards for the Apple IIe, Apple III, and the Lisa.  Unlike its predecessors, the Macintosh would show the keyboard shortcuts for menu commands in the menus themselves, using symbols for modifier keys like Command.  Since the symbol would be displayed many times all over the menus, Steve Jobs felt use of the Apple logo would be dilute its value.  He tasked Susan Kare, principal & beloved visual designer for the original Macintosh, to come up with a new symbol.  She found the iconic symbol after pouring through book collections of symbols, looking for something ‘abstract’.  It had previously been used very little, mainly just as a ‘place of interest’ indicator on maps in some Nordic countries.

In Unicode it is formally still the “Place of interest sign”, even though most of the world now knows it as the Command key symbol.

The Apple logo persisted alongside ⌘ on the key until 2007!

See its origin for yourself in Macintosh System 1.0!

3 / 32

What does this symbol mean:

⌥

Place of interest

Option

Apple

Command

Control

Function

A [very] little bit of history

The Option key replaced the Closed Apple key () from pre-Macintosh Apple computers, for the same reason that the Open Apple key was replaced with the Command key – to reduce repetition of the Apple logo in the Mac GUI.

It seems to be unknown or at least undocumented as to how the symbol was chosen.

4 / 32

What does this symbol mean:

⌃

Option

Place of interest

Control

Function

Apple

Command

A little history

The use of a caret (also known as a chevron or circumflex) to symbolise the Control key appears to date back to at least the PDP-6 era (1963), where an upwards-pointing arrow was used.  That symbol was part of the very first ASCII standard (ASA standard X3.4-1963) as 0x5E, but a few years later that character was changed to the now-familiar caret (I believe in X3.4-1967, although the closest I can find an actual copy of is X3.4-1968).  You can read the full history of ASCII, if you’re interested.

5 / 32

What does this symbol mean:

⇧

Control

Command

Option

Shift

Function

Apple

It’s been the same shortcut since the original Macintosh.

6 / 32

How do you take a fullscreen screen shot?

⇧⌘4

PrtScn

⇧⌘3

⌘P

⌃⌘P

Fun fact:  Apple’s very first operating system technical note, OS01, was to call out the existence of command-shift-N shortcuts, including ⇧⌘3.

⇧⌘4 also existed from the beginning, although its original behaviour was to print the active window (or the whole screen if Caps Lock was enabled), rather than save to a file!

7 / 32

How do you cycle through open applications (in order from most recently used to least)?

⌃⌘→

⌘]

⌃→

⌘⇥

⇧⌘A

⌘`

Tip: ⇧⌘⇥ cycles in the opposite direction, i.e. least recently used application first.

Pro tip: you can release the ⇥ key while still holding ⌘ to keep the application switcher on screen.  You can then hit ⇥ or ⇧⇥ successive times to move through the applications at your own pace.  Or interact with them via the mouse (including dropping things onto them, such as files to open).

8 / 32

How do you minimise the active window?

⌘H

⌘W

⌘C

⌘M

9 / 32

How do you insert an ellipsis (…)?

⌥;

⇧⌥.

⇧⌥;

⌥.

In some applications you can also just type three periods followed by a space, and auto-replacement will turn the three periods into an actual ellipsis.  But this is not reliable across applications, even amongst native Mac apps.

10 / 32

What does this do in the Finder:

⇧⌘A

Selects all files (but not folders)

Selects all items

Jumps to the Applications folder

Creates a zip archive of the selected items

Creates an alias of the select item(s)

11 / 32

In a native Mac program, how do you hyperlink the selected text (where applicable)?

⌘K

⌥⌘U

⌘L

⌃⌘H

12 / 32

What do these do:

⌥⌘C / ⌥⌘V

Copy / paste text, removing styling information

Cut text / paste and clear the clipboard

Copy / paste text styling

Copy / paste text

Clear / reset the current text field

Nothing (beeps)

13 / 32

How do you type the  symbol?

⌥⇧K

⌃⌘A

⌥A

⌥5

14 / 32

How do you cycle through open windows within the active application?

⌘`

⌃⌘→

⌃→

⇧⌘A

⌘⇥

⌘]

Tip: you can use ⇧⌘` to cycle through the windows in the reverse order.

15 / 32

How do you show the dictionary definition of the selected word (or phrase)?

⌥⌘D

Trick question: there is no such shortcut

⇧⌘D

⌃⌘D

Tip: Apple build in a large number of translating dictionaries, e.g. for Spanish to English.  They provide translations and definitions in your native language.  You can enable them in the Settings for the Dictionary app.

Pro tip: Apple include a special dictionary of proper nouns for Apple products, such as macOS releases.  Helpful if you can’t remember the name of the operating system you were running just last year. 😜

16 / 32

In a native Mac application, the Home key moves the focus point to the beginning of the…

Paragraph

Word

Document

Page

Line

Tip: in non-native applications which get this wrong, an alternative shortcut that they sometimes get right is ⌘↑.

17 / 32

When clicking a disclosure triangle in a hierarchical list view, what modifier causes it to expand / contract the target item and all its children recursively?

⌃

⌥

⌘

⇧

18 / 32

How do you jump to your Documents folder in the Finder?

⇧⌘G

⇧⌘H

⇧⌘D

⇧⌘O

Don’t feel too bad, I get this wrong every single time, too.  It’s an incredibly poor design choice, on Apple’s part, to use ⇧⌘D for the desktop folder.

19 / 32

How do you cycle through find results in reverse order?

⌥←

⇧⌘G

⌃⌘R

⌥F

20 / 32

What is the traditional Mac way to cancel an operation?

⌘.

⇧⌘S

⌃C

Brk

⎋

⌃⌥⌫

Don’t feel too bad – this isn’t a well-supported shortcut.  Since Mac OS X, ⎋ is sometimes used as well (bleeding over from Windows) and ⌃C likewise from Unix.

21 / 32

What modifier key do you use to show a Spotlight file result in the Finder?

Fn

⇧

⌃

⌥

⌘

22 / 32

What does this do:

⌥⌘Space

Opens Spotlight

Opens Control Centre

Opens a Finder window with the search field selected

Inserts a non-breaking space character

23 / 32

How do you record a video of the screen (or a subset thereof)?

No shortcut, only through Quicktime Player

⇧⌘3 held down for at least one second

⇧⌘5

⌃⇧⌘R

⇧⌘4, then hold M while selecting the target region

No shortcut, only through 3rd party programs

Strictly-speaking this doesn’t record only a video – it brings up a palette which lets you choose between stills & video, among other configuration options.

This feature was introduced relatively recently, in macOS 10.14 Mojave (2018), as part of the addition of the Screenshot app to macOS.

Tip: similar to ⇧⌘4, ⇧⌘5 lets you choose a specific region of the screen.  However, unlike ⇧⌘4, your chosen region persists across invocations – making it trivial to capture the exact same region of your screen repeatedly.  Very convenient for marketing shots (e.g. light vs dark mode versions).

24 / 32

In a native Mac app, how do you toggle full screen mode?

⌘⏎

⌥⏎

⌃⌘F

⌥⌘↑

⌘F

25 / 32

With the cursor at the start of a word, how do you select the word?

⌥⇧→

⇧⌘→

⌃⇧W

⇧⇟

Option-arrows, the various modifications thereof, are handy text editing utilities.  For completeness:

⌥← / ⌥→ move the cursor to the start or end (respectively) of the word (in the given direction), jumping word-by-word as necessary.

⌥↑ / ⌥↓ move the cursor to the start or end (respectively) of the paragraph (in the given direction), jumping paragraph-by-paragraph as necessary.

⌘← / ⌘→ move the cursor to the start or end (respectively) of the current line (the equivalent of Home and End on some other platforms).

All of these can be combined with ⇧ to select text as the cursor moves.

It sometimes doesn’t work if you use a Windows keyboard.

26 / 32

On a PowerPC or Intel Mac, what do you hold down after hitting the power button in order to enter recovery mode?

D

⌘R

⌘V

⌥⌘PR

T

The mouse / trackpad button

R

⌥

It’s not the same as on PPC and Intel Macs.

27 / 32

On an Apple Silicon Mac, what do you hold down after hitting the power button in order to select the startup disk?

The power button

⇧

⌘

The mouse / trackpad button

R

⌥

D

T

28 / 32

In the Finder, what can this do (depending on what is selected – choose all that apply):

⌘R

Moves the selected item(s) to the bin

Rotates the selected image(s) 90°

Renames the selected item(s)

Shows the target of the selected alias / symlink

Removes (hides) the file extension of the selected item(s)

Refreshes the current window

Many a Mac newbie has accidentally rotated their images when they merely meant to rename them. 😕

Sidenote

Introduced in System 7, aliases are the Mac version of a Unix symlink or Windows shortcut.  They are still nominally supported to this day in macOS, although many applications – even otherwise well-written, native ones – do not handle them correctly.  Most Unix applications, such as almost everything you find through Terminal, will not resolve aliases to their targets, even when those same programs work correctly with symlinks and hardlinks.  Not because they explicitly support those either, but because in macOS aliases are not automatically resolved by the Unix file system APIs, and curious and unfortunate design choice on Apple’s part.

As a result, aliases were forced out of typical use by Mac OS X.  Today they are rare in the wild.

Which is a shame, because they were technically far superior to symlinks.  Rather than merely storing a brittle path, as symlinks do, they stored a detailed and partially-redundant set of identifiers, making them maintain their link even if the original is moved or renamed, for example.  Unfortunately, Apple broke this behaviour as of Mac OS X 10.2 Jaguar, further cementing the demise of the alias.

29 / 32

How do you bring up the Character Viewer (also known as the Character Picker, Unicode Picker, or Emoji Picker)?

⌥⌘P

⌃⌘Space

⌃E

⌃⌥⇧⌘C

Tip: make sure to explore its Settings (the ⋯⃝ pop-up menu button in the top-left corner) to see the full range of available character categories.  By default only a small handful are enabled.

Note: on some Macs, Fn-E also works.  It is not listed here because it is not the canonical shortcut, only works on some Macs (those that have a Fn key), and only since about macOS Big Sur.  It also has a habitat of not working reliably even on Macs which meet both those criteria.

Meta-trivia: in an earlier version of this quiz, Fn-E was actually listed as an option, but not accepted – whoops!  The quiz has since been corrected to not list it as an option, to avoid confusion.  Of the options given (and on many Macs) ⌃⌘Space is the only correct answer.

30 / 32

In a text field, what does ⌃E do?

Moves the cursor to the end of the line

Ends editing (removes focus from the field)

Erases the rest of the line

Erases the current line

Scrolls to the bottom

31 / 32

What does this do:

⌥Space

Inserts a space character after the cursor

Inserts a non-breaking space character

Opens Control Centre

Actives Spaces / Mission Control

Opens Spotlight

Tip: lots of input validation code is very badly written, especially in websites (as opposed to e.g. native apps).  You can often get around “no spaces” restrictions with the non-breaking space character.

32 / 32

How do you paste text as “plain text” (adopting the existing style at the insertion point, rather than any styling from the original cut or copied text)?

⌥⌘V

⌘V

⌃⌘V

⌥⇧⌘V

If you encounter any answers you believe are incorrect, please comment below.

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.

iTools

Long before iCloud, iTools was was of Apple’s first forays into web services as we recognise them today. The headlining features were the ability to create an email address (free!) under the @mac.com domain (which I still use to this day!) and an online file storage and sharing system called iDisk, which was the foundation for several other services & tools within the bundle including HomePage and Backup.

Backup wasn’t exclusively tied to iDisk, and I used it (in the later .Mac era) for a couple of years to backup my essential documents to iDisk and my entire computer to a external hard drives and CDs. I think it was my first real backup system…? And I still have all those backups!

I don’t recall that I used iTools, or at least not in any serious way. I was still in high school when it came out (just), going into university, and I recall using my university email address during that time.

If I remember correctly, iTools was pretty well received by actual users but panned critically, with the press and technorati unimpressed by it in light of antecedents like Hotmail (launched three years earlier in 1997) and numerous existing “DIY” website builders and free webhosts (GeoCities!).

There was also some resentment due to its Mac-only nature, although technically most of the services worked through a web browser on any platform, you just couldn’t create an account except on a Mac.

Remember, too, that Mac OS X didn’t exist when iTools launched. It was Mac OS 9 – retroactively named “Classic Mac OS” re. Rosetta etc – and for Mac users the world was a very different place. Once Mac OS X did launch, iTools became even better with integration into the Finder (for iDisk). This was over six years before Dropbox even existed.

Hotmail and lesser known contemporaries pioneered free email, but with tight limits on usage (e.g. only 2 MB of email storage, enough for about two modern spam emails!). .Mac offered 50 MB (upgradable to 2 GB for a fee). This was three years before Gmail was launched, too (at which time the word “unlimited” started to get thrown around, although technically Gmail only offered 1 GB initially).

My old website dates back to at the latest September 2005 when I launched my blog, although I’m pretty sure I’d been using it for quite some time before that (though the Wayback Machine didn’t notice it for three more years, until September 2008 😂).

It took a little bit of effort to get it functioning again – it contained a lot of references to 3rd party resources (Google Adsense & Analytics, Haloscan, etc) that are no longer valid / necessary, as well as to some more intrinsic .Mac HomePage functionality that’s long gone, like iDisk (the early file-sharing functionality a la Dropbox / iCloud Drive). I pruned out most of that for the sake of removing long-dead, broken links & images.

.Mac

.Mac was a relaunch of iTools – a major version update in technical terms, but also a major departure in that it was no longer free for all Mac users. You now had to buy it! For actual money! And keep paying for it, every year, like a caveman! $100!

I still remember receiving an actual box for .Mac, and I suspect that was when I first really used the service. I think I might have received it through the AUC as part of their scholarship program which effectively launched my career, lining me up to work at Apple, move to California, and all the rest.

As for .Mac, it was somewhat ill-received, and despite Apple bragging about receiving 100,000 sign-ups, the general attitude was that it was too little for too much. It didn’t help that it then went years without much improvement or attention from Apple.

The name was a bit weird, too – clearly playing on the .com TLD, but in an era long before the expansion of TLDs, back when there was basically just .com, .net, .org, and .edu¹. It’s interesting that to this day there’s still no .mac TLD (although there is .apple, albeit for no apparent reason since it’s retained by Apple for their exclusive use, and they don’t use it).

Years later, in 2008, it was rebranded and “relaunched” yet again as MobileMe. I for one don’t recall ever having significant issues with MobileMe, but it was widely lambasted for being unreliable. I certainly don’t think it was any worse than iCloud (especially in light of macOS Sonoma’s catastrophic embuggering of iCloud Drive).

Incidentally, as part of this trip down memory lane, I also went through and fixed the broken images on my very earliest blog posts, that didn’t originally import into WordPress when I migrated off of MobileMe HomePage in 2012, when the product was shut down by Apple (in favour of iCloud, which was mostly a PR move to distance themselves from perceived reliability problems with MobileMe – notably not an actual improvement in reliability, which to this day remains sorely needed).

1. Well, plus .gov and .mil, but regular people never encountered those in everyday life. ↩︎

So I didn’t buy an M1 Ultra.

The M2 was announced in July 2022. The M2 Ultra wasn’t announced for another eleven months, in June 2023, and offered only a small performance gain over its predecessor. There were rumours that the M3 was right around the corner (and it was, released just four months later). Worse, the M3 Pro and Max were released simultaneous to the base M3, and the M3 Max actually outperforms the M2 Ultra in many workloads.

So I didn’t buy an M2 Ultra.

So now the question is: when will the M3 Ultra come out? If it takes eleven to sixteen months, like its predecessors, then we’ll be expecting the M4 by then, and this sad cycle will have repeated yet again.

Will I buy an M3 Ultra?

I hope so, but it’s up to Apple.

It’s also highly problematic when new versions are flat-out broken. Starting with around STP 124 I started experiencing consistent crashes on some websites, making them completely unusable in STP. For the time-being I chose to use them separately in regular Safari, on the assumption that these egregious issues would be quickly fixed in the next STP version. Well, three versions later and those bugs have not been fixed. Not even close.

Now, with STP 126, it crashes on launch. Every time.

Well, thankfully there are places where you can obtain the prior versions, even if Apple won’t provide them. My preference is The Wayback Machine – you can start with this calendar, from which you can pick a date and (with any luck) the download page for that date will point to the version you want. You then download the disc image, delete the current copy of STP from your Applications folder (otherwise the pkg installer for the older version will refuse to work), and re-install the older version.

Once you’ve done that, make sure to turn Automatic Updates off in System Preferences, otherwise Apple will just trash your working version with the broken one again.

If you appreciate that – I certainly did; I like having a web browser that doesn’t crash on launch – remember that The Wayback Machine is run by the Internet Archive, a non-profit group, and they can always use monetary support as well as volunteers.

P.S. Yes, I’m aware that their donation page is sadly a bit janky. If you’re a web developer or designer, maybe you could volunteer some of your time to improve it? 😁

I started out as a one-person shop, doing my own things, selling shareware. I had no manager nor technical lead. I had to make all my own decisions, in all aspects, without guidance or assistance.

Subsequently, during my four years at Apple, I did have a manager, but they focused on people, not the technical – myself and/or my colleagues collectively made the technical decisions, and provided technical leadership, and effectively set the product direction. My managers were there to make that as easy as possible for us.

Over my nearly eight years at Google, I observed the tail half of a major cultural transition for Google. Long before I started, Google had explicitly laid down a culture where managers were not product / technical leads. The two roles were physically separated, between different people, and they operated independently. Managers focused on people – career growth, happiness, basic productivity, & skills – while tech leads focused on the technical, the product. In fact the manager role was so principled about focus on people that managers would sometimes help their direct reports leave the company, if that was simply what was best for those people for their own success & growth. And, to be clear, not in a “you aren’t working out” sense, but for engineers that were excellent and simply didn’t have deserved opportunities available to them at Google.

By the time I joined, that culture was half-gone, but still present enough in my division for me to experience it. But by the time I left the culture was heavily weighted towards managers being technical leads.

In my nearly three years now at LinkedIn, I’ve completed that arc. LinkedIn culturally & executively emphasises managers as technical / product leads even moreso than Google ever did. As far as I’ve been told, LinkedIn always has (meaning, this is presumably the culture Yahoo had too, from which LinkedIn forked).

Having experienced most of this spectrum, I finally feel qualified to pass judgement on it.

I immediately, intuitively recognised & appreciated this at Google, but now I’m certain of it.

People management & (technical) product leadership are fundamentally at odds with each other. The needs of individuals are often at odds with the needs of the product. The product might need Natalie to really focus on churning through a bunch of menial tasks, but to evolve, Natalie might really need design experience & leadership opportunities.

Having one person (in authority) try to wear both hats creates conflict, bias, and inefficiency. It discourages dialogue, because you can never really trust where the polymorph stands. The roles require different skillsets, which rarely coexist in a single person and in any case are difficult to keep up to date in parallel. Context-switching between them is burdensome. It creates a power imbalance and perverse incentives.

Even if an individual is exceptionally talented at mitigating those problems, they simply don’t have the time to do both well. Being a product or technical lead is at least a full-time job. Likewise, helping a team of any real size grow as individuals requires way more hands-on, one-on-one attention than most people realise. It’s hard enough being good at either one of them alone – anyone that attempts doing both simultaneously ends up doing neither effectively.

I’ve had the opportunity to be both a technical lead only and a manager only. This is quite rare in the tech industry. I deeply appreciated being able to focus on just one of those roles at a time. I could be consistent, deliberate, and honest. I could, as a manager, tell people exactly what I thought they should or shouldn’t work on, irrespective of what the product(s) need, because I knew the technical lead(s) would worry about those angles. Conversely, when I was a technical lead, I could lay out what was simply, objectively best for the project, uncomplicated by individuals’ interests. In either case, there was real, other human being that could be debated with, as necessary, to find happy mediums.

Yet beyond just being more efficient and effective, the serendipitous consequence was that it gave agency to the individuals – whenever a conflict arose between people and products, it was revealed to them, and the implicit decision about it at least in part theirs to make. Most importantly, they knew that whichever way they leaned they had someone in their corner who had their back.

(Of course, sometimes they didn’t like having to make that decision, but putting it on them forced them to take control and responsibility for themselves, and evolve into more confident, happy, motivated developers.)

I suppose it’s no surprise that companies tends this way – to conflate people with products. These days, for many big tech companies, people literally are the products, and their humanity inevitably stripped away in the process. People are “promoted” into management from technical positions, and often by way of the Peter Principle, are not actually good people managers, nor able to relinquish their former role and ways of thinking. A hierarchy of technical leads in manager’s clothing becomes self-sustaining, self-selecting, and self-enforcing.

The question is: what’s the antidote?

Acknowledgement: I was inspired to pen this post by reading Tanner Wortham‘s Why Manager as Product Owner Will Usually Fail, which is essentially positing the same thing albeit in different terminology.

I don’t recall why exactly, but evidently I had to write some kind of cover letter in order to intern at Apple. I don’t even know if this was addressed to Apple, or was perhaps just part of the visa process.

Statement of Motivation

My internship offered at Apple Computer Inc. is a fantastic opportunity for me to be introduced to and get involved with one of the worlds leading and most innovative technology companies.  It will provide exposure to their current – and possibly future – hardware products, as well as the processes by which they develop them.

Additionally, the time in the U.S.A. will provide exposure to U.S. culture and general life, which will be an invaluable grounding should I pursue further work in the U.S.A. (at a later date).  While I have no immediate plans to do so, I would certainly like to have the option, as the U.S.A. is the worldwide hub for development of advanced computer technology – the best place for someone in my industry to end up.

In terms of furthering my studies and career, the impact is almost immeasurable.  My employability – not just in Australia, but also internationally – will be increased tremendously by the internship, both from the training and experience provided as well as from the impressive addition it would make to any resume.  Specifically, I hope it will open the door to future employment at Apple Computer Inc.

On a personal level, I’d like to see a bit of North America as a tourist, as much as I can – visit all the cliché spots, like the Grand Canyon, Death Valley, Yosemite, all those.  I think it’d be a great experience, and hopefully a lot of fun.

21-year-old me, in 2005

I’ve been to all three of those places now. Two out of the three were indeed fun, as hoped.

A fun footnote was that the internship paid $25 US / hour, @ 40 hours per week. That was about $33 AUD / hour, given exchange rates at the time. That compared preeetty favourably with my prior internships – $18.50 AUD / hour at NEC, $15.79 AUD / hour at PIRVic – and beat the pants off the first real job I recall having, at a flower nursery, in high school, for an amazing $5 AUD / hour.