Broken by design – Wade Tregaskis

Backblaze seemingly does not support files greater than 1 TB

Thu, 02 Jan 2025 23:27:59 +0000

For nearly a month now, Backblaze has been fixated on a particular file of mine, that happens to be over 1 TB in size. Backblaze seemingly uploads it completely, but then on the next backup it uploads it again, even though it has not changed (in eight years!). Ad infinitum.

Using their Explainfile tool to dig into the log files, the clue seems to be:

  - line 288 - 2024-12-16 16:16:17 0000000646 - ERROR: UpdateBzDoneRegardingFlsToBeExp - Z_B_TOO_MANY_CHUNKS bz_done_ line chunk related, numBytesInLargeFile=1099512156951, totNumChunks=104858, bz_done_line_is: 5	! …
  - line 522 - 2024-12-16 16:18:46 0000000646 - ERROR - bz_done_ INCONSISTENCY_FOUND - 20241216161846 - BadBadBadChunkRecord hexAsciiVal=0x78 - AfterBzdoneLargeFileAnalysis: chunkSeq=100001, highestChunkSeqSeen=104857, fileIdOfLargeFile=00000000002c53cd, dateTimeOfLargeFile=20231217091843, XYXBXXX_FILE_NAME: …

Admittedly I’m guessing somewhat, since that’s a rather reader-hostile log message, but the combination of the Z_B_TOO_MANY_CHUNKS error mnemonic and chunkSeq=100001 (because of its proximity to the arbitrary round number 100,000) strongly suggests that Backblaze is imposing a 100,000 chunk limit. Since chunks are 10 MB each, that’s exactly 1 TB.

This is unequivocally at odds with what they claim repeatedly on their website, on pages like What Backblaze Backs Up and File Sizes.

It’s not clear to me why this is suddenly a problem; is this a newly-imposed limit? It’s possible that a month ago I removed some exclusion on the file, but I don’t remembering doing that and I can see no reason why I would have excluded it to begin with. If it is newly imposed, that would imply it’s also retroactive – that Backblaze actually deleted the existing backup of the file from their servers, thus causing the client app to try uploading it again.

I reached out to their technical support, of course, but thus far have only received mindless responses – restart your computer, reinstall Backblaze, etc.

Update

I received no further response from Backblaze’s technical support. They asked me to send them the log files, which I did on January 2nd, 2025, and they never responded again.

As of this update (February 4th 2025) their website still falsely advertises support for files of any size.

Addendum

I was surprised to see that many folks on HackerNews were surprised by the idea of a 1 TiB file. I certainly agree that’s large, but it doesn’t seem unusual or inexplicable to me. In my case, this particular “problem” file is an encrypted, compressed disk image of the boot drive of a prior computer, that I saved when I upgraded to my current computer.

It’s true that I could probably throw it out at this point – it was just a precaution in case I forgot to migrate something over, so now (eight years later) it seems that either I made no such mistake or whatever I forgot to migrate doesn’t matter anyway. For now I’ve just manually excluded it from the backup, to work around Backblaze’s bugs.

There are other cases in which I’ve had files over 1 TiB, though – e.g. video files:

With some cameras and recording modes (e.g. documentarian, interviews) it’s in principle easy to exceed 1 TiB per file. e.g. the Nikon Z9 & Z8 record around 700 MB/s for 8k60 N-RAW, which is about 24 minutes per TiB.

Note that I don’t recall if I personally have ever actually exceeded 1 TiB this way. I mention it mainly for illustration. It’s also possible that the Z9 & Z8 shard large recordings into multiple files (I don’t recall seeing this in years – not since the 4 GiB per-file limit of cameras a decade ago – but perhaps I’ve just not had a single recording large enough).
Usually (for me) it’s output files that are largest, since they can combine many clips. I use Final Cut Pro and its video compression capabilities aren’t great, so I export essentially lossless ProRes and then use ffmpeg or Handbrake for the real compression. ProRes 422 HQ is nearly a gigabyte per second for 8k60, so it takes less than twenty minutes of video to exceed 1 TiB. Fortunately these large intermediaries only have to live as long as the final compression takes (though that can be days, especially with the latest formats like AV1).

NSCopyObject, the griefer that keeps on griefing

Tue, 16 Jul 2024 00:42:07 +0000

NSCopyObject is a very old Foundation function – pre-dating Mac OS X entirely; from the NeXT era – that was originally basically just memcpy, but now it’s complicated. A lot more complicated.

What `NSCopyObject` does

Its implementation currently starts with essentially:

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

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

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

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

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

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

But I don’t use `NSCopyObject`…?

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

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

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

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

So how do I defend against `NSCopyObject`?

Objective-C

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

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

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

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

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

Swift

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

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

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

Strictly-speaking, the only safe thing to do is override copy(with:) and not call super, but rather create a new instance from scratch.

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

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

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

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

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

Do as Apple says, not as Apple does

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

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

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

NSCopyObject has been officially deprecated since 2012:

The NSCopyObject() function has been deprecated. It has always been a dangerous function to use, except in the implementation of copy methods², and only then with care.
Foundation Release Notes for OS X 10.8 Mountain Lion and iOS 6

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

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

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

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

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

Tangent: NSCopying considered harmful

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

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

Yes, it’s still possible to this day to write Objective-C without using ARC – -fno-objc-arc / CLANG_ENABLE_OBJC_ARC. There might even be valid (albeit unfortunate) use-cases for having to do so, such as for performance.

And even with ARC, it’s of course possible to have pointers to things which aren’t NSObjects and therefore aren’t handled by ARC, such as raw malloc allocations. ↩︎
This is false and always has been (that it was safe to use in copy methods). Apple’s false statements in the deprecation notices may ironically have caused even more instances of people using NSCopyObject. ↩︎
Any and all that add retain-counted ivars, Swift stored properties, or ivars of C++ types that have destructors. ↩︎

Copying whole folders in an Xcode Copy Files Build Phase

Mon, 26 Feb 2024 00:00:26 +0000

If you try to copy a regular folder (what Xcode calls a “Group”) into a file list for any Build Phase, Xcode refuses. But it does work if you use a folder reference .

I have been unable to deduce any reason for this.

Proactive Peek & Reveal on Edge Hover

Mon, 12 Feb 2024 22:29:57 +0000

These are two misfeatures that appeared in macOS Sonoma (I believe). They are where a closed sidebar forces its way back into view temporarily, if the mouse comes to rest near the relevant edge of the window.

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

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

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

I’m not the only one to detest this ‘feature’, although it’s hard to know the sentiments of the overall Mac community since these ‘features’ have no official names – I deduced them from the private method & category names in AppKit – so they’re hard to search for. FWIW, I could not find a single positive comment about these behaviours.

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

defaults write -g NSSplitViewItemFullscreenEdgeRevealDelay -float 1e300
defaults write -g NSSplitViewItemTileEdgeRevealDelay -float 1e300
Steve Troughton-Smith

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

SwiftUI drag & drop does not support file promises

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

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

FB13583826.

Is that it?

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

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

Best alternative (other than ditching SwiftUI)

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

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

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

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

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

        return nil
    }
    
    return provider
}

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

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

Understanding the SwiftUI drag & drop APIs

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

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

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

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

Bad API example: FileManager’s url(for:in:appropriateFor:create:)

Wed, 31 Jan 2024 20:40:07 +0000

I find FileManager‘s url(for:in:appropriateFor:create:) to be very unintuitive. It seems to have multiple, largely-orthogonal functions. It can provide paths to common folders (albeit badly). It can create temporary folders. It can locate volume-specific bins (Trash folders).

It is an example of bad API design. Specifically, regarding cohesion: the principle that an API should have one purpose. A litmus test for this is whether all the method parameters are always applicable¹.

It wasn’t until I wrote a test driver which explores its entire parameter space, that I was finally able to grok what the hell it’s doing and delineate its multiple modes of operation.

I’ve contrasted it with the results from its sibling urls(for:in:), to better understand what it’s doing (and expose some more of its flaws).

Test driver

Creating files safely in Mac apps

Wed, 31 Jan 2024 02:48:27 +0000

Creating a file is a pretty basic and conceptually simple task, that many applications do (whether they realise it or not – library code often does this too, at least for temporary files such as caches or for communicating between programs).

So you’d think it’d be trivial to do correctly. Alas, it is not.

☝️ This is a challenging topic, and I’ve done my best to research thoroughly and check everything experimentally. Still, it’s certainly possible I’ve made a mistake or overlooked something. Please let me know of any errors, in the comments at the bottom.

Also, it’s a dense topic, so I’ve tried to highlight (in bold) the most important points. In case of TL;DR. 🙂

What is the danger?

There are two key things to watch out for when creating files:

Security flaws due to incorrect use of, or badly designed, file system APIs. This is especially a concern for privileged applications (e.g. setuid) or those that ever run with elevated privileges (e.g. via sudo or by admin users). Unintentional reuse of existing files can be (and has been) the cause of major security vulnerabilities. See the appendix for more details.

Another security concern is leaking sensitive information to other programs (or users, on a shared computer). This can easily happen if files are created in places other programs or users can access, such as shared folders. The files may be inadvertently created with inappropriately broad permissions (e.g. world-readable) or the parent folder’s permissions might permit others to change the permissions of the file after the fact even if they don’t own it (e.g. a world-writable folder without the sticky bit set).
Data loss risks due to inadvertent overwrites or modifications of existing files. If you’re not certain you know what file is already at a given path on disk, and that you should be allowed to overwrite it, then you should not. Usually, the user has to give explicit permission (e.g. Save dialogs that explicitly ask the user if they intend to overwrite an existing file).

This risk is greatest for persistent files, e.g. files in your Documents folder. Those are usually where the user stores their most important data.

For temporary files the level of danger is generally lower but not zero. If you’re using a system-designated temporaries folder, then in principle anything in there is unimportant anyway. However, randomly mucking with temporary files can still cause data corruption or loss, depending on how those files are used by applications (including your own). e.g. they might store autosaves of the current document in temporary files, and directly copy / move those files when the user formally saves. Thus, modifying the temporary file might end up modifying the user’s actual save file.

How are these dangers mitigated?

App Sandboxing helps

As annoying & limiting as App Sandboxing can be in other regards, it is one of the best single steps an application author can take to improve file security. For the most part, your application is the only (non-system & non-privileged¹) application that can write within its sandbox, and you’ll usually be creating files only within your own sandbox.

