Thanks again for the reply, and especially for such a thorough and helpful one! For example, I suspect this doesn't happen if you start with a security-scoped bookmark, which you resolve to a bookmark before each save. Out of curiosity I just tested this, and I still see the bug. To see it yourself, just use the code from my first post but change the savingURL accessor to use a security-scoped bookmark, as follows: private var bookmarkData: Data? // Ask user to choose this via a save panel. var savingURL: URL? { get { var isStale = false if let bookmarkData, let url = try? URL(resolvingBookmarkData: bookmarkData, options: .withSecurityScope, relativeTo: nil, bookmarkDataIsStale: &isStale) { if isStale { // Should really update the bookmark data here... } return url } else { return nil } } set(newURL) { bookmarkData = try? newURL?.bookmarkData(options: .withSecurityScope) setUpSpamSave() } } Then add the following to the top of spamSave() after checking savingURL is non-nil: let didAccess = savingURL.startAccessingSecurityScopedResource() if didAccess == false { print("Failed to start accessing scoped URL.") } defer { if didAccess { savingURL.stopAccessingSecurityScopedResource() } } The save will fail with the same permissions error every now and then. Just to clarify, are you: a) Copying the file once, modifying it over time, then copying that file back for each save. b) Copying the file prior to each save operation. I suspect you're doing "a" (and it's probably what I would do), but if you're doing "b”, then that changes things a bit. I’m actually doing (b), since this is very fast on copy-on-write volumes such as APFS even for large files. (Copy-to-temp file is almost instant; updating the zip file is super-fast too thanks to LibZip’s support for copy-on-write, meaning it doesn’t recreate the entire zip file; then it's just a matter of moving the updated file back into place using replaceItemAt(_:withItemAt:.) For slower volumes, much like Pages.app, we offer a second, package-based version of our file format which supports in-place saving. (Zip-based is the default since it works everywhere and package-based files don’t work with cloud-based services other than iCloud Drive on iOS. But if saves get particularly slow, we prompt users to consider the package-based option.) As I mentioned, I keep a snapshot of the zip file from the previous save around (for cases where the user has accidentally deleted the underlying file between saves), and I have done some testing and I can indeed re-save successfully using that. That is slow, though, since it has to recreate the entire archive. On APFS it’s faster to make a backup copy of the temp file before using replaceItemAt and then to try with the copy if it fails - that seems to work well. Based on your suggestions, though, I’m going to do a bit of refactoring. Keeping the zip file around in the temp folder and making copies from it for replaceItemAt sounds like a great solution with multiple advantages, and since my custom file wrapper already keeps a reference to the previous snapshot, it wouldn’t be difficult to have it keep a reference to a temp file URL too. Your app copies from the destination to your local storage…. Your app pushes that initial save data to the final target. This is a little off-topic, but in this case - where you are doing the intensive work on your local storage and then pushing back to the slower volume when done - what is the safest way of replacing the original file? The point of FileManager.url(for: . itemReplacementDirectory…) is to return a temp folder on the same volume as the passed-in URL, since replaceItemAt(_:withItemAt:) won’t work if the original and new URLs are on different volumes. The only other way I can think of risks data loss: Delete the original file from the destination. Move the updated file from the local storage to the destination. We could make a temp copy of the original file before (1), but if the volume is slow, that adds back in some of the slowness we’re avoiding by doing work on another volume. My own instincts would be to redo the entire save, but if you want to do this, I would do two things: I’m going to focus on retrying the save. I’m curious though as to whether the bug could occur twice in immediate succession, so that the resave also triggers the error. Although I can’t get this to happen in testing, given that the error seems random, I wonder if it is possible if I ran the test for long enough - a day, say. In that case, I wonder if this approach would work: Save - encounter some sort of save error. Retry the save no matter what the error was. If we get another error, examine the error and if it was caused by the bug, just try deleting the temp file and move on. I’ve attached some code at the end of this post that scrutinises the error to check it matches the one triggered by this bug. (Although I wonder if I should use .fileContentIdentifier instead of .fileResourceIdentifier.) Anyway, thanks again, as I’m very close to a solution now.

Just to add that I have now filed the bug as #FB22107069.

Many thanks for the reply and information, Kevin, much appreciated. Have you filed a bug on this and, if so, what's the bug number? As part of that bug, I'd suggest installing the "iCloud Drive" profile, reproducing the issue a few times, then uploading a sysdiagnose of the failure. See the profile installation instructions for the full details of that process. I hadn’t filed a bug report yet because I had assumed it was something I was doing wrong given that using replaceItem and a temporary folder is presumably a common pattern. I’ll file a report tomorrow - I’m following the iCloud Drive profile instructions you linked to and am now waiting the 24 hours they say I need to wait before I can get the sysdiagnose. Once I have that I’ll file the report along with a sample project. Have you tried retrying the save? That appears to work in my testing, though it may not be a workable solution in your case. Beyond that, I'd need a better understanding of exactly how you're interacting with the files and what your full requirements are. With a bit of refactoring I probably could retry the save. In my app this is all done inside my NSDocument’s writeToURL method. I use my own drop-in replacement for FileWrapper (you helped me with some of the finer points of FileWrapper a few years ago) that incrementally writes changes to a zip file using Libzip, which supports incremental saves on copy-on-write systems such as APFS. A potential problem with the re-save approach is that my save usually works by copying the zip file at the original location to a temporary location, updating it there, and then moving it into place using replaceItemAt. After this particular replaceItemAt error, however, the original file has in fact been updated despite the error (the error being on the old version of the file which is now in the temporary directory). So if I re-save by making a copy of that and try updating again, I could potentially mess up the file by trying to save into it stuff that has actually already been done. (However, I do keep a snapshot of the older archive around in case of problems, so I might be able to work around this problem using that.) I wonder, though - given that the original file has in fact been replaced by the temp file despite the error, can I not just check for this and ignore the error if the file seems to have been replaced after all? E.g.: Before replacement, record the file resource ID of the temp file. Use replaceItemAt(originalURL, withItemAt: tempURL). If there’s an error, get the file resource ID for the file at the intended saving location and compare it against the ID I recorded in (1). If they are the same, I know the replacement has succeeded despite the error. In this case, I can just try to delete the temporary folder and move on. If the file IDs of the current user file and the temp file from before replace don’t match or couldn’t be got, attempt a re-save. Is there something wrong with this approach? (I’ve attached some sample code below demonstrating how this might work.) Many thanks, Keith // Get a temporary folder appropriate for creating the new file in. let replacementDirURL = try fileManager.url(for: .itemReplacementDirectory, in: .userDomainMask, appropriateFor: savingURL, create: true) // Create the new file at the temporary location. let tempURL = replacementDirURL.appendingPathComponent(savingURL.lastPathComponent) try createNewContentAt(url: tempURL) // Record the file resource ID of the temp file we created. let tempFileID = (try? tempURL.resourceValues(forKeys: [.fileResourceIdentifierKey]))?.fileResourceIdentifier // Now try to move the file into place. do { // Use replaceItemAt to safely replace the original file with the updated file we created at the temp location. _ = try fileManager.replaceItemAt(savingURL, withItemAt: tempURL) // Clean up. try? fileManager.removeItem(at: replacementDirURL) } catch { // Check to see if the original file was in fact replaced despite the error. if let tempFileID, let savingFileID = (try? savingURL.resourceValues(forKeys: [.fileResourceIdentifierKey]))?.fileResourceIdentifier, tempFileID.isEqual(savingFileID) { // If so, just try to remove the temp dir and move on. try? fileManager.removeItem(at: replacementDirURL) } else { // If we got here, replace really did fail and we need to handle it. // We should do some more work and try to resave here before throwing an error. throw error } }

An update on this weird behaviour: I have discovered that when replaceItem fails in this circumstance, the temp file has in fact been moved into place correctly and has replaced the original file. But when I get the error, the old original file has taken the place of the old temp file and it's that which cannot be removed. I have tested this by checking both the content and the fileResourceIdentifier of the original file and the temp file, and logging them before and after the error. After the error they are swapped.

[Deleted - sorry, I missed the comment from the DTS engineer on my earlier post, so what I posted here was irrelevant, but there doesn't seem to be a way to delete the post. Glad the op got their issue sorted.]

This may well be related to a bug I'm also seeing in iOS 26. In beta 4, many controls were messed up in dark mode, so that they didn't adapt to a dark appearance at all, including UIBarButtonItems with a customView. There have been some improvements in beta 5, but some controls now have a disabled appearance in dark mode when they are in fact enabled. UIBarButtonItems with a customView are one of the controls affected. I'm seeing this in my own app, and I can easily reproduce this with a UIBarButtonItem that uses a UISegmentedControl as its customView. Here it is in light mode: (Only the link button should be disabled, so all is as expected in light mode.) And in dark mode (or in light mode but against a dark background): As you can see, the segmented control now looks disabled when it isn't. And this is set up using the segmented control directly as the custom view (i.e. UIBarButtonItem(customView: segmentedControl)). I've reported this as FB19431646. The issue may be more general, as nav bar titles in sidebars and inspectors also appear pale grey and disabled (FB19431807). Original report for dark mode issues in beta 4: FB19023069.

You should generally add the constraints in your view controller code, where you have access to both views., right after calling addSubview(:). Or if you really want the code in your image view for some reason you could create a method on your image view that takes the view as a parameter (e.g. addToView( view: uIView)) and call that from the view controller.

These lines are your problem: self.centerXAnchor.constraint(equalTo: self.centerXAnchor).isActive = true self.topAnchor.constraint(equalTo: self.centerYAnchor).isActive = true You‘re setting self.centerXAnchor to equal itself, which will do nothing, and self.topAnchor to equal self.centerYAnchor, which is impossible. Instead, you want to set self.centerXAnchor to equal the superview’s centerXAnchor and the same for the Y anchor. (In your case the superview will be the view controller’s view.) For a specific position rather than centred, you’ll want to use constraints lining the image view up with the leading/top/trailing/bottom edges of the superview with a constant depending on your needs.

I've also filed a bug report on this just now (#FB19023069). I was trying to work out why a UILabel set as the subview of a glass UIVisualEffectView's content view wasn't adapting to dark mode (not in a Split View), when I realised it wasn't alone. Here's a screenshot of the sample app I sent to Apple: Light mode: So far, I've noticed the following controls are affected: Primary and inspector nav bar titles in a Split View (but not the secondary title). The toggle sidebar button (but not always). Bar button items in the nav bar with isEnabled set to false. Bar button items containing custom views (at least containing a segmented control, such as in my screenshot). Labels inside a UIVisualEffectView using the glass effect. No doubt there's more. Even setting segmentedControl.overrideUserInterfaceStyle = .dark on the segmented control in the custom nav bar item didn't help. It is very strange that Apple's own apps aren't affected.

It's strongly implied in the video "Build an AppKit app with the new design": The scroll edge effect is applied automatically underneath toolbar items, title bar accessories, and… split item accessories. I've filed feedback asking for a property to control it programmatically too though. At the moment the automatic detection isn't reliable - there are easily reproducible cases where you get blurring at the top of a scroll view ("soft" effect) when it should be a hard effect (I've filed a couple of bug reports on this). Of course macOS 26 is still in early beta so fingers crossed these bugs will be fixed, but it would be good to have some manual control in case there are edge cases that automatic detection still misses - especially since there are properties for this in both SwiftUI and UIKit, with only AppKit lacking.

I tried reproducing this but couldn’t. Having seen the error myself, I could reproduce it as follows: Paste the three structs from the op's original post into a Swift file in a new app project. Change "Decodable" for each to "Codable" (I couldn't reproduce it for "Decodable" only for some reason). Make sure that strict concurrency checking is set to "Complete" and "MainActor" is set as the default actor isolation for the project. When I do this, I see a "Circular reference" error with several "Through reference here" comments that don't make much sense. There seem to be two possible fixes depending on how the struct is intended to be used: Explicitly set the struct as "nonisolated" (which prior to the change in default actor isolation would have been the default): nonisolated struct FriendListResponse: Codable Force the conformance to @MainActor: struct FriendListResponse: @MainActor Codable (Note that the second solution will break if you use custom codingKeys, however, even if you try to force the conformance on that to @MainActor - not sure why.) I hasten to add that my knowledge of Swift 6 and concurrency is wanting - I'm only starting to explore migration from Swift 5 to Swift 6 and understanding the errors involved, so apologies to the op if this is unhelpful.

