Post

Replies

Boosts

Views

Activity

Reply to How can I test a QuickLook Preview Extension using Xcode?
I didn't really find anything in Apple docs on how to debug my extension using Xcode (so not saying it doesn't exist). It doesn't exist. I found a current Stack post on it, with several devs all stuck. Gotta love the internet, eh? In 2024 someone said run the Preview Extension, select Finder as the test app, then in a Finder window select a file of the correct type and tap space. It's hard to debug what someone once said. QuickLook has been redesigned a couple of times. Maybe they were still trying one of the old designs. The easiest solution is to write a test rig. I was going to include a preview of folders in my new app, but then decided against it. But the QuickLook test rig will be useful in the future. Here's part of that code: This is view controller for QuickLook: import Cocoa import Quartz class PreviewViewController: NSViewController, QLPreviewingController { @IBOutlet weak var folderController: FolderController! override var nibName: NSNib.Name? { return NSNib.Name("PreviewViewController") } override func loadView() { super.loadView() // Do any additional setup after loading the view. } func preparePreviewOfFile(at url: URL) async throws { folderController.url = url } override func viewDidLayout() { super.viewDidLayout() folderController.updateLayout(frame: view.frame) } } Here's the AppDelegate for my test rig that manually triggers it: import Cocoa import UniformTypeIdentifiers // The application delegate. @main class AppDelegate: NSObject, NSApplicationDelegate { var previewWindow: NSWindow! var previewWindowController: NSWindowController! var previewViewController: PreviewViewController! // The application has finished launching. func applicationDidFinishLaunching(_ aNotification: Notification) { previewWindow = NSWindow( contentRect: NSRect(x: 0, y: 0, width: 800, height: 600), styleMask: [.titled, .closable, .resizable, .miniaturizable], backing: .buffered, defer: false) previewWindow.title = "FolderPreview" previewWindow.center() previewViewController = PreviewViewController() previewWindow.contentViewController = previewViewController previewWindowController = NSWindowController(window: previewWindow) previewWindowController.showWindow(nil) previewWindow.makeKeyAndOrderFront(nil) } // The application is going to quit. func applicationWillTerminate(_ aNotification: Notification) { // Insert code here to tear down your application } // Support secure restorable state. func applicationSupportsSecureRestorableState( _ app: NSApplication) -> Bool { return true } } extension PreviewViewController { // Open a document. @IBAction func openDocument(_ sender: Any?) { // Allow opening a folder or directory. var allowedContentTypes = [UTType]() allowedContentTypes.append(UTType.folder) allowedContentTypes.append(UTType.directory) let panel = NSOpenPanel() panel.allowsMultipleSelection = false panel.canChooseDirectories = true panel.allowedContentTypes = allowedContentTypes if panel.runModal() == .OK { if let url = panel.urls.first { self.folderController?.url = url } } } } Assigning the url property is what does all the work. You'll need to change your allowedContentTypes as appropriate. Just run the app and choose File > Open.
Nov ’25
Reply to sshd-keygen-wrapper permissions problem
Looks like Full Disk Access is broken in 26.1. It only works with full-fledged apps, not command line tools. The error log seems to suggest that it wants a bundleID, which is something that typically only apps have. It is possible to shove a bundleID into a command-line tool. And sshd-keygen-wrapper has that. But I guess that hack isn't checked. Someone discovered this on another forum and I tried it with my own tool. I couldn't get it to work either.
Topic: Privacy & Security SubTopic: General Tags:
Nov ’25
Reply to Creating an URL bookmark in macOS 26.1 of a Windows NTFS fileshare returns a bookmark with access to the local drive
Creating bookmarks to the root directory of a volume was broken in earlier versions of 26. It looks like a change was made and that change broke NTFS. Good thing I haven't released yet. I need to double check. My workaround assumed that creating the bookmark would fail. I didn't anticipate success with invalid data. I don't know if my workaround would work for you. I have a special case where I don't actually need to access the data. I just want to know the URL. I can get the data I need without a security scoped bookmark. And it sounds like I need to re-do it anyway.
Topic: App & System Services SubTopic: Core OS Tags:
Nov ’25
Reply to Creating an URL bookmark in macOS 26.1 of a Windows NTFS fileshare returns a bookmark with access to the local drive
Never use the "comments" feature here in the forums. They don't trigger notifications and people don't notice them. This was an annoying bug for me so I wanted to double-check and close the loop. Otherwise, I might have forgotten about it and never seen your comment. But my bug does seem to be fixed. I actually got thrown off when you said "NTFS". I was thinking about the NTFS driver. You're actually talking about SMB file shares. I just tested that and it seems to work fine for me. However, I have a special use case. I don't actually need to look at the data. But curiously, the bookmark I restore is NOT the same one I saved. When I save a bookmark to the root filesystem of the startup volume, the url I decode is file:///.nofollow/. So dig into your code and see if the url you are decoding from the bookmark is actually the same url you encoded. I'm not seeing this behaviour on a network volume, but I'm using a Mac as a server.
Topic: App & System Services SubTopic: Core OS Tags:
Nov ’25
Reply to Creating an URL bookmark in macOS 26.1 of a Windows NTFS fileshare returns a bookmark with access to the local drive
No, the decoded URL is not the same as the encoded URL. That's the whole point of my post. So how is it different? I'm going to update my thread complaining about security scoped bookmarks, but all I can so is complain. That won't fix anything. In my limited case, it doesn't actually matter. I just updated my code to compare the original URL with the decoded one and I reject any value that's different. That gets me back to the old 26.0 behaviour. That's still broken, but broken in a better way. In my workaround, I define a URLBookmark class that encode/decodes the URL absolute string, the bookmark, and a secure flag. Originally, if decoding a security scoped bookmark failed, I would fall back to a standard bookmark, and then fall back to just the absolute string. But I don't actually need a security scoped bookmark. I'm just getting certain volume attributes that should (fingers crossed) always be accessible. I did have plans for using document-scoped bookmarks in the future, but those plans are fully dashed at this point.
Topic: App & System Services SubTopic: Core OS Tags:
Nov ’25
Reply to Seeking clarification on macOS URLs with security scope
Now that macOS 26.1 has been released, this bug now has different behaviour. It still isn't correct. If anything, it's more wrong than it was before. As of 26.1, when you encode a security-scoped bookmark to "file:///", what you decode will be a bookmark to "file:///.nofollow/". So the decode method now succeeds, but the value is wrong. I actually preferred the behaviour of the original bug. Luckily, due to my limited needs, I was able to easily modify my workaround. Instead of encoding just the URL bookmark, I encode the bookmark, the original URL absolute string, and a secure flag. I just added a check on the decode. If the decoded URL absolute string isn't identical to the encoded absolute string, then reset my url reference to nil, as if it were running on 26.0. I did learn a lot from this experience, and that's always good.
Topic: App & System Services SubTopic: Core OS Tags:
Nov ’25
Reply to Seeking clarification on macOS URLs with security scope
I think you filed this as FB20915052; however, this is also a known issue (r.161870449). Not me. There is a bug here, but it's not exactly what you think. The ".nofollow" syntax is a new part of the core system that allows components to construct paths that the lower level system guarantees will not be resolved or followed. This makes it simpler to protect against TOC/TOU attacks by allowing one component of the system to resolve a particular path, then pass that path to another component while guaranteeing that the second component won't inadvertently cause a second resolve. I understand about those kinds of race conditions. I'm not sure why it would be classified as an "attack". And I have no idea what that has to do with URL bookmarks. Unfortunately, the bug here is that parts of Foundation aren't handling this correctly when the path references root. I expect this will be resolved in the next system update; however, it's not clear to me whether that will mean that resolution will return "/" again or that the new "file:///.nofollow/" construct will start working. I don't think we're talking about the same bug here. However, even if we revert to "/", you should be aware that ".nofollow" and ".resolve" paths are not inherently invalid and you should expect to see more of them in the future. They are most definitely invalid. I mean, they do exist. That's not what I'm saying. I'm saying that if I take a given value, and archive it to an opaque type, I expect the unarchive process to return that original value to me. If the unarchive process returns some different value, that's simply wrong. If there are some kinds of security complications, or crazy file system constructs, that's fine. I understand. It's complicated. Then return a failure on the archive or the unarchive. Let me and the user know that the data round-trip has failed. Maybe I ask the user to re-select. Maybe I tell the user that root volumes are invalid and I disallow them in the first place. Otherwise, there's a very real risk that the user opens the app one day and all their data is gone, at least as far as they know. No errors, just no data. As I've said before, this isn't a problem for me. I don't actually need a security-scoped bookmark for this app. I was just trying to write proper code using the proper data structures. I implemented a workaround so I could get the functionality I needed, with code that would automatically use the proper logic once the bug was fixed. I didn't anticipate the unarchive returning valid, but incorrect, data. But I've got it fixed now. I use my workaround to verify the data obtained via the "correct" API. But I really shouldn't have to do that.
Topic: App & System Services SubTopic: Core OS Tags:
Nov ’25
Reply to Layout recursion error message
There's no easy answer here. I wouldn't necessarily ignore the error. There may be one or more UI interactions that you simply haven't tried yet. For example, I recently discovered that if I minimized a window and then restore it, I would get some auto layout errors. I fixed those. But the point is that the window/view controller/view/layout architecture is extremely complicated. These kinds of errors may indicate that you're doing something in the wrong sequence, or doing something else that's invalid in some way. You're running on Xcode 16. It might not work on Xcode 26 or macOS 26. Or maybe macOS 26.1 or 26.2 breaks it. Are you subclassing NSWindow? That is the kind of thing that will get you into trouble. Apple's APIs aren't like Perl. There isn't "more than one way to do it". Rather, on average, there's about 0.92 ways to do it.
Topic: UI Frameworks SubTopic: AppKit Tags:
Nov ’25
Reply to Seeking clarification on macOS URLs with security scope
And one more little gotcha. I started all of this from a Login Item. But I've seen references to Login Items being frowned upon by Apple, so I wanted to change that to a Launch Agent. Plus, XPC doesn't work with a Login Item. And this is meant for the Mac App Store, so all of it has to be sandboxed. That meant putting the launch agent into an "app-like wrapper". XPC doesn't work with a sandboxed launch agent either, in spite of it being in an app group. But that's OK. I configure the launch agent from the database and run it on a calendar interval, which is better regardless. But it looks like I got carried away with sandbox restrictions. I have to give my launch agent the "user selected files" capability. Otherwise, it can't talk to the ScopedBookmarkAgent at all, even on Sequoia.
Topic: App & System Services SubTopic: Core OS Tags:
Nov ’25
Reply to Layout recursion error message
But it does interfere. It blocks the operation if _frameLocked == true. I understand this seems pretty simple, but there's no way to know what the impacts of that might be. There are many different setFrame variants. I'm not implying that this is a problem, or in any way related to the message you're asking about. It's just example of the risks of interfering in a really fragile architecture. There are just so many possible causes, it's not reasonable to try to guess. The more you do with Auto Layout, the greater the risk of this kind of message. If you have specific requirement to deploy to 10.13, that's fine. But macOS 13 is really the oldest reasonable deployment target for most apps.
Topic: UI Frameworks SubTopic: AppKit Tags:
Nov ’25
Reply to Scanning Macintosh HD produces single .nofollow file since update to macOS 26.1
A user of one of my apps reported that since the update to macOS 26.1 they are no longer able to scan Macintosh HD: the app used to work, but now always reports that Macintosh HD contains a single empty file named .nofollow, or rather the path is resolved to /.nofollow. There's more information about this here. I don't understand it myself, so I can't do anything other than give you that link. Initially I thought this could be related to resolving the file from the saved bookmark data, but even restarting the app and selecting Macintosh HD in an open panel (without resolving the bookmark data) produces the same result. I've gotten very confused over these URL APIs recently. I know I've seen them discussed in some of your threads. I don't know if I saw this in one of your threads or not, but I definitely remember seeing advice from a DTS engineer to always take a URL provided from an open panel and launder it through a bookmark before use. If you were doing that with a security scoped bookmark, then it perhaps it would be related. Maybe I misunderstood, I did it wrong, or I just couldn't get it to work in 26.0. But I'm doing that URL laundry in my app but not using a security-scoped bookmark, because it wouldn't work 26.0. Had I been doing that, then I expect I would have the same problem as you in 26.1. I'm still able to scan the whole drive. I did encounter the ".nofollow" issue in a different feature and resolved it just by rejecting the result from the bookmark decode in favour of my truth data. In this feature, I don't actually need access to the URL, so I'm able to just build the URL from a string. But that's all totally a guess. I still have to think about it some more before I can even reply in that other thread.
Topic: App & System Services SubTopic: Core OS Tags:
Nov ’25
Reply to Scanning Macintosh HD produces single .nofollow file since update to macOS 26.1
The user had mentioned that they use a non-admin account, but I had discarded that fact as irrelevant. After your mention of "take a URL provided from an open panel and launder it through a bookmark before use" I felt inspired to create a non-admin test account and I was actually able to reproduce the issue. On my test rig, where I run 26.1, my user is an Admin user. But on my primary machine, still running Sequoia, I always use a standard user account. I just did a test with my own app. I changed my current laundry code from using a standard bookmark to a security-scoped bookmark. This would have returned nil in 26.0, but in 26.1 it returns a "valid" URL of "file:///.nofollow/" which is an empty directory. Mostly this has been just a minor annoyance because I was dealing with a different, non-scanning feature. But this is the app's primary functionality. Hopefully, this issue can be avoided entirely by avoiding security scoped bookmarks. Can someone at Apple confirm whether this is expected behaviour or what I have to do so that scanning a URL resolved from bookmark data behaves the same as scanning a URL returned from an open panel? +1
Topic: App & System Services SubTopic: Core OS Tags:
Nov ’25
Reply to How can I test a QuickLook Preview Extension using Xcode?
I didn't really find anything in Apple docs on how to debug my extension using Xcode (so not saying it doesn't exist). It doesn't exist. I found a current Stack post on it, with several devs all stuck. Gotta love the internet, eh? In 2024 someone said run the Preview Extension, select Finder as the test app, then in a Finder window select a file of the correct type and tap space. It's hard to debug what someone once said. QuickLook has been redesigned a couple of times. Maybe they were still trying one of the old designs. The easiest solution is to write a test rig. I was going to include a preview of folders in my new app, but then decided against it. But the QuickLook test rig will be useful in the future. Here's part of that code: This is view controller for QuickLook: import Cocoa import Quartz class PreviewViewController: NSViewController, QLPreviewingController { @IBOutlet weak var folderController: FolderController! override var nibName: NSNib.Name? { return NSNib.Name("PreviewViewController") } override func loadView() { super.loadView() // Do any additional setup after loading the view. } func preparePreviewOfFile(at url: URL) async throws { folderController.url = url } override func viewDidLayout() { super.viewDidLayout() folderController.updateLayout(frame: view.frame) } } Here's the AppDelegate for my test rig that manually triggers it: import Cocoa import UniformTypeIdentifiers // The application delegate. @main class AppDelegate: NSObject, NSApplicationDelegate { var previewWindow: NSWindow! var previewWindowController: NSWindowController! var previewViewController: PreviewViewController! // The application has finished launching. func applicationDidFinishLaunching(_ aNotification: Notification) { previewWindow = NSWindow( contentRect: NSRect(x: 0, y: 0, width: 800, height: 600), styleMask: [.titled, .closable, .resizable, .miniaturizable], backing: .buffered, defer: false) previewWindow.title = "FolderPreview" previewWindow.center() previewViewController = PreviewViewController() previewWindow.contentViewController = previewViewController previewWindowController = NSWindowController(window: previewWindow) previewWindowController.showWindow(nil) previewWindow.makeKeyAndOrderFront(nil) } // The application is going to quit. func applicationWillTerminate(_ aNotification: Notification) { // Insert code here to tear down your application } // Support secure restorable state. func applicationSupportsSecureRestorableState( _ app: NSApplication) -> Bool { return true } } extension PreviewViewController { // Open a document. @IBAction func openDocument(_ sender: Any?) { // Allow opening a folder or directory. var allowedContentTypes = [UTType]() allowedContentTypes.append(UTType.folder) allowedContentTypes.append(UTType.directory) let panel = NSOpenPanel() panel.allowsMultipleSelection = false panel.canChooseDirectories = true panel.allowedContentTypes = allowedContentTypes if panel.runModal() == .OK { if let url = panel.urls.first { self.folderController?.url = url } } } } Assigning the url property is what does all the work. You'll need to change your allowedContentTypes as appropriate. Just run the app and choose File > Open.
Replies
Boosts
Views
Activity
Nov ’25
Reply to sshd-keygen-wrapper permissions problem
Looks like Full Disk Access is broken in 26.1. It only works with full-fledged apps, not command line tools. The error log seems to suggest that it wants a bundleID, which is something that typically only apps have. It is possible to shove a bundleID into a command-line tool. And sshd-keygen-wrapper has that. But I guess that hack isn't checked. Someone discovered this on another forum and I tried it with my own tool. I couldn't get it to work either.
Topic: Privacy & Security SubTopic: General Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Creating an URL bookmark in macOS 26.1 of a Windows NTFS fileshare returns a bookmark with access to the local drive
Creating bookmarks to the root directory of a volume was broken in earlier versions of 26. It looks like a change was made and that change broke NTFS. Good thing I haven't released yet. I need to double check. My workaround assumed that creating the bookmark would fail. I didn't anticipate success with invalid data. I don't know if my workaround would work for you. I have a special case where I don't actually need to access the data. I just want to know the URL. I can get the data I need without a security scoped bookmark. And it sounds like I need to re-do it anyway.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Creating an URL bookmark in macOS 26.1 of a Windows NTFS fileshare returns a bookmark with access to the local drive
Never use the "comments" feature here in the forums. They don't trigger notifications and people don't notice them. This was an annoying bug for me so I wanted to double-check and close the loop. Otherwise, I might have forgotten about it and never seen your comment. But my bug does seem to be fixed. I actually got thrown off when you said "NTFS". I was thinking about the NTFS driver. You're actually talking about SMB file shares. I just tested that and it seems to work fine for me. However, I have a special use case. I don't actually need to look at the data. But curiously, the bookmark I restore is NOT the same one I saved. When I save a bookmark to the root filesystem of the startup volume, the url I decode is file:///.nofollow/. So dig into your code and see if the url you are decoding from the bookmark is actually the same url you encoded. I'm not seeing this behaviour on a network volume, but I'm using a Mac as a server.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to API for disk throughput?
You can get this information from IOKit. But I'm not sure what notarization has to do with anything. You can even get this information from the sandbox.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Creating an URL bookmark in macOS 26.1 of a Windows NTFS fileshare returns a bookmark with access to the local drive
No, the decoded URL is not the same as the encoded URL. That's the whole point of my post. So how is it different? I'm going to update my thread complaining about security scoped bookmarks, but all I can so is complain. That won't fix anything. In my limited case, it doesn't actually matter. I just updated my code to compare the original URL with the decoded one and I reject any value that's different. That gets me back to the old 26.0 behaviour. That's still broken, but broken in a better way. In my workaround, I define a URLBookmark class that encode/decodes the URL absolute string, the bookmark, and a secure flag. Originally, if decoding a security scoped bookmark failed, I would fall back to a standard bookmark, and then fall back to just the absolute string. But I don't actually need a security scoped bookmark. I'm just getting certain volume attributes that should (fingers crossed) always be accessible. I did have plans for using document-scoped bookmarks in the future, but those plans are fully dashed at this point.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Seeking clarification on macOS URLs with security scope
Now that macOS 26.1 has been released, this bug now has different behaviour. It still isn't correct. If anything, it's more wrong than it was before. As of 26.1, when you encode a security-scoped bookmark to "file:///", what you decode will be a bookmark to "file:///.nofollow/". So the decode method now succeeds, but the value is wrong. I actually preferred the behaviour of the original bug. Luckily, due to my limited needs, I was able to easily modify my workaround. Instead of encoding just the URL bookmark, I encode the bookmark, the original URL absolute string, and a secure flag. I just added a check on the decode. If the decoded URL absolute string isn't identical to the encoded absolute string, then reset my url reference to nil, as if it were running on 26.0. I did learn a lot from this experience, and that's always good.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to QuickLook Thumbnailing returns stale macOS 26 folder icon
QLThumbnailGenerator is for generating thumbnails. It sounds like you are just trying to read whatever icon is there, not generate a new one. Just use one of the NSWorkspace or URL methods to retrieve the icon.
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Seeking clarification on macOS URLs with security scope
I think you filed this as FB20915052; however, this is also a known issue (r.161870449). Not me. There is a bug here, but it's not exactly what you think. The ".nofollow" syntax is a new part of the core system that allows components to construct paths that the lower level system guarantees will not be resolved or followed. This makes it simpler to protect against TOC/TOU attacks by allowing one component of the system to resolve a particular path, then pass that path to another component while guaranteeing that the second component won't inadvertently cause a second resolve. I understand about those kinds of race conditions. I'm not sure why it would be classified as an "attack". And I have no idea what that has to do with URL bookmarks. Unfortunately, the bug here is that parts of Foundation aren't handling this correctly when the path references root. I expect this will be resolved in the next system update; however, it's not clear to me whether that will mean that resolution will return "/" again or that the new "file:///.nofollow/" construct will start working. I don't think we're talking about the same bug here. However, even if we revert to "/", you should be aware that ".nofollow" and ".resolve" paths are not inherently invalid and you should expect to see more of them in the future. They are most definitely invalid. I mean, they do exist. That's not what I'm saying. I'm saying that if I take a given value, and archive it to an opaque type, I expect the unarchive process to return that original value to me. If the unarchive process returns some different value, that's simply wrong. If there are some kinds of security complications, or crazy file system constructs, that's fine. I understand. It's complicated. Then return a failure on the archive or the unarchive. Let me and the user know that the data round-trip has failed. Maybe I ask the user to re-select. Maybe I tell the user that root volumes are invalid and I disallow them in the first place. Otherwise, there's a very real risk that the user opens the app one day and all their data is gone, at least as far as they know. No errors, just no data. As I've said before, this isn't a problem for me. I don't actually need a security-scoped bookmark for this app. I was just trying to write proper code using the proper data structures. I implemented a workaround so I could get the functionality I needed, with code that would automatically use the proper logic once the bug was fixed. I didn't anticipate the unarchive returning valid, but incorrect, data. But I've got it fixed now. I use my workaround to verify the data obtained via the "correct" API. But I really shouldn't have to do that.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Layout recursion error message
There's no easy answer here. I wouldn't necessarily ignore the error. There may be one or more UI interactions that you simply haven't tried yet. For example, I recently discovered that if I minimized a window and then restore it, I would get some auto layout errors. I fixed those. But the point is that the window/view controller/view/layout architecture is extremely complicated. These kinds of errors may indicate that you're doing something in the wrong sequence, or doing something else that's invalid in some way. You're running on Xcode 16. It might not work on Xcode 26 or macOS 26. Or maybe macOS 26.1 or 26.2 breaks it. Are you subclassing NSWindow? That is the kind of thing that will get you into trouble. Apple's APIs aren't like Perl. There isn't "more than one way to do it". Rather, on average, there's about 0.92 ways to do it.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to QuickLook Thumbnailing returns stale macOS 26 folder icon
Never use the comments feature. All it does is hide your reply. I see what you mean. I stand corrected.
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Seeking clarification on macOS URLs with security scope
And one more little gotcha. I started all of this from a Login Item. But I've seen references to Login Items being frowned upon by Apple, so I wanted to change that to a Launch Agent. Plus, XPC doesn't work with a Login Item. And this is meant for the Mac App Store, so all of it has to be sandboxed. That meant putting the launch agent into an "app-like wrapper". XPC doesn't work with a sandboxed launch agent either, in spite of it being in an app group. But that's OK. I configure the launch agent from the database and run it on a calendar interval, which is better regardless. But it looks like I got carried away with sandbox restrictions. I have to give my launch agent the "user selected files" capability. Otherwise, it can't talk to the ScopedBookmarkAgent at all, even on Sequoia.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Layout recursion error message
But it does interfere. It blocks the operation if _frameLocked == true. I understand this seems pretty simple, but there's no way to know what the impacts of that might be. There are many different setFrame variants. I'm not implying that this is a problem, or in any way related to the message you're asking about. It's just example of the risks of interfering in a really fragile architecture. There are just so many possible causes, it's not reasonable to try to guess. The more you do with Auto Layout, the greater the risk of this kind of message. If you have specific requirement to deploy to 10.13, that's fine. But macOS 13 is really the oldest reasonable deployment target for most apps.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Scanning Macintosh HD produces single .nofollow file since update to macOS 26.1
A user of one of my apps reported that since the update to macOS 26.1 they are no longer able to scan Macintosh HD: the app used to work, but now always reports that Macintosh HD contains a single empty file named .nofollow, or rather the path is resolved to /.nofollow. There's more information about this here. I don't understand it myself, so I can't do anything other than give you that link. Initially I thought this could be related to resolving the file from the saved bookmark data, but even restarting the app and selecting Macintosh HD in an open panel (without resolving the bookmark data) produces the same result. I've gotten very confused over these URL APIs recently. I know I've seen them discussed in some of your threads. I don't know if I saw this in one of your threads or not, but I definitely remember seeing advice from a DTS engineer to always take a URL provided from an open panel and launder it through a bookmark before use. If you were doing that with a security scoped bookmark, then it perhaps it would be related. Maybe I misunderstood, I did it wrong, or I just couldn't get it to work in 26.0. But I'm doing that URL laundry in my app but not using a security-scoped bookmark, because it wouldn't work 26.0. Had I been doing that, then I expect I would have the same problem as you in 26.1. I'm still able to scan the whole drive. I did encounter the ".nofollow" issue in a different feature and resolved it just by rejecting the result from the bookmark decode in favour of my truth data. In this feature, I don't actually need access to the URL, so I'm able to just build the URL from a string. But that's all totally a guess. I still have to think about it some more before I can even reply in that other thread.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’25
Reply to Scanning Macintosh HD produces single .nofollow file since update to macOS 26.1
The user had mentioned that they use a non-admin account, but I had discarded that fact as irrelevant. After your mention of "take a URL provided from an open panel and launder it through a bookmark before use" I felt inspired to create a non-admin test account and I was actually able to reproduce the issue. On my test rig, where I run 26.1, my user is an Admin user. But on my primary machine, still running Sequoia, I always use a standard user account. I just did a test with my own app. I changed my current laundry code from using a standard bookmark to a security-scoped bookmark. This would have returned nil in 26.0, but in 26.1 it returns a "valid" URL of "file:///.nofollow/" which is an empty directory. Mostly this has been just a minor annoyance because I was dealing with a different, non-scanning feature. But this is the app's primary functionality. Hopefully, this issue can be avoided entirely by avoiding security scoped bookmarks. Can someone at Apple confirm whether this is expected behaviour or what I have to do so that scanning a URL resolved from bookmark data behaves the same as scanning a URL returned from an open panel? +1
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’25