İOS 26 beta battery %1

This behavior is still present after 26.1 release and on 26.2 Beta 1

Hi there! Thanks for the feedback. This must be something else going wrong – we should disallow the recording on iOS devices lower than 26.0, so you should not even be allowed to hit the Record button. Would it be possible to file a feedback with Apple (feedback assistant.apple.com), include screenshot of what you're seeing and sysdiagnose from a target device? Also, please let us know if after recording on the device the new Instrument wouldn't work for some reason. Thanks!

@DTS Engineer I've submitted a bug report with ID FB20925084. Unfortunately I wasn't able to provide too many details. I'm not able to reproduce this issue on iOS 26 but it was reported by one of my beta testers and the app review team. The issue is now blocking submission of my app to the app store. I'm surprised there are not more reports of this issue. I'd had thought it would affect many apps that use web services or OAuth to authenticate.

Hi @Lu Linxuan I was unable to reproduce this behavior. Here's what I tried. Download the sample app, Displaying video from connected devices. Remove the entitlements. As of visionOS 26 they are unnecessary. Add a button that opens an immersive space to ContentView. Run the sample and click the button to open the immersive space. The above worked for me. Are you doing something different?

I think you filed this as FB20915052; however, this is also a known issue (r.161870449). Not me. There is a bug here, but it's not exactly what you think. The .nofollow syntax is a new part of the core system that allows components to construct paths that the lower level system guarantees will not be resolved or followed. This makes it simpler to protect against TOC/TOU attacks by allowing one component of the system to resolve a particular path, then pass that path to another component while guaranteeing that the second component won't inadvertently cause a second resolve. I understand about those kinds of race conditions. I'm not sure why it would be classified as an attack. And I have no idea what that has to do with URL bookmarks. Unfortunately, the bug here is that parts of Foundation aren't handling this correctly when the path references root. I expect this will be resolved in the next system update; however, it's not clear to me whether that will mean that resolution will return / again or th

@allinne_a The Accessing a person’s contact data using Contacts and ContactsUI sample code describes how to implement the Contact access picker. Download the sample then let me know if you can reproduce your issue using the sample. Only select few contacts when prompted to give access to your contacts. Then enter a name or phone number in the search field. In the Quick-Add view, select one or more contacts in the Contact access picker.

So basically the fix is to: Make your app to support all orientations and support resizing. Easy ! All disable all orientations on iPad and stick to one orientation. The funny thing is that my app is already supporting all orientations and I'm using native SwiftUI but the problem is that the window controls are overlapping navigation of my app, which is using standard top-left navigation to go back. So my app is not usable on windowed mode. I've put a lot of effort on the landscape mode and I will need to disable it. Thank you.

Now that macOS 26.1 has been released, this bug now has different behaviour. It still isn't correct. If anything, it's more wrong than it was before. I think you filed this as FB20915052; however, this is also a known issue (r.161870449). As of 26.1, when you encode a security-scoped bookmark to file:///, what you decode will be a bookmark to file:///.nofollow/. So the decode method now succeeds, but the value is wrong. There is a bug here, but it's not exactly what you think. The .nofollow syntax is a new part of the core system that allows components to construct paths that the lower level system guarantees will not be resolved or followed. This makes it simpler to protect against TOC/TOU attacks by allowing one component of the system to resolve a particular path, then pass that path to another component while guaranteeing that the second component won't inadvertently cause a second resolve. Unfortunately, the bug here is that parts of Foundation aren't handling this correctly when the path refere

Really? I would count having all system .app compressed on everyone's Mac as widespread use. Yes. I think well-designed, file system-level compression is a very reasonable feature that could be very useful. Unfortunately, that's not really what we implemented in HFS+ or APFS. There's a reason our APIs don't really support compressed files, and that's because their file system implementation means that they aren't fully supported by the entire system. Moreover, everyone loves macOS's compressed .dmg! It's a shame the app bundle I dragged out of it takes more than 2x the space than the distribution .dmg.[1] FYI, part of the reason this works so well is the other side of the same problem that makes it less valuable in the general file system. The file system manages storage in terms of allocation blocks (typically 4kb on our system), each of which is used regardless of the files’ actual contents. You can see this if you create a file with a few bytes of text in it, then Get Info on it using the Finder.

Hi @joelgethinlewis @mtsrodrigues. Thank you for your post. You can only track one image at a time currently. If you'd like to track multiple images simultaneously, please file an enhancement request via Feedback Assistant.