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

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.

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.

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

Thanks Quinn. Adding the --forkCorpse parameter does indeed make the message go away, which I guess is a good thing. But I now occasionally get messages like this: leaks[60595]: [fatal] Malloc enumeration of zone "MallocStackLoggingLiteZone_0x113eb8000" failed to get full information about malloc metadata and/or allocations with the error "(os/kern) failure (5)". It is likely that the target was suspended while malloc metadata was being modified. It appears that leaks itself is crashing in this case. Any idea what might be causing it or how I can prevent it?