“file uri scheme”

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. We implemented your own HTTP protocol on top of NetworkConnection. OK, cool, that’s kinda what I expected but I’m glad you confirmed it. We are very eager to send HTTP requests over Wi‑Fi Aware using URLSession — is this achievable? No. I recommend that you file an enhancement request for that. Please post your bug number, just for the record. Coming back to your throughput issue, I don’t have an immediate answer to that. I’m gonna do some digging and get back to you. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

matthewruzzi wrote: Report a bug Exactly! See Bug Reporting: How and Why? for lots of hints and tips about filing effective bug reports. Also, if you do file a bug, please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='820314021, Ludovic, /thread/820314, /profile/Ludovic'] As far as I understand for preboot I need to provide a persistent token [/quote] No, you’ve got that backwards. CryptoTokenKit supports two different types of token: Smart card tokens Persistent tokens A smart card token is backed by hardware; a persistent token may be entirely virtual. A smart card token subclasses TKSmartCardToken. A persistent token subclasses TKToken directly. Because a smart card token is backed by hardware, it can work at login time. In a persistent token, the information about the credentials in the token is stored in the user’s home directory, and thus it can’t be used to log in. It’s a chicken’n’egg problem. My understanding is that you have a smart card token working for general login, and now you’re trying to get that work for FileVault unlock. There’s no way to make that work. It’s another chicken’n’egg problem. Your app is stored on the encrypted volume, so it can’t be accessed until the user has unlocked that. This w

The temporary solution is to change the uploadSymbols value in the plist file to false.

Thanks for the post. This is interesting now you can't copy and paste from the same machine to the simulator? Before we file a bug, can you try something for me? Open your Mac Terminal. Paste and run this command: xcrun simctl spawn booted launchctl kickstart -k system/com.apple.pboard Try pasting in the Simulator again. Let me know the results. Thanks, Albert Pascual
  Worldwide Developer Relations.

Hi Ajaxharg, mistermodem, thanks for reporting this issue. Additional logging will help with the investigation. Please file an issue with http://feedbackassistant.apple.com, attach a sysdiagnose, and provide the issue number here.

Thanks for filing the feedback report (FB22325366). Yeah, that does look like an issue on the framework side. I can reproduce the crash without the need of adding a second relationship with Xcode 26.4 (17E192) + iOS 26.4 (23E244) Simulator. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks for the post, in this page you'll find a sample for AppClips as well as the first note will provide you the 101 of App Clips. I always recommend developers to go over all those videos and documentation liked on that note. Then download the app, look at every single configuration from that app including the Clip target! https://developer.apple.com/documentation/appclip/fruta-building-a-feature-rich-app-with-swiftui In my opinion and without going deep in your solution, the reason your AASA endpoint is never getting called when you scan the QR code is due to a common misconception about how iOS handles App Clips and Universal Links, the iOS device does not fetch the AASA file at the moment you scan a QR code. Downloads the file at app installation time and there is also a delay. When you scan a QR code, iOS checks its local cache and Apple's CDN records to see if that URL is registered to an App Clip. If Apple's CDN hasn't validated your AASA file, or if the TestFlight configur

Is there any supported way for a sandboxed macOS app to read an MDM-delivered preference plist under /Library/Managed Preferences/? Any guidance on the correct and Apple‑supported method would be appreciated. There are basically two ways to make this work: Have the user select the file or directory using an open panel (or drag and drop). Use an entitlement that gives you access to the target directory. In this particular case, that means using one of the File Access Temporary Exceptions to hard-code access to /Library/Managed Preferences/. A few notes on that: The documentation suggests using Shared Preference Domain Temporary Exceptions. I would certainly try that; however, I suspect it won't work as Managed Preferences may not be part of the standard preference system. While there's always an inherent risk in using a temporary entitlement, I generally consider this particular entitlement set to be relatively safe. The entitlement’s role is clear and straightforward (it gives access to the

After additional testing, this appears to be an orphaned MobileAsset cleanup issue rather than a normal simulator uninstall problem. The runtime payload remains on disk under /System/Library/AssetsV2, but in some cases Xcode no longer exposes it in Components/Platforms and simctl does not have a usable reference to remove it cleanly. In other words, the asset still occupies space, but the supported management tools have effectively lost authoritative control over it. At that point the problem becomes structural: the remaining files are in a SIP-protected system location. So even if the exact asset folder can be identified, it cannot be manually removed through normal user-space means while SIP is enabled. That leaves no supported path to reclaim the space once the asset has fallen out of Xcode/simctl management. Technically, the remaining workaround is to disable SIP and remove the orphaned asset manually, but that is not a reasonable solution for routine simulator runtime cleanup. SIP exists specifi

@JorisVD We are working on understanding the problem and looking for a fix. We could use as many incidents with detailed logs as possible to help with finding a root cause. If you can, please file a bug report with Bluetooth debug logs as well as described in the above message: https://developer.apple.com/forums/thread/806999?answerId=865783022#865783022 Please @mention me with the Feedback ID once done.

When did you install the TestNet Profile and are you sure it's still valid? The previous profile expired in early February, so you'll need to have updated it recently. Note that you need to install the profile on all the devices involved and that a mixed configuration where the iOS device has the current profile but the HomeHub does not will very likely generate behavior similar to what you're seeing. Here is exactly what is happening: Our device successfully sends a QueryImage command to the HomePod. The HomePod receives it, but immediately fires back a QueryImageResponse that essentially means UpdateNotAvailable, forcing the device into an 86400-second sleep timeout. Chapter 4 of the Apple Matter OTA - User Guide (r6) outlines a number of specific recommendations and guidelines. Are you following all those guidelines, particularly around MinApplicableSoftwareVersion and MaxApplicableSoftwareVersion? Many of our recommendations in these specifications are best understood as requirements, not suggestions. Als

The Apple Developer Forums are for questions about APIs and features intended specifically for developers. Since it sounds like you went to the Apple Support Community already and were sent here because you are running a beta, then you should file a bug report in Feedback Assistant.