file uri scheme

Thank you for your post. If you disagree with the outcome of the review, we recommend submitting an appeal to the App Review Board. When filing your appeal, make sure to: Provide specific reasons why you believe your app complies with the App Review Guidelines. Submit only one appeal per rejection. Respond to any requests for additional information before submitting an appeal. Once you have submitted the appeal we can escalate it to the App Review Board for review. The App Review Board will contact you directly as soon as they've completed their investigation.

If you haven't already, please file bugs on this and then post the bug number back here. Answering your question here officially: So, my question is, which settings are actually correct to enable the Enhanced Security and the Additional Runtime Platform Restrictions? Xcode is using the correct values: com.apple.security.hardened-process.enhanced-security-version 1 ... com.apple.security.hardened-process.platform-restrictions 2 For obvious reason, App Review uses an automated system to validate that entitlements have the correct value and format, and that's what's causing the rejection. They're working to sort that out now. I'd try replying to them and link them the documentation pages, asking them to double check. Unfortunately, it doesn't help that the documentation has issues (r.162641480) as well and claims that one of those values should be a string. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Sorry for the late reply to this, it was outside of the areas Quinn and I normally monitor and we both missed it. In any case, some additional questions were passed over to me through a DTS ticket, so I'm going to answer your questions above and then the other questions that were passed to me. (Splitting posts for length) First of all, as a general comment here: I am looking for alternatives and was previously under the impression that if we were to move to a DMG then that would provide the user a better user experience for moving it. So, one thing to understand here is that the pattern of using disk images for software distribution is primarily a holdover of what is now ancient history, not technical merit. It started when software was being distributed on floppy disk as the easiest way to exactly duplicate the contents of the original floppy disk. Originally, these images couldn't even be mounted, so their only purpose was to be written back out to physical media. That pattern was then carried over to CDs a

@Gernot Do you have a crash file or better yet a focused sample that reproduces that issue? Posting a Crash Reports: https://developer.apple.com/forums/thread/688669 Focused Sample: 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. Thanks, Albert Pascual
  Worldwide Developer Relations.

Thanks so much, @tbartelmess1—this is super helpful, and really appreciated a bit more context from our app: App context (what we store) The blobs we persist will be user-generated cruise photos, we would downsize those to more manageable size as iphone format photos can be quite big, but they would still be in the 1-3 mb after downsizing Realistic volume per active user: a few hundred images/year; heavy users could reach low thousands over time. Decision: use Core Data Binary Data + “Allows External Storage” We’ll keep originals as Binary Data (Allows External Storage) so Core Data handles externalization transparently, my philosophy has always been to offload as much work to the system services as possible. We’ll keep thumbnails as well inline in coredata (let coredata decide but likely will be inline (blob)). CloudKit mirroring We’ll rely on NSPersistentCloudKitContainer mirroring; we understand CloudKit decides when an attribute becomes a CKAsset independently of Core Data’s externalization threshold. Tha

Now that this is mostly working, I've come across a new issue I'm wondering if anyone else is seeing. Using UTM version 4.7.4 on a macOS 26.0.1 host, I am setting up a macOS 26.1 beta 3 guest. I am unable to log into my Apple ID in the macOS 26.1 beta host. This happened with beta 1 and now with beta 3. This is not just the normal limitations of logging into an Apple ID in a macOS VM. With macOS 26.1 beta, you can't login at all. This means no iCloud access. This means you can't even update to the next beta since you need iCloud access for the Software Update screen to even offer the Beta Software update option. I also have a macOS 15.7.1 VM and a maCOS 14.6.1 VM on this same host and they both let me login just fine (with the usual limitations). I filed bug FB20668616 but I'm curious if anyone has seen this. One step forward, one step back.

Thank you for your post and providing a screenshot that illustrates the issue. Could you please specify the version of iOS and Xcode you are using? Additionally, do you have a focused sample project that I can utilize to reproduce the issue where the values appear beneath the labels? 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. Any chance you already filed a bug for this issue? Thanks, Albert Pascual
  Worldwide Developer Relations.