thanks!

fyi i tried to export the binary from xcode then used the mac app Transporter (avail on mac app store) to upload, and it worked right away (e.g. showed up as "processing" on app store connect site)

fyi we had an apple office hours meeting to address this, this is the first part of the solution we found based on those discussions pixel format needed to change, and 3 dictionary key values added to AVAssetReaderTrackOutput outputSettings: argument per below with these, the UIImage seem to come out much better but we havent done a full check yet the next step is to get these images written back to a video file w/o losing their color again this is just a code snippet, if anyone needs to full code we can post the full xcode sample as we have extracted the buggy dolby stuff into a small test case the info about the color properties (noted below) we had found previously in the apple docs about this technology, but it also needed the updated pixel key to cause any positive effect on the outputted images. that part was not clear from the docs immediately. NSArray* video_tracks = [asset tracksWithMediaType:AVMediaTypeVideo]; AVAssetTrack* video_track = [video_tracks firstObject]; NSMutableDictionary* dictionary = [[NSMutableDictionary alloc] init]; // kCVPixelFormatType_32BGRA // this was the what we had // 420YpCbCr8BiPlanarFullRange // this is the correct one (see next line) [dictionary setObject:[NSNumber numberWithInt:kCVPixelFormatType_420YpCbCr8BiPlanarFullRange] forKey:(NSString*)kCVPixelBufferPixelFormatTypeKey]; // this is also needed dictionary[AVVideoColorPropertiesKey] =             @{AVVideoColorPrimariesKey:                 AVVideoColorPrimaries_ITU_R_709_2,             AVVideoTransferFunctionKey:                 AVVideoTransferFunction_ITU_R_709_2,             AVVideoYCbCrMatrixKey:                 AVVideoYCbCrMatrix_ITU_R_709_2};         AVAssetReaderTrackOutput* asset_reader_output = [[AVAssetReaderTrackOutput alloc] initWithTrack:video_track outputSettings:dictionary];

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.