It's better to respond with a reply. I just randomly checked some of my old replies to look for comments and found this. I'm not sure what you're asking. It may be just a bug with clipboard history in Spotlight. Isn't that still in beta? When you added those strings (deprecated by the way) to the declared types list, that might cause spotlight history to omit this information. But there's definitely no kind of data security going on or anything. You put something on the pasteboard, it's there for all apps to see.

If you think the behaviour of the system is wrong, file a bug report. Just don't assume there is any security in the pasteboard.

If your app is 10 years old, then maybe you need to update your App Store logic. From what I understand, having a receipt is not 100% guaranteed anymore. So if that is your "history of purchases", you may not have it until the user clicks on the Restore button.

It's the same thing. A table view reuses all cell views. It simply takes some time to draw these user interface elements. You have to leverage the tools you have and the material conditions of the user interface. Chances are, the window is going to be too small to show all those views. So you only show what fits on the screen. Table views and collection views are optimized to do this. Then, when the user wants to see more, they can scroll. Any newly revealed portion of the view is going to have less content than the full thing, so this newly revealed content can be drawn in real time. If you're really living on the edge, there are even ways to cache overflows that that scrolling is smoother.

Does your app explicitly advertise support for this file type in imported file types? A recent change to macOS started requiring this explicit support.

[quote='848905022, Nickkk, /thread/795994?answerId=852443022#852443022, /profile/Nickkk'] It does. [/quote] Well, for whatever reason, it doesn't seem to be working. Your original description of the problem, 'choosing in the Finder "File > Open With > Other", then selecting my app and enabling "Always open with"' very specifically describes an app that doesn't advertise support for that file extension. If it did, then it would have shown up in the top-level list, not in "Other". And, by extension, you wouldn't be getting that malware warning either.

[quote='852581022, Nickkk, /thread/795994?answerId=852581022#852581022, /profile/Nickkk'] I didn't say that. [/quote] You were relaying what the end user told you. Obviously the end user's experience was more important than the fact that it worked on your machine. From what I understand, this was a change made to macOS 15.4. I think that Apple changed this behaviour again in 15.6. I could reproduce the problem on a 15.4 VM, but I can't on 15.6, at least on my developer machine. A VM is a good way to test software from an end-user's perspective. But I don't think you need to install Xcode on it to test this. Also, modern VMs on Apple Silicon do not have full access to Apple ID services. Some things work and some things don't. But regardless, always download Xcode directly from the developer site. Never use the App Store.

Contact who? You haven't said who the developer is. However, this is a technical support forum for developers, not for end users. You would get much better responses if you posted in the Apple Support Community. However, even there, you'll need to provide more information. What developer is this? What app is this? Please don't just say the name of the app. App names are 100% meaningless. You must provide a link to the app. Also, where did you buy the app? Did you buy it from an Apple App Store? Or from somewhere else? You should have your receipt and it will clearly say that. I can tell you have developers respond to e-mails 100% of the time. Even if they don't respond, that's a meaningful response. It means they don't care, they've gone out of business, or they've just abandoned that app. This is very common.

But whatever you decide, make a point to save that response from "Framework Engineer". I had no idea it was possible to do either of those two things.

You need to create a help book. Here is the documentation. It is very old, but it still works mostly. In modern versions of macOS, help will open using the standalone "Tips" app. In older systems, the help will be integrated into your app. A help book is nothing more than a bundle of localized HTML resources and assets. It is a little tricky to get it integrated into an app, but no more so than anything else Apple does. And since it is a stand-alone bundle, you can view the help documents using Apple's default help viewer, an external web browser, or your own integrated help display. I recommend against using anchors, however. That seems to be one help feature that was broken a few years ago. Instead, break your help up into smaller pages. And if you're working in iOS, you re-use all the same content and architecture. iOS doesn't have the same kind of help architecture, but you can easily display your help content in a web view.

First of all, WGS84 is a world geodetic system (WGS). It's complicated. Coordinates in MapKit are just basic latitude and longitude. Internally, they are represented as map points in the web mercator system (EPSG:3857), not WGS84. But none of that really matters for your question. Maps in China must use the government-mandated coordinate system which automatically applies obfuscation. So, yes, it is wrong. But it's supposed to be wrong. You don't need to worry about that or try to simulate it. And definitely don't worry much about obvious edge cases like Hong Kong.

This has been an ongoing problem in Apple's Developer forums and the Apple Support Community. These two forums seem to share a lot of code. And apparently, they even share releases. These kinds of problems started on both forums in July. Then both were fixed. Now both forums are having the same problems again.