This bug has been around for a long time. I first reported it to Apple back in 2016 (radar ID 25220931; updated #FB6001878 last year). In my app, I make it so that you can have a large gap below the text you are writing, so that the text is not always at the bottom of the editor (like in Xcode). I was initially using a large bottom textContainerInset to achieve this, but this triggered the selection scrolling bug you describe. My workaround is to leave the bottom textContainerInset alone and to instead increase the contentSize height in a UITextView subclass. (I add the extra height whenever the contentSize is set in the subclass override.) This really only works for adding space below, though. To add space above, as you want, you'd need to mess with contentInset, but doing so causes the same selection scrolling problem as adjusting the textContainerInset so unfortunately gets you nowhere. In your situation I think the only solution is to push the entire top of the text view down to make space for the comment, even though that might not be ideal, as presumably you wanted the text view visible and scrollable beneath the comment.

Overriding NSTextLayoutFragment.draw(at:in:) in an NSTextLayoutFragment subclass provided by the NSTextLayoutManagerDelegate is indeed the designated way of doing custom drawing now. However, note that it still doesn't have quite the same effect as NSLayoutManager.drawBackground(forGlyphRange:at:). While you can draw behind the text by doing your custom drawing before calling super.draw(at: point, in: context), all custom drawing in NSTextLayoutFragment is still done above text text view's selection (in NSTextView anyway). In NSLayoutManager, drawing done in drawBackground(forGlyphRange:at:) was done beneath the text selection, which could be useful for some elements. There seems to be no way of doing the same in TextKit 2 just yet. (I filed this as #FB10159592 but received a fairly standard dismissive reply). You can also do custom drawing in NSTextView's drawBackround(in:), but that's more awkward because calculating the visible ranges is expensive. For custom interaction, I suppose it depends on what you're trying to do. You could do it in a text view subclass and use NSTextLayoutManager's various methods to get the frames of the text you need. For instance, I allow live image resizing in an NSTextView, and draw resizing handles over image text attachments. For that I can use NSTextLayoutManager's layoutFragment(for: point) in mouseDown(_:), converting the point from text view to text container coordinates, and I can then get the image frame using NSTextLayoutFragment.frameForTextAttachment(at:), and add a new sublayer to the text view to draw my resizing handles. There are a couple of gotchas here, though: Because NSTextView (and presumably UITextView) in TextKit 2 does all of its drawing using layers, you have to set the z position of any new sublayer you add to something high (e.g.FLT_MAX). The coordinate system used for TextKit 2 is so far undocumented, and seems pretty strange. NSTextLayoutFragment.layoutFragmentFrame is straightforward, being in text container coordinates, and NSTextLayoutFragment.renderingSurfaceBounds is relative to that (although the docs say its coordinates are flipped compared to layoutFragmentFrame, when they don't seem to be). However, both NSLayoutFragment.frameForTextAttachment(at:) and NSTextLineFragment.typographicBounds seem to be relative to NSTextLayoutFragment.layoutFragmentFrame vertically, but relative to the text container horizontally. (And there are also some issues with the frames being narrower than you'd expect when using overlay scroll bars.) I'm not sure how helpful that is to what you want to do.

It is a little strange that UITextView doesn't have a convenience property for this. However, you can still access it easily enough via the textLayoutManager's .textContentManager property (NSTextContentStorage being the concrete subclass of NSTextContentManager used by NS/UITextView). And of course you could create an extension to UITextView to add the .textContentStorage property yourself: extension UITextView {     var textContentStorage: NSTextContentStorage? {         return textLayoutManager?.textContentManager as? NSTextContentStorage     } } Hopefully Apple will add this, though, as it would be useful. (I've filed an enhancement request: #FB10376167.)

https://developer.apple.com/documentation/uikit/textkit/enriching_your_text_in_text_views