file uri scheme

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

This file confirms that we are indeed defining all the required keys (including kIOMaximumSegmentByteCount) before calling UserReportHBAConstraints, and it also demonstrates the SetProperties workaround we implemented to bypass the issue. Ahh, I see what’s going on. I believe UserReportHBAConstraints actually sets those values at the controller level (not the peripheral), and your ioreg snippet didn’t include the controller. Can you upload a full IORegistryExplorer snapshot just so I can confirm everything is correct? Aside from that, having read through the bug again, I think setting kIOMaximumByteCountRead/WriteKey on the peripheral is probably your best option. I want to double-check that with the engineering lead (he’s out sick today) just in case I’ve missed something, but I don’t think that will change anything. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

My current goal is to ship the PCIe DriverKit. I want my customers to be able to install our DriverKit without having to disable SIP or anything like that. Absolutely. Why is there a difference between the Apple Development value and the Developer ID value? The two different values happen because of the development only variant that's added to all accounts. (a) This is the development only configuration (which all accounts have): 0xFFFFFFFF&0x00000000 (b) And this is the specific configuration you were approved for, which is unique to your account: 0x00001916&0x0000FFFF Unfortunately, the portal and Xcode handling of these overlapping configurations doesn't work all that well. You can find a description of what's actually going on here. However, note that I don't think the flow described at the end of that post actually works today. However, according to the URL you provided, would manual signing using a provisioning file created with a Distribution Developer ID be better? First off, please file

Hi tnortman-jabra, May I ask what error you get when you're compiling your project with the entitlement? You get empty data and no notification with no entitlement in you project, correct? I would also suggest to file a feedback with providing more details about the issue (sample app would be very appreciated): https://feedbackassistant.apple.com

The URL link would be connecting to a SharePoint site and in that site the URLs are for the docx files themselves. Is SharePoint a server one that would cause issues with downloading docx files directly? Or would a login need to be taken care of in some way before hand?

Thank you for your post and the comprehensive description, including the accompanying images. It is intriguing to note that the button will be absent in iOS 26. Your application appears to be well-designed. May I request that you create a simple focused project where you can reproduce the same issue in iOS 26? The button disappears unless you add the key to the Info.plist file to disable Liquid Glass. If so, please share a link to your test project. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. Albert Pascual
  Worldwide Developer Relations.

Please tell what is the exact size of the image you try to load (read dimensions in image file information). Is it a png image ?

[quote='868298022, bims, /thread/806594?answerId=868298022#868298022, /profile/bims'] Looking at the ips-file I found that it does not show the finding that Xcode show [/quote] Right. Xcode has MTE smarts beyond what the human readable crash report shows. To see the underlying data, open the JSON crash report and search for memoryErrorReport. With some reformatting you get this: memoryErrorReport : { faultAddress:0x0c00000d9de112c0, blamedAllocation: { size:48, allocationTrace:…, deallocationTrace:…, isFreed:true, address:0x0c00000d9de112c0 }, errorType:use-after-free }, The allocationTrace and deallocationTrace backtraces need further massaging. I did a hack-ish job of that and have included the results at the end of this post. I wanted the JSON crash report so that I could run it through some internal tools. I was able to do the first part of that today. I was hoping it might point me at some known bugs. It did, but those were resolved a while bug and thus are unlikely to be the cause of this issue