file uri scheme

Hi @vision_pro_developer2000 I'm unable to reproduce the no camera frames issue when building the app with a valid Enterprise.license file. However, I can reproduce the issue when any of the following conditions occur. Verify that none of these apply to your setup Expired or outdated license: Ensure you're using the most recently issued Enterprise.license file, not an expired version. Incorrect filename: The file must be named exactly Enterprise.license (case-sensitive, no variations). License not properly replaced: The placeholder Enterprise.license must be completely replaced with your actual license file; copying and pasting the file's contents into the placeholder file will not work. Team mismatch: Confirm you're building the app using the same Apple Developer team that the license was issued to. Test your license setup Add the snippet below to your app to confirm your app has main camera API access. Refer to this video for a detailed walkthrough. // A

F_FULLFSYNC is basically always going to be relatively slow. The API operates on a file handle, but flushing the volume to a coherent state is a broader operation the final I/O command is a device command. All of that makes it a fairly heavy operation. Gotcha, thanks for the background! On that note, I did my research—to our mutual peril—and found a comment (https://news.ycombinator.com/item?id=25204202) that cited sqlite's codebase, noting that fdatasync() on HFS+ doesn't yet flush the file size if it changed correctly. Some folks on the postgres mailing list also appear to be a bit uncertain about the current situation: https://www.postgresql.org/message-id/flat/CA%2BhUKGLv-kvrtA5QEL%3Dp%3DdYK0p9gsMXJaVhUFu%2BA-KyFrFi%3D2g%40mail.gmail.com#fe6d1c5665a381687842758fd5b245d4. I'm a newbie when it comes to understanding C code, but looking over kern_aio.c, I see two seemingly contradictory comments. On lines 658–659: * NOTE - we do not support op O_DSYNC at this point since we do not support t

Hi, sorry to hear you're having issues with Apple Pay. Given you're using Apple Pay through a third party API (in this case Stripe's), you may need to reach out to them to determine the cause. To try and help, if you've confirmed Apple Pay on the Web is working on the same device with the same merchant identifier, then you should be able to rule out any issues with cards available on the device or the device region, and it suggests more of an issue with the underlying integration between the third party library and the native PassKit APIs. Because the Apple Pay sheet appears, and allows you to attempt to authorise a transaction, this should also rule out any entitlement or code signing issues for the app as well. It may be worth checking to see if the device is logging anything, which may provide some insight as to why it's failing. You can do this using Console on macOS with the device connected, and selecting it in the side menu. In particular, filtering on PassbookUIService should reduce most of the unnece

Ok, I found this in dmesg/syslog: [46147.634755]: DriverKitSampleA[6170] triggered unnest of range 0x1fc000000->0x1fe000000 of DYLD shared region in VM map 0x853f7106fc70fc7d. While not abnormal for debuggers, this increases system memory footprint until the target exits. [46147.634762]: DriverKitSampleA[6170] triggered unnest of range 0x1fe000000->0x200000000 of DYLD shared region in VM map 0x853f7106fc70fc7d. While not abnormal for debuggers, this increases system memory footprint until the target exits. [46148.219526]: Sandbox: ContextStoreAgent(448) allow file-read-data /Users/daniel/Library/Developer/Xcode/DerivedData/DriverKitUserClientSample-haxyygamobxzqybcidlsjqhbccev/Build/Products/Debug/DriverKitSampleApp.appSandbox: ContextStoreAgent(448) allow file-read-data /Users/daniel/Library/Developer/Xcode/DerivedData/DriverKitUserClientSample-haxyygamobxzqybcidlsjqhbccev/Build/Products/Debug/DriverKitSampleApp.app/ContentsSandbox: ContextStoreAgent(448) allow file-read-data

I just filed a bug report about this here: FB20997701 I'm not sure that notification will make it out to that bug, but this should be fixed in the latest seed, iOS 26.2 beta 3 (23C5044b). __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thank you for sharing the post. This appears to be a coredevice issue to me. Have you filed a bug report? You should update your Xcode version to the latest version as well as you macOS. If still happening on the latest version, please file a bug: Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

Hi, we need some more diagnostics to be able to help you with this. Could you please file a feedback request and post the number here so we can examine the logs? Be sure to include your team ID and the link to the build also. You can file Xcode Cloud specific feedback using these steps.

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.

The error occurred when fio attempted to verify the second 1MB data block (starting at offset 1,048,576). So what's IS there? And what should have been? These test use hashes for verification because it's the quickest way to validate the data, but the question I'm interested in here is what your driver actually put on disk. Part of my concern here is that unless you artificially cut power to the device, we shouldn't have needed any explicit cache sync as part of the copy. The system should have flushed all of it's buffers to your DEXT as part of unmount and you should have flushed them to disk shortly after that. If this is really about cache flushing, that's the failure case I'd really be concerned* about here, not the individual copy. *Failure to flush a file loses file data. Failure to flush file system blocks loses volumes. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I'm sorry for the delay in submitting a feedback item; a cross-country move happened. Not a problem, I've got plenty to keep my busy! That leads to here: I've submitted FB21093202. So, looking over the bug, there are a few things I want to clarify: F_FULLFSYNC is basically always going to be relatively slow. The API operates on a file handle, but flushing the volume to a coherent state is a broader operation the final I/O command is a device command. All of that makes it a fairly heavy operation. On the APFS side, the specific concern I have here is about the performance dip at high core count. That's partly because of the immediate issue and mostly because our core count has been increasing, and we need to be watching for these concurrency bottlenecks. Cross platform comparisons are very tricky here because the platforms are (ideally) making different design decisions based on the specifics of of their particular use case and user base. For example, in an enterprise/server environment, there's an ar