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]);

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.

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

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

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

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.

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

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];

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)

thanks!

Added note: in the Settings for iCloud under Optimize storage, it mentions: "If your phone is low on space, full resolution photos and videos are automatically replaced with smaller, device size versions. We want the smaller device size versions." Anyone know how to get these from photo kit to avoid the big icloud download delay?

if anyone has this issue, this seemed to be our problem: the iMessage switch in message settings has to be On for both devices when sending. if one device has iMsg off, live photos come thru as regular photos. if any one has any other ideas how to transfer live photos between users, that would be helpful.

another question has arisen on this issue. the PHImageManager seems to only return a UIImage. however, the noted API above requestContentEditingInputWithOptions works for live photos and videos also (and our code is using it for that) is there is there a similar fast replacement we can use for live photos and videos? e.g. to avoid the long download from icloud and just use local editions of these other media types? thanks again!

I guess another question would be, if we set networkAccessAllowed to NO would we get a reduced size (local to device) media or would we get nothing or error? (E.g. in our original requestContentEditingInputWithOptions call)  PHContentEditingInputRequestOptions * options = [[PHContentEditingInputRequestOptions alloc] init];                    options.networkAccessAllowed = YES; doc doesnt mention this issue: https://developer.apple.com/documentation/photokit/phcontenteditinginputrequestoptions?language=objc

i think i have traced the problem to drand48() system call random number generator which i use extensively it seems like when you use the drand48 function a lot in the block sent to dispatch, the various threads that run the block get serialized or otherwise jammed up because of this function, so your code doesnt speed up the the expected amount when you dispatch concurrent blocks and just runs the same speed or slower as on 1 thread (slower due to the extra overhead of other threads, dispatch, thread syncing, etc) the thing i found is that this slow down doesnt seem to show up in the Instruments app. it shows a little bit of drand48 taking up CPU as expected, but not huge.... since it is not using CPU power and is just waiting for other threads to handle memory access, i would guess. such waiting may show up in some portion of instruments i didnt look at. this post seems to get into the details of why this is occurring: https://stackoverflow.com/questions/22660535/pthreads-and-drand48-concurrency-performance will post a workaround. tentatively working on pre-generating some randoms in per-thread arrays or a global array using a per thread index. if you use a global index to pull from the pre generated randoms, it shows a similar slowdown as drand48