file uri scheme

When a Binary Data attribute is marked as “Allows External Storage”, large image files are stored as separate files on the device rather than inline in the SQLite store. That is correct. There is a threshold when the data will get stored in external files next to the SQLite database, similar to the approach that you described with URLs, but that process is managed by CoreData and transparent to your app you. How effective is this mechanism in keeping the Core Data store size small on the device? It depends on what you mean by the store. The SQLite file will be smaller, but the files are still stored on the device. Are there any recommended size thresholds or known limits for how many externally stored blobs can safely be managed this way? There is in general no limit. CoreData will decide when it's worth using an external file. If the blob you are storing is only a few bytes, it'll remain inline. If you expect to have a lot of assets, you should consider h

OK, noticed the difference in animation / no animation between the 2 OS versions. Is it a constraint due to liquid glass (would be bad news). Did you file a bug report, at least against documentation if that's on purpose ? Please note reference here.

Thank you for your reply. I see you filed a bug, you have provided some code in the bug, thanks for that, but may I ask to upload a focused project showing the issue? I’ve already attached code that reproduces the issue in the first post of this thread. Please note that the issue only occurs on iOS 26 when the device is set to Dark Mode and Reduce Transparency is enabled. I have also uploaded the Xcode project for this sample code to GitHub: https://github.com/hmuronaka/iOS26NavigationTitleSample If so, please share a link to your test project or better upload it into the FB issue I’ve also uploaded the link to the project in the FB report (FB20370553) as well. Thank you for your support

I’ve been working on this for the past two days, but in a UIKit Mac Catalyst context. I managed to get it working, though I believe this might actually be a bug in Mac Catalyst. I was about to file a report when I came across your post. Did you already submit one? The workaround I found is to assign an instance of NSToolbar to the windowScene's titlebar like this: // Inside SceneDelegate.swift #if targetEnvironment(macCatalyst) let toolbar = NSToolbar() toolbar.displayMode = .iconOnly // reduces toolbar height self.window?.windowScene?.titlebar?.toolbar = toolbar #endif This setup gives you the unified sidebar and toolbar, but there’s still quite a bit of empty space at the top, even with displayMode set to .iconOnly. Since I didn’t actually need a toolbar in my case, I fixed it by applying a negative top safe area inset. That gave me the look I wanted: let splitViewController = UISplitViewController(style: .doubleColumn) let sidebarNavigationController = KNavigationController(rootViewController: Sid

Thanks for the post. I see you filed a bug, you have provided some code in the bug, thanks for that, but may I ask to upload a focused project showing the issue? If so, please share a link to your test project or better upload it into the FB issue 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. There, you can track if the report is still being investigated, has a potential identifiable fix, or has been resolved in another way. The status appears beside the label Resolution. We're unable to share any updates on specific reports on the forums. For more details on when you'll see updates to your report, please see What to expect after submission. Albert Pascual
  Worldwide Developer Relations.

I was able to reproduce this on the iOS Simulator by enabling Reduce Transparency. In addition, this behavior occurs not only in the sample project but also in iOS 26 system apps such as Files and others, so I believe it is an iOS 26 issue. iOS 26 File app

Yeah, I see the following error when trying to prompt the on-device foundation model from within a device activity report extension (DeviceActivityReportExtension), which I believe is the same as what you mentioned: establishment of session failed with Unrecognized underlying error: Underlying connection was invalidated. Reason: failed at lookup with error 159 - Sandbox restriction ModelManagerError: got unrecognized error Underlying connection was invalidated. Reason: failed at lookup with error 159 - Sandbox restriction I am pretty sure that is as-designed. To give you more context, when responding your prompt, the model needs to communicate with the model manager, which is a system daemon that manages the inference requests. To protect the user’s privacy, however, the system doesn't allow a device activity report extension to move data outside the extension’s address space, and that prevents the model from creating a connection to the model manager. Having said that, if you have a compelling case that need

Could you share your understanding of the crash and give any hints on how we can fix it? So, let me actually start by commenting on this: At first, we assumed that the issue is with hardware. The first thing to understand here is that DEXTs are FULLY capable of panicking the kernel and probably always will be, particularly PCI DEXTs. The main benefit DEXTs provide is that they DRAMATICALLY improve overall system security and risk by constraining the range of what it's POSSIBLE for a component to do. Your DEXT only has access to a very limited set of kernel data, so that's the ONLY kernel data your DEXT interacts with. It's possible for a network DEXT to disrupt the network stack, but it's very difficult to see how it would disrupt the file system. However, your DEXT is still being given access to many of the same resources it would have access to as a KEXT, and many of those resources are inherently dangerous. In the case of the PCI family, that issue is quite direct— I don't know of any way to build

Thanks for following up, and apologies for the delay-- this slipped past me. Here’s a repro asset I wrote that you can test directly: https://github.com/alexchuber/Assets/raw/refs/heads/main/Repros/triangleNegScale.usdz For additional reference, here's the USDA content of the asset (material omitted for clarity): #usda 1.0 ( defaultPrim = Root metersPerUnit = 1 upAxis = Y ) def Xform Root { def Mesh Triangle { matrix4d xformOp:transform = ( (-1, 0, 0, 0), (0, 1, 0, 0), (0, 0, 1, 0), (0, 0, 0, 1) ) uniform token[] xformOpOrder = [xformOp:transform] int[] faceVertexCounts = [3] int[] faceVertexIndices = [0, 1, 2] normal3f[] normals = [(0, 0, 1), (0, 0, 1), (0, 0, 1)] ( interpolation = vertex ) point3f[] points = [(0, 0, 0), (1, 0, 0), (0, 1, 0)] uniform token subdivisionScheme = none } } The steps to reproduce are just: Add the asset to a new Reality Composer Pro scene. Open the same asset in QuickLook on iOS/macOS. Compare the facing direction in both views. You should see that the triangles appear to have opp

Same here. Anything in SwiftUI with a Slider will crash on macOS 26. Following this thread… FB20614181 also filed.