file uri scheme

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