See if this works. Thanks. https://gist.github.com/hecht1962/34e35e4917da2d10fb66e2c88d299b51

I'm happy to share it. I tried to add it as a file enclosure, but this system doesn't seem to want to let me do that. And it's too large to paste as text.

Here are straw man answers to my own questions. I'm still hoping someone can give me better answers. Just open the binary file and read the first few bytes of it. Traipse through the cafe babes and the feed faces to find the cputype, then check it against the defined values for arm64 or x86_64. The formats are defined in <mach-o/loader.h> and <mach-o/fat.h>. Another possibility would be to do a preflight dlopen(); if it works, you know the binary contains your current architecture. But that possibility won't work for me for other reasons. Don't use NSTask. Use posix_spawn, giving it a posix_spawn_attr that contains a posix_spawnattr_setbinpref_np, into which you can put the cputype you prefer. This is much more complex than using NSTask, and I can see why it hasn't been added to that class, but I sure wish it was. In my case, I will take the more pragmatic approach of just creating two non-fat binaries, one for each architecture. Then I can choose which one I want to launch, and do so using NSTask.

To answer my own question for posterity, I did find this: ips2crash But ultimately, I ended up writing my own with Perl.

I managed to install on a thumb drive, but I'm not able to boot. I just get a gray screen with an arrow cursor. I even let it sit overnight with no change. I saw in the release notes about problems installing on an external volume. Can anyone elaborate on this?

Thanks Quinn. I reviewed the linked thread and, other than a wish that there were an API to modify the DYLD search paths at runtime, I didn't see anything that would help me resolve my issue. I think the answer to my question, "Is there a way to get dyld to honor changes to DYLD_LIBRARY_PATH made at runtime?", is "No".One possible workaround that I thought of, however, would be to change DYLD_LIBRARY_PATH, then exec a child process that calls dlopen() and interacts with the library (MATLAB in this case) for me. Would that work -- would the child process get my modified DYLD_LIBRARY_PATH, or would it just use the same path as me?

Thanks John. We don't distribute R with our app. But we can optionally call it if the user has downloaded and installed it. So us building our own framework is not feasible.

Quinn, thanks for the research on this. Very helpful!

I found the answer.In my target's Build Settings, under Build Options &gt; Validate Workspace - Ignored Frameworks. I add an item "OpenGL".SummaryList of framework names for which to suppress deprecation warnings and missing framework errors in the workspace validator.DeclarationVALIDATE_WORKSPACE_SKIPPED_SDK_FRAMEWORKSValue TypeString List