Is anyone else having these issues? Nope.

According to Apple's built-in dictionary app, "e.g." is from the Latin "exempli gratia ‘for the sake of example’". However, you haven't mentioned what kind of app you have. It's curious, when developers get an app rejected for spam or some other criteria, they'll often include 4-5 paragraphs going into great detail about their app and why it shouldn't have been rejected, as if we could overrule App Review. But usually, their description only serves to support App Review's rejection. To be clear, I'm not asking for 4-5 paragraphs. But a couple of sentences might be useful. All anyone knows at this point is that you seem to think your app would be rejected. You know your app better than anyone I suppose. Never forget the "living document" clause: "This is a living document; new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this."

Maybe post a very simple demo file that reproduces the error. All of those headers look like ancient versions with the ".h".

After a few frustrating hours of experimentation and Google searches, all failing That is the path to frustration and failure. I'd prefer it to be in the /usr/local/bin folder, but that's apparently not an option anymore. Or am I wrong? You're wrong. It can be anywhere you want. But you have to remember that Apple's toolchain is not designed for personal apps. Xcode is designed to build apps that will be distributed to end users. The Command Line Tools are intended to build command line tools locally. Your usage doesn't fit into either of those categories. You're building an app. But you're sandboxing it, as if you were going to ship it in the Mac App Store. Because you are building it for the Mac App Store, you have to conform to those expectations. But if you don't ever intend to distribute it in the Mac App Store, then you can adjust your expectations. You can turn off sandboxing. Because you seem to be incorporating a 3rd party tool, I strongly recommend this option. As I've said repeatedly, you don't know if this tool will work properly in all situations when run from the sandbox. More generally, there are still other methods to directly access any path or executable. If you're not distributing in the Mac App Store, but you want to keep the sandbox turned on, you can simply give yourself a sandbox exemption for this path. Another option is to provide a simple UI to allow the user to directly pick a file in /usr/local/bin, or anywhere else for that matter. You might even be able to do this in the Mac App Store. There are many options, and they are all documented, just not on the internet.

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.

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.

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

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.

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.

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.

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

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.

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

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.

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.