Avoid /private/tmp (a.k.a. /tmp)

/tmp is merely a symlink to /private/tmp.

/private/tmp is world-readable: every program on the computer can access its contents. Thankfully, it’s not as bad it first appears – /private/tmp is special in that it has the “sticky bit” set, which imposes some key restrictions on what users may do to each other’s files (most importantly, that they can’t delete them even though /tmp is world-writable).

Still, it’s better to use the tmp folder designated via FileManager.default.temporaryDirectory or URL.temporaryDirectory. Though the location and security properties of that folder varies:

If App Sandboxing is in use, it’s an application-specific folder like /Users/SadPanda/Library/Containers/com.sadpanda.MyApp/Data/tmp/. No other (unprivileged) application can access that folder.
If App Sandboxing is not in use, it’s a user-specific folder like /var/folders/v3/8anbad56df64adf3_35gj346jg13v19a/T/ (the exact path varies between user accounts and computers, by design for security). That folder is still insecure – it is accessible to all programs of the same user – but at least you don’t have to worry about other [unprivileged] users.

If used correctly, /private/tmp has essentially the same properties as the user-specific temporary folders. Using it correctly starts with ensuring files are created with no group or ‘other’ privileges, but the full complexities are beyond the scope of this post.

☝️ /private/tmp is not accessible when App Sandboxing is enabled.

Consider setting a restrictive umask

When you create a file on any Linux or Unix system, such as macOS, its permissions are set based on a combination of the specific API used and the process-wide umask. Good APIs will require you to specify the initial privileges of the file, but some do not (e.g. fopen) and instead use some arbitrary default, such as creating files as readable and writable by anyone (0666). That is bad – usually you don’t want your files readable by any other users.

While you should generally avoid APIs that don’t provide proper control over file permissions, you realistically may not even know if you’re using such APIs because they might be employed by library code you don’t control (including Apple’s).

While it’s possible that the parent folder(s) will protect a given file (by preventing access to their contents by other users), it’s safest to not assume that.

The umask can help mitigate the dangers of bad APIs by specifying which privileges are not to be granted by default².

The umask defaults to denying write access to groups and other users (0022), which is a start but still not good – read access to private user data is still a concern.

However – beyond the overly permissive default setting – there at two problems with umask:

It is a process-wide global. Modifications to it apply to all threads in your process, which makes it dangerous to modify. e.g. you might be creating a particularly sensitive file and need the umask to be 0177, so you set it to that, but before you actually get to execute the file creation another thread sets the umask to 0000 because it wants to create an otherwise unrelated file that’s world-writable.

So unfortunately the only safe way to use umask is to set it very early in process launch before any additional threads are created³.

You can try to enforce your own mutual exclusion around umask, e.g. with a global lock, but beware of 3rd party code (including Apple’s) that might modify umask without following your mutual exclusion protocol. Generally umask isn’t modified often, so this arguably is possible to achieve in practice, but proving that there are no missed calls to umask can be practically impossible.
Lots of existing code, that you might be unwittingly using via libraries or frameworks, assumes the umask remains at its default. Thus, making it more restrictive might break things in ways & places that are difficult to foresee.

In general the more complicated your program, that more of a concern this is. e.g. most command-line programs can modify umask without causing issues, but GUI programs pull in a lot of framework code and functionality, some of which might implicitly rely on certain umask bits. Unfortunately the only way to find out is experimentally.

So umask is not a panacea. Still, setting a restrictive umask improves security if you can get away with it.

Correctly use the right file creation APIs

In short, creation of files needs to (generally) not extend nor replace existing files, and ensure correct initial file permissions.

There are quite a lot of APIs for creating a file in macOS. I’m going to enumerate only the most common ones provided by the system libraries & frameworks.

`⚠️` `open`

Nominally this is the low-level API for opening (existing or new) files, although as you’ll see later it’s not actually the only one.

It has a flags parameter, which is how you tell it what to actually do, between opening existing files, creating new ones, etc. Two of the most important flags are O_CREAT and O_EXCL. O_CREAT tells open to create the file. If O_EXCL is specified, open will fail if a file already exists at the target location. If O_EXCL is not specified, O_CREAT is interperted as “create the file if necessary” – meaning, it will actually open the existing file if it exists, and not create a new file.

You should almost never use O_CREAT without O_EXCL. If you really do intend to overwrite the existing file, then it’s safer to remove the existing file first (e.g. with unlink), and then create your new file (with O_EXCL to ensure no other file appears at the target location in the interim). That way you ensure the new file has your expected location (not a symlink) and attributes (e.g. file permissions).

Note that O_EXCL will fail if the target is a symlink, so you don’t need to specify O_NOFOLLOW (although it doesn’t hurt).

open requires you to specify the new file’s permissions if you use the O_CREAT option (and respects the umask), which is good as it makes you think about what the permissions should be, and lets you set them to something suitable for each use case. These permissions are only applied to new files, so in a nutshell you cannot rely on them if you don’t use O_EXCL.

For that reason also, you typically should not use O_TRUNC. If you don’t need the contents of the existing file, delete the file first. “Reusing it” via O_TRUNC also reuses its permissions and other attributes, which might not be set correctly for your intentions (e.g. a malicious program might have pre-created the file as world-readable, even though you intend it to be readable only by the current user and have otherwise done the right things such as set the umask to ensure that).

One reason you might validly use O_TRUNC is if you anticipate there being multiple hard links to the file, and you want to modify the file as seen by the other links too. This is very rare. Be sure that’s necessary before you use O_TRUNC, and consider putting validations in place to ensure the file you’ve just opened for reuse has the expected permissions and attributes (e.g. via fstat64 and similar APIs that operate on the file descriptor – do not use lstat or any other path-based APIs).

⚠️ `fopen`

This is essentially just a wrapper atop open, with the “w” and “a” flags mapping to O_CREAT (essentially) and the “x” flag mapping to O_EXCL. The same rules apply, so you should generally never use “w” without the “x” flag as well, nor “a” without “+”.

fopen does not let you specify the permissions of the created file, instead defaulting to 0666 (readable & writable by everyone) which is a terrible default. It does respect umask, so by default it will create files as 0644 which is marginally better. But, as discussed previously, it is difficult to guarantee what the umask actually is at any particular point in time. So in general you should prefer open instead of fopen.

❌ `OutputStream(toFileAtPath:append:)` & friends

This ultimately (when you call the open method) calls open with the flags O_WRONLY | O_CREAT (plus O_TRUNC if the append argument is false). As such it will always modify an existing file if present.

It also does not let you specify the permissions of the new file, instead defaulting arbitrarily to 0666 (but respecting umask, at least).

It is an unsafe API and should not be used.

⚠️ `NSData.write(toFile:options:)` & friends

This family of methods all ultimately call open_dprotected_np (implementation), a variant of open specific to Apple platforms which adds Apple-specific functionality regarding file encryption and isolation (see e.g. the protection-related flags within NSData.WritingOptions). It takes the same flags as the regular open, and write(toFile:options:) by default uses O_CREAT | O_TRUNC. If you use the withoutOverwriting option, it adds O_EXCL. So you should usually use withoutOverwriting.

If you use the atomic flag, it creates the file using a private function _NSCreateTemporaryFile_Protected which obtains a file path using mktemp ⚠️ and calls open_dprotected_np with the flags O_CREAT | O_EXCL | O_RDWR⁴. Once it has created & written to that temporary file, it uses rename to move it into place. rename just silently deletes any existing file at the destination path. So it’s safe against race attacks, but susceptible to data loss bugs from unintentionally overwriting existing files. As such, use atomic only with caution.

⚠️ If you add withoutOverwriting on top of atomic, the call crashes your program! It throws an Objective-C exception – NSInvalidArgumentException. Swift does not support Objective-C exceptions (it’s fundamentally unsafe to pass Objective-C exceptions up to Swift functions) so you have to use an Objective-C helper function as an intermediary.

This is a particularly unfortunate limitation – even aside from the crashiness – because using both options together is highly desirable and it should in principle work – the implementation can simply use renamex_np instead with the flag RENAME_EXCL.

FB13568491.

It also does not let you specify the permissions of the new file, instead defaulting arbitrarily to 0666 (but respecting umask, at least). For files containing sensitive data (such as private user data), this API should generally not be used.

❌ `NSString.write(toFile:atomically:encoding:)` & friends

These are essentially just wrappers over NSData.write(toFile:options:) & friends, where the atomically argument maps to the atomic option. They provide no way to use the withoutOverwriting option, so they should not be used in most cases.

Use randomised names for transient files

Whenever the file name doesn’t actually matter – i.e. it’s not chosen by the user and isn’t pre-defined by some system requirement – it’s best to use a randomised name. This serves two purposes:

If your code has any bugs that allow it to erroneously overwrite existing files, using random names at least makes it a lot less likely that you’ll trigger those bugs, by greatly reducing the odds of using the same name twice.
It makes it harder (if not impossible) for attackers to predict the file names, and therefore to attack them.

There are many ways to obtain a randomised name, but it’s wise to use one of the canonical methods detailed below.

☝️ If you do care about the file name, but not its location, you can use these APIs to create a randomly-named temporary folder, and then create your file within there.

This can be handy for e.g. preparing a file URL to be dragged from your app, where you want the file to have a proper name but don’t care (per se) where it lives.

⚠️ `mktemp`

mktemp is infamously a source of security vulnerabilities, because it doesn’t actually create the file (or folder) but merely returns a path. The caller is responsible for securely creating the file (or folder). This can be done safely – by following the guidance earlier in this post, in particular around the O_EXCL open flag – but it’s easy to screw up.

Generally it’s preferable to use mkstemp / mkdtemp & friends. Unfortunately, if you want to use higher-level file APIs on Apple’s platforms that’s a problem because most of those APIs don’t support initialisation from a file descriptor, only a path (or equivalently, URL). So you may find that you still need to use mktemp. If so, be very careful about how you actually create the files & folders.

✅ `mkstemp` / `mkdtemp` & friends

These replacements for mktemp actually create the file / folder (respectively), in a safe way.

mkstemp creates the file and returns the corresponding open file descriptor, instead of merely returning a path and leaving it to the caller to get the creation step right. It will never overwrite (nor open) an existing file. It also sets the file’s initial permissions to 0600 (i.e. read-writable but only by the current user), which is a pretty safe default.

