Request failed with http status code 503

Hi Kevin — thanks for the detailed reply. Quick confirmations We’re already shipping the ES daemon as an app-bundled executable (signed, hardened, notarized). FDA is being granted through System Settings → Privacy & Security → Full Disk Access to the app bundle (per your #1), not to a bare exe. ES entitlement is present; Gatekeeper/SPCTL and codesign checks are clean. What we’re actually hitting (repro matrix) Apple Silicon (M-series) – macOS 15.6: Works. FDA toggles on and persists. ES daemon runs fine at boot. Intel – macOS ≤ 15.5: Works. Intel – macOS 15.6 ONLY: Broken. In Full Disk Access, turning the toggle On either immediately flips back Off, or appears On but flips Off after navigating away and back. When it “looks” On, the ES daemon still behaves as if FDA is not granted. This behavior is consistent across multiple Intel machines and fresh user profiles. Extra notes about launch The daemon is launched by launchd (system domain) as usual. Our installer (run by another LaunchDaemon’s install.sh) re

Hi @leokaminski07. Thanks for posting a sample project. I was able to reproduce your results here using your sample on an iPad Pro running iOS 26.0.1. Beyond turning off the Button Shapes option, I don't have any recommendations for avoiding this bug. Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a reference to your Xcode project 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.

No custom navigation bar background. Here's what the view itself looks like before and after and a code snippet of the setup if that helps. What major changes happened that could prevent this title from showing? navigationItem.title = L10n.Accounts.navTitle navigationItem.searchController = searchController navigationItem.hidesSearchBarWhenScrolling = false navigationItem.largeTitleDisplayMode = .always tabBarItem.title = L10n.Accounts.navTitle tabBarItem.badgeValue = hasMissingOrders ? ● : nil tabBarItem.badgeColor = .clear tabBarItem.setBadgeTextAttributes([NSAttributedString.Key.foregroundColor: UIColor.M360.secondary], for: .normal) tabBarItem.selectedImage = Asset.accountsNewActive.image tabBarItem.image = Asset.accountsNewInactive.image tabBarItem.accessibilityIdentifier = AccessibilityIdentifiers.Tabs.accountsButton }

@Etresoft, Well there's still the Apple Events capability in Signing & Capabilities. You have to provide a message to the user about why your app needs AppleEvents. I'm not sure what happens if that's missing. I don't remember from when I've done it previously, but I think OS just offers some default message presented to the user. I'm going to go ahead and disagree on that point. But I assume you're only talking about the end result for your use case. I haven't tried it, but osascript just executes scripts, without providing any extra functionality to control them. Since the plain script exhibits the undesirable (for me) behaviour with already existing files, I assume using osascript would result in the same. Are you sure that's even possible? So I think your suspicions here are likely unfounded. I'm not sure, but for the beginning, I first need to programmatically make Finder to react. And at the moment I'm not able to, due to all the explanations I provided in the initial post. I don't understand why it

Thank you for filing a bug report (FB20271264). Looking at the status of your bug initial testing shows engineering was unable to reproduce the problem. However, they are continuing to investigate. If you can provide specific steps they can use to reproduce the bug please add that to your bug report.

I’m not going to be able to help you with this. We don’t support folks killing arbitrary system processes. This is problematic for a variety of reasons, but the big issue here is that the name, location, and behaviour of system processes are all implementation details. If you build a product that relies on such implementation details, you are likely to run into compatibility problems down the line. Which is exactly what’s happened in this case )-: My advice is that you find an alternative way to achieve your ultimate goal. If you’re unable to do so, I recommend that you file an enhancement request for a supported path forward, making sure to explain your requirements and the reasons why the current mechanism don’t work for you. If you do file an ER, 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

Hey, sorry for not the greatest title, initially thought I will be able to edit and polish title and content, but saw in the forums, that it is possible to do that only for a short amount of time. Getting back to the topic: https://github.com/nymtech/nym-vpn-client/blob/develop/nym-vpn-apple/Daemon/net.nymtech.vpn.helper.plist Yes, we are using BundleProgram.

Thanks for the post. Are you running your app when that happens? Do you get called at: https://developer.apple.com/documentation/alarmkit/scheduling-an-alarm-with-alarmkit#Observe-state-changes-on-the-alarms Do you have a simple focused sample showing that you can share with us? If so, please share a link to your test project. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. Albert Pascual
  Worldwide Developer Relations.

Have you jumped through all the hoops so that your app can actually send Apple Events? Here is some old documentation that might be a good starting point: https://developer.apple.com/library/archive/qa/qa1888/_index.html The application isn't sandboxed, so I didn't add any additional entitlements and it should not matter. Moreover, if it was sandboxed I'd expect some kind of error in the console regarding sandboxing limitations, as it usually happens in such cases. But in this case, everything is silent (but doesn't work). NSAppleEventsUsageDescription should not matter either, but even with that added, nothing changes. Any new code that relies on AppleScript is risky. Apple is already transitioning to Shortcuts. And Apple has begun to be much more aggressive about deprecating and discontinuing technologies, pretty much all of which are much recent than Apple Events. I realise all that. However, I don't see why I wouldn't use it while it's still there and hasn't been deprecated yet. I can't

@IMITeam Thanks for providing more information about the issue with the API. Do you get the same results with just the relevant code in a small test project? If so, please share a link to your test project. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. Albert Pascual
  Worldwide Developer Relations.

You started a couple of other ExtensionKit threads (here and here) and it’s not clear why our answers there are sufficient to address the issue being discussed on this thread. If not, please reply here with a status update and I’ll take another look. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='803426021, suzsfot, /thread/803426, /profile/suzsfot'] Many developers in Chinese forums have provided feedback on this issue [/quote] Generally? Or to Apple? If anyone has filed a bug about this, I’d appreciate it if you posted the bug number here. Frankly, this looks like something that needs to be investigated by Apple’s network engineering teams. For that to happen, someone needs to file a bug about it. Ideally, that bug would include: A small test project that demonstrates the issue. It’d be best if you wrote this using Xcode and Apple’s APIs, rather third-party tooling, because that rules out the third-party tooling as a source of this issue. A sysdiagnose log taken shortly after reproducing the problem. On a device with Network Diagnostics debug profile installed. Get that from our Bug Reporting > Profiles and Logs page. An RVI packet traces showing the working case on iPhone 16 and the failing case on iPhone 17. However, this is the ideal situation. If you’re not able to provide al

Any help is highly appreciated, thanks! Have you jumped through all the hoops so that your app can actually send Apple Events? Here is some old documentation that might be a good starting point: https://developer.apple.com/library/archive/qa/qa1888/_index.html And here is a previous question from someone managed to get it working, after a fashion: https://developer.apple.com/forums/thread/771769 Any attempt to script the Finder is going to limit your app. It won't be acceptable for the Mac App Store. Any new code that relies on AppleScript is risky. Apple is already transitioning to Shortcuts. And Apple has begun to be much more aggressive about deprecating and discontinuing technologies, pretty much all of which are much recent than Apple Events. In older apps where I still did such things, I had good success with running the osascript command-line tool with carefully constructed parameters.