Has anyone else had this happen to them? I see at least 2-3 identical questions every day. If so what was the resolution? No one ever knows. You would think that with 700-1000 identical questions per year, at least one person would follow up with what happened, but I haven't seen it.

What do you need these metadata files for? More specifically, do you need these metadata files or do your users? I deal with the same thing with GIS files. In my case, I have some open-source libraries that want to automatically write those metadata files. Obviously that fails in the sandbox. But what I've been able to do is define an alternate location for these sidecar files. In my case, the library already supports a "PROXY_DIR" environment variable for read-only locations. So I just used that. I could have also hacked up the source, but I got lucky. What this means is what when various legacy software bits want to write a sidecar file, it always succeeds. It writes the sidecar file in an appropriate location inside my app's sandbox container. Then when other bits of the legacy software look for the sidecar data, it's there and always available. If I needed to export the sidecar files (which I won't), I could do that by allowing the user to specify an entire output directory and write all necessary files under a pre-determined name.

It looks like there is a name conflict between a SQLite framework and the latest version of Swift Foundation. They both use the term "Expression", but they are radically different. It sounds like you need to write "SQLite.Expression" instead of just "Expression". That should fix it. See https://github.com/stephencelis/SQLite.swift/issues/1269

Does it matter? Suppose you publish app with the iOS 17 SDK and it's a big hit. But then you find a critical security bug. You have to update the SDK to iOS 18 to submit the fix. But now it won't build. So why not build and test with iOS 18 today and avoid the problem altogether?

Don't use the "Comments" feature. Just add a new Reply to the end. Unfortunately, everyone already assumed you were using SwiftUI. You need to show the actual code.

Can you clarify the warning? Does it say the app was downloaded from the internet and no malware was found? Or does it say something worse? If this is an app downloaded from the internet, then it's going to say it was downloaded from the internet. No way around that unless you want to put it in the Mac App Store. If it is just an app, then there is no reason to put it inside a DMG. Just compress it into a zip file. I have no idea what you mean by "complete codesigning using the third-party app itself—not via command-line scripts". Are you saying that you didn't use Xcode to build the app? If so, then you're on your own. You are totally at the mercy of whatever tool you are using to build the app. These things are a single button click in Xcode.

If it's GPL, then fix it. That's literally the whole idea.

There is no meaningful concept of "the binary". The entire app bundle is signed. If you change any part of the app bundle, you must also replace the signature with a valid one for the new bundle. Replacing an entire app is a bit tricky as there are OS-level complications. The recommendations I've seen here on the forums are to duplicate the existing app bundle, swap out the parts, then move the new app bundle into place. But that's really a lot of pointless work. Just post a new app bundle and let the user replace the old one with the new one.

Your toolchain is corrupt. You've installed some 3rd party framework that has dependencies on the botan project.

What are you trying to do - at a high level? The application sandbox restricts access to certain paths. That's the whole idea. If an executable is already part of the operating system, then you can probably access it. However, command-line tools may not run properly from the sandbox. Normally what you would do in this situation is include the "codeview" binary, if possible. Another option would be to give the user the option to specify executables to run. Then the user could select that path in /usr/local. But again, you have to hope the tool works when running in the sandbox.

Can you post a simple snippet that reproduces the problem? A common cause of these problems is including some 3rd party project in your include search path. It may have its own versions of some of these files and that is breaking your compilation.

I'm already an experienced software engineer, just new to iOS/MacOS development Those are two radically different environments. Most of your question seems to pertain to macOS. But you said you're new to the platform, and learning how to swim by diving into the deep end. My problem is not learning the language, but rather how to learn modern best practices. What do you mean by "modern best practices"? It would really be helpful if you provided some context. Do you have a contract and funding to write this macOS network app? If so, then there do exist some older documentation and newer tips on Apple-approved ways to accomplish this task. But unless someone is already paying you a lot of money to do this, I wouldn't even call it a "good idea", let alone a "best practice." What's the current best practices on how to write and launch a daemon? You mentioned a network extension. It would be a better idea to start your search there. Network extensions are a relatively new artifact that is relatively well-understood, documented, and supported in modern versions of macOS. If you go looking for daemons, you're likely to get stuck in ideas from a decade ago, if not older. I'm not even sure you should be using a daemon at all. Should the daemon be its own library/package which is them imported into the main app? If so, which Xcode template do I use for this? Are there any Hello World! examples of this? This part is easy enough. Modern best practice is to bundle all of this inside the app bundle. You start with an app and then add a "network extension" target. The "best practice" would be to start with a WWDC video on modern network extensions. Note that "modern" is becoming a shorter and shorter timeframe. It's almost measured in months at this point. What is the best way for a UI app to communicate with a daemon? Again, forget daemons for now. Are there any Hello World! repositories on how to implement network extensions? Should this be done in the main UI app, or in a separate library/package? I strongly recommend starting with a WWDC video. I'm sure there are many. Network extensions are an absurdly popular thing these days. Then look at the documentation.

knows what could cause it? Knows? No one here knows anything about your app. Don't automatically assume it's a system bug.

For example, when researching daemons, it looks like their are multiple folder paths to put them in as well as multiple ways to launch them. How am I supposed to know which is considered best practice? I was actually hoping to get more context regarding the app your are trying to build, other than "network extension". What is this app supposed to do? As I said before, this is an advanced topic. The documentation is targeted to people building various kinds of low-level system modifications. That can be confusing if you don't need to do all of those things at once. The current best practice is to bundle both the daemon and the launchd config files (as well as everything else) in specific subdirectories inside your app bundle. Apple changed the design in macOS Ventura. In the past, it was customary to scatter all these bits in various places. You're specifically asking about "most recent best practices". Most of the advice you'll find on the internet is out-of-date and misleading. Here is a link from the documentation. No contract. No funding. I'm writing this in what little spare time I can claw and scratch for myself. Best practices have changed over the years due to technical, social, and market considerations. Most people are actually seeking something more than simply writing code. The documentation and the APIs themselves are designed for people looking to distribute software to others.

Even disabling SIPs and logging in as the root user, I was unable to copy the file or any file to /usr/bin. That's some serious security. So why is there even an option to disable SIPs at all if I still can't change these areas. There is more to SIP than just directory permissions. In the past, you could have done this by disabling SIP. Apple is a curious case of the Schrödinger's company. It is both alive and dead. Everyone is obsessed with having the very latest version of every Apple software update. But at the same time, they expect that nothing has ever changed, or should ever change, in the operating system. At least, this is the perspective from the internet at large. When developing for Apple platforms, it is better to use the current documentation from Apple instead of searching the internet. The internet is a source of frustration and misinformation. Also got it to work by setting App sandbox for any of the user folders: Downloads, Pictures, Music, and Movies to "read only" or "read/write". (see photo). and move the utility to one of them. But this is not where I wanted it to be. This is not a viable solution. Unfortunately, since you've just posted it on the internet, someone in the future is going to try it and then get frustrated when it gets rejected by App Review. Interestingly. I created a command line utility to test this separate from a sandboxed app, and it worked just fine from /usr/local/bin. Yes. That's how the sandbox works. But don't get too excited. Turning off the sandbox does enable access to more locations in the file system, but not all locations. I would prefer to have it in /usr/local/bin, which is where I have several of my own command line utilities. This way, it's in the path and I can use it in a terminal window and from within my APP. You can always modify your path. But I want to re-iterate that this app might not function properly in the sandbox. Consider the difficulty that you've had when trying to run your app from the sandbox. The developers of the "codeview" app have probably never tried to run it from the sandbox. If you experience any problems, they will be unable or unwilling to help.