mkdtemp still returns a path (not a file descriptor), like mktemp, but it ensures the folder was actually created (and not previously existent) with the permissions set to 0700 (i.e. usable only by the current user).

Neither make any guarantees regarding security – or lack thereof – due to parent folder permissions. The caller still needs to ensure necessary security protections for those (whether by choosing a suitable system-provided folder, or manually checking permissions and symlinks in the path). URL.temporaryDirectory is a good starting point.

Using these from Swift is a little awkward because they mutate their primary argument (the path template), but here’s an example. Once you have the file descriptor (in the mkstemp case) you can wrap it in e.g. a FileHandle and work with it at a slightly higher level.

`⚠️` `FileManager.default.url(for:in:appropriateFor:create:)`

In its special mode where ‘for’ is .itemReplacementDirectory and ‘in’ is .userDomainMask, this behaves like mkdtemp; it creates a randomly-named folder and returns the URL to it (note that it completely ignores the ‘create’ argument in this case – there is no way to have it not create the temporary folder).

This API seems to presume the use of App Sandboxing to mitigate its problems – and when App Sandboxing is enabled, it’s the best way to obtain a temporary file or folder path, though only if you use a suitable value for the ‘appropriateFor’ parameter, such as URL.temporaryDirectory⁵. When App Sandboxing is enabled, that will result in a path inside the sandbox, which is the most secure place an unprivileged application can use.

However, if instead a URL is provided which points to a different volume, it returns a path to a user-specific temporary folder on that volume, e.g. /Volumes/Example/.TemporaryItems/folders.501/TemporaryItems/. While that does exclude (unprivileged) other users, it’s still a big step down from a location inside the app’s sandbox.

Appendix: File system races in more detail

Generally-speaking, the file system is a shared resource. Multiple programs can access it simultaneously with no coordination required⁶ between them. That opens the door for races – where the state of the world changes in-between file system operations that a program might mistakenly assume are atomic.

In general, any single call to a low-level file system API – e.g. open – is atomic. Most such APIs correspond to a single syscall into the kernel, and the operation inside the kernel is wrapped inside a lock (conceptually if not also literally).

Conversely, any operation that takes multiple calls to a file system API is never atomic.

A textbook security vulnerability arises when you do something like:

Make up some random file name (e.g. with mktemp).
Check that it doesn’t exist (one syscall), and see that it doesn’t.
Write to that file (a separate syscall).

A malicious program could inject its own file in-between steps two and three – or even more dangerously, a symlink – and cause your program to overwrite something (many file APIs will automatically follow symlinks and open existing files, if not used correctly as detailed in this post).

The classic concern in this regard is with privileged programs that have the ability to overwrite sensitive files, e.g. /etc/passwd. Tricking them into doing so can cause major damage to the system (e.g. nobody can login anymore!) in the best case, and in the worst case – where the attacker can also influence the contents of the file, or those contents are conveniently just what the attacker wants – they might be able to implement a more subtle attack that doesn’t merely break the system but instead e.g. changes the root password, giving them superuser access to the computer.

Even for unprivileged applications, it can still be a concern. e.g. they might be tricked into writing a bunch of private user data into a shared location from where the attacker can exfiltrate it.

Appendix: File writing APIs that cannot create new files

These APIs are nominally irrelevant since they can’t be used to create new files, but it can be useful to know that fact, for use in converse scenarios where you do not want to create a file.

`FileHandle(forWritingAtPath:)`

…ultimately calls [[NSConcreteFileHandle alloc] initWithPath:… flags:0x1 createMode:0 error:nil], which turns the path string into a URL using -[NSURL fileURLWithPath:] and calls -[NSConcreteFileHandle initWithURL:flags:createMode:error:], which calls _NSOpenFileDescriptor to do the actual file system calls. That calls open with only the flag O_WRONLY; it does not pass O_CREAT nor O_EXCL. So FileHandle cannot create new files (which I find a bit unintuitive, as nothing in the name really suggests that limitation).

`NSData(contentsOfFile:options:)` & friends

…ultimately call open with no flags (meaning they can only read existing files, not even modify them). So again, cannot create new files. Which is perhaps implied and obvious from the name, but it’s good to be certain.

In principle system programs & privileged (e.g. root & admin) programs should be defended against too, but it’s often impractically difficult to do so, and beyond the scope of this post to try to explain how.

Root is of course the most impractical to defend against – even though the root user is not a traditional “God” user on macOS, Apple’s nerfing of root is designed to protect Apple’s programs, not yours. Root (and admin users) can ultimately still access any files your application(s) create and there’s nothing you can do about it (other than potentially through orthogonal protections, such as encryption). ↩︎
It is of course possible for libraries to override the umask, but that would be particularly foul of them and none that I’ve surveyed do that, thankfully. ↩︎
This can be hard to guarantee, in a non-trivial program. You can use an assertion or precondition on the return value of pthread_is_threaded_np to help ensure you’re modifying umask before additional threads are created. ↩︎
It’s not apparent to me why it needs read access to the file as well – that appears to be a bug. ↩︎
I’m not sure what happens if the App Sandbox container is not on the boot volume. ↩︎
There are various mechanism for voluntary coordination, such as NSFileCoordinator and flock, but programs are not required to use them (and malicious programs happily won’t). ↩︎

NSImage is dangerous

Tue, 23 Jan 2024 21:53:57 +0000

NSImage is formally documented as largely not thread-safe:

The following classes and functions are generally not thread-safe. In most cases, you can use these classes from any thread as long as you use them from only one thread at a time. Check the class documentation for additional details.
Apple’s Threading Programming Guide > Appendix A: Thread Safety Summary, subsection Application Kit Framework Thread Safety

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

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

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

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

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

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

NSImage 101

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

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

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

Sidenote: notice how it supports modern formats like WebP, AVIF, and JPEG-XL, but only for reading, not writing. 😕

It used to be that NSImage was pretty much a one-stop-shop for typical app image I/O needs, but Apple have for some reason crippled it over the years. I feel like this is part of a larger trend of Apple providing increasingly less functionality, more complexity, and less coherence in their frameworks.

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

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

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

Accessing / using an NSImage

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

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

☝️ You can usually obtain the NSBitmapImageRep (via e.g. bestRepresentation(for: .infinity, context: nil, hints: nil)) even before it’s actually been loaded – initially it’s largely just a shell, that knows its metadata (e.g. dimensions and colour space) but not yet its actual imagery.

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

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

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

Nominally, bitmapData just returns a uint8_t*.

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

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

There is no mutual exclusion protecting any of these code paths.

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

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

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

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

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

The pointer you pass to the function is only guaranteed to be valid for the duration of the function call. Do not persist the pointer and access it after the function has returned.
Apple’s Swift Standard Library > Manual Memory Management > Calling Functions With Pointer Parameters, subsection Pass a Constant Pointer as a Parameter.

The source code for the relevant NSBitmapImageRep methods is essentially:

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

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

🤦‍♂️

The bitmapData property and getBitmapDataPlanes methods are fundamentally unsafe.

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

Nominally the colorAt(x:y:) method could also be safe, but it currently lacks the same underlying mutual exclusion – and even if it didn’t, the performance when using it is atrocious due to the Objective-C method call overhead. Even utilising IMP caching, the performance is still terrible compared to directly accessing the bitmap byte buffer.

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

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

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

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

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

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

What can you do?

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

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

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

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

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

Reminder: macOS system frameworks binaries are hidden (since Big Sur)

Tue, 23 Jan 2024 18:59:12 +0000

Every now and again I’ll go to do something really innocuous with an Apple framework, like disassemble it in Hopper or check the link headers. And every. single. time. I forget that Apple did some really weird shit in Big Sur, and removed the binaries.

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

WTF, mate?

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

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

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

Mac app sandboxing interferes with drag & drop

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

Failed to get a sandbox extension

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

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

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

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

Noticing when drag & drop operations start

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

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

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

Drag & drop implementation detail

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

Pasteboard implementation detail

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

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

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

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

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

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

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

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

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

The essential code is:

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

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

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

    lastDragPasteboardChangeCount = currentChangeCount
}

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

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

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

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

You get only one look at the dragged files

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

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

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

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

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

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

Sigh.

FB13520048.

Failed workarounds

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

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

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

Partial workaround

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

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

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

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

Addendum: Michael Tsai’s Blog

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

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

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

SwiftData pitfalls

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

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

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

Background

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

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

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

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

Example use case

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

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

Design flaws

Auto-save doesn’t work

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

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

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

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

Workarounds

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

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

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

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

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

Arrays of `@Model` objects are randomly shuffled

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

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

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

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

Workarounds

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

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

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

`let` cannot be used for bidirectional relationships

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

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

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

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

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

Workarounds

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

Relationships are secretly implicitly unwrapped by default

@Model
final class Room {
    let monster: Monster

    …
}

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

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

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

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

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

Workarounds

None, really.

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

You cannot directly initialise bidirectional relationship properties

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

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

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

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

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

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

Workarounds

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

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

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

Relationship constraints are only enforced at save time

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

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

Workarounds

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

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

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

Singletons are unsupported

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

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

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

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

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

Workarounds

Basically you have three choices:

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

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

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

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

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

You cannot create model objects outside of SwiftData contexts

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

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

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

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

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

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

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

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

Workarounds

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

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

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

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

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

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

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

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

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

Apple’s documentation is wrong

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

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

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

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

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

Another poignant example:

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

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

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

Workarounds

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

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

Non-pitfalls

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

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

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

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

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

Bonus: TablePlus recommendation

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

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

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

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

Apple Watch Ultra is a poor dive computer

Tue, 06 Dec 2022 04:59:28 +0000

Note: this was written in 2021 (and updated in 2022) based on version 1 of the Oceanic+ app. In September 2023 version 2 of that app was released, and it appears to have fixed quite a few limitations (e.g. you can finally export your log book, as a standard UDDF file). Once I’ve gathered some real-world dive experience with the updated watch, I may write a new review.

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

It’s been a rough and disappointing road.

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

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

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

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

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

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

It doesn’t start recording automatically.

You have to hit the “Action” button to acknowledge a lawyer-smelling disclaimer that you’re “fit to dive”. If you forget, it doesn’t record.

