I have no idea what causes this. One solution is to restart the affected Mac – but that’s obviously very disruptive.

Another solution is to open the bin in the Finder (which works just fine, contrary to what the error message implies), select all, right-click, and choose “Delete immediately…”. And the bin is now empty. 🎉

What’s particularly interesting is that it’s presented in the context of programming languages. Its specification doesn’t really describe a general purpose programming language – the title is accurate in that it is a calculator language. But in context it seems implied that Jef had aspirations of turning it into something bigger. Something that might have been the programming language for the Macintosh (which turned out, instead, to be Pascal).

Furthermore, there’s an extensive addendum presenting Jef’s opinions on programming languages of the day – ALGOL, APL, BASIC, Cobol, Fortran, Lisp, Pascal, PL/1, SNOBOL – which I guess is what Jef felt were his ‘competition’ in some sense, or at least his predecessors; he clearly had aspirations towards creating a new language of his own. In time-honoured fashion, this is because he felt all existing languages weren’t good enough. 😆

Jef was especially not a fan of BASIC (which was the lingua franca at the time, for personal computers – ignoring assembly languages, at least) and didn’t mince words about it:

He wasn’t wrong about its longevity. I wonder what he later thought (he lived until 2005) of Visual Basic, RealBasic, and all their derivatives…

On Fortran, PL/1, and Pascal – the latter being used heavily on the Macintosh, until Mac OS X – he seemed… bitter? A little resentful of their success? Of them, he said:

He didn’t think much of Lisp, either, which heavily inspired Smalltalk and in turn Objective-C.

But on APL, he really can’t say enough good things – he has an entire section on singing its praises (as he saw them). It’s too much to quote here, but I suggest you read it.

While it’s true that APL did somewhat influence C/C++, and arguably Python, overall APL proved to be a dead-end in the programming language evolutionary tree. Looking back at it now, with modern sensibilities, its syntax looks like a parody, an absurdism – something someone invented so they could basically cheat on the Obfuscated C Code Contest.

Which – and thank you for bearing with me as I meander to my point – is why it’s all the more startling to me that his little “Apple Calculator Language” is actually so darn appealing. The simplicity of left-to-right evaluation, the surprising elegance of his “clumps”… there’s something about this which I find surprisingly refreshing.

Reading about it in his spec is a bit dry, so I – well, Claude Opus 5 – built a working implementation for our amusement!

You can get the 1M token context window back, though – you just have to enable Usage Credits. You don’t have to pay for any usage credits, nor turn on auto-reload, nor have a non-zero limit. You literally just have to have the Usage Credits toggle enabled. 🤷‍♂️

Why does the context window size matter? Especially for coding – where single tasks can be long-running and use very large numbers of tokens, for reading source files, mentally evaluating complex logic & control flow, and so forth – it’s important that everything fit into a single context window, for maximum efficacy of the model. If the model has to run compaction mid-way through a task, there’s a significant risk it’ll (a) ‘forget’ important details, and therefore make more mistakes, and (b) have to re-read or re-compute things, wasting tokens (i.e. your precious usage quota).

0.2M is pretty tiny by modern standards, and – because I do actually track token & context window usage somewhat, for edification if nothing else – I know that I regularly use far more than that in everyday coding tasks. In fact even 1M tokens isn’t a big enough window for the occasional task (though recent versions of Claude models tend to use subagents more aggressively, which helps avoid hitting the window limit – albeit at the expense of less token efficiency overall).

As to why Anthropic did this… I suppose it’s conceivable that they believe Opus 5 is so good at carrying context across compaction that it can get away with it? I haven’t tested it. That’d be wonderful, if true – a smaller context window is less computationally costly (and much less costly if you’re conversing back-and-forth a lot within a session).

This is because support for files larger than 4 GiB requires using the “ZIP64” zip file format, which would be fine except Apple’s notary servers can’t handle them. If you give them such a zip file, you’ll see notarytool fail something like this:

$ xcrun notarytool submit "MyScreenSaver.saver.zip" --apple-id user-id --team-id team-id --verbose --wait --password lovesecretgod
[02:33:46.871Z] Debug [MAIN] Running notarytool version: 1.1.0 (39), date: 2026-07-13T02:33:46Z, command: /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool submit MyScreenSaver.saver.zip --apple-id user-id --team-id team-id --verbose --wait --password private<String>
Conducting pre-submission checks for MyScreenSaver.saver.zip and initiating connection to the Apple notary service...
[02:33:46.943Z] Info [PREFLIGHT] Confirmed that MyScreenSaver.saver.zip (4.61 GB) is likely a PKZip file.
[02:33:46.943Z] Debug [PREFLIGHT] Finished completing determination of file type for MyScreenSaver.saver.zip. Operation took 71ms.
…
[05:09:56.690Z] Info [API] Preparing GET request to URL: https://appstoreconnect.apple.com/notary/v2/submissions/some-uuid?, Parameters: [:], Custom Headers: private<Dictionary<String, String>>
[05:09:56.690Z] Debug [AUTHENTICATION] Using cached token value for app-specific password request: team-id:user-id
[05:09:56.691Z] Debug [AUTHENTICATION] Authenticating request to '/notary/v2/submissions/some-uuid' with WebServices Token. AppleID: user-id, Team ID: team-id, Token: private<String>
[05:09:56.692Z] Debug [TASKMANAGER] Starting Task Manager loop to wait for asynchronous HTTP calls.
[05:09:57.115Z] Debug [API] Received response status code: 200, message: no error, URL: https://appstoreconnect.apple.com/notary/v2/submissions/some-uuid?, Correlation Key: some-key
[05:09:57.115Z] Debug [TASKMANAGER] Completed Task with ID 37 has received a parsable response.
[05:09:57.116Z] Debug [TASKMANAGER] Ending Task Manager loop.
[05:09:57.116Z] Info [API] Received new status: Invalid
Current status: Invalid....................................
[05:09:57.116Z] Info [API] Submission in terminal status: Invalid
Processing complete
  id: some-id
  status: Invalid
