I never said anything about anyone making any accusations. You posted your website and within a few seconds I could see there was more than one other website with an identical name.

I followed your instructions to the letter and it worked perfectly every time.

We are just other Apple developers. We don't know who you are or who owns the smarden.io website. Both are anonymized. There are other organizations that use the "smarden" name. At least one of them has a web site that is six years older than yours. How is Apple to know who really owns the rights to the "smarden" name? Apple isn't going to do that research. You will have to do the research yourself and submit documentation that confirms your global ownership of the name.

It's going to be a big challenge to port an existing project to SwiftUI. What you describe makes a lot of sense. Most people never encounter this error anymore because they are starting small, with a new project. That being said, you specifically said that you were "porting a project over to iPhone". I don't think trying to do that kind of massive port from a foreign architecture is going to be any more pleasant in UIKit. I recommend starting small, with a new project. Build the bones of your UI to match the old project. But don't attempt to port the entire thing at once. Follow the path of least resistance and write the code the way SwiftUI or UIKit expects.

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.

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.

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.

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.

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.

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.

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.

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.

You would probably find better responses in a CMake forum.

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.

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