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.

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

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."

Is anyone else having these issues? Nope.

Based on your quote and description, I would agree with your interpretation and confusion. But it is important to remember power discrepancies in any relationship. For all but a few developers, Apple holds all the power and can interpret "e.g." to mean whatever it wants. I'm curious now. App Review says that they have resolved your issue. What was the resolution? What does "e.g." mean in the context of the Apple App Review Guidelines? Does it mean "for example" or "specifically"?

That's for the detailed follow-up! I suggest submitting a bug report against the wording on the guidelines. I think that "e.g." should be changed to "specifically". I think this is one of the under appreciated aspects of App Review. They are an unbiased, outside set of eyes looking at your product and website. If they're confused, then end users likely would be confused too.

You would probably find better responses in a CMake forum.

Can't comment on any CMake issues. I've used CMake enough to consider it worthwhile to burn a whole day just to port the build environment to Xcode. That makes so many problems go away like magic. However, in this case, CMake seem irrelevant. You can construct an app bundle with as many executables as you want. If you put them in the wrong locations, that could cause problems with code signing, notarization, and/or App Store submission. But otherwise, there's literally no limit. But why even do that at all? It's not hard to make an app that runs totally on the command line, if you provide the correct commands. I have an app that does that. I just have to provide a "--headless" argument to trigger command-line operation, or "-h" to show command-line help. If I don't have either of those two arguments, then I let the normal app launch process run.

Lots of people write apps that connect to their web servers. I think it's pretty unusual when an app doesn't do that. Internally, Apple is really old-school, big-iron corporate. I don't know specific details of specific products, but Apple's a big company, so there are lots of them. Generally speaking, if a 3rd party corporate networking/security app was a Big Deal 15 years ago, Apple probably still uses it today. Probably the two most important things to check are IPv6 and SSL. Make sure your app works in a purely IPv6 environment. Curiously, this policy is 9 years old now. Apple has a solid track record of announcing major changes 9 years before making a hard change. People who ignore those warnings because their app is working fine then get blindsided years later. Also, Apple can be very strict about SSL certificates for its own use. It really doesn't matter if your website works great in Chrome. It might not work from an Apple app or from an Apple internal network. People who roll their own SSL certificates are more likely to encounter this problem. I recommend checking your site with SSL Labs (http://www.ssllabs.com/ssltest/). Even if you get an A+, double-check the details against Apple's published specs like this one and this one. I'm not saying these are the same requirements as Apple internal networks. Apple is a black box. I have no idea what goes on there. But this is something you can check without going through App Review. Send yourself an e-mail containing HTML with images hosted on your site. If Apple Mail won't display the images, then this could be the reason.

Those are archives, aka static libraries, not frameworks. The only possible option is to embed them into the code itself. But even if they were frameworks, you can't embed one framework into another. That would be an umbrella framework which Apple discourages and/or disallows.

The command line version of the app is structured quite differently from the GUI and is already written and working. The entry point for both is the same - the "main" function. It's trivial to check the command line arguments at that point and do either one or the other. Here's my main() function: #import <Cocoa/Cocoa.h> #import "HeadlessController.h" int main(int argc, char * argv[]) { if([HeadlessController isHeadless: argc args: argv]) if(NSApplicationLoad()) { @autoreleasepool { HeadlessController * controller = [HeadlessController new]; [controller run: argc args: argv]; [controller release]; } return 0; } return NSApplicationMain(argc, (const char **) argv); } The only problem would be if both sets of source code share some symbol names. Ideally, most of the code would be UI-agnostic. The command line version would call it directly, maybe with a text-based progress. The GUI version would call the same code with a Cocoa UI. I've just spent weeks porting from Visual Studio/msbuild to CMake so we can build for Win/Linux/Mac using ONE tool. So I really don't wish to convert the build to XCode. That's unfortunate. Just remember that Xcode people don't speak CMake and vice-versa. When you have problems with CMake, you'll be on your own. These two camps really don't get along. I understand you're not willing to switch at this point. But do keep it in mind if you have problems in the future. I've ported a lot of open source projects into Xcode from autotools, CMake, and some even more complex Google build systems. When targeting Apple platforms, Xcode make so many problems go away entirely. Don't spend days or weeks on a build problem when you can just make it go away in a single day. Should I put the command line version into the SharedSupport directory of the app rather than the MacOS one? I think it would be more appropriate for the "Helpers" directory. Here is Apple's current documentation on the topic. I do see a "SharedSupport" directory referenced in Apple's archived documentation but the description of ("non-critical resources that do not impact the ability of the application to run") seems to preclude executables.

Maybe take a step back. Perhaps the answer is social rather than technical. Mac users aren't like Windows or Linux users. It's unlikely they would ever discover a command line tool regardless of whether it's integrated or where it lies in the bundle. There are Mac command-line tool users. If you want to find them, go to where they live. On the Mac in 2025, for better or worse, that's Homebrew. I don't know if your code is open source or not. But Homebrew does have a system for installing binaries. Otherwise, your market pool for Mac command line users who aren't running Homebrew is essentially just me. 😄 This way, users don't have to worry about creating a .zshenv file. Homebrew handles all of that.

Regardless of whether you are using SharedSupport or some other resources folder, there are a number of different ways to access them. Your first problem is going to be language. It's a Swift world now. If you're writing a Swift app, then all these APIs are easier to use, at the cost of a bunch of new Swift-isms. But I'm guess that's a non-starter in this case, so I'll move on. Swift or not, the Mac development and Xcode is not C++ friendly. There are a couple of different ways to approach the problem. You can use the old C APIs. These are referred to as "Core Foundation" and virtually always have a "CF" prefix. This kind of code is clunky and hard to use. I really only mention it in case you find it on your own so you know to avoid it. A much better idea is to release your grip on C++ just a little bit and use Objective-C. You might even consider Objective-C++. The trick here is to make sure that your pure C++ code never sees any Objective-C code. While Objective-C++ can speak both, plain C++ cannot. So you can write some public headers that define some C++-friendly functions you can call. Then, you pair that public header with a private Objective-C header/source set to actually get access to these folders. It sounds more complicated than it is. This is the easiest way - trust me. ARC alone is worth it. And getting your strings into C++ will be much easier. At that point, you can access any of those bundle paths through the "NSBundle" class. This class is stable, well-documented and relatively easy to use. Most such code is "toll-free bridged" with a Core Foundation counterpart. So compare the NSBundle methods with their "CFBundle...." versions. As I mentioned before, you're probably looking for path strings. That will be much easier with NSStrings than CFStrings. There is also a different set of functions for the various accessing application support folders that might exist in a "Library" folder. These belong to the "NSFileManager" class. Look for the "URLsForDirectory" methods. I assume there is a CoreFoundation version of these, but I don't know about them. These methods are a little trickier to use. You have to specify domains and results are arrays. Plus, you're expected to create folders if they don't already exist. It's a lot of boilerplate and error handling.

App Structure: A native Swift/Obj-C wrapper app that launches a nested .app inside its Resources. Can you elaborate on that? Can you describe the full structure of the top-level bundle? You should definitely never put executable code in the "Resources" folder.

That tutorial is based on Pixar code. Plus, it dates from WWDC 2022. Try reverting your Pixar code to something closer to that timeframe - June, 2022. Sometimes very active open source projects like this will break tutorials that were written at some point in the past. If that doesn't work, you'll probably have to ask on the Pixar Github site. There isn't a lot of cmake information available here. It could be something simple. I'm surprised to see cmake being used in an Apple tutorial.