[05:09:57.138Z] Debug [CTXMGR] Removed temporary directory: Optional(file:///var/folders/v3/6w91zvg53dqgh_3fl858wtrh0000gn/T/TemporaryItems/NSIRD_notarytool_36y4rY/)

If you check the log, you’ll see absolutely nothing useful:

$ xcrun notarytool log --apple-id user-id --team-id team-id --password lovesecretgod some-uuid
{
  "logFormatVersion": 1,
  "jobId": "some-uuid",
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "statusCode": 4000,
  "archiveFilename": "MyScreenSaver.saver.zip",
  "uploadDate": "2026-07-13T05:02:27.652Z",
  "sha256": "cbafd582f7b3221af5f2930b9a97019da5275116610c46ad3874e7b392fd7196",
  "ticketContents": null,
  "issues": [
    {
      "severity": "error",
      "code": null,
      "path": "MyScreenSaver.saver.zip/MyScreenSaver.saver/Contents/MacOS/MyScreenSaver",
      "message": "The signature of the binary is invalid.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "MyScreenSaver.saver.zip/MyScreenSaver.saver/Contents/MacOS/MyScreenSaver",
      "message": "The signature of the binary is invalid.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
      "architecture": "arm64"
    }
  ]
}

The ‘help’ URLs it links to are useless, since the problem is an outright bug in Apple’s infrastructure, not the input binary or bundle. Indeed, Apple’s own tools confirm this:

$ codesign -vvv --deep --strict /Users/me/Documents/MyScreenSaver.saver 
/Users/me/Documents/MyScreenSaver.saver: valid on disk
/Users/me/Documents/MyScreenSaver.saver: satisfies its Designated Requirement

The only workaround I’ve been able to find is to package within a DMG instead.

For the record, Apple, this is a stupid error on your part. 😡 While trying to figure out what the hell was actually going on, I spent multiple hours scouring the web, and experimenting, to no avail. It took Claude Fable 5 a couple of hours too, but it finally cracked it.

It’s especially irritating that I was only using zip files as a workaround for a design flaw in Apple’s notarytool, whereby it won’t accept the app bundle directly. And it’s Apple themselves that recommend using zip files specifically.

And lastly, it’s flabbergasting that this problem exists given that ZIP64 was first released & publicly documented in 2001. It’s 25 years later – why aren’t Apple supporting it?! How did they even find a zip library that doesn’t support it? Did they write their own specially just to remove support for it? I cannot fathom how they’ve created this problem.

Async inside defer

SE-493

func f() async {
  await setUp()
  defer {
    await performAsyncTeardown()
  }
  
  try doSomething()
}

The enclosing context – the function “f” in the above example – must be async, of course. Type inference will work in closures, too; they’ll implicitly be async if they contain any awaits in defers.

// 'f' implicitly has type '() async -> ()'
let f = {
  defer { await g() }
}

Cautions:

• Use of async in defer adds additional suspension points to the end of the function. Though this is not much different from the existing hazard that defer introduces, in placing code obliquely at the end of the function.
• Task cancellation works like normal inside defer, so care needs to be taken that clean-up actually happens and isn’t short-circuited. Again, this is just the same as it’s always been for non-async code inside defer (though async code is more likely to check for and react to cancellation). But, it can be guarded against using…

Task cancellation shields

SE-504

This allows you to hide task cancellation status within a block (and stop automatic propagation of cancellation to subtasks). This is particularly helpful for clean-up code that wants to ensure it actually runs, even if it calls general helper functions that normally do observe cancellation.

func doWork() {
  while !Task.isCancelled {
    let result = crunchNumbers()
    await send(.latestResult, result)
  }
  
  // Clean up
  await send(.goodbye)
}

func send(_ type: MessageType, _ payload: Data? = nil) { 
  guard !Task.isCancelled else {
    return 
  }

  …
}

The ‘goodbye’ message in that example would never actually be sent, and worse that failure is completely silent (because you typically don’t want to log “Cancelled!” everywhere, as it’s very noisy in what may be a relatively common case – depending on how you & your dependencies use task cancellation).

With Swift 6.4 you can write:

func doWork() {
  while !Task.isCancelled {
    let result = crunchNumbers()
    await send(.latestResult, result)
  }
  
  // Clean up
  withTaskCancellationShield { 
    await send(.goodbye)
  }
}

func send(_ type: MessageType, _ payload: Data? = nil) { 
  guard !Task.isCancelled else {
    return 
  }

  …
}

send will read false from Task.isCancelled (as would any children, function- or structured-task-wise) and thus actually send the goodbye now.

Caution:

• Hiding cancellation status from arbitrary code might lead to unbounded delays in cancellation completing, because the code under the shield sees no reason to finish promptly. Cancellation usually has some degree of time-sensitivity, e.g. if a user cancelled the task – or asked the program to quit, cancelling any work in progress – then they might tolerate a few seconds of delay, but won’t be pleased if the program just “hangs” (takes so long they start questioning whether it’s actually cancelling at all).
• Since cancellation propagation to subtasks is blocked while the shield is in place, you may need to do extra work to ensure subtasks are appropriately cancelled (e.g. if you exit the cancellation shield ‘early’, you probably do want the subtasks to then cancel too – but you’ll have to explicitly cancel them yourself).
• Conversely, task cancellation shields do not block explicit cancellation of subtasks, so you must be careful wherever you have cancellation handlers or code that might show a little too much initiative in cancelling tasks.

Async Result Support

SE-530

Now there’s a way to initialise a Result from an async closure, through a new initialiser. It works exactly like you’d expect:

let result = await Result {
  try await asyncWork()
}

More standard library types support ~Escapable and ~Copyable

SE-499

As of Swift 6.4, these protocols will no longer require the conforming types to be Copyable and Escapable:

• Equatable
• Comparable
• Hashable
• CustomStringConvertible
• CustomDebugStringConvertible
• TextOutputStream
• TextOutputStreamable

Additionally, LosslessStringConvertible no longer requires Copyable, and both Optional and Result now support ~Copyable and ~Escapable elements. The latter is an especially big improvement for users of ~Copyable or ~Escapable types, given how fundamental (and nice!) Optional is to idiomatic Swift.

struct Handle: ~Copyable {
    var uuid: InlineArray<16, UInt8>
}

// Now valid in Swift 6.4, so you can e.g. use Handle as the key in a collection!
extension Handle: Hashable {
  static func == (lhs: borrowing Handle, rhs: borrowing Handle) -> Bool {
    lhs.uuid == rhs.uuid
  }
    
  func hash(into hasher: inout Hasher) {
    for b in bytes {
      hasher.combine(b)
    }
  }
}

// Now valid in Swift 6.4, so you can e.g. use Handle in log messages!
extension Handle: CustomDebugStringConvertible {
  var debugDescription: String {
    "Handle<\(uuid.description)>"
  }
}

// As of Swift 6.4, `createHandle` can return a `Handle?` like you'd expect!
guard let h = createHandle() else {
  return
}

handleCreationTimes[h] = .now

print("Created new handle: \(h)")

These are essentially bug fixes – these protocols never semantically required copyability or escapability, but because the notions of being non-copyable or non-escapable came longer after they were first defined, and the way Swift makes copyability and escapability the default, they needed their definitions to actually be changed in order to accomodate. It’s unfortunate that this wasn’t done when ~Copyable and ~Escapable were introduced in Swift 5.9 and 6.2 (respectively). Alas it’s common practice for the standard library to intentionally be left out of sync with the language (in some cases it’s because other dependencies, like borrowing, had to be developed in order to facilitate the fixes – the proposal notes that many more standard library types still need similar fixes, but lack the necessary compiler support).

Private member variables with default values are excluded (by default) from compiler-generated initialisers

SE-502

A mouthful to describe, but actually a simple change – the following code will now work, as of Swift 6.4, instead of failing with the error “initializer is inaccessible due to ‘private’ protection level”:

struct S {
  var x: Int
  var y: Int
  private var z = 0
}

let s = S(x: 1, y: 2)

Previously, the initialiser that the compiler implicitly generated looked like:

private init(x: Int, y: Int, z: Int = 0)

Now, it looks like:

init(x: Int, y: Int)

This makes it easier to use implicit initialisers by increasing the number of situations in which you can utilise them, and also makes it easier and safer to add additional private member variables later.

Caveats:

• If you were actually relying on the private member variable(s) being part of the initialiser – and didn’t mind the implicit access restriction – then this will ultimately be a regression. However, for now Swift continues to also provide the old initialiser, for backwards compatibility (but the intent is to remove it in a future Swift release). Also, it’s not foolproof – some uncommon cases will still see a source-incompatible change.
• This does not extend to open / public / package structs – if you have a struct accessible at one of those levels, its implicit initialiser will continue to behave as in prior versions of Swift, i.e. it will still include all the member variables and thus be limited to the accessibility of the most restricted variable. This is intentional, though – it’s to prevent module API changes.

Borrow and Mutate Accessors

SE-507

The final piece of the Prospective Vision for Accessors, this allows for more efficient accessors on structs, in a nutshell.

In older versions of Swift, a getter had to return [semantically] a copy of the value of interest. If that value was expensive to copy (e.g. a large struct) then that made the accessor slow. And it entirely precluded getters for ~Copyable types.

struct RigidWrapper<Element: ~Copyable>: ~Copyable {
  var _element: Element

  var element: Element {
    borrow {
      return _element
    }

    mutate {
      return &_element
    }
  }
}

Where inlining is permitted, the above code basically boils down to direct [indexed] pointer access to _element by all callers, without any safety concerns (the compiler continues to enforce correct lifetimes, access permissions, and mutual exclusion). That’s basically as efficient as it gets.

Like many of the Swift 6.4 features, this is of direct interest to only a few Swift users (e.g. authors of packages like swift-collections) or in uncommon cases (e.g. optimising the occasional hot-spot). But it will be beneficial to all Swift users by virtue of quietly faster and more efficient types in the standard library, Foundation, and other packages.

Caveats:

• These new accessor types are only supported on structs, not classes or actors, for now.
• You can only return a single variable, which must be deterministic at compile-time. So no if xyz { return _a } else { return _b }.
• The returned values must outlive the accessor call, so these accessors can’t return a local variable or a computed value or similar (unless it too is a borrowed / mutating return with appropriate lifetime). They are really only intended to provide direct, optimally-efficient access to stored properties (though more advanced usage does permit returning stored values from outside the struct).
• You can’t mutate an object while you have borrowed or mutating references from it, through these accessors. This is part of the correctness enforcement. It’s a little heavy-handed – depending on the object’s semantics, it might be perfectly safe to mutate other stored properties within it, but for now the Swift compiler doesn’t have a way to deduce that nor does the Swift language have a way to specify that. So you may need to be careful about lifetimes and order of operations. Also…
• You can’t have a ‘regular’ get accessor and a borrow accessor; they are mutually exclusive. This does unfortunately mean the upgrade path is complicated, as adopting borrow accessors can be source-incompatible and binary-incompatible.

withTemporaryAllocation using OutputSpan / OutputRawSpan

SE-524

Now there’s a safer version of the existing withUnsafeTemporaryAllocation (first introduced in Swift 5.6). It works just like you’d expect. It comes in both “raw bytes” and typed elements versions, just like its unsafe predecessor.

let result = try withTemporaryAllocation(
  of: MyResult.self,
  capacity: 42
) { output -> Int in
  for i in 0..<capacity {
    output.append(calculateResult())
  }

  return processResults(output.span)
}

What makes this ‘safe’ is that, unlike its predecessor:

1. It guarantees to correctly deinitialise the contents of the allocation (i.e. all the elements you appended). i.e. it’ll run deinit or any other such teardown required to properly clean up elements when they’re removed (or when the temporary allocation goes away).
2. Per the normal OutputSpan contract, it won’t let you write to invalid indices nor read uninitialised elements (by default – there is an unsafe version of the subscript operator that bypasses this check, if you want to live fast and dangerous).

The API is also much nicer, as OutputSpan / OutputRawSpan are much more like regular collections than the byzantine API of UnsafeMutableBufferPointer / UnsafeRawMutableBufferPointer (used by withUnsafeTemporaryAllocation).

~Sendable

SE-518

Analogous to ~Copyable and ~Escapable, it’s now possible to explicitly opt out of Sendable conformance.

The primary motivation is to provide clarity – the lack of an explicit Sendable conformance no longer has to be ambiguous as to whether sendability is or isn’t intended. It can also prevent unintended sendability changes – important for stable APIs.

// Either not sendable right now, or expected to be non-sendable in future.
public class NotThreadSafe: ~Sendable {
  …
}

It also enables selective sendability in a class hierarchy – e.g. a ~Sendable base class with Sendable subclasses. Previously it was possible to express the semantic of non-sendable, but in a somewhat hacky way (using @unavailable) and applying irreversibly to all descendants. Now, it’s straightforward and simple:

class Base: ~Sendable {
  // Some internals which are not sendable, or the contract is to not presume sendability for subclasses.
}

class Sub: Base, @unchecked Sendable {
  // Overrides whatever it was that makes `Base` non-sendable, or is just a subclass which choses to be Sendable even though it's not required by the ancestor(s).
}

You can also add conditional Sendability through conditional type extensions.

// Could hold anything, including non-sendable types, so not naturally sendable.
class MyContainer<T>: ~Sendable {  
  var contents: T
}

// But automatically Sendable if the contents are.
extension MyContainer: Sendable where T: Sendable {}

Caveats:

• Explicit ~Sendable on a type declaration, that’s then overridden by an extension, sends mixed signals and may confuse readers as to the author’s intent.
• ~Sendable has to be declared on the type declaration itself, not in an extension. Similar to other ~Foo declarations.
• Unlike e.g. ~Escapable, sendability is not presumed on types, so there’s no need (and it’s not supported) to declare ~Sendable in generics. Not-sendable is already assumed. The ~Sendable declaration is more for humans than the compiler, to more clearly express intent (and correspondingly it has no impact on the ABI).

Compiler warning for silently swallowing errors inside a Task

SE-520

Previously, code like this would compile without any complaints, even though it is likely faulty:

Task {
  try boom() 
}

print("Yay!")

Now, that will issue a compiler warning:

warning: Unstructured throwing task was not used, which may accidentally ignore errors thrown inside the task [#NoUseUnstructuredThrowingTask]

The fix is, of course, to do something about the potential exception – either catch & handle it inside the Task, or actually do something with the returned Task instance.

isTriviallyIdentical

SE-494

The new isTriviallyIdentical(to:) method offers a guaranteed-fast way to check two objects for equality. It is essentially an optimised version of the existing equality condition provided by Equatable and the == operator. It’s useful because it guarantees O(1) time complexity, whereas == makes no formal guarantees at all (and for many types is O(N) or worse). But unlike the existing identity comparison operator === – also O(1) – it promises to do more than just tell if two objects are the exact same pointer, and it works on value types (not just reference types).

The catch is that it’s not available for all types. It’s opt-in, initially for a fairly broad but finite set of collection types in the standard library (see the complete list in the proposal).

The way it typically works, in the initial set of implementations at least, is to check if the underlying shared storage is the same, between two objects that either utilise a copy-on-write mechanic (most standard library collections, like Array, Set, etc) or are wrappers on raw memory (Unsafe*BufferPointers and *Span).

Note that there’s nothing in its definition that restricts it to just copy-on-write or raw-pointery types (e.g. most if not all Identifiable types can implement isTriviallyIdentical(to:), as just comparing IDs¹).

func update(_ contacts: [Contact]) {
  guard !self.cachedContacts.isTriviallyIdentical(to: contacts) else {
    // `contacts` is _guaranteed_ identical (==) to our cached copy.
    return
  }
  
  // `contacts` _might_ or might not be identical to our cached copy.
  // We could try `==` for a more precise check, but depending on what we're doing, it might be more efficient to just do our work - e.g. a scan of the contacts checking for some criteria is O(N) and `==` will be O(N) and possibly even slower (since it may have to check _every_ contact field for equality, not merely the subset of fields we're actually interested in).
  
  self.cachedContacts = contacts
  // <expensive operation here, like scanning all the contacts>
}

Note that there’s nothing preventing the same check being part of == for the types that implement this (and many likely already contain this optimisation). But the big difference is that Equatable‘s == usually has to fall back to an exhaustive recursive check, using ==, whereas isTriviallyIdentical(to:) by contract does not.

Caveats & cautions:

• There’s no new protocol defined, so it’s very difficult to make use of this new feature with generic code. This was discussed in the proposal but no satisfying reason given for the omission – the authors seem to believe that supporting generics isn’t important.
• Similarly, the authors explicitly chose not to support this transitively on common types like Optional, intentionally punting that work to every Swift programmer.
• A fallback to == is not a good idea in some cases, so be wary of making that a habit or pattern. Generally if you actually need to know equality precisely, you should just use ==.

Hashable conformance for UnownedTaskExecutor, Dictionary.Keys, CollectionOfOne, and EmptyCollection

SE-514 & SE-523

This simply fixes some oversights in the standard library.

Note that for CollectionOfOne and EmptyCollection conformance is conditional on the Element type being Hashable. It’s unilateral for Dictionary.Keys since Dictionary always requires Key to be Hashable, and unilateral for UnownedTaskExecutor by nature.

One obvious and notable benefit of UnownedTaskExecutor‘s conformance is that, because it’s relatively common to store collections of such executors, such as a connection pool or cache, that pool or cache can be much faster. Previously the only way to check if an executor was already in such a pool was to do a linear search (yuck!):

func pickConnection(preferring executor: UnownedTaskExecutor) -> Connection {
  for (e, connection) in executorConnectionList {
    if e == executor { return connection }
  }

  return executorConnectionList.first!.connection
}

…whereas now it can be a much faster constant-time lookup:

func pickConnection(preferring executor: UnownedTaskExecutor) -> Connection {
  if let connection = connectionsByExecutor[executor] {
    return connection
  }

  return connectionsByExecutor.values.first!
}

Ref and MutableRef types

SE-519

These new types generalise the existing patterns of borrowed and mutable references, that have previously existed in Swift in much more restricted forms (e.g. inout parameters are essentially MutableRef parameters, and Span & MutableSpan are array equivalents).

This allows for more control and therefore more precise use of borrows / references.

// Fetch the value *once*…
var entry = MutableRef(&dictionary[key, default: 0])

// ...and repeatedly modify it, without repeatedly looking it up again in the Dictionary's hash table.  Much more efficient!
for value in values {
  entry.value += value
}

It can be combined with still-experimental lifetime annotations to enable some pretty powerful optimisations, e.g.:

struct Vec3 {
  var x, y, z: Double

  @_lifetime(&self)
  mutating func at(index: Int) -> MutableRef<Double> {
    switch index {
      case 0: return MutableRef(&x)
      case 1: return MutableRef(&y)
      case 2: return MutableRef(&z)
      default:
        fatalError("out of bounds")
    }
  }
}

Previously – and even with the new borrow & mutate accessors – this would require at least two accesses to the struct, one to fetch the value and then another to set it later. More importantly, it would not guarantee exclusive access to the relevant field in the meantime, so other code could modify the struct in-between the get and the set. The MutableRef guarantees exclusive access to the struct while it exists.

Caveats:

• Only Escapable types can be used with Ref and MutableRef, for now. This is due to compiler limitations that will hopefully be addressed in future.

Array expression trailing closures

SE-508

The compiler now supports trailing closure syntax for Array and Dictionary. Previously it got a bit confused because it tried to interpret the trailing closure as an array or dictionary literal, or as a random unrelated and uncalled closure, requiring more verbose initialisation syntax as a workaround. Now, intuitive code like this just works:

extension Array {
  init(@ArrayBuilder build: () -> [Element]) {
    self = build()
  }
}

let value = [String] {
  "a"
  "b"
  
  if bonusItem {
    "c"
  }
}

This is interesting mainly in the case where you use a result builder, such as ArrayBuilder as shown above. Note that ArrayBuilder is not currently part of Swift proper, or any Apple-owned packages, but its inclusion has been proposed.

The demangle function

SE-498

There’s now a built-in function for demangling Swift symbol names, in the Runtime module (that’s bundled with the Swift toolchain, alongside the stdlib etc). This won’t be of direct interest to most Swift users, but for certain package developers (such as for crash reporting) this may be very helpful.

var demangledOutputSpan: OutputSpan<UTF8.CodeUnit> = ...

do {
  try demangle("$sSS7cStringSSSPys4Int8VG_tcfC", into: &demangledOutputSpan)
  let utf8 = try UTF8Span(validating: demangledOutputSpan.span)
  let demangledString = String(copying: utf8)
  print(demangledString) // "Swift.String.init(cString: Swift.UnsafePointer<Swift.Int8>) -> Swift.String"
} catch DemanglingError.truncated(let requiredBufferSize) {
  // Handle truncation - need a buffer of size requiredBufferSize
} catch {
  // Handle invalid symbol
}

Caution:

• While the format of mangled symbol names are pretty much guaranteed to not change, because they’re part of the Swift ABI which froze circa Swift 5, the format of unmangled symbol names are not standardised and this new function explicitly reserves the right to change its output format in future.

Software Bill of Materials Generation

SE-509

This adds a swift package generate-sbom command and a --sbom-spec flag to swift build, that both generate a ‘bill of materials’ – a JSON file describing all the dependencies (recursively) of the package. It can be used for auditing and to aid in build reproducibility, among other things.

You can find examples of these JSON outputs in the proposal.

The initial implementation, in Swift 6.4, is pretty spartan, and doesn’t provide much more than what you can already see in Package.resolved. But there’s a long list of potential enhancements which will make this feature more useful.

1. Technically Identifiable doesn’t require the id property to be O(1), so it isn’t formally valid to conform all Identifiables. But in practice the function of Identifiable is often to short-cut an otherwise expensive equality operation, and the ID is typically a simple value type (e.g. number or string), so comparison usually is O(1). ↩︎

That’s not a compliment.

There’s the non-native GUI, though of course that doesn’t tell you much in this day and age. It’s obviously just Chromium or something similar (hell, you can right-click on some things and they still have the “Inspect Element” contextual menu item, which does indeed open a very Chrome-looking web inspector).

There’s its general everyday bugginess – it frequently resets the scroll position of conversations to some arbitrary point miles back in time, for example. Or just abruptly removes focus from the text field while you’re in the middle of typing (doesn’t move it anywhere else, just defocuses). It smells, in a nutshell.

But the “vibe coding” stench really wafts in when you consider that [cynically] their most important user flow – the upsell – doesn’t even work.

I hit my usage limit for the week. So, I went into Settings, Billing, etc and upgraded to the “Max” level. I’d been thinking about this anyway, so I didn’t have any animosity around it – I’d just been wondering if it was worth it; if I’d use the extra quota.

Having done that successfully, I exit Settings, and go to resume my work – only to see my Code conversations are all still claiming I’ve hit the usage limit. And the input text field is disabled.

Ugh. Great. Bugs.

I go back into Settings to double-check – but no, I have in fact upgraded my account and do have plenty of quota left.

I restart the app, of course, but that doesn’t help. I click a whole bunch of buttons – I won’t bore you with the details, suffice to say there is no way to get the damn app to realise I have my entire quota left.

So I go to the Help menu and click the promisingly-titled “Get Support”. Which merely opens a page on Claude’s website, “How to get support“. Pro tip: if your product or website needs such a page, you’ve already failed at customer support.

That page tells me to go back to the app because the only avenue I have for communicating with them – even just to report a bug in their own damn app – is to use their support robot (via an incredibly obtuse GUI route – when your app has a Help menu, like every app, and it even includes a “Get Support” menu item, then why the fuck does it not just open your in-app support; why do you require an easter egg hunt through your GUI?! Oh, wait, it’s because this is not a native app and it bloody well shows.

Okay.

Fine.

Let’s just do this.

I follow their ridiculous instructions on how to ‘get support’, but then I get this.

There’s something wrong with this picture. Look carefully, it might be hard to miss.

How the fuck am I supposed to talk to their bot? There’s no text input field.

This problem also persists across app relaunches.

They had no trouble taking my money – they billed me for the upgraded plan within seconds – but they seem to have trouble actually delivering the service I paid for.

And this is what’s considered state of the art today?

Resolution

The extra resolution is significant – it is 38% more pixels – and welcome, but it’s not revolutionary. It feels like what should have just been the natural progression and not a big deal – in the same way we started with 9″ sub-VGA displays and have over decades worked our way up to bigger and higher-resolution ones.

And in that vein, the prospect of downgrading back to a 5k display is immediately deeply unappealing (pay attention, Apple 😠). The notion of going down to a mere 4k display is absurd (tempting as bright[er] OLEDs are¹).

Dimness (née Brightness)

Even though it’s supposedly brighter than the LG UltraFine 5K it’s replacing for me – at least at peak, given its DisplayHDR 600 rating – it really isn’t. For everyday work (coding etc) I had the LG set at 50% brightness (so nominally 250 nits, given its 500 peak rating) but the equivalent brightness requires ~75% on the Asus. Which actually fits if you take the Asus’s manual (not its tech specs) at its word of a 350 nominal max brightness, since 250 nits is roughly 75% of 350.

So that’s disappointing. The LG UltraFine 5K was sort of bright for its day, but that day was nearly a decade ago. We now have cheap laptops with 1000-nit displays, so 500 is unequivocally dim now.

Not that I expected much else – while Asus can’t seem to agree with themselves over the actual peak brightness, they never claim more than 400, so going in I suspected it would be dim. What I didn’t expect was that the claims of multiple reviewers, that it’s actually closer to 700, would turn out to be completely false.

The one thing that makes a difference in practice, in the Asus’s favour over some older displays like the LG, is that it supports HDR mode. So you can in practice get noticeably higher brightness in image & video editing without having to blind yourself².

Matte-ugly

I do not like the matte finish. Compared to the LG UltraFine 5K that I was previously using, the PA32QCV has lower overall contrast (it’s more washed-out looking), and visible ‘shimmer’ or ‘sparkle’ – basically fine luminance noise that changes as your viewing position changes (even just slightly). It makes the screen look a bit dirty, too.

In a nutshell, contrast is lower than it should be, and text just doesn’t have quite the same clarity it does on other displays (like Apple’s, or the LG UltraFine 5k).

I’ve not yet decided if it’s a deal-breaker… there’s no good glossy 6k display options currently. I’m hoping that I’ll just get used to it. But there’s no mistaking that the screen’s finish is notably worse than its predecessors and Apple contemporaries. Especially for bright content (folks using Dark Mode might not be affected so much).

VESA mounting

I was perplexed when I first opened the box, and found what looked like a proprietary mounting system, with only a stand included, not a VESA mount adapter. The box contains basically no instructions or explanation of anything, and even the manual – dug up through manualslib online because Asus’s website contains only broken links to it (though I later noticed that B&H host it too) – has no real information on how to VESA mount the display, other than cryptically stating that you need a “VESA Wall Mount Adapter (sold separately)”.

Thankfully, Itchy_Pin9813 on Reddit had already figured it out – the four screws that look like they might be structural, are actually just weird placeholders.

You just remove them and then screw in any standard 100⨉100 VESA mount.

However, be aware that the mounting point is recessed significantly. Though the plate itself fit in the recessed area just fine (as shown above), I was only barely able to get my mount plate attached to the arm itself, without the arm hitting the surrounding casing. I did notice that you can buy adapters specifically designed to address this design flaw.

BSOD

When the display detects no input video signal, it displays a hideously-coloured bright blue screen, reminiscent of Window’s Blue Screen of Death.

Which would be fine – generally you won’t see that, unless something’s genuinely gone wrong with your cables or computer – except that it sometimes flashes into this mode when your Mac goes to sleep or wakes the display back up. It’s jarring and ugly.

This isn’t the first display to have this design flaw, but I just cannot fathom how, after decades of experience in displays all around us in the real world, someone somewhere inside Asus still thought it’d be a good idea to do this instead of just displaying a black screen (optionally with calm grey “No Input Signal” text on it).

KVM

Having a built-in KVM should be nice – I have my personal Mac and [sometimes] my work laptop connected, and previously I was manually moving the Thunderbolt cable between them (like a cave man! 😜). Which wasn’t a big deal per se, but I do worry about frequently plugging and unplugging a Thunderbolt cable – those USB-C style connectors aren’t infinitely durable. And Thunderbolt is a pretty demanding protocol, that I suspect doesn’t tolerate electrical flaws well. And quality Thunderbolt replacement cables aren’t cheap.

So, KVM, great!

Except… the implementation in the Asus is pretty clunky. There’s a dedicated “Input Source Switch” button right on the front panel, which should be perfect – except it often doesn’t work. If your Mac(s) are set to turn the display off after some period of idleness, they’ll stop sending a video signal to the display, and the display then considers them non-existent. So the “Input Source Switch” button only ever works in the brief period after a previous switch, when the prior Mac is still sending a video signal to the display.

Disabling display auto-off on all your computers is one option, but not a great one – sometimes I’m called away abruptly, potentially for many hours, and I don’t want the display sitting there wasting power and burning itself in. A screen saver might help with the burn-in aspect, at least, but not the power (and keep in mind this display is rated to about 50W (not counting USB & Thunderbolt power), which is too much to waste).

If you have your keyboard & mouse connected through the display – in order to make intended use of the KVM functionality – then you also run into the problem that if the Mac has gone into screen off mode, the Asus display turns off all the USB devices too. So you can’t wake your Mac from the keyboard or mouse. Nor switch input sources.

So, I’m having to resort to hitting the power button on my Mac Studio, and opening my laptop on the MacBook Pro, in order to wake them up. Or, I discovered that you can ‘force’ switch input sources – which will wake the connected Mac – through the display’s on-screen display. But that’s quite a few clicks and nudges of its joystick – and only makes it more baffling and frustrating that the dedicated “Input Source Switch” button doesn’t just work.

I wish there were a configuration option to (a) never power down the USB devices and (b) just tell the display that some inputs (Thunderbolt, Display Port, and/or HDMI) are always connected, whether it’s receiving a video signal currently or not. Clearly the display can wake up connected Macs – it does so when you select their input source deep in its settings.

Picture-in-Picture (PIP) / Picture-beside-Picture (PBP)

I’m not sure if I’d ultimately use these – I hate the PIP “feature” of YouTube and some Apple apps, for example, and don’t want to mess with display resolution and aspect ratios for any of my connected computers – but it turns out I can’t, anyway.

The caveats are buried deep in the manual:

To active this function [PIP / PBP], you need to do the following: turn off MediaSync / Dynamic Dimming and disable HDR on your device.

I don’t want MediaSync or Dynamic Dimming anyway (see the Configuration recommendations section below for why), but I do want HDR mode enabled. Having to disable HDR mode is far too great a sacrifice, for a feature that’s arguably just a gimmick anyway.

10-bit colour lies

The Asus (like most displays these days) is marketed as having 10-bit colour.

But it doesn’t.

The lie is revealed only in the back pages of the user manual (the one that doesn’t come with it in the box, nor is accessible from Asus’s website). This display, like so many others, is actually an 8-bit panel that uses FRC (Frame Rate Control) i.e. temporal dithering: the monitor accepts a 10-bit signal but can only set the actual pixels to 8-bit precision, so it oscillates back and forth between adjacent 8-bit values in order to approximate the desired 10-bit value, over time.

I don’t actually know how much that matters – I can’t say I’ve had complaints about the LG UltraFine 5K w.r.t. banding or other 8-bit artefacts, and it was also an 8-bit display with FRC.

Still, I’m not happy with Asus basically lying in their marketing material – and tech specs, which are usually one place you can get to the truth.

Subtler effects

It might take more time to appreciate some of the more subtle differences, vs the LG UltraFine 5K at least.

HDR Mode

The ability to use HDR mode – meaning I can set my ‘regular’ GUI brightness to what’s comfortable without [artificially] limiting the brightness of imagery – might reveal itself as kind of a big deal, with further use, but since the additional brightness is pretty minor (in a daylight-lit room, at least) I don’t know yet.

Colour accuracy

I also haven’t actually checked the colour accuracy yet. Asus do include a basic printed calibration report in the box, from their factory calibration, which is nice and hopefully not just performative. I do have a colour metre (an old ColorMunki), but going through the process is frankly frustrating and tedious, and I’m rarely actually happy with the results (more accurate is not the same as better looking). I can at least say that the colour looks fine (once I dialled in better settings than the defaults – see below) and similar-enough to the other displays in my life that I have no complaints.

Configuration recommendations

• In macOS Settings:
  • Enable “High Dynamic Range” for the display (in the “Displays” pane). This does two things:
    • It enables macOS brightness control – the brightness slider appears in System Settings, and the keyboard shortcuts to control brightness will then work.
      
      Note that, conversely, it basically prevents you adjusting the display’s brightness from the display’s own controls (you become limited to “MAX” and 250).
    • It allows HDR content to use the full luminance range of the display irrespective of the brightness setting. i.e. you can adjust the “regular” brightness of the GUI independent of the HDR image & video brightness. Note, however, that there doesn’t seem to be a way to control the brightness of HDR content.
      
      Keep in mind, though, that the PA32QCV is not a bright display. It’s rated to up to 600 nits, and even that’s probably only for small patches of highlights or for brief time periods, which is really quite low – it’s nothing like a “true” HDR display such as Apple’s MacBook Pro displays, Apple’s Pro Display XDR, or the Asus ProArt 8K, that have sustained maximum brightness of at least 1,000 nits (2⨉ brighter), and generally peak much higher. Even iPhones are brighter³ (and have much better dynamic range, being OLEDs).
• In the display’s settings:
  • Settings > Dynamic Dimming should be OFF. When it’s on the display adjusts the brightness over time in response to the image shown, but very slowly such that you can see it ramping up or down lazily after an average brightness change (no matter what you tweak its sub-settings to). It’s just horrible for video creation since it’s seriously messing with your luminance and animation. And I’m not even sure it’s a good idea when merely watching video, since the brightness transitions are noticeable and distracting.
    
    If you never view animated content, then I suppose leaving it on could be beneficial since its purpose is ostensibly to give you greater static range – when the screen overall is dim, such as editing a dark photo, it will reduce the backlight in order to darken the blacks, while conversely in a bright image it’ll boost the backlight to give you maximum brightness (but at the expense of washing out the blacks completely).
    
    But, it really doesn’t do much. Yes, I can see the effect – it does make the blacks a little bit darker when the image is overall quite dark – but it’s very subtle and not remotely worth the visual artefacts it introduces.
  • Palette > Brightness must be set to “MAX” when macOS is using HDR mode, otherwise you’ll be limited to 250 nits even for HDR content! If macOS is not set to HDR mode then it sets the brightness in nits, from 0 to 400.
    
    It’s pleasing to see a scale that’s in real units, not just some arbitrary scale like 0 to 100%. Or at least, I’m assuming that’s the case – that the scale goes to 400, and otherwise odd, arbitrary number, and that the display’s nominal peak [SDR] brightness is 400⁴ seems like an unlikely coincidence.
  • Palette > Black Level > Signal should be left at its default, 50. Changing this basically changes the luminance curve of the display – lowering it pulls down the brightness, crushing the shadows in particular, while raising it increases the brightness, washing out the shadows. It has no apparent effect on actual black levels (nor, surprisingly, does its peer “Backlight” setting, which seems strange because surely that’s the point of it?).
  • If you’re creating HDR content, in the display’s settings, set Preset > HDR to “PQ Clip”.
    
    If you’re viewing HDR content, use “PQ Optimized”.
    
    Yes, this might be something you have to change frequently, because there’s no happy medium. 😔
    
    Under the default setting, “PQ Optimized”, the display futzes with the image to make the display’s brightness limit less noticeable – it “smoothes” out the approach to the maximum brightness by making the too-bright parts darker (to prevent clipping) and the nearly-too-bright parts brighter. This provides a pleasing but highly inaccurate effect – you don’t see stark clipping as easily, and the image overall looks bright, but you’re seriously changing the localised luminance of the image. If you edit a photo or video this way and then put it on another display, you may be dismayed to find it looks completely different, luminance- and contrast-wise.
    
    This is a consequence, I infer, of how macOS renders HDR content. In SDR mode, macOS just directly maps the input image’s dynamic range to the display’s – 100% in the image goes to the display as 100%. But in HDR mode it seems like it’s basically ignoring your display’s capabilities and working in absolute brightness. So if the input image says it is 2,000 nits, macOS emits pixels with that nominal brightness. Which may be way beyond what the display can handle, so they just get clipped to its max brightness (or artificially adjusted by the display – as in “PQ Optimized” and “PQ Basic” modes).
    
    And (for completeness) the “PQ Basic” setting is, I think, doing just the darkening part of “PQ Optimized”, which in a nutshell means it looks like “PQ Optimized” but dimmer overall. I’m not sure what use that is.
  • Settings > PowerSaving can be set to “Deep Level” (the default, for “Energy Saver” mode) iff you have macOS set to HDR mode. Otherwise, it limits the maximum brightness severely.
    
    Of course, I’m not yet sure what “Deep Level” does in HDR mode – possibly nothing. But I’m hoping it just means the display uses less power when not actually active.

1. This ties into my choice to get this 6k display, here and now. I agonised over the decision for a long time. I was pretty much resigned to just paying some obscene amount of money for the Apple Pro Display XDR 2 – on the assumption that it’d be a nice modest upgrade with more backlight zones and a brightness boost, which turned out to be correct but alas not the whole story – but once Apple publicised that they were killing the XDR entirely, it left me in the doldrums.
   
   I considered many options – including buying no-name-brand ones from China – but ultimately whittled it down to two possibilities: the Asus ProArt 8K, or the 6K. The Asus ProArt 8K is Apple-level expensive, and at 32″ its pixel density is far too high to actually reap noticeable benefit from the extra pixels over the 6K, but it otherwise checks the boxes. I spent a long time trying to convince myself it wasn’t insane to spend $9,000 on a display – keeping in mind that the original Apple Cinema Display was $4k at time of release in 1999, which is nearly $8k in 2026 dollars, and the Sony Trinitron displays were thousands of dollars too, in the 1990s… I also tried to reason that a display should last basically forever, and remain useful for decades, so what’s $9k over the rest of my life? 😅
   
   But in the end I thought… why? Even that $9k 8K display isn’t the best at everything. It’s not the brightest, it doesn’t have the biggest colour gamut, it doesn’t have the best contrast ratio – it’s not even the prettiest… if I’m going to spend eye-watering amounts of money, I want to at least feel like it’s worth it.
   
   So, I went with the cheapest option instead, on the assumption that I’ll revisit my display situation in a few more years. ↩︎
2. On “non-HDR” displays – specifically, where macOS doesn’t let you use the “HDR” option in the display settings – your images & video can only be displayed as bright as the current brightness setting – which is typically not the maximum brightness the display can manage, because if you raise the display to maximum brightness in order to get the full dynamic range available, then all your regular windows – white-backed webpages, TextEdit & Xcode documents, etc – become blindingly bright. ↩︎
3. Well, maybe… the iPhone 17 Pro might be rated at [up to] 3,000 nits, but in reality it can’t even handle the display being on at all sometimes, such as if exposed to sunlight. I have a torch (flashlight, Americans), a Google Firesword, that’s spec’d as 3,000 lumens – just 875 nits – and it’s way brighter than the iPhone screen ever is. Way brighter.
   
   Yes, there’s a significant difference in emitter area between a torch and an iPhone’s display, but even just considering how much it lightens the room it’s in, the Firesword easily wins against any iPhone. And any display I’ve owned. ↩︎
4. Well, maybe. As noted, while the tech specs claim 400, the manual says 350, and it’s my guess – based on comparison with other displays and referencing their rated peak brightnesses the the truth is much closer to 350 than 400. ↩︎

$ ssh somehost
somehost$ sleep 15 &
somehost$ exit

$ ssh somehost
somehost$ sleep 15 &
somehost$ exit

If you run that command sequence, you’ll find that it makes the SSH connection and then exits immediately – and it kills the background job (sleep 15) as it exits. Which I find intuitive if only because that’s obviously how it’s always worked.

But now run it this way:

$ ssh somehost 'sleep 15 &'

$ ssh somehost 'sleep 15 &'

Now it makes the SSH connection, waits fifteen seconds, and only then exits.

This subtle difference matters a lot if you’re e.g. writing an automation system that happens to sometimes spawn background jobs on remote machines via SSH, since it can lead to SSH commands hanging (potentially forever, depending on the nature of the background jobs).

And it’s very hard to debug, because no matter what debugging aids you put into your SSH session’s remote command – e.g. an explicit exit 0 at the end, set -xv, or echo 'Okay, going away now!' as the last command – it’ll still just hang instead of completing.

Turns out this is because when run without a remote command, SSH implicitly creates a pseudo-terminal. And the pseudo-terminal provides the behaviour of killing all subprocesses (including un-detached background jobs) when the main process ends.

When you run SSH with a remote command, SSH does not create a pseudo-terminal. I’m guessing technically what it’s doing is waiting for the remote side to close the connection, which the remote side (sshd) won’t do until all child processes have exited (or at least closed their stdin, stdout, and stderr?).

One workaround is to use the -t argument to SSH, to force creation of a pseudo-terminal. The downside is that remote programs may then assume an interactive session, so they may prompt for input in cases where they wouldn’t otherwise. That could cause misalignment between what you write through to the remote command and what it’s expecting input for, or may cause a hang (if you don’t write anything but keep the remote side’s stdin open), or may cause the remote command to abort because it detects the end of stdin.

Another option is to manually kill all background jobs before exiting the main command, with e.g.:

jobs -p | egrep '^\d' | xargs kill

jobs -p | egrep '^\d' | xargs kill

…or just kill all subprocesses:

pkill -P $$

Or, if you can precisely control where you create background jobs (and are confident they don’t spawn background jobs recursively), you can do:

some background command &
BACKGROUND_PID=$!

… # Rest of script.

kill ${BACKGROUND_PID}
# *Now* we can exit without hanging.

some background command &
BACKGROUND_PID=$!

… # Rest of script.

kill ${BACKGROUND_PID}
# *Now* we can exit without hanging.

Just beware with this more precise approach that it’s more fragile – subprocesses could get spawned in ways you didn’t anticipate (if not now, then maybe in future versions of your code / production environment), and that sometimes the PID returned is effectively invalid because it’s merely the PID of some transient subprocess anyway (not the long-lived subprocess(es)).

  1> "\r".count
$R0: Int = 1
  2> "\n".count 
$R1: Int = 1
  3> "\r\n".count 
$R2: Int = 1

Yes, Swift treats the two bytes “\r\n” as a single character.  This is actually super convenient a lot of the time, because it means algorithms that look for line breaks with isNewline just work, even on “Windows”-style text.  Otherwise, you’d have to explicitly look for two isNewline characters in sequence and check if they are exactly “\r\n”.

But it does lead to some potentially surprising side-effects, like:

 4> x.unicodeScalars.count
$R3: Int = 2
 5> Array(x.unicodeScalars)
$R4: [String.UnicodeScalarView.Element] = 2 values {
  [0] = U'\r'
  [1] = U'\n'
}

This isn’t surprising if you’re pretty familiar with how Unicode actually works – starting with the difference between graphemes (approximately what Swift calls a Character) and “scalars”, but I suspect it’ll catch some people out.

For the price of one Apple Pro Display XDR you can get five Asus ProArt 6k displays. And it’s worth noting that the 2nd-hand price for the XDR has risen dramatically since it was discontinued, with some ‘retailing’ on eBay for more than their original purchase price! So forget about the 2nd-hand market.

I suspect there’s only three 6k panel models in existence – the one used by Apple, the AUO one used by Asus², Acer, & ALOGIC, 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 33% less (and you can get the very similar Asus display for 56% 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. Sometimes listed as “ProDesigner”, not “ProCreator” – I suspect the former is a U.S. variant of the name, as seen at retailers like B&H. Perhaps someone told them that “ProCreator” might elicit snickers in some parts of the world (not that anyone told Procreate, apparently). ↩︎
4. Be careful not to confuse this with the very similarly named PE320QKX, which is a 4k OLED version. Acer’s own marketing and website people confuse this (the product page erroneously claims that the PE320QXT has an OLED panel – it does not). ↩︎
5. This is what LG states in the display’s specifications. Yet, LG also states that this display is DisplayHDR 600 certified, which means it’s required to have a static contrast ratio of at least 8,000 : 1. But, this requirement was added in v1.2 of the DisplayHDR standard, so perhaps LG are referring to the old, obsolete version of the standard. ↩︎
6. As with the LG, Dell states a 2,000 : 1 contrast ratio even though DisplayHDR 600 conformance requires at least 8,000 : 1. ↩︎
7. 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 (but it appears the latter is only with “Dynamic Dimming” on, which is where it adjusts the overall backlight brightness based on average image brightness, but it does it too slowly such that you clearly see the transitions as the image changes, so I recommend leaving it off – plus, I can barely see any difference with it on anyway). ↩︎
8. Acer list 100,000,000 : 1 with the caveat of “ACM” (Adaptive Contrast Management), a technique to supposedly achieve ‘visually equivalent’ results to an intrinsically higher contrast ratio. I’m not personally an expert on this, but the internet seems full of scepticism and critique of this technique as a whole, and contrast ratio claims based on it. Unfortunately Acer don’t list the actual (“non-ACM”) contrast ratio. ↩︎
9. In a single breath Kuycon’s product page says both 1,500 : 1 and 2,000 : 1. But the tech specs repeat the 2,000 : 1 number – and I suspect it’s using the LG panel which is listed as 2,000 : 1 in other displays – so I’m assuming the 1,500 : 1 is a typo. ↩︎
10. 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.
    
    Note that they claim to have VESA DisplayHDR 600 certification, which requires at least 350 lumens sustained but also at least 600 for a very small (8% of screen area) bright patch. But also that Dell very likely use the exact same panel and they claim 450 lumens sustained. So I’m not sure what the 360 is about… I’m hoping it’s just an overly cautious product lawyer that’s recognising that thermal throttling can happen at unusually high ambient temperatures. 🤞
    
    Also, PCWorld measured the SDR brightness at 480, which fits best with the 450 claim. ↩︎
11. Sigh… brightness claims. These days they’re subject to so many caveats and conditions that they’re verging on meaningless.
    
    A luminance rating is conspicuously absent from the Asus product page (other than the claim about DisplayHDR 600 certification, which merely sets a 250 nits minimum). Their tech specs say 400 nits, though.
    
    PCWorld measured peak brightness at 714, and Tom’s Hardware measured it at ~650. Not the same as sustained brightness or full-screen brightness, though (neither of those reviewers described their methodology).
    
    But, I’m not sure how they got those numbers – because I actually bought this display, and I’ve seen nothing that indicates to me that it’s getting much more than 500 (though I don’t have a luminance measurement device – I’m comparing it to other displays like the LG UltraFine 5K and Apple M2 MacBook Air – both rated at 500 nits).
    
    But, the actual manual says 350. And I’m inclined to believe the manual, because it’s also the only place which actually admits that it’s not a 10-bit panel. ↩︎
12. Their terminology is non-standard, but they say that 400 is “native” while 600 is “peak”, which I take to mean 400 is the sustained maximum brightness. ↩︎
13. The tech specs state “450 nits typical (SDR) • 750 nits (HDR enabled)”, which is a bit ambiguous. But it seems very likely that this is the same panel used in the LG, so likely we can follow LG’s guidance there, which is a more explicit 450 nits sustained brightness (in typical temperature environments). Meirro are the first to put a number to the peak brightness, however, at 750. It’s possible they’ve tweaked the operating parameters in order to achieve that, but FWIW the [presumed] same panel in the LG was reported by Wired as only 640 nits at peak, but 748 nits by PCWorld, so while 750 seems plausible, it’s unclear if there’ll actually be a difference between the two. Note that both of those measurements were “maximum”s, not necessarily something the monitor can sustain indefinitely. ↩︎
14. ALOGIC says “typical” brightness is 400, with minimum being 350, 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 350 is ridiculously dim. ↩︎
15. LG don’t explicitly state this, but it’s a requirement of the DisplayHDR 600 conformance. ↩︎
16. Dell don’t explicitly state this, but it’s a requirement of the DisplayHDR 600 conformance. ↩︎
17. Asus don’t explicitly state this, but it’s a requirement of the DisplayHDR 600 conformance. ↩︎
18. It offers pseudo-10-bit mode using FRC (temporal dithering), but is not a true 10-bit display. ↩︎
19. It offers pseudo-10-bit mode using FRC (temporal dithering), but is not a true 10-bit display. ↩︎
20. It offers pseudo-10-bit mode using FRC (temporal dithering), but is not a true 10-bit display. ↩︎
21. 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. ↩︎
22. 96% in PCWorld’s testing. ↩︎
23. ALOGIC’s flashier marketing material claims 100%, but the tech specs say 99% – and some older marketing material on Amazon says 97%. I’m sceptical of the 100% coverage claim – and of marketing people in general – and not sure what to make of the 97% number from 3rd parties, so I’m going with the actual tech specs. ↩︎
24. ALOGIC’s flashier marketing material claims 100%, but the tech specs say 99%. I’m sceptical of the 100% coverage claim – and of marketing people in general – so I’m going with the actual tech specs. ↩︎
25. Acer’s product page claims 240 Hz, but that seems to clearly be an error – it’s referring to other ProCreator models, in much smaller sizes and lower resolutions. ↩︎
26. ALOGIC sometimes says 90W (e.g. in the dominant marketing material) but the tech specs say 95W. I’m erring on the side of caution here, by going with the lower number. Though in practice I don’t think this 5W difference is significant in any case. ↩︎
27. 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). ↩︎
28. Acer’s marketing pages, product specs, and release announcements list conflicting and non-sensical things (e.g. “USB-B”), so while it seems clear it has some downstream USB ports, it’s not at all clear how many, what port type, or what speeds. ↩︎
29. 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. ↩︎
30. Acer’s product page specifies the dimensions as “72.55 × 52.77~28.28 × 32.11 cm (28.56 × 20.77~11.13 × 12.64 in)”. I have no idea what that’s supposed to mean, but it’s clearly not correct no matter how you interpret it (the display is assuredly not a foot deep). ↩︎
31. Meaning the simple product of the three maximal dimensions. Some of these displays have curved backs, so their actual volume will be substantially less. ↩︎
32. Note that MRRP (Manufacturer Recommended Retail Price) may vary over time, not to mention sales or other store-specific price changes. At various times I’ve found most of these displays on sale for at least a few hundred dollars less than their list price. ↩︎
33. Note that MRRP (Manufacturer Recommended Retail Price) may vary over time, not to mention sales or other store-specific price changes. At various times I’ve found most of these displays on sale for at least a few hundred dollars less than their list price. ↩︎
34. Acer only lists this display model on their Singapore website, though it is available from some U.S. retailers (e.g. B&H). At time of writing (30th of April 2026) the price in Singapore ($1,799 SGD) translates to ~$1,400 US, but I have not been able to find any U.S. retailer offering it for less than $1,500. ↩︎
35. At time of writing, only when purchased via ClickClack, not Kuycon’s website direct. And yes, it’s therefore cheaper with the stand than without (since ClickClack sell only the with-stand version). ↩︎

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.

But, looking over other people’s shoulders, and listening to the groans and cries, I’m struck by something. We’ve been here before. Icon jail, I mean (“Squircle” jail specifically in Tahoe’s case):

This isn’t the first time Apple’s put icons in grey jail. Mac OS 9 already did this:

This mode made the icons activate with a single click rather than a double-click. It was a window-specific (and desktop-specific) setting. I vaguely recall it being sold as a simpler, more efficient way of using the Finder – fewer clicks! It did not catch on, though possibly there were some fans. I vaguely recall encountering Macs in the wild that had this mode enabled.

It wasn’t new in Mac OS 9 either, really – it was actually introduced with At Ease circa System 7.1:

In a way, Apple is just returning to its roots; continuing to try to dumb-down the Mac.

Of course, a big difference between all these prior incarnations and macOS 26 Tahoe’s is that previously the user controlled it, and could turn it off. You didn’t have to install At Ease at all. Mac OS 9 didn’t use the Buttons view mode by default, you had to enable it, and anyone could disable it again at any time.

That’s where today’s Apple actually differs from yesteryear’s – they used to respect the user, and now they don’t.

Contrary to what you might read online or what the dumb robots might tell you (because they just plagiarise it from those same Reddit threads and YouTube videos), you can’t simply “Expand Audio” and apply the Cross Dissolve to just the video lane¹. You can detach the audio entirely, but that’s heavy-handed and may make your life much harder downstream (since Final Cut Pro will then treat the separated audio and video as completely independent clips).

Actually, there’s a simple ‘hack’ which works:

1. Drag the Cross Dissolve (or similar) onto the clip.
2. Select the clip and “Expand Audio” (from the Clip menu, contextual pop-up menu, or by pressing ⌃S). This is really just to get access to the audio track that’s otherwise hidden under the Cross Dissolve.
3. Carefully drag the audio fade-in handle to the edge of the clip, to exactly where the tooltip says the offset is zero. Don’t go too far – if you go over the end of the clip it’ll re-install the audio fade!

It feels like that shouldn’t work – like it’s actually a subtle bug where Final Cut Pro actually intends to ignore your zero-duration fade-in and reset it back to the full length, like it does if you drag just a pixel too far. But hey, thank goodness for some bugs!

1. Maybe this did work in an earlier version of Final Cut Pro, but it definitely does not in 11.2. ↩︎

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

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

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

You must use 48kHz sampling

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

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

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

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

You don’t have to record on the Portacapture X8

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

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

The primary reason to extract the images exactly as is, bit-for-bit-identical, is that they’re typically already lossy-compressed (usually JPEG). Recompressing them will introduce further losses or increase the file size¹, or both.

Kudos to Josef Habr for suggesting The Unarchiver on StackExchange – I would never have found it on my own, even though I already had it installed and use it occasionally (for more traditional archive file formats, like Zip or StuffIt).

Frustratingly, Josef’s post aside, none of the recommendations you read online mention The Unarchiver, pointing instead to other options which are harder to install, harder to use, and don’t extract the images correctly. Worst of all, many people falsely claim that their suggested approach will extract the images losslessly. Examples include:

• pdfimages from Poppler – silently re-encodes images in some cases (contrary to what its documentation and users claim), such as if they have non-sRGB colour profiles, and fails to preserve the embedded ICC profile. Worse, the developers have known about this for nearly a decade and refuse to fix it.
• pdftoppm (et al) – explicitly convert the embedded images into another format, which while usually a lossless format (e.g. PNG or PPM) by default, still requires you to then re-encode them for use online etc. Plus, they typically don’t preserve ICC profiles.
• ImageMagick – doesn’t extract the images, merely renders the whole PDF page(s) as images, requiring further post-processing and inevitably reducing the image quality (due to mismatched output resolution and pixel alignment vs the embedded images’).
• Exporting pages as images from Preview or Acrobat Reader – obviously doesn’t preserve the extracted images as-is, requires re-encoding them with additional compression losses, etc.
• Screenshots via Preview or Acrobat Reader – ugh, I can’t even.
• Various websites – I mean, they might work, but why upload your personal data to some skeezy website when it’s easy and fast to just use The Unarchiver locally?

I saw a recommendation for File Juicer, but unfortunately the free trial doesn’t work for me – it claims it’s already expired – so I was unable to check that it actually works. Plus, it’s not free (USD$19 at time of writing) so that’s a strong disincentive compared to The Unarchiver.

1. It is possible, with some newer formats like AVIF, to recompress a JPEG in a way that arguably improves the image quality while also reducing the file size. AVIF encoders typically have some built-in smarts to recognise JPEG artefacts specifically, and try to remove them – a direct benefit visually since the artefacts are ugly and a benefit to [re]compression since the encoder then doesn’t need to waste time & output bits trying to preserve the artefacts.
   
   But, utilising this feature can require more care during compression to find the right trade-offs and ensure the result is in fact as good or better than the original – and in any case, AVIF recompression will work better from the original JPEG than a mangled version. ↩︎

extension AVPlayer {
    func fadeAudio(from startVolume: Float, to endVolume: Float, duration: Double) {
        let audioMix = AVMutableAudioMix()

        audioMix.inputParameters = (player.currentItem?.tracks ?? [])
                                    .compactMap(\.assetTrack)
                                    .filter({ $0.mediaType == .audio })
                                    .map { track in
            let currentTime = player.currentTime()

            let parameters = AVMutableAudioMixInputParameters(track: track)

            parameters.setVolumeRamp(fromStartVolume: startVolume,
                                     toEndVolume: endVolume,
                                     timeRange: CMTimeRange(start: currentTime,
                                                            duration: CMTime(seconds: duration,
                                                                             preferredTimescale: currentTime.timeScale)))

            return parameters
        }

        player.currentItem?.audioMix = audioMix
    }
}

I’m not certain what curve this implements, but to my ears it doesn’t sound quite as harsh as a naive linear ramp, so perhaps it’s an S-curve or similar.

Edge cases not handled

Where there’s less than duration time left in the track(s).

How you want to handle that might vary depending on context. e.g. you could clamp the duration to the remaining duration (but you have to think about whether your individual tracks all have the same duration, whether they match the duration of the overall playback item, and whether they’re all aligned within the playback sequence), or wrap it around to the beginning (if you’re looping), or carry the fade through to the next item (if you’re playing a sequence of items), etc. Alas this must be left as an exercise to you, the reader.

Starting a fade while another one is still in progress.

It will halt the previous fade, immediately jump to startVolume, and perform the new fade. If you know that a prior fade is in progress you could potentially extrapolate the current volume and start from there instead (though beware of non-linear ramping).

If you move the playhead backwards (e.g. skimming, or looped playback).

The mix will stay in place, and result in wonky volume levels on the subsequent plays through. To work around that, you can add:

player.currentItem?.audioMix = nil
player.volume = endVolume

…wherever you restart playback at the beginning or move playback earlier than the end of the fade.

Future work?

You can work around these limitations by doing a timer-based fade (i.e. player.volume += smallIncrement at regular, short intervals). However, the problem with that approach is that it’s not synchronised to actual playback – e.g. if the audio is paused, stutters, or faces an initial loading delay, your fade won’t wait for it, potentially resulting in no fade at all (e.g. it takes five seconds to buffer the audio before playback starts, at which point your five second “fade” has run to completion, so your audio starts playing abruptly at full volume).

There’s very likely a third option that addresses all these shortcomings, but I explored that a bit and concluded that it’d be a lot more work. If someone wants to explore that all the way, I’d be interested to see the result. But for many purposes the above code is quite sufficient.

If you’re using AVQueuePlayer, then just use AVPlayerLooper. Easy. But if for some reason you want to use AVPlayer specifically (e.g. you need to do additional things anyway when playback loops back around), read on.

AVPlayer itself doesn’t really help you here – it’s AVPlayerItem that you need to look at, as it has several notifications associated with it that can be very useful – most relevant here is the didPlayToEndTimeNotification. Simply observe that and restart the player explicitly, like so:

let player = AVPlayer(…)  // You'll need to keep a reference to this somewhere, for use in the notification handler, as the notification doesn't provide it.

void startPlayer() {  // Or wherever / however you start playback.
    NotificationCenter.default.addObserver(self,
                                           selector: #selector(playedToEnd(_:)),
                                           name: .AVPlayerItemDidPlayToEndTime,
                                           object: player.currentItem)

    player.play()
} 

@objc func playedToEnd(_ notification: Notification) {
    assert(player.currentItem == notification.object as? AVPlayerItem, "AVPlayer \(player)'s current item (\(player.currentItem)) doesn't match the one in the notification object (\(notification.object)).")

    player.seek(to: .zero)
    player.play()
}

Again, considering using AVQueuePlayer if possible, but the above works too.

• Permission errors with the destination folder (e.g. not writable by the current user).
• Conversion failures if you have the iPhone set to export images in “compatible” formats rather than their originals¹
• Unsupported image formats (e.g. HEIC) on very old versions of macOS (macOS 10.12 Sierra and earlier).
• The destination folder not existing.
• Etc.

Basically it seems like this “-9934” error is a catch-all for any kind of I/O error. Good job, Apple, in providing useful information to your users.

But add to the aforementioned list one other possibility, that I didn’t see mentioned anywhere: the destination volume is full.

I’ve been hitting this error message in Image Capture sporadically for months and been baffled by it – especially since it seemed to occur for seemingly random sets of images and videos, that were sometimes consistent between attempts and sometimes changed unpredictably. Which is of course the result of the destination volume being perpetually close to full but varying slightly over time as random bits & pieces are added or removed from it.

It’s especially tricky because the destination volume won’t typically show as actually full, in the Finder – it could have virtually any amount of space left, even hundreds of gigabytes, because the particular image or video that hits the limit could be huge, and Image Capture either tries to pre-allocate the entire file’s space up front (failing immediately if there’s insufficient space) or retroactively zeroes out the file if it encounters a write error. Either way, it leaves a bunch of zero-byte files (the failed transfers) behind, rather than incompletely-written ones, further hiding the fact that it ran out out of disk space.

1. Please don’t ever do that. It means transcoding your original images from DNG or HEIC into JPEGs, increasing their file size and/or reducing their quality in the process. Don’t do it. DNG and HEIC are old formats that are widely supported – not just on Apple devices, but Windows as well (and probably most Linux distros). ↩︎

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 you should use DMGs, not Zip files, because of bugs in Apple’s server-side infrastructure, and also that those instructions are missing the final step:

xcrun stapler staple -v MyScreenSaver.saver

Note that you run it against the screen saver itself, not the DMG. The DMG’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.

Five minutes of some trivial testing shows that this is just not true.

Noise is still affected by input gain

Here’s a composed recording of four 3-second clips recording the room tone in my office. They are (in order): Auto gain, 57dB, 35dB, 0dB:

As you can hear, auto and maximum input gain in this case have very similar noise levels (which is to say, perceptually none), but as you reduce the recorder’s input gain (and instead apply the gain in post) the noise increases substantially and becomes very noticeable.

Granted this is a very big gain application – 57dB – which you would hopefully never need to apply to a real recording, but nonetheless it demonstrates that Tascam’s claims are exaggerations at best; if you actually had the Portacapture X8’s input gain set to 0dB and recorded quiet sounds, you would in fact have problems with noise – problems that would be avoided with a correct input gain setting.

Clipping still happens if input gain is too high

The recorder clearly applies actual analog amplification and can still saturate its ADCs, as shown in this composite of three gain levels. They are (in order): Auto gain, 35dB, 57dB.

Warning: annoying, distorted sound.

It only went over by about 3dB (at 57dB input gain), but that was enough to destroy the input signal and make the recording unusable.

Auto Gain still affects the recording

In the above tests I included the Auto Gain setting, even though it doesn’t exhibit particularly high noise nor does it clip in these simple sound environments (basically constant sound levels). And it worked pretty well (not optimal input gain levels, but close enough for my taste).

But, I was curious if it had any effect at all – again, reading about 32-bit floating-point recording online, you’d be forgiven for thinking Auto Gain has no impact on the actual recorded data. Many people liken the format to camera raw files, and some explicitly state that Auto Gain has no impact on the bits that get written to disk.

This is completely false, at least in the case of this Tascam Portacapture X8. It’s trivial to see why:

Auto Gain still does exactly what it always does – it changes the gain in response to the input. That change is baked into the recorded audio track(s).

So in a nutshell, 32-bit floating-point recording might provide slightly more flexibility in some situations, but it does not mean you can ignore your input level settings, it does not mean you can use Auto Gain in every scenario, and it does not mean you cannot clip.

Addendum: Technical details

I tested post-production gain changes in Final Cut Pro, Logic Pro, & Audacity. All produced the exact same results (to my ears). I had read that Final Cut Pro sometimes ‘bakes in’ clipping with 32-bit float inputs, as if it’s pre-rendering them down to some smaller dynamic range, so I wanted to rule out some Final Cut Pro-specific stupidity. It’s possible that all these editors are doing that, but I’d be flabbergasted if that’s true.

The “industrial noise” sample I used was my dehumidifier, which is about 66dB according to DecibelX on my iPhone 14 Pro. My office room tone is about 42dB according to the same app.

I used Sennheiser K6 modules with an ME65 and ME66 attached, plugged into the Tascam Portacapture X8 via 3′ Cable Matters XLR cables.

I recorded at 96kHz because that’s what I’ll use most often. I like the aliasing headroom above 48kHz (even though of course my final outputs are almost always 44.1kHz or 48kHz), but don’t see evidence that 192kHz provides meaningful additional benefit (and it also hurts the frequency response significantly, compared with 48kHz and 96kHz, according to Tascam).

In short:

1. File > Library Properties (⌃⌘J).
2. Click “Modify Settings” next to “Storage Locations”.
3. Set the “Backups” option to “Do Not Save”.

My projects are already covered by Time Machine and other backup mechanisms, and I tried to tolerate Final Cut Pros built-in backup system, but the damn thing runs so often, which I know about very well because whenever it runs Final Cut Pro becomes completely unusable for several minutes. It’s immensely irritating when it kicks in while I’m in the middle of editing.

I discovered this from April King via John Siracusa.

If all that is lost on you, you’re in for a treat.