I’m not aware of any other dive computer that does this. e.g. my Shearwater Peregrine autodetects submersion below one metre even if it’s not on. It turns itself on and starts recording automatically.
If you ascend above one metre, even just for a split second, it immediately ends recording.

This makes shore entries, in particular, likely to go unrecorded (unless you’re able to swim out to deep water and descend rapidly, which isn’t always an option or the best dive plan). Descents in significant swell, currents, or surge could also fall victim to this design flaw.

So on my first dive I got five “dives” recorded, representing the four times where the swell floated me up to just above one metre (I never actually broke the surface). Even just reaching up momentarily with your watch hand, such as to grab a line or brush away a fin, could trigger it to fail.

Furthermore, there’s no way to merge these together in Oceanic+ – you can either keep them, messing up your dive counts and stats, or delete them, throwing away [parts of] actual dive records.

And on later dives I didn’t always notice it had failed and stopped recording, so it basically didn’t record the dive at all. This will be less of an issue if you’re using it as your only computer, since you’ll be looking at it periodically throughout your dive (I was using a separate dive computer as my primary, since I wisely didn’t trust the Apple Watch Ultra untested).

Again, I’m not aware of any other dive computer that has this flaw. e.g. my Peregrine allows a sixty second grace period before ending the dive (configurable for up to ten minutes).

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

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

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

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

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

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

“Dives number”… wot? And why are the sizes & baselines different for every single number on this screen?

This can’t be intentional. And that colour-coding scheme is quite hostile to colourblind people.

I guess it could be a stylistic choice to have the “Edit” button escape its bounds… but I suspect not. I’m also not convinced my life is improved by the omission of “nths”.

Why is “Gas” so tiny and lonely in all that white space? Why isn’t “Scuba” vertically centred? What is “PPO2 Dive” and do they mean “PPO₂ Limit”?

Good chart. Really captures the essence of my dive.

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

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

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

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

Any time you ascend past six metres, it throws up an alert about a safety stop. Which keeps buzzing at you forever, until you hit the action button. It’s hard to overstate how annoying this is when doing shallow dives. It is super distracting and may put you in harms way (e.g. if you’re constantly having to fiddle with the Apple Watch Ultra instead of paying attention to the reef around you).

I simply can’t fathom why they feel the need to alert for this at all. An alert would be warranted for skipping your safety stop, yet it doesn’t do that.
It vibrates the Apple Watch Ultra frequently without any indication why (nothing changes on the display). Observationally, I suspect it’s something to do with ascending “too fast”, but if so then it’s way too sensitive to small depth changes – it vibrates at me when simply ascending less than a metre (even when tens of metres deep, where a metre makes very little difference in pressure).

Overall, the Apple Watch Ultra is too chatty. It’s a classic boy-who-cried wolf problem waiting to happen.
It doesn’t show CNS, current PPO₂, [surface] GF, etc. Especially when using enriched air (Nitrox), nearing no-decompression limits, or deep diving, these are important for safety. They are purely software features so it’s especially odd that they’re not included.

Surface GF is arguably the most important of these – it basically tells you how dangerous it is to surface immediately. When everything goes smoothly – and assuming you’re planning safe, conservative dives – you don’t need to worry much about it. But when things go awry it can be critical in helping you make the right decision under pressure.
There’s no Oceanic+ Mac app, or even a web version, which strongly discourages actually using Oceanic+ as your full dive log. Entering all the details of your dive – gear, notes, etc – is very tedious on an iPhone.

Some other dive computer manufacturers do have Mac apps (e.g. Shearwater, albeit one that’s clearly made in some janky cross-platform framework and looks like something you’d find in X11 in the 90s), and there are a few viable 3rd party options (e.g. MacDive, Subsurface).
The map it shows, of your entry & exit points, is useless most of the time, because it just shows as flat blue (for water) with no identifying geography. There’s no way to switch it to anything useful, like a satellite view that would actually reveal the reefs, sand bars, atolls, etc.

This is exacerbated by Apple Maps’ limitations. Google Maps, for example, often does show atolls & islands at least, and other surface features. Apple Maps simply lacks actual maps for most of the world’s oceans.

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

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

…and why is “m” sulking under the 2?

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

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

Gas usage recording. Upmarket dive computers support wireless communication with a dongle that attaches to your first stage regulator. This means you can forgo a whole separate hose and dangly, annoying air gauge, and have a unified view of your dive status. It also means you get more accurate tracking of tissue loading, and more advanced functionality like gas consumption rates (great for extra safety – know if you’re going to run out of air too early – and for optimising your gas consumption over time).

Radio protocols like Bluetooth don’t work underwater – lower frequencies are required. So the Apple Watch Ultra would require an additional built-in antenna. It’s arguably reasonable to omit this in a watch that’s not intended solely for diving, given the cost or other trade-offs it might require.

That said, some air-integrated dive computers use sound instead of electromagnetism, and I suspect it’s not hard to support the necessary, inaudible frequencies in the Apple Watch Ultra’s microphone(s). Maybe this support is already present in hardware, and a transmitter dongle will be released later?
Multi-gas support. Most dive computers support this, even those that are much cheaper than an Apple Watch Ultra. This is arguably a more “serious” or “technical” feature, that most recreational divers won’t ever need, but it’s also easy to do – it’s purely a software feature.
The ability to enter key dive details on the Apple Watch Ultra (as opposed to an iPhone), such as gas start & end pressures. It’s all too easy to forget these in-between the dive itself and when you get back to land and your iPhone.
The dive planner functionality is pretty rudimentary. e.g. you can’t do anything like actually enter a dive depth profile (whether as a squiggle with your finger, to give the rough idea, or importing it from a previous dive at the same site). The GUI is also a bit obtuse, especially in the Oceanic+ iOS app, as rather than showing a simple table or chart of depth vs no-deco times it makes you pick a single depth and gives you a single no-deco time. For planning you often want to consider multiple depth options and pick the right trade-off against dive (or at least bottom) duration.
It might actually be nice to have some “social” functionality. Not for bragging and other vanity purposes – I’m not talking about inane integrations with Facebook or whatever – but for sharing amongst dive buddies and the like. I suspect there’s some neat, innovative possibilities here (e.g. automatically detect physically- & temporally-nearby dive friends, and be able to automagically see their photos & notes on what they saw on what’s presumably the same dive with you – maybe even add your own notes on theirs like “don’t forget about that Whale Shark eating that Orca!”).

And lastly just some miscellanea:

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

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

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

Addendum (May 2023)

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

Two things which did improve at some point:

Recording now happens when submerged even if you haven’t clicked through the lawyer screen. This is a significant safety improvement.

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

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

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

Never import by copy into Final Cut Pro

Sat, 19 Nov 2022 00:04:30 +0000

By default, Final Cut Pro prefers to “copy” all files on import. Indeed you’d think this is the only sensible option most of the time, since most of the time you’re importing from a memory card and you do need to make a local copy somewhere on your computer.

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

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

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

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

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

Preventing system sleep in Ventura

Sat, 12 Nov 2022 16:55:49 +0000

Ventura’s new System Settings app, replacing System Preferences, removes the ability to control quite a few important things. One of those is whether or not the system goes to sleep automatically.

Well, it does let you control this setting but only for when the system is on mains power:

Limited controls over system sleep, in Ventura

By default the system will sleep on battery power after some undefined amount of idle time (approximately ten minutes, from observation). System Settings does not allow you to change this.

Fortunately you can use pmset in Terminal to fix this:

sudo pmset -a sleep 0

This specifies that the system should never sleep automatically – that’s the 0 part – and that it should apply in all situations – that’s the -a part.

Alternatively you can modify the setting for just certain power modes, by using different flags:

-b for when on battery.
-c for when connected to mains power.
-u for when connected to a UPS (and mains power is down).

Sidenote: you can use pmset -g to see the current settings regarding power management, e.g.:

System-wide power settings:
Currently in use:
 standby              1
 Sleep On Power Button 1
 hibernatefile        /var/vm/sleepimage
 powernap             1
 networkoversleep     0
 disksleep            10
 sleep                0 (sleep prevented by powerd, sharingd, nsurlsessiond, nsurlsessiond, nsurlsessiond, nsurlsessiond, nsurlsessiond, nsurlsessiond)
 hibernatemode        3
 ttyskeepawake        1
 displaysleep         2
 tcpkeepalive         1
 lowpowermode         0
 womp                 0

The dumpster fire that is the Raspberry Pi

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

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

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

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

I very quickly started wishing I hadn’t.

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

Acquiring a Raspberry Pi

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

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

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

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

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

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

Booting a Raspberry Pi

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

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

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

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

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

Aside: Raspberry Pi 4 as a desktop computer

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

Enabling Remote Access

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

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

Installing Homebridge

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

Ugh.

What a fucking dumpster fire.

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

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

Installing Homebridge Docker

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

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

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

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

The worst was yet to come.

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

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

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

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

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

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

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

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

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

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

This is why Linux can’t have nice things

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

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

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

Truly deleting ‘removed’ files from Lightroom

Sun, 10 Mar 2019 17:29:06 +0000

When you tell Lightroom to deleted rejected photos, it pops up a dangerous dialog box:

Though it does explain itself well – i.e. if you want to actually delete the photos, you need to click “Delete from Disk” – the default option is that misleading “Remove” button, which doesn’t really remove the files at all – it merely makes Lightroom lose track of them. They’ll still be there on disk, wasting space forever.

And, you can’t directly undo this operation, so if you hit return a little too quickly, or misread the dialog at any point, you’re seemingly pretty screwed (if you have a Lightroom catalog of any significant size).

Luckily, there is a way to find these undead files – that doesn’t require you walking through every single file on disk one by one & comparing against Lightroom’s view of the world.

1In the left-side panel, under the “Folders” section, select all the folders and right-click on them (if you have multiple volumes listed under “Folders”, you’ll have to do this one volume at a time as Lightroom won’t let you select folders across multiple volumes simultaneously). You’ll get a contextual menu:

2Click “Synchronize Folder…”. A dialog will appear:

You probably want to uncheck “Remove missing photos from catalog” (if it’s not already disabled) and “Scan for metadata updates”, as those are unrelated to the purpose here and have their own ramifications. Instead, just select “Import new photos” and “Show import dialog before importing”. Then, click “Synchronize”.

