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.

I have no chance to use this feature as I do not find the relevant header files. I added the Framework and the Capability. But still I do not have any chance to compile my code. Are you able to share a short snippet of your code?

Thanks for filing the feedback report (FB20664344) for us. We did annotate NSManagedObject with nonisolated – You can see the following by looking into the header file (NSManagedObject.h): NS_SWIFT_NONISOLATED NS_SWIFT_NONSENDABLE @interface NSManagedObject : NSObject { } But that doesn't make a subclass of NSManagedObject nonisolated. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks again @RickMaddy I nicely added items to the File Menu using your example. As it turns out I was way overthinking this. I thought there would be a unified menubar in multitasking, not a per window one. This is much simpler and answered my, where is it in Vision, question. I don't really know how I missed this point in the intro video. The only other note I will point out for any other dinosaurs following along is that this line [super buildMenuWithBuilder:builder]; only works with supers that are UIResponder subclasses. So if you started your project in iOS 4.x your AppDelegate might still be an NSObject subclass, and you should upgrade to eliminate some build warnings.

Hi, thanks for mentioning the .exp file approach. This works well with the scenario I explained above (dynamic framework depending on static libs). However, when I tried this with a slightly different project configuration, I faced linker errors. I replaced the static libs with dynamic libs. So, now I have a dynamic framework with 3 target dependencies, each being a dynamic library. This project builds and runs fine when tested on the iOS simulator. But according to our other discussion here, when I test this on a real iPhone, it builds fine but fails at runtime with a linker error: 0_abort_with_payload and Xcode shows the following assembly instructions specifying the error Thread 1: signal SIGABRT - dyld`: 0x1aa0a15f8 <+0>: mov x16, #0x209 0x1aa0a15fc <+4>: svc #0x80 -> 0x1aa0a1600 <+8>: b.lo 0x1aa0a1620 ; <+40> 0x1aa0a1604 <+12>: pacibsp 0x1aa0a1608 <+16>: stp x29, x30, [sp, #-0x10]! 0x1aa0a160c <+20>: mov x29, sp 0x1aa0a1610 <+24>: bl 0x1aa040064

I confirm that the issue is still there in Xcode 26.1 Beta 2. When the Default Actor Isolation (SWIFT_DEFAULT_ACTOR_ISOLATION) is set to MainActor, the compiler adds @MainActor to the subclass of NSManagedObject, which makes the attributes added to the subclass MainActor-isolated, and triggers the warning. Unless you'd change SWIFT_DEFAULT_ACTOR_ISOLATION back to nonisolated or live with the warning, the Swift forum post you provided mentions the following options: Create a nonisolated variable to hold the closure, and call the closure from within the perform method of the managed object context. Manually create the entity class (the subclass of NSManagedObject), and annotate it with nonisolated. These options work, but are not ideal. The best solution may be that Xcode annotates the entity class with nonisolated when generating the code, but that needs to be implemented in Xcode. I'd hence suggest that you file a feedback report – If you do so, please share your report ID here. Best, —— Ziqiao Chen