file uri scheme

Thank you for your post. This is quite interesting for me, as I am still learning about this API myself. It is possible to “unshield” an application by modifying the ManagedSettingsStore().shield.applications array https://developer.apple.com/documentation/ManagedSettings/ShieldActionDelegate. However, the immediate disappearance of the shield depends on how the associated extension handles state updates. Typically, invoking completionHandler(.none) after modifying settings signals the system to apply changes, but immediate UI updates may require explicit app/extension design support for dynamic reloading. If this does not work, we should examine the code. Debug builds typically allow real-time data synchronization and immediate reflection of ManagedSettingsStore changes. However, TestFlight should have the same experience. Some functionality may not operate configurations in TestFlight builds, and you should file a bug for those. The shield does not necessarily require the main app to remain in the

Volume does not implement both maxFileSizeInBits and maxFileSize, while one of them must be implemented. Implementing this didn't seem to change the result. But I definitely do need to fix the sample FSKit project I've been copying as a base for all of these bug reports, then! Have you looked at what the actual block size of that device is and what FSBlockDeviceResource.blockSize is? Both physicalBlockSize and FSBlockDeviceResource.blockSize are 512 on the disk image. However, there are other issues. Your testing with a disk image, but the disk image block size is 0x200/512, NOT 0x1000/4096. If you’re looking at those values from the volume side, you may get 4096, but that's because the volume changed what stat returned, not because it's actually true. ... In your particular case, this also means that the stat value you're returning is 4x larger than the underlying FSResource size. That isn't necessarily wrong, but that's because the VFS layer will basically believe anything you tell it, not because that's wh

I am following up on this thread and my feedback report FB20986470. I have not received any response on either platform. If anyone has information about the status of this CallKit issue, I would appreciate an update. I don't have a lot that I can share, but I will share what I can. The basic issue is basically what you'd expect— there's a database that's used to collect all call directory entries, and that database has become corrupt and cannot be opened. How/why it's becoming corrupt is unknown, as the engineering team has never been able to identify any specific cause. There were significant reports of this happening several years ago, and those were addressed by the addition of several different data recovery mechanisms. That's also why the file wasn’t simply deleted and the entire directory system “reset”, as those recovery mechanisms were expected to be sufficient. At this point, the issue is under active investigation, but I can't comment on if/when a fix might ship. __ Kevin Elliott DTS Engine

Hello. We have not received a bug report number from you so I cm unable to check on status. Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

Special thanks for asking the key question: So what’s there? This prompted us to shift our focus from high-level hash verification to inspecting the raw bytes written to the disk. This investigation revealed that the root cause was not related to cache flushing, but rather a hardware limitation regarding single transfer lengths. Good, I'm glad that was helpful. One of the things I've learned in DTS is that it's very easy for a bug investigation to be derailed by jumping straight to what went wrong without really having looked closely at what actually happened. We're so used to our code doing what we think it does that we skip right past the possibility that it simply ISN'T doing what we think it is. With these fixes applied, all previously failing test scenarios (including cp + sync and fio, with file sizes ranging from 256MB up to 5GB) now PASS 100%. The checksums match perfectly. Fabulous and congratulations! __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Using Xcode 26.2, targeting an iPhone 17 Pro running 26.1, Xcode crashes saying the symbol isn't available. The isEligibleForAgeFeatures property is actually available in iOS 26.2 beta or later. The documentation showing it as iOS 26 is a bug. Thank you for filing your Feedback report. Upgrade your device to iOS 26.2 beta to test it.

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, please ensure that you provide specific reasons why you believe your app complies with the App Review Guidelines. Additionally, please submit only one appeal per rejection. It is also important to 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 have completed their investigation. Albert Pascual
  Worldwide Developer Relations.

Thanks for the follow up post and the bug number. Very interesting for sure. Your domain returns a 301 error for redirect something that will cause a failure: curl -v https://xn--montral-fya.ca/.well-known/apple-app-site-association If the response contains a 301 or 302 HTTP status code, your is doing an HTTP redirect, which is not supported when hosting the AASA file as redirects are not supported. TN3155: Debugging universal links | Apple Developer Documentation#Host-and-verify-your-AASA You can see the status of your feedback in Feedback Assistant. 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.

Thank you for your post. Very interesting. Your observation regarding the behavior of Universal Links on iOS, where the app opens automatically in some instances but prompts a confirmation dialog in others, is intentional and aligns with iOS’s security and user experience considerations. Apple implemented this confirmation mechanism partially due to security concerns. While this behavior is designed to enhance security and user control, Universal Links requires proper configuration of Apple-app-site-association files and associated domains. It is recommended to verify configurations using Apple’s validation tools to identify and resolve any technical inconsistencies. For more information, please refer to the following document: TN3155: Debugging universal links | Apple Developer Documentation In my opinion, best practices for Universal Links and redirect handling should be adopted to optimize user experiences as much as possible. Oh remember the iOS will also remembers how the user want to handle eac

Hi @Ewan_Ke Thanks for the reply. We pushed a small refactor to the sample yesterday. Here's the diff. I recommend applying the changes. It's worth calling out that the changes would not cause the behavior you reported, but they will make your app better. Changes Summary This patch addresses camera feed handling and removes unnecessary scene phase restart logic. Files Modified 1. CameraFeed.swift Added flush check before processing sample buffers to prevent decoding issues if preview.sampleBufferRenderer.requiresFlushToResumeDecoding { preview.sampleBufferRenderer.flush() } 2. CameraSessionManager.swift Changed restart() method visibility to private Was: func restart() async Now: private func restart() async 3. MainCameraView.swift Removed unused @Environment(.scenePhase) property Removed .onChange(of: scenePhase) modifier that was calling sessionManager.restart() when returning from background Rationale Restarting CameraSessionManager after the app is backgrounded is excessive. Instead the code shou

Thanks for the quick response! I filed a bug report and included the two relevant sample applications, the sysdiagnose log, and a screen recording of the behavior occurring: FB21115847

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.