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.

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.

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.

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

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.

It would help if you could clarify some things. First of all, passing arguments to an app is very unusual. I support it in one of my apps, but I'm pretty sure that virtually no one has ever used that feature. There was also a recent thread here where an Apple engineer suggested that command line operation may be incompatible with linkage of UI frameworks. Add to that the fact that you are doing something with UIElement. Plus, you are running all this through the "open" tool. Does it behave the same if you directly launch the executable with your arguments?

It is but not totally out of the ordinary. It is totally out of the ordinary. I would like to be more "mac arsed" in my app development. I don't know what that means. It might be helpful to remember that the entirety of the macOS platform is an outlier. It constitutes 8% of Apple's sales, and probably a smaller percentage of profit. Apps run on iOS. If you're flush with cash and have time to burn, maybe you can play around and port your app to the Mac. But ain't nobody going to be using any command-line arguments. I'm also aware that there is a potential conflict with things like using -AppleLanguages to change the language an app is launched in so there is some pre-processing going on by the OS that is parsed before an app is launched fully but again That's a debugging flag. The Cocoa/AppKit frameworks do some parsing of command line arguments. However, they do that as part of NSApplicationMain(), which takes over completely. There also exists an NSApplicationLoad() that command-line apps would typically call so that they can use most Cocoa/AppKit system functionality, or maybe construct their own run loop. --args is available to be used, whatever macOS is doing should be able to handle that and just pass through arguments array into the app. --args is just an argument to the "open" tool. And it works fine, as do command line arguments if you run an app directly. I don't know what problem you're having, but it isn't any kind of system-wide problem and isn't related to any Xcode version. I don't want to discourage you. Clearly there is something very wrong with your setup. It would probably be worthwhile to find out what's causing the problem. Command line arguments are irrelevant. But there is a risk that whatever is going wrong could affect some important functionality. Virtual machines are useful for testing code. But I wouldn't recommend installing Xcode in one. Xcode is for a real machine. But also, once you install Xcode on a real machine, it isn't a real machine anymore. It's now a "developer device" whose behaviour may not be the same as an end-user's device. Virtual Machines can be useful as a quick-and-easy end-user, non-developer device. Ideally, you would also test on a real machine that has never had Xcode installed. You had mentioned that "my device is corporate owned so has MDM enrolment, AV, and other paraphernalia". I strongly encourage you to focus your attention there. Don't forget the network either. Your corporate network is probably also non-standard.

is it known issue for Apple team? No. Nobody uses iOS 12 anymore, so nobody knows of any issues when it runs apps built with Xcode 16. In Xcode 16, I can't even set a deployment to anything earlier than iOS 15. to resolve this issue, what can we developers do? You can drop support for anything before iOS 15, or Use an older version of Xcode.

Just use unicode characters for 🐒🦜🐁 emojis right in the source code.