build disappears

I have previously referred to PTPPassThrough, but there is no example of sending the outData parameter, and I have not found it on Apple forums or online. So, I did find some test code of ours that does use outData. I can't directly provide the code, as it's part of a multi-layer architecture which means that code can't easily be provided. However, what I can say is: The way you've built out the structure generally appears correct. Every operation we send has type set to 1. It's actually hard coded into the method that builds out USB data packet. Nothing special is done to handle outData. The data object is built out as a separate data object and then included with the request. Finally, on the actual command you're sending, I don't know what the command format for 0x9205 actually is, but I don't think this is correct: unsigned char specialData = 1; NSData sendData = [NSData dataWithBytes:&specialData length:1]; As far as I can tell, the main reason the extra data approach is used is to provide a

tried to restore purchase Are you calling restoreCompletedTransactions() to restore your purchases? If yes, this method doesn't return in the following situations: All transactions are unfinished. The user did not purchase anything that is restorable. You tried to restore items that are not restorable, such as a non-renewing subscription or a consumable product. Your app’s build version does not meet the guidelines for the CFBundleVersion key.

@seanodonnell , @ToniMC Thank you for your Feedback reports. Please update your reports with a link to your failing build so our team can investigate the issue.

From restoreCompletedTransactions(): This method has no effect in the following situations: All transactions are unfinished. The user did not purchase anything that is restorable. You tried to restore items that are not restorable, such as a non-renewing subscription or a consumable product. Your app’s build version does not meet the guidelines for the CFBundleVersion key.

Does version mismatch affect already released builds? We have submitted an update using an Xcode RC build (17A321) after the keynote, the latest build number of Xcode is 17A324. I wonder if simply resubmitting will fix the crash.

Quinn asked me if I could take a look at this, and I have to say this is going to be a tricky one to track down. Let me start with the basics of what's going on. Pulling from your first crash log, here are the crucial details: Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000000000000 Exception Codes: 0x0000000000000002, 0x0000000000000000 ... Termination Reason: CODESIGNING 2 Invalid Page ... Thread 4 name: Dispatch queue: assetsQueue Thread 4 Crashed: 0 ??? 0x0 ??? 1 Video Star 0x1012b34b0 __28-[ClipMixerView asyncRender]_block_invoke + 512 2 ...g_rt.asan_ios_dynamic.dylib 0x10559adf4 __wrap_dispatch_async_block_invoke + 196 3 libdispatch.dylib 0x19aacaaac _dispatch_call_block_and_release + 32 4 libdispatch.dylib 0x19aae4584 _dispatch_client_callout + 16 5 libdispatch.dylib 0x19aad32d0 _dispatch_lane_serial_drain + 740 6 libdispatch.dylib 0x19aad3dac _dispatch_lane_invoke + 388 7 libdispatch.dylib 0x19aade1dc _dispatch_root_queue_drain_deferred_wlh + 292 8 libd

Thank you for your post. As per the crash file recommendations, please file a bug against the sample. Include the crash file in the report and provide a link to the sample you used. Additionally, please provide the versions of the sample and the build numbers. Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Thanks again for your help on this one. Albert Pascual
  Worldwide Developer Relations.

This is happening to our team as well. We had a build run overnight last night, stuck archiving. As well as several yesterday that ran for many hours (more than 2 hours) and had to be manually canceled. It was failing because the version string in our Info.plist was the same as an approved, Pending Developer Release version submitted on App Store Connect. We received (and missed) emails about this, until one of us noticed them this morning. Usually that sort of failure is reported in Xcode Cloud logs, and results in a failure of the job on-time. We should be refunded for the hours that the job spent idling, however applicable. Feedback assistant ticket: FB20279578

@storj Cool story. For whatever reason I'm not getting email notifications when people respond to my threads. Still think it would be great if building with the 'Debug Configuration' caused the same permission error to accurately simulate the behavior you'll get in the wild but maybe there is a good reason why Apple doesn't want to do this. I dk.

Thank you for your response! Attached are some crash reports that represent attempts to merge in two separate branches that take our relatively stable (not crashing in the ways described above) main branch and introduce (or reintroduce) the observed crashes. Also, ASan is enabled for two out of four of the reports (one per branch) and disabled for the others. Did you try doing this incrementally? If you have a bunch of them, it’d be interesting to see which combinations do and don’t reproduce the problem. I will try this, but one of the primary issues with tracking these crashes down has been not knowing if/when they are truly eliminated as they tend to come and go after minimal code changes. It seems that almost any change to the code, or which files/libraries/frameworks are included in the build will change how the crashes manifest, or in some cases do not manifest. This is a bit of a long shot, but are there any things in particular (in crash reports or otherwise) we can look for in the future tha