An update: I thought it would be enlightening to write a simple demonstration app. I did that and learned a few things. Apple documentation describes two entitlements that are required for security scoped bookmarks. This document is strange. For one thing, the URL is under video applications. And it's ancient, referring to changes in macOS 10.7.3. It's also wrong. The entitlement "com.apple.security.files.bookmarks.app-scope" is not necessary and has no effect. More importantly, the entitlement "com.apple.security.files.bookmarks.document-scope" is required for security scoped bookmarks with document scope. You'll get an error if you attempt to use them without this entitlement. Unfortunately, they also don't work at all. The entitlement error is straightforward and tells you that you need the entitlement. But then, when you provide it, all attempts fail with error 256 "Item URL disallowed by security policy". It does seem to be modifying the metadata of the reference URL, but then it just doesn't work. That's too bad. I prefer to have data where I can see it. As far as security-scoped bookmarks and URLs, it's just really complicated now. It's impossible to create security-scoped bookmarks for certain URLs. I've only found two paths that are guaranteed failures: / and /System/Volumes/Data. These are kinda the same thing, but also kinda not. Unfortunately, if you allow the end user to select a directory, there's nothing stopping them from selecting these two locations. My recommendation is to wrap a URL in a class that can manage both the start/stopAccessingSecurityScopedResource and when creating a security scoped bookmark, fall back to a standard bookmark (or just an absolute string) on failure and hope that's useable after restart. Maybe this is just a bug in macOS 26 and it'll be fixed before launch. But even if this happens, this is obviously an API that's at risk for breakage.

It's probably related to whatever you are doing with adguard and vaultwarden. I don't know what any of that is, but when I search for your domain, it shows up on a couple of Github domain lists. I also don't know what those domain lists are for. But if you're going to play around with anything even remotely related to "security", you should do that on a burner site. Otherwise, you effectively turn your site into a burner site. There is no differentiation on the internet between legal/illegal, safe or malicious. It's the internet. It's all illegal and malicious, unless proven otherwise. Google and others work hard to hide that from regular folks. But if you fall through the cracks, even by accident, it's your problem to solve. Nobody's going to help. This is a developer support forum. It's a place for questions about SwiftUI, APIs, NSURLSession, etc. You can ask anything you want, but if you're asking about something that isn't developer related, you probably won't get any answer. I can tell you that there is no escalation process. The modern world runs on scripts and automated flows. If you ever need personal support, for any reason, you're in deep trouble. And I'm talking about situations where you've paid money for a service, over several years. Even with that kind of established relationship, trivial support requests that require human intervention will take weeks at best. At even the slightest hiccup, entirely unrelated to you, you'll be dropped and forgotten, and they might even keep your money. The internet's not for the faint of heart.

If you wanted to create a process that created bookmarks but didn't present open/save panels (for example, as a helper process), then you could use it. The only time I imagine this could be executed would be if a helper resolved a bookmark and found it stale. Don't know how I could test that, but I guess this means "com.apple.security.files.bookmarks.app-scope" actually is required. Thanks for the insight. In concrete terms, a bookmark created directly to "/" (hard-coded path) will be able to read "/" (the top level) but will NOT be able to read "/Users/". However, a bookmark created from an open panel WILL be able to read "/Users/". My issue here is the type of bookmark. I cannot create a security-scoped bookmark to / from an open panel. That's what I meant about being lucky. For this app, in this instance, I don't need to read /Users. I just want the size and free space on the volume itself. The app is currently working just by creating whole-volume URLs from the path. Originally, I thought I would need security-scoped URLs. Then they didn't work. Then I figured out I didn't need them at all. But I would still prefer to code defensively. On the Mac, start returning "false" generally means that you don't have access to the file, which generally means you're doing something wrong. That is not the focus of my question here. I think I've seen it return false, and noted it in passing, but didn't have any problems. It could have been on iOS. I have a large cross-platform project on temporary hiatus. That project is where I adopted the practice of checking the result of start. My general advice here is to treat any URL you receive from the system as a "magic" object. In practice, I generally convert it to a bookmark, then resolve the bookmark again, and use that new URL*, discarding the original ("magic") URL. *This ensures that the rest of my app is ALWAYS working with "a URL that came from a bookmark", instead of a "split" flow. But converting certain "magic" URLs always fails, therefore a "split" flow is unavoidable. the better option here is to create your own class which "handles" access to that object and "owns" both the bookmark and any URL. If it has problems, then it just resolves the bookmark again. Yes. That's what I'm going to do, in order to manage this split flow. Your advice makes a lot of sense, especially for this issue. When I get a URL from the system, convert it to a bookmark. First try a security-scoped bookmark. But if that fails (as it will for / and /System/Volumes/Data), then try a standard bookmark, and if that fails just use the path. Then resolve that "persisted resource" to my own URL and use that. I think a better approach than wrapping the URL is just to create a "URLResource" object that will contain a type enum and data. It will handle security-scoped bookmarks, regular bookmarks, and absolute strings. It'll still be sendable too.