3Lightroom’s standard import dialog will now appear, and will slowly sort through all the files in the folder(s) you selected, filtering them down to just those that exist on disk yet are not tracked in Lightroom – e.g. all those rejects you accidentally “Removed” but didn’t really remove previously. You can now review those and see what you’ve got – it’s possible you’ll find in there media you didn’t intend to delete, but rather were somehow misplaced by Lightroom at some point.

You might want to, in the import dialog, change your preview generation setting to ‘Minimal’ in order to minimise import time & wasted preview generation. You could also choose to add some keywords to the imports, e.g. “to be deleted” or “recovered” or “undead”, if you’re not going to just immediately delete them anyway.

In any case, you can now import some or all the undead files. Importing them might seem counter-productive, since the goal here is to delete them – but it’s necessary for the final step…

4Once they’re imported, you can now immediately mark them as rejects and delete all rejects again – this time correctly choosing “Removing from Disk”.

So while it’s a bit roundabout, it does get the job done pretty quickly and easily. Now if only Lightroom would fix that stupid dialog to make the default option the one that actually does what you told Lightroom to do to begin with. 🙄

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

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

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

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

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

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

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

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

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

Blink XT review

Sun, 28 Oct 2018 00:50:14 +0000

Normally I’d just post a review like this on the merchant’s website – in this case Amazon. Yet perplexingly when I tried to do so, I was given the error message:

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

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

Anyway, FWIW here’s my review:

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

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

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

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

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

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

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

FTZ adaptor hates tripods, straps, and harnesses

Sun, 21 Oct 2018 02:13:14 +0000

The FTZ adaptor has a surprising and very frustrating design flaw – it’s impossible to mount it to the camera body when you have almost any kind of mounting plate, strap, or harness (e.g. Cotton Carrier) mount point attached to the camera body. This is because the FTZ has a big fat foot, as can be seen in the above photo, which sticks down well below the bottom of the camera body. Furthermore, the camera body’s tripod socket is very close to the front edge of the body – and thus the FTZ’s foot. Anything you attach to the camera body’s tripod socket tends to stick out from the front of the camera’s body – a lot. The FTZ’s fat foot collides with that, and makes it impossible to use both at the same time.

I suppose nominally you’re never supposed to use the camera body’s tripod mount when you have the FTZ attached, but that’s naive – if you’re going back and forth between native to adapted lenses, you’re not going to be constantly removing & reattaching things to tripod sockets. At most you’d want to have the same widget in both the camera body’s and the FTZ’s tripod sockets, so that you always have one available irrespective of what lens you have attached.

I miss companies that gave some thought to having all their products work well together (this is just the latest example I’ve noticed in an increasing trend).

iOS 7 first impressions

Wed, 10 Oct 2018 03:23:58 +0000

I found this post in the ‘Drafts’ folder from 2013 – evidently I started writing, got distracted, and forgot about it.

It’s interesting to me even now because the aesthetics of iOS have been stuck in iOS 7 ever since. I still don’t like the look, the design language, how many things operate – the interface is ugly, unintuitive, lacks personality, and – as the hosts of ATP might say – is absent the whimsy that defined Apple for decades.

It felt like a betrayal, too – now iOS, as of version 7, looked like a cheap Android rip-off. Apple had wilfully and pointlessly thrown away their most important positive differentiators. Insult was further added to injury by the mere existence of Windows Phone Metro, which – while still ugly to me too – at least demonstrated originality and a kind of bravery – it at least had a style, even if it wasn’t the one for me.

And it was dog slow. It basically killed my love of the iPad, because it made my iPad 3 frustrating to use. Even when I later got an iPad Air 2 (as a hand-me-down), my iPad love never really rekindled.

Nonetheless, I had been wondering for a few years: were I to go back now to iOS 6, would I be revolted & repulsed by it, and suddenly realise that iOS 7 and its ilk are in fact the current pinnacle of user interface & visual design?

A few months ago I got out my original iPad and turned it on. It was running iOS 5, the last version of iOS support on it. I hadn’t intended to go back in time – I’d forgotten entirely that it was pre-iOS 7. I didn’t realise straight away, either. My first thought, upon booting to the home screen, was “wow, this looks amazing”. It genuinely took me a while to figure out why this non-Retina, decade-old, square & heavy iPad felt fantastic.

Then I realised – because it looks good and is easy to use.

The default iPad 3 home screen under iOS 6. Admittedly prettier than on the original iPad, thanks to the Retina display, but you get the point nonetheless.
Screenshot courtesy of Dane Wirtzfeld via Flickr.

Without further ado, my until-now unpublished iOS 7 first impressions:

It’s buggy. The task switcher has a terrible time dealing with landscape orientation.
It’s slow. Both in general – perhaps just lacking some optimisations – and by apparent design flaws. e.g. many new animations are unnecessary to begin with, and unnecessarily slow to boot, and you can’t interact with things until the animation is done. It’s quickly frustrating.
The new slide-up gesture (for the little control sheet) steals scrolls periodically, which is exceedingly annoying. Perhaps in time I’ll recalibrate where I need to touch things in order to avoid that, but it’s annoying in the meantime.
Actually installing it was a pain and took multiple attempts, as per usual for any system restore. Le sigh.
Spelling correction is more aggressive now, and will even re-incorrect things after you explicitly fix them. Fucker.
To delete emails you now have to swipe the opposite direction – from right to left. No obvious reason, and certainly no indication on how to do that.
The new icons and dock design look like UI mocks. By someone who’s either not very good at them or just needs a really basic placeholder. They’re probably the most disappointing thing about iOS 7 so far.
The new lock screen is obtuse, as others have noted. The whole slide to unlock debacle is ridiculous and Apple has no excuse for it. But furthermore, it displays your chosen lock screen image arbitrarily cropped, and jitters it about randomly in what must be intended to be this infamous parallax effect, but in reality has no apparent relationship to the orientation of the iPad, and so just looks broken and stupid. Big cock-up all round there.

I love (meaning am tremendously sad) how certain aspects of those first impressions have lasted – some becoming huge memes of their own (e.g. damnyouautocorrect.com). And how some parts of the iOS upgrade experience – like having to do the install repeatedly to get it to work – persist to this day.

Nikon Z7 second first impressions

Sun, 07 Oct 2018 20:05:12 +0000

Having spent a week or so using the Z7 – though still not as much as I’d like, given the continued need to work for a living – I have some further thoughts, beyond / expanding upon my very first impressions.

Autofocus

Photo mode

Autofocus is a problem.

It is very clear that the Z7’s AF system is not in the same league as the Advanced Multi-CAM 20K system in the D500, D5, & D850. I’m increasingly concerned that it doesn’t even match up to the much older 51-AF-point systems used in much older DSLRs going way back to the 11-year-old D300.

As I immediately noticed from the moment I turned the camera on, it has big problems in anything approaching low light, especially with the slow (f/4) kit lens. Not just night photography low light, but indoor lighting low light. e.g. under 250W-equivalent LED ceiling lights, in a small room, shooting at ISO ~800, it struggles to focus accurately even on high-contrast, stationary subjects.

In fact for a while during my testing it back-focused to infinity, vs my subject 2 metres in front of me, and consistently kept focus there for a dozen photos, despite having AF-C engaged continuously, in single-point AF mode, with that point on my subject.

[Edit: DPReview also saw the exact same behaviour, in all respects.]

In bright light – e.g. direct sun – it seems to do fine, but then so does any camera from the last fifty years.

Another very concerning and frankly infuriating behaviour is that it simply won’t even try to focus if the subject is significantly out of focus to begin with. Every other camera I’ve ever used in my life would at least resort to racking the focus plane back and forth, but the Z7 simply will not do anything. You have to use manual focus override to bring the subject closer to being in focus, before the Z7’s autofocus system will even bother engaging. This is mind-bogglingly stupid – and a real problem if you remapped the ‘function ring’ on your lens to a function other than focus (e.g. aperture control).

Thus far in my initial experiments using the FTZ mount adapter and the Sigma 50/1.4 Art – where you’d think the huge increase in maximum aperture might alleviate some of the AF sensitivity problems – I’ve been disappointed. The much wider aperture seems to help a little bit, but not enough to make the AF system feel up to the Nikon name – nor the price tag for the Z7. (and yes, this is photographing wide-open – I’m well aware that the Z7 will stop the lens down to the shooting aperture during autofocus (down to a limit of f/5.6), unlike Nikon’s DSLR)

Next to consider are the AF modes, and AF tracking. For background, frankly I never found 3D Tracking in Nikon’s DSLRs to be very good – it’s very easily confused and will usually fail to track even the most clearly distinguished subjects. I have & do use it occasionally, but about the only scenario where I’ve found it consistently usable is birds in flight against a flat sky – at which point it doesn’t actually perform any better than Auto mode, really, since it’s merely focusing on the only thing in the frame that it can.

Put simply, the Z7 has some dumb – baffling – user interface flaws around its AF modes, the most egregious being that:

You cannot configure different physical buttons to engage different AF modes. My D500, for example, has the AF joystick configured so that pressing it engages single-point AF, while the dedicated AF-ON button engages a different mode (e.g. 3D Tracking, one of the dXX modes, or Group mode). You cannot do anything like this on the Z7, which is a bizarre regression and a serious problem not just for its own sake, but also because it compounds many of the Z7’s other flaws, below.
Face detection only works in Auto mode, and Auto mode continues (as with all prior Nikon cameras, and digital cameras in general) to be useless in most situations because it is utterly incompetent about determining your intended subject. It’s also incredibly sticky once it’s focused on something – face or otherwise. You actually have to move whatever it’s stuck on out of the frame entirely, re-engage AF, and hope it picks something better. I really wanted to use face detection, but repeatedly I find myself rushing to switch to single-point AF mode in order to get the shot that Auto mode is blocking. So while face detection itself is useful, and I’d like to use it more, the problem is that it’s rarely the only AF mode I need in any given situation, and Auto is basically never a useful AF mode. Given the inexplicable inability to configure different buttons to engage different AF modes, you’re stuck with this awkward choice of being able to conveniently focus on faces – but only faces, and only when it works, which is only sometimes – or do it all ‘manually’ with single-point AF mode. Or try to frantically switch back and forth between the two modes constantly, which I found to be impractically slow (and dangerously reminiscent of entry-level consumer DSLRs where basic functionality is buried in menus).
Face detection struggles in the presence of multiple faces. It makes strange choices about which face to default to, and switching between faces is basically a losing game of whack-a-mole – first you have to wait for it to recognise the face you want at all, then select it before it loses it again, all the while doing your best to guess which ‘direction’ the face you want is from the current one – you can only use the left & right buttons of the d-pad, even if the faces are arranged vertically, and the movement direction isn’t even consistent. e.g. several times I hit left and it jumped to a face to the right of the previously selected one.
The ‘tracking’ AF mode is a sub-mode of Auto mode, and frankly I find it a bit confusing to use as a result since you have to remember which of three states you’re in (normal Auto, tracking point placement, or tracking active) and use a variety of buttons to move between these states. It’s not quite as slow to engage as I feared from reading early reviews, and thus far it seems markedly superior to 3D Tracking in terms of actually tracking the subject, but the bad user interface really discourages its use.

