file uri scheme

I don't think the problem is coming from the macOS instance itself as the problem does not occur when the extension is updated using an installation package. The problem only happens when replacing the system extension and its wrapper .app using basic NSFileManager APIs. I diffed the 2 cases and there are no differences. Same files, same contents. And anyway spctl and codesign are happy. I tried different macOS versions in VMs (14, 15). Same result. What I'm also observing is that after updating the system extension using an installation package, just using the NSFileManager APIs is going to work fine when reverting to any version that has been previous installed via an installation package or updating to version that has been previously updated via an installation package.

I ended up solving the signing by signing the package once with my script which signs all files individually inthe right order and then afterwards signing it again with py2appsigner. Since it's working now I haven't spent more time analyzing why both steps were required. Thanks againg for the help everybody involved.

I made some progress! Or at least I think so, it is still unclear. I simplified the shader code to not include the external library for now: #include using namespace metal; [[ stitchable ]] half4 checkerboard(float2 position, half4 currentColor, float size, half4 newColor) { uint2 posInChecks = uint2(position.x / size, position.y / size); bool isColor = (posInChecks.x ^ posInChecks.y) & 1; return isColor ? newColor * currentColor.a : half4(0.0, 0.0, 0.0, 0.0); } I am going to deal with the missing library later. Now the expanded shader compilation code looks as follows: let shaderURL = Bundle.main.url(forResource: shaders, withExtension: txt)! let source = try! String(contentsOf: shaderURL, encoding: .utf8) do { let device = MTLCreateSystemDefaultDevice()! let opt = MTLCompileOptions() opt.enableLogging = true // Those two options are important. opt.libraryType = .dynamic opt.installName = shaders.metallib // We need to create MTLLibrary... let library = try device.makeLibrary(source: source, options: op

@Graphics and Games Engineer Thanks for the suggestion! I am trying to follow it and trying to compile shaders dynamically, so that I can use them as effects in SwiftUI, but it does not work. What I am doing is this (please don’t mind forced unwrapping): let shaderURL = Bundle.main.url(forResource: example-swiftui-shaders, withExtension: txt)! let source = try! String(contentsOf: shaderURL, encoding: .utf8) do { let device = MTLCreateSystemDefaultDevice()! let opt = MTLCompileOptions() opt.enableLogging = true let library = try device.makeLibrary( source: source, options: opt) print(ok, library) } catch { print(error, error) } I am getting a compilation error: Error Domain=MTLLibraryErrorDomain Code=3 program_source:10:10: fatal error: 'SwiftUI/SwiftUI_Metal.h' file not found #include ^~~~~~~~~~~~~~~~~~~~~~~~~ program_source:10:10: note: did not find header 'SwiftUI_Metal.h' in framework 'SwiftUI' (loaded from '/System/Library/Frameworks') UserInfo={NSLocalizedDescription=program_source:10:10: fata

👋Hi @DTS Engineer I remember that the form submitted last year needed to be filled in with Xcode or Playground test, and it seems that it was also mentioned: • If you use Xcode, the judges may use Simulator to run. • If you use Playground, it's a real machine. But my work this time will encounter two limitations: It will use the framework/API only available in iOS 26 (so if it is a Playground environment, it may not run) It will also use some content that must be real to run (such as ARKit), which means that Xcode Simulator is not good. So I would like to ask: Does this year's review allow you to compile and connect the iPad to the real machine? Or did I misremember last year's regulations? If the judge's environment is fixed (for example, only Playground or only Simulator), how should I adjust the submission method or implement the scheme? Looking forward to your reply, thank you. ~ Jiaxu Li

Here is the bug number FB21338185 The test file I am testing with is 7 GB, and on cellular the upload can be a bit slow. I can test again, but I think in case 1, the progress updater updates much more slowly than it does when directly updating the progress task in case 2. Perhaps the UI only looks at completedUnitCount and not fractionCompleted as well? If it's interesting I can see if I can try to repro it more clearly

Apologies if I misunderstand things completely, I am no developer so memory management is completely foreign to me. Are the steps you describe involving the creation of a file and mmap it, to be used in the shell, and the output then applied to a process already running (say some python code) or are they supposed to be performed before the python code is run? In the first case, how do I assign this points to the process already running? I assume this will be extra virtual memory on top of the one the VMM has already used for the process. In the second case, does the pointer have to be used within the python script (that is, do I need to modify my python script in a certain way to tap into this file for virtual memory)? Or once I have it, I have to launch the process in a certain way that it uses it? Feel free to refer me to some resource that explains how to map a file to a process, all I could find, manages included, was not helpful and does not go into enough detail for my backgro

I investigated this further and confirmed the issue is due to a toolchain mismatch inside Xcode 26.1. Although test execution successfully generates multiple .profraw files, the coverage merge step fails. Running the merge manually using the Xcode-bundled tool results in the following error: raw profile version mismatch: Profile uses raw profile format version = 8 expected version = 10 error: no profile can be merged. The same project and test configuration generates coverage correctly on earlier Xcode versions, which strongly suggests a issue in Xcode 26.1’s coverage toolchain.

Hi @muhammadharoon. Thanks for the details. It sounds like you may have a reproducible case. I recommend packaging that up into a bug report so engineering can consider adding further investigation into their work schedule. Capturing this information in a forums post is interesting, but it is not the sort of thing our engineering teams use for scheduling work. Won't you please consider filing a feedback report about this question.

@jsemmons, thank you for filing FB21233847. I see a note in your bug report asking if you can reproduce the problem in the most recent beta?

As you identified, annotations are specified using a 2D geographic coordinate, represented by CLLocationCoordinate2D. There aren't any APIs that add a third dimension to this information for the system to use in positioning the annotation on the map. If you'd like us to consider adding this functionality, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number here. — Ed Ford,  DTS Engineer