“file uri scheme”

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.