The baffling thing in all this is why Nikon just didn’t do the incredibly obvious thing that they’ve basically already established with their pro DSLRs, i.e. have a dedicated AF mode – ideally the default – where you place the AF point wherever you like, position it over your subject, and hit AF-ON to start tracking, and continue tracking until you release AF-ON. Nothing could be simpler, and Nikon’s DSLRs have done this for over a decade. The lack of a sensible AF interface is an inscrutable, unforced error, which makes me genuinely question who designed the Z7, and whether they’d ever used a camera before.

Video mode

One of the main attractions to me of the Z7 over all Nikon’s DSLRs is the expected improvement in video capability. By all rights the Z7 should be dramatically superior to any DSLR, for video, even if only because it can finally do phase-detection autofocus in video mode.

Instead it’s a mixed bag.

The ability to do full-sensor-width UHD, rather than the severely cropped UHD of the D500, is very nice, and while I haven’t yet had occasion to do very wide angle video, I know when I do I’ll be very happy to actually be able to do it (even a 10mm lens on the D500 doesn’t give you an ultra-wide UHD video frame, because of the severe cropping).

Being able to use the viewfinder while recording video is a big improvement for general usability, and also stability – having that third point of contact, and your arms in closer to your body’s centre, make for a much more stable camera hold. It’s also correspondingly easier to record for long periods, since it’s an overall much more comfortable position.

Unfortunately, all of that is really undermined by the AF problems. Just as with photo mode, of course, AF in video mode struggles in anything even vaguely reminiscent of low light. And in video recording you just can’t have certain behaviours, like racking focus back & forth searching for correct focus. Alas, the Z7 does that constantly. Its video AF performance seems very similar to the purely contrast-detection based implementations in Nikon’s DSLRs. It’s basically unusable, in my experience so far… maybe in bright daylight it’ll prove more reliable – I have not yet had the opportunity to test it in such circumstances.

So for now video mode remains predominately manual focus, which is a huge disappointment.

Manual focus

Thankfully the manual focus story is much better than the auto one. The ability to digitally ‘zoom’ in the viewfinder, at the press of a button (configurable, of course), is extremely helpful for manual focusing (and verifying accurate autofocus). It’s the single most important focus feature in the camera, by far.

Focus peaking should be very helpful, but in practice I’ve found it to be inexplicably difficult to engage to begin with, and even then it doesn’t work well in many situations – e.g. it doesn’t work at all at high ISOs. While I did ultimately discover that if you switch the lens into manual focus mode, focus peaking enables persistently, it’s frustrating to basically be coerced out of AF entirely – given that when you’re not in complete manual-focus mode, getting focus peaking to show up requires holding down AF-ON (or similar), and moving the focus ring far enough to trigger peaking. It doesn’t sound like much, and maybe it’ll become more natural with practice, but right now it’s an awkward combination of actions. It’s baffling to me that focus peaking, when enabled, isn’t simply enabled – it shouldn’t require holding down extra buttons and jumping through hoops.

The 24-70/4 ‘function ring’ is definitely different for manual focus. It’s noticeably sloppy compared with the auto-clutched AF rings typical of Nikon’s DSLR lenses – meaning, primarily, that you have to turn it a noticeable amount before it engages at all (though this pick-up ‘slop’ has always varied between lenses, and the 24-70/4 isn’t necessarily worse than all prior ones). I’m also finding it difficult, so far, to get it to move the focus plane consistent amounts – presumably attributable to the ‘acceleration’ behaviour it has, whereby the speed at which you move the ring apparently affects the magnitude of focus plane movement. I do expect that I’ll get used to that in time, just as I did when acceleration was introduced to computer mice many years ago. For now though it makes manual focus adjustment a tad more difficult than I’m used to. It also remains to be seen how consistent the implementation is – if you’ve ever used a cheap computer mouse vs a high quality one, you’ll know the subtle difference in accuracy & precision.

Ergonomics

Size, weight, & balance

With a small lens (e.g. the 24-70/4 kit lens) it’s overall not too bad, though the small size – particularly of the grip – makes it noticeably less comfortable to use than a D500, D850, or D5. With a larger lens – e.g. a 70-200/2.8, it’s actually less of a problem, since the whole setup is much more front-heavy, putting the majority of the weight on your lens hand, so the smaller, dainty grip is less of a concern. Nonetheless the controls – shutter, ISO button, exposure compensation, etc – do feel very cramped, though this is odd as they don’t appear, visually, to be packed any more densely than on the D500.

Control placement

The placement of the exposure compensation button is different to Nikon’s DSLRs, and is in a pretty awkward spot – it’s now much too close to the right edge of the camera. I frequently hit the ISO button by mistake as my pointer finger searches in vain for the exposure compensation button, starting with where it used to be on all prior Nikon DSLRs. Presumably I’ll get used to this in time, but it’s a strange and seemingly unnecessary change that simply makes the exposure compensation button harder to reach.

Similarly the placement of the d-pad on the back of the camera is very awkward – it’s basically impossible to use comfortably or quickly with a normal hand-hold, requiring you to move your hand off of the grip somewhat in order to be able to reach the d-pad with your thumb, and move your face away (if you use your left eye to the viewfinder) to make room. This is a bit of a hinderance to an otherwise exciting new possibility, given the EVF, of being able to adjust lots of settings quickly without taking your eye from the viewfinder. In practice I find it quicker and safer (for the camera’s sake) to just use the rear LCD as before, as that gets my face out of the way and allows me to move my hand more freely.

Speed

One surprising thing I’ve noticed is that some of the camera’s controls are noticeably laggy. Rotating the control dial, for example, to change aperture, has a very noticeable delay before the aperture actually changes, and the display(s) update. Only a fraction of a second, to be clear. Nonetheless, on Nikon’s DSLRs going back as far as I can remember, there has always been zero perceptible delay for such basic actions as changing the aperture. While it’s not strictly speaking a significant problem, it is a constant reminder in use that the Z7 is sluggish.

In fact, one very noticeable manifestation of that “but I am le tired” feeling the camera conveys is when you put your eye to the viewfinder – if the camera has been idle for long enough (tens of seconds, I think), it takes a couple of seconds for the viewfinder to turn on. I’ve already had several awkward moments where I’ve had people posed in front of me, brought the camera up to my eye, and then had to pause for an uncomfortably long time while I wait for the viewfinder to turn on. It’s not just me that notices this – my subjects notice the delay too, and find it a bit unsettling – like I’m staring at them motionless for an uncomfortable amount of time. I’m presuming this is some overly-aggressive power saving feature, which I wish I could just turn off. (FYI I have the camera configured to viewfinder priority mode, since that’s the only one that makes any sense to me, but I haven’t explored if other modes alleviate this problem).

Info & Display buttons

I basically never used these two buttons any other Nikon DSLR – maybe occasionally in video mode to toggle the display of various things, but otherwise I just had no apparent need, or had better ways to get at the same functionality.

The Display button doesn’t really change from Nikon’s DSLRs – as before it toggles through various display ‘HUD’ modes. As always, I wish I could more precisely configure what’s shown – certain information is only shown in certain modes that otherwise contain heaps of crap I couldn’t care less about, so being able to cherry-pick the exact ‘widgets’ I want to show would be ideal, and eliminate the need for a mode-switching button entirely.

The Info button and associated functionality is something I find myself naturally using on the Z7. It’s unfortunately awkward to use via the touchscreen, as inexplicably you must double-tap everything to get settings to actually apply, which I consistently forget because it’s so unintuitive. Using the d-pad & ok button is much safer, and so I do that, which is fine most of the time.

Being able to configure the contents of the Info panel is of course what makes it much more useful than before. And though the number of items you can place there simultaneously is fixed, and seemingly not many – twelve – I actually find myself searching for useful things to fill the last couple of spots. So thus far I’m pretty happy with it – I don’t mind using it as opposed to dedicated physical buttons, for the most part, though for now I did still find myself occasionally reaching for the AF mode and bracketing physical buttons, that no longer exist.

I also am having a surprisingly hard time remembering that there’s still a release mode physical button, albeit in an awkward location now – I keep going through the Info panel instead, which isn’t really a problem but makes me feel a little silly sometimes.

Image stabilisation

It’s still early for me on image quality – I have a lot of photos taken with the Z7 I haven’t even gone through yet – so I’m not certain how good or bad the in-body image stabilisation is. My impression from chimping is that it’s not all that great, based on significant numbers of camera-motion-blurred photos, but I’m also quite self-aware that I’m coming from (primarily) a 21 MP D500, to this 46 MP Z7, so it’s an intrinsically much more demanding sensor re. motion blur. And the lightness of the Z7 probably isn’t doing it any favours here, either.

Certainly I think it’s fair to say it helps with previously unstabilised lenses, like the Sigma 50/1.4 Art. More testing is needed, though, especially to estimate the degree to which it helps.

One of my pet peeves about the D500 is that it has huge mirror shock. Certain shutter speed ranges – typically ~1/50 to 1/160 – with some lenses are utterly unusable on the D500. I’m optimistic that the Z7 will not suffer from such issues, given its ability to utilise a purely electronic (i.e. no moving parts) mode. I’ve not yet put it through its paces in those specific scenarios, though (e.g. macro photography with the Sigma 105/2.8 is the worst such case with the D500, that I’ve encountered). I know from past experience with mirrorless cameras (e.g. a7r II, GH4) that these shutter speeds don’t have to be verboten.

Image stabilisation in video mode does seem noticeably better than on the D500 (with a VR lens). I haven’t explored it much yet, though.

