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!

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.

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?

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.