file uri scheme

You can find my general advice for problems like this in Investigating Third-Party IDE Code-Signing Problems. But I also want to address this specific point: [quote='809448021, nickblair, /thread/809448, /profile/nickblair'] I can create an ipa file with vs using the wildcard bundle identifier [/quote] There’s no such thing as a “wildcard bundle identifier”. A bundle ID is always explicit. If you’re trying to use a * in your bundle ID, stuff is not going to work. There is such a thing as a wildcard App ID, but App IDs and bundle IDs are not the same same thing. An App ID is a key input to a provisioning profile; it determines the apps to which that profile applies. I talk about this more in TN3125 Inside Code Signing: Provisioning Profiles. A wildcard App ID creates a wildcard provisioning profile that authorises execution of all App IDs that match the pattern. However, each app’s bundle ID, and hence its App ID, must be explicit. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @

The first error in that list is the most significant. In the App Clip view of the universe, every App Clip has a parent app, that is, the app in which it’s embedded. Xcode is having problems figuring out the App ID of that parent app, and things go wrong from there. If you create a new app from the built-in iOS > App template and then create a new App Clip target within that, you’ll see that Xcode creates a .entitlements file for the App Clip that lists the parent app in the com.apple.developer.parent-application-identifiers entitlement. I recommend that you check that that’s set up correctly in your real project. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Not for us, unfortunately. The issue is present throughout iOS 26, 26.1 and 26.2. Multiple radars filed already, but no response / fix in sight. [quote='868578022, kgaidis, /thread/793747?answerId=868578022#868578022, /profile/kgaidis'] iOS 26.1 seems to maybe have fixed it [/quote]

I have filed a request as well: FB21274407

Thank you for the crash file. However, it appears that the crash file is not symbolicated from your symbol file. The crash occurred in thread 0, but there are 16 frames for the project ProjectiOS without symbols. Kindly submit a comprehensive crash report, adhering to the guidelines outlined in Posting a Crash Report. https://developer.apple.com/forums/thread/688669 Hope this helps Albert Pascual
  Worldwide Developer Relations.

Update: I just tried replacing the child progress with a URLSessionDelegate that updates the progress completedUnitCount directly, and it seems to be more stable (but I only tried this once). Potentially a bug with using Child Progresses to keep alive BGContinuedProcessingTasks? Yes, that's very likely. This is something that should work, but there are also a lot of edge cases and details to cover. I expect this will improve over time; however, please file a bug on this and post the bug number back here. Having said that, my other question is what does the progress UI look like during this time? The primary purpose of progress here isn't to keep your app awake; it's to make sure the user knows what's going on. Similarly, I suspect the big problem here isn't that your task is expiring; it's that your progress bar isn't showing any progress! __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Also, in the past I have done extensive testing with 'AVCaptureVideoPreviewLayer'. My understanding is that you can only ever have one 'AVCaptureVideoPreviewLayer' in use, is that right? In my use case the Live Video from a UVC Capture Card (AVCaptureDevice) needs to be displayed on the iPad Screen as well as the External Display. There seems to be something special about 'AVCaptureVideoPreviewLayer' as it has the least delay from Capture Device to the Screen. When I try to implement any other way of displaying the image from the CMSampleBuffer there is always more delay than using 'AVCaptureVideoPreviewLayer' directly. Around 1fps is the delay from my measurements. I ended up ditching 'AVCaptureVideoPreviewLayer' due to this dual use limitation and moving a to fully Metal backed pipeline. The CMSampleBuffer is converted to a MTLTexture and this is used for the iPad and the External Display. This also allows for other GPU Backed Functionality like LUTs, False Color, Focus Peaking, etc. The only trade off is t