Image review

One thing I noticed very quickly upon picking up the Z7 is that it has an ugly flickering problem when panning photos in review mode. It’s at its worst when using the d-pad for panning, but also shows up a little bit when using the touch screen to pan too. It’s very distracting, and I don’t understand why it would be doing that, nor how this is considered acceptable by Nikon. I’m hoping it’s some very stupid but fixable bug that can be addressed in a firmware update. No other Nikon camera I’ve ever used had this issue, or anything like it.

Otherwise though it’s just as on any prior Nikon DSLR – scrolling between images is plenty fast, zooming is instantaneous, the touch screen works nicely including pinch-to-zoom & double-tap-to-zoom, etc. It’s a genuine compliment to say that image review continues to work – flickering notwithstanding – as on Nikon’s prior cameras.

Silent mode

I’m a big fan of silent mode. It unfortunately doesn’t always work – under some artificial lights – certainly fluorescents – it’s useless as it results in pronounced, ugly banding. But under better lighting (e.g. LED), or natural light, it has no such issues. The ability to take photos silently is really handy in a lot of situations, and I use silent mode by default even when silence isn’t strictly necessary (in part also motivated by a desire to eliminate sources of motion blur).

I do wish that the camera’s flicker detection feature could be enhanced to provide a warning to you when you’re in silent mode and it suspects banding will occur – a few times I started taking photos only to find out some time later, when I finally checked them on the LCD, that they were ruined by banding. Since it’s not always obvious when it will occur – nor does it necessarily occur consistently – it’s currently something you have to be careful about, currently.

Wifi

The Z7 claims to have a new ability to stream photos as they’re taken to a computer. That would be really handy sometimes. Unfortunately, the Wireless Transmitter Utility software that you need on your Mac, in order to do this, doesn’t work. The installer doesn’t work, more specifically. After clicking through the first few screens, it abruptly says it’s installed, but it isn’t – nothing has been installed.

My guess is that it’s incompatible with the current version of macOS, Mojave. Officially they don’t claim WTU is Mojave-compatible. Mojave has been out in various forms, including public let-alone developer betas – for most of this year already, so there’s zero excuse for Nikon’s software being incompatible at this point – if indeed that is the issue.

Memory card

I do like the XQD format in general – the cards are fast, robust, & reliable. Unfortunately right now they’re also the most expensive they’ve basically ever been, despite greater market demand than ever, more manufacturers than ever, the lowest commodity NAND prices in years, and broadening adoption across multiple camera brands. And since Nikon didn’t see fit to include an XQD card with U.S. orders – unlike their actions everywhere else on the planet – I find myself with just one XQD card for now, purchased way back when they weren’t so insanely expensive. And that’s a problem for a camera that can operation at 8 FPS with ~60 MB files. For the first time in pretty much ever, for me, this week I found myself abruptly unable to take any photos because I had no space left on any available memory card (nor any way to get the photos off wirelessly, thanks to SnapBridge’s refusal to transfer raws, and WTU’s inoperability as commented on above).

So that’s unpleasant. It appears for the foreseeable future I’m going to have to live with this problem, and do my best to mitigate it – at least until XQD card prices come down dramatically, to something more sensible. While I don’t really care about the lack of a second slot, the lack of an SD slot is a big problem given where the XQD market is right now.

Also, for the Sony fans that think the a7r III is superior specifically because it has two memory card slots – no, it doesn’t. Only one of those slots supports UHS-II. The other slot is basically useless, given how slow UHS-I is. I have absolutely no use cases where I could reasonably make use of a UHS-I slot, in a 46 MP camera. The Z7’s XQD slot is capable of much higher speeds than UHS-II. Alas only for a king’s ransom, currently.

24-70/4

Nikon (and many reviewers) made kind of a big deal about how small they believe this lens is. It’s a fairly small lens I suppose, though not remotely as tiny as the 18-55s you get with Nikon’s DX DSLRs, despite having a similar focal length & aperture range. It’s not that much smaller, volume-wise, than the 16-80/2.8-4, despite the latter’s much wider focal length range and wider aperture (albeit without full-frame coverage, of course). Maybe that’s an unfair comparison – certainly I’m more familiar with DX lenses in this focal range, than FX ones. I don’t know how it compares with 24-105/4 or 24-120/4 kit lenses of yesteryear.

Regardless, I’m not impressed by its size at all. Not that I think it’s too big – I’d actually much prefer it be bigger and have a better focal length range (e.g. 24-120), or a bigger aperture (e.g. f/2.8). I’m interested to see the Z-mount 24-70/2.8 next year.

I can’t comment on its optical quality yet – I haven’t reviewed enough photos. Certainly it’s a big net win over my D500 with pretty much any lens, in terms of sharpness, though the massive sensor resolution difference is presumably the biggest factor in that.

Its weather sealing seems pretty poor – I seem to recall Nikon asserting that it has pretty good weather sealing, yet within seconds of its first use, cat hair was getting inside it through the telescoping barrel. I definitely would not use this lens in a wet, dusty, or hairy environment if I could avoid it.

One small but odd note – the lens hood is surprisingly difficult to attach, whether in use or in inverted stowage mode. The last bit of rotation – to get it to ‘click’ on securely – requires a surprising amount of force, so much so that I’m really worried I’m going to wrench the lens in half. I’ve had a few lenses in the past where this operation required a bit more force than I’d like, but none nearly so bad as this one. It makes me wonder if I’ve got a dud copy of the lens hood, or somesuch.

(it also made me, upon first attempt, spin the hood around about five times look for the latch release button that it must surely have had, given the resistance – kind of like rotating a USB type A plug six times to permute it through the four-dimensional space it exists in, in order to get it to plug in successfully in our three-dimensional space)

Overall opinion so far

I’m not returning the Z7 yet. I actually don’t expect that I will – despite its many shortcomings, I think it’ll still work well for some of my intended uses. I’m definitely not selling my D500 any time soon, though.

I guess the simplest expression of my feelings is to say that: I’m not angry with you Nikon – I’m just disappointed.

The Z7 should have been a tour de force entrance into mirrorless for Nikon, leveraging their class-leading DSLRs to launch an unbeatable mirrorless camera. They seemed to have all the advantages & resources they needed. That they’ve fallen short of that, and produced merely a decent mirrorless camera, is hugely disappointing.

I didn’t even cover some the features that are missing entirely – e.g. sensor shift image stacking.

I’d like to hold onto hope that Nikon will fix a lot of these issues, and add the more glaring missing features, in a future firmware update. They technically could, at least in some cases. However, that would be a dramatic departure from their modus operandi to date. A hugely positive one, for sure – but just as they seem to have not quite known what they were doing in designing the Z7, I fear they also don’t really know what they’re doing with their firmware strategy.

FWIW, here’s my bug fix / feature enhancement list, roughly in descending order of importance:

Fix the AF system so it actually works.
Fix the AF interface to not be so hard to use.
Fix video focus so that it works well, and doesn’t imitate a mediocre contrast-based system.
Fix the unusually long delay in the viewfinder turning on.
Fix focus peaking so that it’s actually enabled when it’s enabled.
Support clipping warnings (zebra stripes) in photo mode.
Fix the flickering in picture review during panning.
Warn about banding in silent mode shooting under flickering lights.
Reconsider control placement, and the general size of the grip re. its current diminutive stature.
Fix the control lag.
Fix SnapBridge to support NEFs.
Make the Wireless Transmitter Utility actually work.
Customisable Display modes.

These are of course just limited to basically fixing the obvious shortcomings & bugs the Z7 currently has – it’s a much longer list if we incorporate ‘wishlist’ items like leading-edge video capabilities (8-bit H.264 video, in 2018? Come on…).

Lightroom “Classic” doesn’t play well with others

Sat, 21 Oct 2017 16:16:57 +0000

So far the new “Classic” Lightroom looks & feels mostly identical to the prior version(s), which isn’t really a compliment, but could be worse. There’s no apparent performance improvements, that’s for sure, so as expected Adobe’s promises to suddenly learn how to write efficient & performant software, well… at least their marketing department gave it the college try.

One thing I have very quickly discovered, however, is that Lightroom “Classic” deliberately chooses not to perform some functions if it is le tired. Or it thinks your computer is le tired. By which I mean, if there is pretty much anything else running and consuming CPU time (and/or RAM?), it refuses to even attempt some operations. HDR merges is the first one I hit. I was a bit flummoxed by it just happily queuing up a number of HDR merge operations, and them just sitting there in its queue, with no indication of error – just never executing.

Only after I quit or disabled a bunch of other processes – any and all that were using any measurable CPU time – did it finally, about ten seconds later, decide that it was now willing to consider my ‘requests’.

#%@!ing fussy little turd.

It’s worth noting that it’s not the only popular app, on macOS, that does this same bullshit. Time Machine is another big one. At least in Time Machine’s case I can see a more plausible line of reasoning behind it, even if it is misguided – the user’s probably not explicitly waiting for a Time Machine backup to complete. As in, not all the time. Sometimes they are. And they certainly expect backups to happen at all, which on a consistently busy machine simply doesn’t happen. So Time Machine’s reluctance to function on a working machine is still stupid overall. But Lightroom refusing to complete a user initiated, user-interactive, and user-blocking operation, is just patently stupid by its very notion.

Update: Worse, now it doesn’t work at all. And a quick web search shows many other people having the same problem, and Adobe as usual doing nothing about it.

Incidentally, I tried to log in to Adobe’s forums in order to ‘Me too’ those issues, only it won’t let me log in anymore, falsely claiming my password is invalid. Good job, Adobe, good job.

Your system has run out of application memory HUR HUR HUR

Tue, 16 May 2017 17:22:47 +0000

I hate this dialog with the fire of a thousand suns.

When this appears, it basically means one (or both) of two things:

Some application went nuts and chewed through all your memory and/or disk space.
macOS got itself into a darkly comical & embarrassing deadlock.

Quitting any of the listed applications is rarely the correct move. It’s often enough the case that none of them are the root cause, and you can kill all of them if you want, but it won’t fix the problem.

One important thing to clarify first, though, is that this dialog does not necessarily use the term ‘memory’ in the conventional sense – i.e. RAM. It can also refer to disk space. Unfortunately it doesn’t bother to distinguish between the two, which is particularly stupid of it since any possible resolution of the issue is highly dependent on which of the two cases it in fact is.

