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.

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.

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.

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.

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.

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.

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.

What I don't understand from the reviewer's response is what receipts validation are they talking about? When a user makes a purchase, it creates a receipt in the app bundle. Your app should check the validity of that receipt. If it is valid, then you make the premium features available. If you don't validate the receipt, then hackers will re-distribute your app with a fake receipt so that anyone can use it for free. They might even charge a fee, making money off your app instead of you. Don't assume you're too small to be targeted. I assure you that you're not. I have no payment servers (the whole concept of using Apple's in-app-purchases service is to not have to deal with my own payment implementation) That's something totally different. Most apps are subscription based or have some service provided over the internet. For these use cases, Apple provides a quick-and-easy way to validate receipts. In your case, since you're entirely on-device, you'll need to validate the receipt on-device. That's tricky because your receipt validation logic can (and will) also be hacked. Again, don't assume that hackers won't reverse-engineer your app and change the binary instructions. They will. The reviewer's response is so vague, and so completely deprived of details that I have no idea what to do I'm afraid that the reviewer is assuming that you already know about the issue, but maybe copied code from the internet or an AI. It's not a developer's market. Performing receipt validation on device used to be a Really Big Deal. It isn't such a problem anymore because users have become trained to accept subscriptions. I've tried to give you a little background to explain what's going on. Unfortunately, I have no idea what your problem is. Your app does need to connect to Apple servers to find your in-app purchases and do things like get the region-specific price to be shown to the user. It sounds like your app isn't talking to the production servers. App reviewers test in a hybrid environment where everything is real except the money. The reviewer's note is straightforward. Just substitute "app" for "server" in your case.

The application isn't sandboxed, so I didn't add any additional entitlements and it should not matter. Well there's still the Apple Events capability in "Signing & Capabilities". You have to provide a message to the user about why your app needs AppleEvents. I'm not sure what happens if that's missing. I don't see why I wouldn't use it while it's still there and hasn't been deprecated yet. Just because something hasn't been deprecated doesn't mean that it's reliable. This approach works the same way as when executing AppleScript script with NSUserAppleScriptTask I'm going to go ahead and disagree on that point. But I assume you're only talking about the end result for your use case. I've mentioned in my initial post why such approach isn't working for me in case files with same names already exist at the destination. Are you sure that's even possible? While the Finder is an unusual app, it's still a stand-alone app. Just because it exposes certain functionality via AppleScript doesn't guarantee that said functionality is going to be the same as what the user experiences when interacting directly with the app. There's a strong argument to say that it shouldn't. People who are writing scripts want their script to run in their own UI and logic flow. They generally don't want a service provider to inject its own UI into the process. So I think your suspicions here: I came to suspect that I could achieve such bahaviour by using Apple Events directly are likely unfounded. I don't understand why it's so important to use the Finder. Writing your own conflict resolution UI would be a lot easier than writing anything in AppleScript. I'm aware of Finder's "merge" functionality, but it's really not very good. It's quite difficult to trigger it in the first place. That strongly suggests that it's an artifact of the user's interaction with the Finder's file listing rather than a lower-level, scriptable operation.

Any help is highly appreciated, thanks! Have you jumped through all the hoops so that your app can actually send Apple Events? Here is some old documentation that might be a good starting point: https://developer.apple.com/library/archive/qa/qa1888/_index.html And here is a previous question from someone managed to get it working, after a fashion: https://developer.apple.com/forums/thread/771769 Any attempt to script the Finder is going to limit your app. It won't be acceptable for the Mac App Store. Any new code that relies on AppleScript is risky. Apple is already transitioning to Shortcuts. And Apple has begun to be much more aggressive about deprecating and discontinuing technologies, pretty much all of which are much recent than Apple Events. In older apps where I still did such things, I had good success with running the "osascript" command-line tool with carefully constructed parameters.

I've heard you can get pre approval You heard wrong.

However, we are trying our hardest to maintain a unified codebase going forward, so we are very much trying to prioritize finding a way to make the original python build work. That's all well and good. But Apple's priority is obviously Swift apps for iOS. I have no reason to think that the workflow is the source of this issue I didn't say the workflow is the source of the issue. I said the workflow is the easy part. The difficult part will be getting the Python app to run once it's been notarized. That's a significantly different runtime environment. I wasn't able to find any resources in the documentation about the nuances of notarizing python apps. And you won't. You can search this forum for either "python" or any variant of "notarized" and find dozens of posts about notarizing Python apps. Apple Developer support usually tries very hard to help, but it's always painful.

I am new to the apple developer program...The software is entirely written in python and includes ffmpeg That's probably the single most difficult type of software you can try to build on a Mac. We are currently adding the signing and notarization of the app to our github workflow. Have you tried to do any of this not using a GitHub workflow? Because I hate to tell you this, but most people who experience notarization problems get stuck at a much later stage. You haven't got to the difficult part yet. I would like feedback about if there is a fundamental flaw in our approach for signing and notarizing our application, so that we can identify it. I recommend skipping all the automation stuff until you confirm that your notarized app actually runs. Notarization adds a lot of runtime checks that are particularly difficult for Python apps to pass. I would appreciate some guidelines about how long to expect this notarization step to take until we can get notarization to finish within 10s of minutes, as we have a hard-coded 30 min wait time for the completion of the notarization in our workflow right now. For a native app, notarization usually takes 10 seconds or so. It would be helpful to know how to check our logs, as requesting the logs for any of our attempts results in being told that the logs are not available yet. If the logs aren't available yet, then there's nothing for you to check. I don't know anything about Python apps, other than they seem to generate an inordinate number of problems as reported here in the forums.

I'm pretty sure that if availability information is missing, that means that the glyph is only available in xOS 26. There is a 3rd party package that imports all of these symbols into a static namespaces so the compiler can check this for you. See https://github.com/SFSafeSymbols/SFSafeSymbols

Once, the App Store empowered indie creators - small teams could launch great apps Nothing has changed in that respect. There are more opportunities now for people to build low-quality apps by using low-quality, cross-platform frameworks and tools. But people are still able to launch great apps with discipline, intelligence, and hard work. and find users easily This part has changed. There are lots more apps to choose from, a radically different marketplace, and different user expectations. It now takes more work and more time to find users. But in 2025, that era feels long gone, with algorithms, big players, and pay-to-win discoverability reshaping everything. Many things have changed over the past 17 years. Is there still a real chance for indie iOS developers today, or has Apple’s evolving ecosystem made independent success nearly impossible? Many people are having success. They're just focused on their products and providing a great experience for their customers. Posting content on social media doesn't help with that. That's why you see so much negativity. Negativity and hate, not success, are what drive social media. I think one big difference from 2008 is the idea of "indie". Back then, it generally meant working for yourself instead of working for some larger company. These days, it essentially means someone makes a few hundred dollars from 6 months of work. On social media, people cheer making a billion dollars and making 25. But nobody wants to hear about making a living. It does take more work now. Being a developer isn't enough. One also needs to know how to run a business, advertise, attract customers, and support them. At first, everything was new, and that was easy. Now, people expect Apple to do all that for them. When that doesn't happen, they try cheats and scams, which usually get traction in social media. Avoid the labels and build software that people will value.