How can I proceed? Very carefully. If your account is associated with a terminated account, you might be next. Apparently to re-activate it, they have to provide "passport" info, which seems over the top. Obviously I have no idea about your client or any of the details. But this is standard, and mandatory, "know your customer" industry practice.

Hello I'm wrapping my head around on how to properly set up xcode project to produce a static library Why? file locations /usr/local/lib/libXXX.a and /usr/local/include/XXX/xxx.h so it can be used Unix style in other projects That's not really the way that macOS works. I could write an old style Makefile and have xcode call the makefile but there must be an easier way to do this. What's wrong with a makefile? Xcode is designed to build iOS apps. There is no "easy" way to make it build open-source style archives and headers. And why should there be? Any open source project would be using standard tools to do this kind of thing. They would never, ever use Xcode. This is for a cross platform development so having it packaged into a Framework would not solve it neither. The Mac and Xcode are not useful for cross-platform development. Just use whatever standard tools fit your technical and social requirements - autotools, CMake, Google-build-engine-du-jour, whatever. Now if you wanted to build an app with any of those open-source projects, then porting it all to Xcode can be a very good idea. That makes many problems vanish. But if you're trying to go the other way, you're just inventing new problems. Pro tip: recent versions of Xcode allow you to statically link frameworks, with a few caveats.

Inno Setup was a sweet app. I used to use that when I made Windows software. I don't know anything about Filemaker. A quick search says that runtimes were deprecated and removed years ago. Apparently Filemaker 18 was the last version to support them. There is some kind of "iOS App SDK" that may still be supported. It doesn't sound like this would be a quick and/or easy solution, but that seems to be all there is. After Hypercard, there was never the same kind of custom database app community (Clipper, Access, Paradox, etc.) as on PCs. I don't know what you mean by "inherited icons". A DMG is just a disk image. Its use in installing software is problematic. Why use a zip files or pkg installer when you can use DMGs that make it 3 times more difficult? Look at the "pkgutil" tool. All you need is a folder with the app you want to install. Create a directory tree of all the locations where you want to install files. Then use pkgutil to create an installer for that. Forget everything I said about the Mac App Store. That isn't applicable to what you're trying to do. This runtime approach seems like a dead end. I don't know what your higher-level goals might be for this app. There's no good way to approach this on a Mac.

I'm afraid you'll have to provide a bit more context. Do you have a specific question that someone could answer? Are you talking about building or installing? For building, the standard process is simple. Xcode > Product > Archive. There is no step two. For distribution, you can choose the Mac App Store or direct distribution. If you choose the Mac App Store, you're done with the installer package at that point. For direct distribution, you'll still need to zip the resulting app. You can do that in the Finder with control-click or double-click and choose "Compress". Of course, if you're more of a masochist, there are many, many suggestions from the internet on how to make the process more difficult. You're correct that those procedures can get Kafkaesque in no time. But you don't have to do it that way if you don't want. And if you don't like those procedures, then I don't see the point of attempting them.

Yes. See the post here: https://developer.apple.com/forums/thread/805177 The only problem is that it's async. So what I have to do is use the old-style initially and then update that asynchronously. And the problem being discussed in the above thread is valid. If the user changes the icon while your app is running, you can't get the new version.

That's what I thought. In certain situations, namely the one you're in, the idea of a "successful" notarization isn't what you think it is. Once you "successfully" notarized your app, you subject it to an additional layer of runtime checks at launch. If you're using any kind of 3rd party framework or environment to launch/run your app, then it will most likely fail to launch. You'll have to figure out why. Maybe you can just tweak your hardened runtime settings. Maybe you have to start from scratch. I can't tell from here.

What is "the malware warning"? Are you referring to XProtect blocking the execution of your app? Or is your app simply failing to launch after notarization? You said you're using Electron, so it sure sounds like some runtime error.

Everyone's getting those messages. Nothing you can do about it.

My assumption was that NSURLBookmarkCreationWithoutImplicitSecurityScope would create a bookmark that, when resolved via NSURLBookmarkResolutionWithoutImplicitStartAccessing, would ensure that the initial access count of the resource was 0. You know what they say when you "assume" The goal is to ensure that my own balanced pairs of startAccessingSecurityScopedResource and stopAccessingSecurityScopedResource on the resulting URL will never leak kernel resources due to unbalanced implicit accesses that I've somehow opted in to. Apparently, they shouldn't be balanced at all anymore. Instead, developers should issue one extra stopAccessingSecurityScopedResource to release the implicit startAccessingSecurityScopedResource.

This thread was started in July. I just added an Icon Composer Icon to my app and it seems to work fine in Ventura. Can someone clarify precisely how and where the current 26.1 implementation is broken?

