file uri scheme

No there is not. However you can configure your app's windows to work together with Stage Manager when it is available. For some recommendations for working with Stage Manager, please see What's new in AppKit If you'd like us to consider adding a way to tell when Stage Manager is active, please file an enhancement request using the Feedback Assistant. If you file the request, please post the Feedback number here so we can make sure it gets routed to the right team. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why?

Are you able to reproduce this issue on previous versions of iOS? If no, please file a Feedback report using Feedback Assistant, then post the number here.

has the In-App Purchase capability enabled in the Apple Developer portal (checkbox is grayed out and checked). That is an expected behavior. In Certificates, Identifiers & Profiles, the In-App Purchase capability appears enabled by default for an explicit App ID and disabled for a wildcard App ID. You can't change the default value. Provisioning profile doesn't include the com.apple.developer.in-app-purchase entitlement The com.apple.developer.in-app-purchase entitlement doesn't exist as explained in Determining if an entitlement is real. If your entitlements file includes it, remove it. Additionally, if you added the In-App Purchase capability to your app target in Xcode, remove it. It is unnecessary. This capability is already enabled when you use an explicit App ID. Deleted and re-created provisioning profiles (both automatic via Expo/EAS and manual in Developer portal). After removing the key from the entitlements file, regenerate your provisioning profile, download and install it on

Hello, I checked on the status of the bug you filed FB9856371 and it remains open and under investigation. Looks like this bug has been set to a high priority and I can see lots of comments from engineering in there. I can't comment about future business plans so that's all I can tell you today. Please continue to test your software in release and pre-release versions of system software made available to you through your developer.apple.com account. When you do, add details about that into your bug report to keep it up to date. Please see https://developer.apple.com/download/.

@nathan-onlyhumn Please file a Feedback report, then post the number here.

Thank you all for filing a Feedback report. We are still looking into the issue.

I tried before posting, but isVisible stays true even when disabling the status item in System Settings. Hmmm. Please file a bug on that, as you should be able to detect your status. But will the agent be listed in System Settings > General > Login Items? No, it'll be shown immediately below in the section labeled App Background Activity. In my opinion, it would make more sense to use an option that is kept in sync between the app and System Settings. Yes, and that's how this works. SMAppService.status returns the app’s current state in the preference UI. Looking at how different privacy features are implemented in macOS, I would have expected that login items (or agents, or however we might call them) can be disabled in System Settings, without the app being able to turn them on again without the user noticing. Yes, and that's how this works too. If your status is SMAppServiceStatusRequiresApproval, then the user will need to activate the component themselves through the preference UI. Having

When will we configure Hibernate 25? Is it valid for M series MacBooks? Is Hibernate 25 called deep sleep mode? So, let me start by quoting the man page for pmset: hibernatemode = 3 by default on portables. The system will store a copy of memory to persistent storage (the disk), and will power memory during sleep. The system will wake from memory, unless a power loss forces it to restore from hibernate image. ... hibernatemode = 25 is only settable via pmset. The system will store a copy of memory to persistent storage (the disk), and will remove power to memory. The system will restore from disk image. If you want hibernation - slower sleeps, slower wakes, and better battery life, you should use this setting. The thing to understand here is that the difference between those two ISN'T about how either mode “prepares for sleep. Both of them do exactly the same thing— that is, they flush all memory to disk, ensuring that power loss won't lose any data. The difference is that having done that flush, Hibernate 25

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.

Seeing this as well. When I look at the crash log for the Simulator I see an issue where it seems to be crashing in unrelated apps. Worth raising a feedback here as well and uploading the ips files (+ the sysdiagnose). I'll do the same later today and share the number here.

I can confirm this is not reproduced in a virtual machine running 15.6_24G84 (btw cannot find 15.7 (24G222) for download). As previously written to DTS this was not reproduced in 26.0_25A5327h either and the reason was this was also tested in a clean virtual machine. On the installation this is reproduced running 15.7 (24G222) the folder in ~/Library/Group Containers has indeed a .com.apple.containermanagerd.metadata.plist file with faulty, cached MCMMetadataIdentifier key referencing a different team identifier that was used for testing at some point.

I worked in CoreOS for a while. I'm good with spindump files. 😄 Cool! In that case, you should also be properly terrified of our mach APIs! It's almost 8 p.m. here, so I’ll look at it tomorrow. While you're looking at the files, search for libendpointsecurity in any non-Apple* process. I mentioned this above, but I've seen many weird issues that ultimately boiled down to a 3rd-party EndpointSecurity client is making something fail that would otherwise never fail. *A few of our daemon's use this as well, but I've never seen our clients disrupt anything that didn't deserve it. __ Kevin Elliott DTS Engineer, CoreOS/Hardware