thanks, do you know if you can change the yellow part of it to another color?

ah ha, interesting on my backwards interpretation of hardened runtime. thanks for that clue. from the above apple "embedding a helper tool" doc, i was able to get past the issues with the runtime entitlements (i think...), but then got stuck on a dlopen( ) (dynamic library open?) issue with the main Python library. it looks like some others have reported this issue as i was looking around online, but i havent found a solution that works for me yet. at least i made some progress.

it seems that apple policy is to not allow what i asked for earlier (code signed only). you have to do the whole hardened runtime business for all sub-executables unless you want macOS to flag your app as potentially harmful fyi if anyone is looking for similar, i found this, seems fairly descriptive but non trivial as they say https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app?language=objc started going thru it the trick seems to be the step where they talk about adding a new copy files phase and 'check the "code sign on copy" button' but it looks like it will require some trial and error for my particular case

having same issue, need to do some cleanup when mac app is closed, saw this hint on a stack overflow post https://stackoverflow.com/questions/8193305/applicationwillterminate-not-called add this function to the mac app delegate, and then the applicationWillTerminate: method is called -(BOOL) applicationShouldTerminateAfterLastWindowClosed:(NSApplication *) sender{ return YES; } i havent tested all cases e.g. user kills an app with kill -9 or something like that, i just checked the window close case at this point (you may need to set both of the aforementioned info plist values in the other chat responses here to NO. I have them set to NO. i did not go thru testing iterations with those plist values. one or both may not be needed.) see attached screenshot for plist settings i used. Update: If you use normal quit from Activity Monitor, this solution traps the exit. If you use force quit, it does not (which kind of makes sense). (That may be the kill -9). also, an app crash doesnt seem to trigger the WillTerminate test: // at end of did finish launching:        [self performSelector:@selector(forceCrash) withObject:nil afterDelay:10]; -(void)forceCrash {   int *x = NULL;   int y = *x; } so, at least normal app close is handled

a good answer we found was: use Transporter app avail on mac app store instead of xcode to upload binaries. much more stable.

try the Transporter mac app (avail on mac app store i think) for uploading binaries to app store. seems much more stable and faster than direct xcode upload. only allows 1 login at a time but, meh, good enough.

for anyone interested in trying to trace weird AV errors, we ran across these methods on AVPlayerItem which seem like they may give more info AVPlayerItemAccessLog * accessLog = [_playerItem accessLog];          AVPlayerItemErrorLog * errorLog = [_playerItem errorLog];          NSString * errorString = [[NSString alloc] initWithData:[errorLog extendedLogData] encoding:[errorLog extendedLogDataStringEncoding]];         printf("video error string = %s\n", [errorString UTF8String]);

note: we traced what was causing this, if any one sees the Cannot Open error. It was a zero length cached version of the mp4 file.

update: binary upload just worked. it failed several times this morning with aforementioned request timed out.

FYI to Apple: getting a big red X and "request timed out"

We would also be interested in the answer to this, e.g. if the 3 packages have the same or similar functions, which is faster on which devices.

now the test flight downloads seem to be working again. strange.

the AVMetadataItem writing indeed seems fraught with peril. i tried a bunch of examples with basic stuff like title and description in the "common" metadata family, and none of them seem to write data to the file using AVAssetWriter for mp4 files. checked by mpls command line. does anyone know the difference between the .key and the .identifier ? i see examples with .key and examples with .identifier. why we should use one over the other = ?

update: user can now download the app (we get the download progress meter and it proceeds) but the app disappears immediately after download and instead of the Open button showing in test flight, it goes back to the Update button. so still no-go.

continued: this is the error we get fairly often (same file works other times). this is a file from the photos folder. Error Domain=NSCocoaErrorDomain Code=260 "The file “IMG_2685.mp4” couldn’t be opened because there is no such file." UserInfo={NSFilePath=/var/mobile/Media/DCIM/102APPLE/IMG_2685.mp4, NSUnderlyingError=0x281af1cb0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}