Thank goodness for iStatMenus, though, which in the most recent incident showed that I had ~20 GiB of RAM completely free (not even inactive, actually outright free). So immediately that rules out what the daft bloody dialog’s actually saying.

The worst thing about all this is when it’s #2 the occurs. For example, I had Lightroom do a 63-image panorama merge. As Lightroom is a gross memory pig when doing panorama merging, it consumed something like 40 GiB of memory. Which caused a bunch of stuff to page to disk. Which consumed all the disk space. Which led to that obnoxious dialog. Which further led to macOS in its infinite fucking wisdom ‘pausing’ (SIGSTOPing) almost all running programs, including evidently whatever daemon actually handles paging. Thus when Lightroom actually completed the panorama merge and released all that memory, I now had 20 GiB of free memory and the system refused to use any of it to page back in all that memory it’d paged out. Because it was out of disk space.

The only solution – short of hard rebooting and hoping it resolves itself – was to delete a bunch of files I actually do still want, but which will now have to be recovered from a backup. Great job macOS, thanks for all your help.

Of course, even once you do that and recover the system from the derpeche mode it put itself into, it won’t actually unpause any of the shit it broke. You have to do that manually. It pretends you can do that via that dialog that started the whole thing – assuming you left it open the entire time, blocking your view as you actually help the situation – but that only shows user-visible applications, not all the other system & background processes that it also rudely halted.

So, simple tip for resuming everything:

sudo killall -CONT -m '.'

Elegant, after a fashion. Though every time, it reminds me that whomever named it ‘killall’ was either not very friendly or not very wise.

Note that the system will probably still be a bit broken in places, as despite what macOS thinks, you can’t just blindly pause random system tasks and not have things get really, really confused. A reboot is always wise after seeing this dialog, to properly undo its fuckery.

iOS Family Sharing users cannot mix authentication schemes

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

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

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

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

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

Versus what you see with “two-step”:

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

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

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

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

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

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

#if DEBUG in Swift

Sat, 14 Jan 2017 21:15:33 +0000

Sigh.

The Swift team give an impeccable impression of a group of people who’ve never actually tried to use Swift.

An incredibly basic compiler task is to provide code a way to distinguish between debug & release builds, in order that it can behave accordingly (e.g. change the default logging verbosity, change asserts from fatal to non-fatal, etc).

Long story short there is no way to do this that works correctly with swift build.

You can make it work with Xcode only by way of a simple workaround – you manually define a custom Swift flag in your target’s settings (here’s one of a bajillion explanations of how do this). You end up with basically identical code to other C-family languages, e.g.:

#if DEBUG
    let logVerbosity = 1
#else
    let logVerbosity = 0
#endif

But there is no way, when using swift build, to specify custom Swift flags in your package config.

You can specify them manually with every single swift build invocation, e.g.:

swift build -c debug -Xswiftc '-DDEBUG'

But now you have extra work and the possibility of screwing it up (e.g. omitting the flag, or mismatching it to your actual build style).

The closest you can get is to use some undocumented, hidden Swift internal library functions:

func _isDebugAssertConfiguration() -> Bool
func _isFastAssertConfiguration() -> Bool

These are defined in swift/stdlib/public/core/AssertCommon.swift.

Only the first is likely to be useful. The second applies in the case where you’re building not just for release but unchecked (-Ounchecked). If you just want to conditionalise on release builds generally, you have to do !_isDebugAssertConfiguration().

The additional problem with this approach is that these are then, in your code, runtime checks. And the compiler then thinks it’s being helpful by pointing out that some of your code that uses them is unreachable.

And of course Swift has absolutely no way to silence compiler warnings, or otherwise tell the compiler not to trust its reachability checks.

Sigh.

Update (February 2018)

While the above method – using the _isDebugAssertConfiguration() method – does still work at time of writing, in Swift 4.1, there are some marginally better ways now available. There’s still not a proper solution, infuriatingly, but with some creativity, as you’ll see momentarily, you can get pretty close to expected functionality.

First alternative

This will only suit some cases, but its relative cleanliness & simplicity makes it appealing when it is an option.

You can use #if targetEnvironment(simulator). This of course only distinguishes between the simulator and a real iDevice environment, though that can often be useful too, perhaps orthogonally to DEBUG vs RELEASE concepts.

Second alternative

Wrap all uses of _isDebugAssertConfiguration() inside a minimal set of functions. All this gets you is a reduced (and fixed) number of unreachable code warnings, though.

For example:

func inDebugBuilds(_ code: () -> Void) {
    if _isDebugAssertConfiguration() {
        code()
    }
}

func inReleaseBuilds(_ code: () -> Void) {
    if !_isDebugAssertConfiguration() {
        code()
    }
}

You can then use these in a fairly streamlined way:

inDebugBuilds {
    print("Hello, I only greet in debug builds!")
}

inReleaseBuilds {
    print("While I only greet in release builds - aloha!")
}

Third alternative

It’s possible to do one better than the above, and eliminate those unreachable code warnings entirely. Plus, doing so actually removes any use of unofficial APIs… but it requires abusing the official API a bit.

The built-in assert() method is implemented atop _isDebugAssertConfiguration() just the same as inDebugBuilds() is, above. However, because it’s part of the Swift standard library, you don’t have to be concerned about its implementation, its use of private / undocumented language, compiler, or library features – that’s up to the Swift compiler team. Most importantly, use of it in your code doesn’t emit an unreachable code warning.

So we can do something like:

func inDebugBuilds(_ code: () -> Void) {
    assert({ code(); return true }())
}

Ugly and obtuse, but functional and reasonably expected to work in all future versions of Swift.

You can similarly create a variant for release-build-only code, though it’s even hackier:

func inReleaseBuilds(_ code: () -> Void) {
    var skip: Bool = false
    assert({ skip = true; return true }())

    if !skip {
        code()
    }
}

Icky, but it works. On the upside, you only have to define this ugliness in one place in your module, and then you can try to forget about its implementation. 😝

One caveat is that I don’t know if the above approach will properly strip out the unreachable code from your built binaries.

Another caveat with these is that since you’re invoking a function, you can’t do a natural if … else … pattern – instead you need explicit, distinct inDebugBuilds & inReleaseBuilds blocks. So it can’t be completely like the vanilla #if DEBUG … #else … that C-family languages have had since before the dinosaurs. You could create versions that take two closures as parameters – one for the affirmative case, one for the other… the trade-off is that your invocations are then a little more verbose and obviously function-cally, e.g.:

func forBuildStyle(debug debugCode: () -> Void,
                    release releaseCode: () -> Void) {
    var debugBuild: Bool = false
    assert({ debugBuild = true; return true }())

    if debugBuild {
        debugCode()
    } else {
        releaseCode()
    }
}

forBuildStyle(
    debug: {
        print("I'm built for debuggin'!")
    },
    release: {
        print("I'm built for the wild!")
    }
)

Up to your personal preferences as to which API you adopt, and which implementation you choose (streamlined but private-Swift-bits-dependent with bonus unnecessary compiler warnings, or official-APIs-only but hacky).

Broken by design – Wade Tregaskis

Backblaze seemingly does not support files greater than 1 TB

Update

Addendum

NSCopyObject, the griefer that keeps on griefing

What NSCopyObject does

But I don’t use NSCopyObject…?

So how do I defend against NSCopyObject?

Objective-C

Swift

Do as Apple says, not as Apple does

Tangent: NSCopying considered harmful

Copying whole folders in an Xcode Copy Files Build Phase

Proactive Peek & Reveal on Edge Hover

SwiftUI drag & drop does not support file promises

Is that it?

Best alternative (other than ditching SwiftUI)

Understanding the SwiftUI drag & drop APIs

Bad API example: FileManager’s url(for:in:appropriateFor:create:)

Creating files safely in Mac apps

What is the danger?

How are these dangers mitigated?

App Sandboxing helps

Avoid /private/tmp (a.k.a. /tmp)

Consider setting a restrictive umask

Correctly use the right file creation APIs

⚠️ open

⚠️ fopen

❌ OutputStream(toFileAtPath:append:) & friends

⚠️ NSData.write(toFile:options:) & friends

❌ NSString.write(toFile:atomically:encoding:) & friends

Use randomised names for transient files

⚠️ mktemp

✅ mkstemp / mkdtemp & friends

⚠️ FileManager.default.url(for:in:appropriateFor:create:)

Appendix: File system races in more detail

Appendix: File writing APIs that cannot create new files

FileHandle(forWritingAtPath:)

NSData(contentsOfFile:options:) & friends

NSImage is dangerous

NSImage 101

Accessing / using an NSImage

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

What can you do?

Reminder: macOS system frameworks binaries are hidden (since Big Sur)

Mac app sandboxing interferes with drag & drop

Noticing when drag & drop operations start

Drag & drop implementation detail

Pasteboard implementation detail

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

You get only one look at the dragged files

Failed workarounds

Partial workaround

Addendum: Michael Tsai’s Blog

SwiftData pitfalls

Background

Example use case

Design flaws

Auto-save doesn’t work

Workarounds

Arrays of @Model objects are randomly shuffled

Workarounds

let cannot be used for bidirectional relationships

Workarounds

Relationships are secretly implicitly unwrapped by default

Workarounds

You cannot directly initialise bidirectional relationship properties

Workarounds

Relationship constraints are only enforced at save time

Workarounds

Singletons are unsupported

Workarounds

You cannot create model objects outside of SwiftData contexts

Workarounds

Apple’s documentation is wrong

Workarounds

Non-pitfalls

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

Bonus: TablePlus recommendation

Apple Watch Ultra is a poor dive computer

What `NSCopyObject` does

But I don’t use `NSCopyObject`…?

So how do I defend against `NSCopyObject`?

`⚠️` `open`

⚠️ `fopen`

❌ `OutputStream(toFileAtPath:append:)` & friends

⚠️ `NSData.write(toFile:options:)` & friends

❌ `NSString.write(toFile:atomically:encoding:)` & friends

⚠️ `mktemp`

✅ `mkstemp` / `mkdtemp` & friends

`⚠️` `FileManager.default.url(for:in:appropriateFor:create:)`

`FileHandle(forWritingAtPath:)`

`NSData(contentsOfFile:options:)` & friends

Arrays of `@Model` objects are randomly shuffled

`let` cannot be used for bidirectional relationships