I don't mean to hijack the original thread No worries. It's a lost cause. Is there any public documentation of how these two magic directories work and should be handled? I think you're reading it. What is the recommended (CF or POSIX) API to resolve a canonical path in the presence of these paths? In Qt we use realpath if the path exists. Testing realpath /.nofollow/Applications in Terminal it doesn't seem to resolve to /Applications (on 26.1). Good question If the path does not exists, and we need a canonical path (for cache key lookup e.g.), are we expected to manually strip .resolve and .nofollow, the same way we might combine/deal with .. and . ? What is a "cache key lookup"? Are you referencing that 3rd party web site? As Apple engineers often say, that's would be an implementation detail that we shouldn't get involved with. Always good advice, isn't it?

What does this value imply on macOS and iOS? Well there is no NSURLBookmarkResolutionMinimalBookmark. But NSURLBookmarkCreationMinimalBookmark is documented to produce "a smaller bookmark that can be resolved in fewer ways". (Note: it's worth keeping some Objective-C in your project just so you can paste in these symbols and then do "jump to definition". Sometimes the Objective-C headers have documentation that isn't available elsewhere. That's not true in this case, but it's an important thing to remember.) There are some additional resolution options that allow resolution without a UI or without mounting a volume. So perhaps one or more of these options isn't possible for a minimal bookmark. Are iOS bookmarks always security scoped? Apparently. Does the minimal enum imply security scoped bookmarks? Is 0 a valid value to bookmarkDataWithOptions, and does that give an even less scoped bookmark than NSURLBookmarkCreationMinimalBookmark`? This URL bookmark API reminds me a lot of the old Grand Central Dispatch API. The more I learned about it, the more confused I got. However, there was always an alternative to GCD. I'm seriously leaning towards ripping out all use of URL bookmarks and avoiding any feature that would require them. We are also using NSURLBookmarkCreationWithoutImplicitSecurityScope on both iOS and macOS, to avoid any implicit resolution of bookmarks we resolve, so that we can explicitly control access by explicit calls to start/stopAccessing. Apparently, you should never use that. (https://mothersruin.com/software/Archaeology/reverse/bookmarks.html provides some really interesting insights, but doesn't discuss the minimal bookmarks.) While interesting, I strongly recommend avoiding anything from that. That page was last updated in July, and these URL bookmarks have changed significantly since then. The behaviour is even changing in 26.2.

You can use the "isReadable" value from URLResourceValues. However, it sounds like you're not approaching this from the right direction. You should never need to do this in the first place. Your app shouldn't attempt to read random files. It should only attempt to access files that the user has specifically requested. And even then, you shouldn't check readability. That's not reliable. Instead, just try to do what the user asked and report an error if it fails.

Perhaps you should file a Feedback report on Feedback Assistant.

System-wide....Nothing really limits the scope My question is more about the fundamental nature of URL paths. Should we be treating these ".nofollow" components like "." components? For example, in most cases, we don't have to worry much about "." and "..". The system handle them fines, they can be harmlessly standardized away, and they don't occur in the context of NSOpenPanel. They're only an issue when URLs are provided by the user. But we do have to worry about ".nofollow" components now? What do we do with them? Should we be removing that (those, plural?) ".nofollow" component manually? Or will that break something? I'm using an NSToken field to show the user their current location in the file system. I don't want to show ".nofollow" to the user. you probably won't see them with fileReferenceURLs, but that's actually because the fileReferenceURL isn't storing a path at all. That's an interesting idea. However, I'm not too confident in the future of fileReferenceURLs. They aren't even supported in Swift. I use them for one neat little trick, but I have to do it in Objective-C. I suggested testing in Terminal as an easy way to understand how the core system behaves, not to replicate your app’s specific behavior. I wasn't talking about my app's specific behaviour, but, rather, the behaviour of the sandboxed app environment, both when the user has provided access to a given URL and when not. In an earlier app, I wrote a tool just so I could execute system tools from the sandbox to see if they would work or not. Of course, in most cases, those tools aren't "API", so I shouldn't be doing that. Fair enough. But official APIs are really no different. How official APIs are documented to behave and how they work in the sandbox are two different things. And that's one of my primary concerns there. You keep talking in terms of Terminal and Foundation. But in the sandbox, "file:///" and "file:///.nofollow/" are NOT the same thing. I don't even have to talk in theoretical terms about it possibly breaking one day. It's broken right now. If the system resolves a security-scoped URL to "file:///.nofollow/", and I do some UI manipulation to avoid confusing the user, and at some point request "file:///". Will that break? You're talking about Foundation dealing with these paths. But I'm talking about the sandbox. Maybe Foundation does it right but then the sandbox blocks it. You mentioned IPC. That's yet another potential point of breakage. I had to give my launch agent a user-facing entitlement just so I could resolve a security-scoped bookmark. If there is going to be some new type of "special" component to URLs, then it needs to be fully documented. When will developers encounter this? How can they test it? Can it be safely removed? That's really my question here. Can I just treat ".nofollow" like "." and strip it out? That would solve a lot of problems.