Search results for

“sandbox”

10,542 results found

Post

Replies

Boosts

Views

Activity

Reply to CTCellularPlanStatus.checkValidity(ofToken:) throws Couldn't communicate with a helper application on iOS 26
Consider this: import Foundation func main() { print(CocoaError(.xpcConnectionInvalid, userInfo: [:]).localizedDescription) // prints: Couldn’t communicate with a helper application. } main() This is NSXPCConnectionInvalid, which is equivalent to XPC_ERROR_CONNECTION_INVALID, which is in turn documented in the xpc_connection_create man page. In short, something went wrong with XPC and the XPC subsystem is not able to automatically retry. This error has a variety of potential causes: During development you often see if when the XPC service is broken some some reason. Or when the sandbox prevents you from accessing it. You can also see it when you connect to an anonymous listener and the remote peer terminates for some reason. So, this is a very general error and it’ll be hard to make progress without a sysdiagnose log. Which is tricky when you can’t reproduce the problem. I have two suggestions for you: In your standard app, you could implement a delay and retry. That may or may not help but, even if
Topic: App & System Services SubTopic: Core OS Tags:
Aug ’26
Reply to Kernel Sandbox/System Policy intermittently denies ALL file access (not just mount syscall) on NFS mounts
Thanks, Kevin — good to have that confirmed, and appreciate the extra context on why the bundled-app path is the right default (broadest toolbox, most-tested code path) rather than a point fix for this one symptom specifically. One honest update while I have you: the launcher-app change has fully solved the FDA-attribution problem for the watchdog daemon itself (no more GUI says granted, daemon's own canary says no), but it hasn't touched the original, broader issue this thread is about. The intermittent kernel Sandbox/System Policy deny(1) on the NFS mount is still occurring independent of that fix. Concrete data point: this morning (2026-08-04, ~09:21 local), a Terminal-launched process hit the same signature we've seen throughout this thread — mount still listed the NFS volume as connected, but ls returned Operation not permitted. Terminal has had Full Disk Access granted since 2026-07-14 (well before the launcher-app change), so this wasn't an FDA-attribution issue — it's the same stale-mount/den
Topic: App & System Services SubTopic: Core OS Tags:
Aug ’26
ExternalPurchaseCustomLink.isEligible is false on German storefront despite valid EU entitlement
We are implementing StoreKit External Purchase Link for an iOS app distributed in the European Union and are trying to determine whether we are missing a configuration step or encountering a StoreKit server-side eligibility issue. The failure is reproducible in a focused native Swift Xcode project that directly calls StoreKit: let eligible = await ExternalPurchaseCustomLink.isEligible The sample contains no Flutter code, PayPal SDK, networking, or application business logic. Configuration we have verified: The Account Holder accepted the StoreKit External Purchase Link Entitlement Addendum for EU Apps. StoreKit External Purchase Link is enabled and shown as Assigned for the App ID. The regenerated Development provisioning profile contains com.apple.developer.storekit.external-purchase-link = true. The installed app's signed entitlements contain the same value. The application-identifier and team-identifier match the intended App ID and team. The compiled Info.plist contains SKExternalPurchaseCustomLinkRegions
Topic: App & System Services SubTopic: StoreKit Tags:
0
0
554
Aug ’26
Reply to Kernel Sandbox/System Policy intermittently denies ALL file access (not just mount syscall) on NFS mounts
---Update: it's been 12 days since we deployed the launcher-app approach (bundled Swift app running the Python job via NSTask, granted FDA on 2026-07-22) and the result looks very promising: Excellent! One small comment here: Your diagnosis — that bare binaries never get a stable FDA/TCC grant in a launchd context, and wrapping the job in a proper .app bundle fixes that — looks correct. I didn't get into the details at the time, but there are actually a few different issues here: Most of our command line tools are designed so that they always inherit the sandbox of their parent process, which can make things complicated if/when you don't directly control whatever is launching the tool. Granting something like FDA to a general command line tool (like Python) obviously has very serious security concerns. There are a lot of edge cases and security components involved here, all of which fail in basically the same way (X didn't work). This often makes knowing EXACTLY why something failed trickier than it
Topic: App & System Services SubTopic: Core OS Tags:
Aug ’26
Reply to How are you iterating on Foundation Models prompts before building the app workflow?
Small(-ish) update relevant to the context-budget part of this thread: I ended up building MCP client support into LocalLM Lab (v0.4), and it turned the what fits in the context window question from the original post into something very concrete. MCP servers advertise their tools with full JSON schemas, and those schemas count against the same ~4096-token budget as everything else the model sees. Some servers are cheap (a couple hundred tokens for everything); others are not. For example, Linear's full tool list alone would blow the budget on its own. So the UI ended up being: every tool starts disabled per server, and you enable only what a given task needs, one or two at a time. This covers both privacy+security in a dev environment. It's a more literal version of the same problem this thread was originally about - deciding what the model actually needs to see versus what's just available. One upside of building against this specific constraint: since the model's already local and free to call, there's no A
Topic: Machine Learning & AI SubTopic: Foundation Models Tags:
Aug ’26
APNs sandbox: Has HTTP/2 request-rejection behavior changed?
Beginning July 29, 2026, we noticed a higher number of error responses from api.sandbox.push.apple.com: http2: server sent GOAWAY and closed the connection; LastStreamID=2147483647; ErrCode=PROTOCOL_ERROR; debug=Stream 3 does not exist for inbound frame DATA, endOfStream = true The errors: Occur across multiple independent applications and regions. Are concentrated on the APNs sandbox endpoint. Did not coincide with a deployment or configuration change in our service. Were not accompanied by other typical failures such as 400 BadDeviceToken. Also increased on the APNs production endpoint, though the large majority remain concentrated on the sandbox endpoint. Could Apple confirm whether APNs recently changed how notification requests are validated or rejected, particularly in the sandbox environment? We can provide exact UTC timestamps, source regions, request metadata, and logs privately if needed.
Topic: App & System Services SubTopic: Notifications Tags:
5
0
1.1k
Aug ’26
Reply to Kernel Sandbox/System Policy intermittently denies ALL file access (not just mount syscall) on NFS mounts
---Update: it's been 12 days since we deployed the launcher-app approach (bundled Swift app running the Python job via NSTask, granted FDA on 2026-07-22) and the result looks very promising: Before the change: recurring deny(1) file-mount clusters roughly every 1-3 days (confirmed via automatic sysdiagnose captures tied directly to the denial signature), most recently 2026-07-22 16:24 — about an hour before the launcher app went live. Since 2026-07-22 17:38: zero deny(1) file-mount events in the system log, and zero new sysdiagnose captures, despite the same machine/network having plenty of ordinary flakiness (SSH timeouts, stale mounts) in that window — so the monitoring is definitely still exercising the failure paths, it's just not hitting the sandbox denial anymore. This is by far the longest clean streak we've seen in this whole investigation (the path-scope and plain-FDA hypotheses both fell apart within days of testing). Your diagnosis — that bare binaries never get a stable FDA/TCC grant in a
Topic: App & System Services SubTopic: Core OS Tags:
Aug ’26
Reply to purchase() always fails with ASDServerErrorDomain 3504 (productUnavailable) in Sandbox, while products(for:) succeeds — all 3 IAPs, JPN storefront
Update (2026-08-02): Resolved itself. As of 2026-07-31, purchase() started succeeding for all 3 products — no app-side or ASC-side change was made between my last update above (2026-07-30, ~17:00 JST) and this. The payment sheet now presents normally in Sandbox for placement, nightsky, and pro.monthly. All three completed a real purchase end-to-end via TestFlight on 2026-08-02 JST (buy -> verify -> entitlement -> finish), including one successful auto-renewal on pro.monthly. No reply was received on this thread or on FB24067333 before it resolved, so I can't confirm what changed on Apple's side. Leaving this thread and the FB open in case the AMSServerCorrelationKey values posted above are still useful for whoever eventually finds the root cause — this pattern is still recurring for other developers (see the replies under thread 836183).
Topic: App & System Services SubTopic: StoreKit Tags:
Aug ’26
Reply to Auto-renewable subscription says “Item already owned” when same Apple ID uses different app accounts
Q. Is this expected behavior for auto-renewable subscriptions? Yes Q. Can this happen in production too, or is it mainly a sandbox behavior? Applies to both environments. Q. If a user has multiple accounts inside the app but uses the same Apple ID, is the subscription considered owned by the Apple ID and restorable across those app accounts? Yes, the entitlement belongs to the Apple ID. The decision for granting access to another app account is up to developer. Q. Is it acceptable/recommended to keep a small “Already subscribed? Restore purchase” option visible on the paywall at all times? Yes Q. If the app wants to prevent the same Apple subscription from being used across multiple internal app accounts, what is the recommended approach? Please check https://developer.apple.com/documentation/appstoreserverapi/appaccounttoken
Topic: App Store Distribution & Marketing SubTopic: App Review Tags:
Jul ’26
requestTestNotification returns 4040007 although both notification URLs are configured and verified via ASC API (FB24069273)
Filed as FB24069273. Sandbox POST /inApps/v1/notifications/test consistently returns 404 {errorCode:4040007} for our app (Apple ID 6765662617), although GET /v1/apps via the App Store Connect API confirms both subscriptionStatusUrl and subscriptionStatusUrlForSandbox are set (V2). With the same JWT, sandbox POST /inApps/v1/notifications/history returns 200 with an empty history — so the key and app resolve correctly. No organic sandbox notifications have ever been delivered, despite active TestFlight sandbox subscription activity. Exhausted remediations (4040007 persists after each, with 30-60+ minute waits): Re-saving the URLs in the App Store Connect UI (two locales) Deleting and re-adding the Sandbox URL PATCH /v1/apps setting the sandbox URL + version V2 twice, with two different valid endpoints (verified by GET each time) Removing the Sandbox URL entirely to rely on the documented Production fallback Deleting BOTH URLs, waiting a full hour, a
Topic: App & System Services SubTopic: StoreKit Tags:
0
0
389
Jul ’26
Reply to StoreKit returns no in-app subscriptions on TestFlight despite correct App Store Connect configuration
Same failure signature here, independent app, adding a data point since this thread seems to be the closest match I could find. App: Safe Cracker, Bundle ID com.seanfu.safe.watchkitapp (watchOS-only), Team 574P9Q3HG7. IAP: com.seanfu.safe.fullversion (non-consumable, $1.99), currently Rejected in ASC after two review rejections that both cite the IAP failing to load (failed to load even after we tapped Retry). TN3186 checklist: fully verified — explicit App ID with IAP capability, valid signing, active membership, Paid Apps Agreement active, banking and tax active, price/localization set, no StoreKit Configuration file attached to the build under test. Symptom: Product.products(for:) returns an empty array with no error (storefront resolves correctly, e.g. USA). This reproduces both for App Review (per the rejection notes) and for my own sandbox testing under certain conditions. New data point I can add: I built a minimal 3-call repro project (same bundle ID/team, only Product.products, currentEntitl
Topic: App & System Services SubTopic: StoreKit Tags:
Jul ’26
Reply to NSURLErrorNotConnectedToInternet (-1009 / ENETDOWN) connecting to a local network host — only on macOS 27 Golden Gate Public Beta Summary
Reposting with improved readability. The content remains the same. Summary Our macOS app makes an URLRequest (via URLSession) to an HTTP(S) server on the local network (a device at a private IP address, e.g. 192.168.x.x). The request fails with NSURLErrorNotConnectedToInternet (-1009) whose underlying error resolves to ENETDOWN (POSIX errno 50) at the socket/connection level — i.e. the failure happens before any TLS/HTTP exchange, at connect() time. This only reproduces on macOS 27 Golden Gate Public Beta. The exact same build/binary works correctly on: macOS 26 Tahoe (shipping release) macOS 27 Golden Gate Developer Beta Based on our diagnosis, we believe the Local Network permission prompt itself is never firing for direct-IP (non-Bonjour) connections on this Public Beta build, leaving the app's Local Network TCC grant permanently stuck in an undetermined state — which then surfaces as ENETDOWN. This is consistent with the app not appearing at all in System Settings → Privacy & Security → Local Network,
Topic: App & System Services SubTopic: Networking Tags:
Jul ’26
Reply to APNs sandbox: Has HTTP/2 request-rejection behavior changed?
FYI Starting from yesterday (2026-08-03) we are seeing this behavior in non-sandbox as well.
Topic: App & System Services SubTopic: Notifications Tags:
Replies
Boosts
Views
Activity
Aug ’26
Reply to CTCellularPlanStatus.checkValidity(ofToken:) throws Couldn't communicate with a helper application on iOS 26
Consider this: import Foundation func main() { print(CocoaError(.xpcConnectionInvalid, userInfo: [:]).localizedDescription) // prints: Couldn’t communicate with a helper application. } main() This is NSXPCConnectionInvalid, which is equivalent to XPC_ERROR_CONNECTION_INVALID, which is in turn documented in the xpc_connection_create man page. In short, something went wrong with XPC and the XPC subsystem is not able to automatically retry. This error has a variety of potential causes: During development you often see if when the XPC service is broken some some reason. Or when the sandbox prevents you from accessing it. You can also see it when you connect to an anonymous listener and the remote peer terminates for some reason. So, this is a very general error and it’ll be hard to make progress without a sysdiagnose log. Which is tricky when you can’t reproduce the problem. I have two suggestions for you: In your standard app, you could implement a delay and retry. That may or may not help but, even if
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Aug ’26
Reply to Kernel Sandbox/System Policy intermittently denies ALL file access (not just mount syscall) on NFS mounts
Thanks, Kevin — good to have that confirmed, and appreciate the extra context on why the bundled-app path is the right default (broadest toolbox, most-tested code path) rather than a point fix for this one symptom specifically. One honest update while I have you: the launcher-app change has fully solved the FDA-attribution problem for the watchdog daemon itself (no more GUI says granted, daemon's own canary says no), but it hasn't touched the original, broader issue this thread is about. The intermittent kernel Sandbox/System Policy deny(1) on the NFS mount is still occurring independent of that fix. Concrete data point: this morning (2026-08-04, ~09:21 local), a Terminal-launched process hit the same signature we've seen throughout this thread — mount still listed the NFS volume as connected, but ls returned Operation not permitted. Terminal has had Full Disk Access granted since 2026-07-14 (well before the launcher-app change), so this wasn't an FDA-attribution issue — it's the same stale-mount/den
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Aug ’26
ExternalPurchaseCustomLink.isEligible is false on German storefront despite valid EU entitlement
We are implementing StoreKit External Purchase Link for an iOS app distributed in the European Union and are trying to determine whether we are missing a configuration step or encountering a StoreKit server-side eligibility issue. The failure is reproducible in a focused native Swift Xcode project that directly calls StoreKit: let eligible = await ExternalPurchaseCustomLink.isEligible The sample contains no Flutter code, PayPal SDK, networking, or application business logic. Configuration we have verified: The Account Holder accepted the StoreKit External Purchase Link Entitlement Addendum for EU Apps. StoreKit External Purchase Link is enabled and shown as Assigned for the App ID. The regenerated Development provisioning profile contains com.apple.developer.storekit.external-purchase-link = true. The installed app's signed entitlements contain the same value. The application-identifier and team-identifier match the intended App ID and team. The compiled Info.plist contains SKExternalPurchaseCustomLinkRegions
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
0
Boosts
0
Views
554
Activity
Aug ’26
Reply to Kernel Sandbox/System Policy intermittently denies ALL file access (not just mount syscall) on NFS mounts
---Update: it's been 12 days since we deployed the launcher-app approach (bundled Swift app running the Python job via NSTask, granted FDA on 2026-07-22) and the result looks very promising: Excellent! One small comment here: Your diagnosis — that bare binaries never get a stable FDA/TCC grant in a launchd context, and wrapping the job in a proper .app bundle fixes that — looks correct. I didn't get into the details at the time, but there are actually a few different issues here: Most of our command line tools are designed so that they always inherit the sandbox of their parent process, which can make things complicated if/when you don't directly control whatever is launching the tool. Granting something like FDA to a general command line tool (like Python) obviously has very serious security concerns. There are a lot of edge cases and security components involved here, all of which fail in basically the same way (X didn't work). This often makes knowing EXACTLY why something failed trickier than it
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Aug ’26
Reply to How are you iterating on Foundation Models prompts before building the app workflow?
Small(-ish) update relevant to the context-budget part of this thread: I ended up building MCP client support into LocalLM Lab (v0.4), and it turned the what fits in the context window question from the original post into something very concrete. MCP servers advertise their tools with full JSON schemas, and those schemas count against the same ~4096-token budget as everything else the model sees. Some servers are cheap (a couple hundred tokens for everything); others are not. For example, Linear's full tool list alone would blow the budget on its own. So the UI ended up being: every tool starts disabled per server, and you enable only what a given task needs, one or two at a time. This covers both privacy+security in a dev environment. It's a more literal version of the same problem this thread was originally about - deciding what the model actually needs to see versus what's just available. One upside of building against this specific constraint: since the model's already local and free to call, there's no A
Topic: Machine Learning & AI SubTopic: Foundation Models Tags:
Replies
Boosts
Views
Activity
Aug ’26
APNs sandbox: Has HTTP/2 request-rejection behavior changed?
Beginning July 29, 2026, we noticed a higher number of error responses from api.sandbox.push.apple.com: http2: server sent GOAWAY and closed the connection; LastStreamID=2147483647; ErrCode=PROTOCOL_ERROR; debug=Stream 3 does not exist for inbound frame DATA, endOfStream = true The errors: Occur across multiple independent applications and regions. Are concentrated on the APNs sandbox endpoint. Did not coincide with a deployment or configuration change in our service. Were not accompanied by other typical failures such as 400 BadDeviceToken. Also increased on the APNs production endpoint, though the large majority remain concentrated on the sandbox endpoint. Could Apple confirm whether APNs recently changed how notification requests are validated or rejected, particularly in the sandbox environment? We can provide exact UTC timestamps, source regions, request metadata, and logs privately if needed.
Topic: App & System Services SubTopic: Notifications Tags:
Replies
5
Boosts
0
Views
1.1k
Activity
Aug ’26
Reply to Kernel Sandbox/System Policy intermittently denies ALL file access (not just mount syscall) on NFS mounts
---Update: it's been 12 days since we deployed the launcher-app approach (bundled Swift app running the Python job via NSTask, granted FDA on 2026-07-22) and the result looks very promising: Before the change: recurring deny(1) file-mount clusters roughly every 1-3 days (confirmed via automatic sysdiagnose captures tied directly to the denial signature), most recently 2026-07-22 16:24 — about an hour before the launcher app went live. Since 2026-07-22 17:38: zero deny(1) file-mount events in the system log, and zero new sysdiagnose captures, despite the same machine/network having plenty of ordinary flakiness (SSH timeouts, stale mounts) in that window — so the monitoring is definitely still exercising the failure paths, it's just not hitting the sandbox denial anymore. This is by far the longest clean streak we've seen in this whole investigation (the path-scope and plain-FDA hypotheses both fell apart within days of testing). Your diagnosis — that bare binaries never get a stable FDA/TCC grant in a
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Aug ’26
Reply to purchase() always fails with ASDServerErrorDomain 3504 (productUnavailable) in Sandbox, while products(for:) succeeds — all 3 IAPs, JPN storefront
Update (2026-08-02): Resolved itself. As of 2026-07-31, purchase() started succeeding for all 3 products — no app-side or ASC-side change was made between my last update above (2026-07-30, ~17:00 JST) and this. The payment sheet now presents normally in Sandbox for placement, nightsky, and pro.monthly. All three completed a real purchase end-to-end via TestFlight on 2026-08-02 JST (buy -> verify -> entitlement -> finish), including one successful auto-renewal on pro.monthly. No reply was received on this thread or on FB24067333 before it resolved, so I can't confirm what changed on Apple's side. Leaving this thread and the FB open in case the AMSServerCorrelationKey values posted above are still useful for whoever eventually finds the root cause — this pattern is still recurring for other developers (see the replies under thread 836183).
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Aug ’26
Reply to StoreKit returns 0 subscription products in Sandbox/TestFlight — payment sheet never opens (auto-renewable subscriptions)
Building from Xcode and using sandbox account will show the subscriptions. For TestFlight flow the subscriptions have to be approved by App Review first as TestFlight can allow distribution to external testers.
Topic: App Store Distribution & Marketing SubTopic: App Store Connect API Tags:
Replies
Boosts
Views
Activity
Jul ’26
Reply to Auto-renewable subscription says “Item already owned” when same Apple ID uses different app accounts
Q. Is this expected behavior for auto-renewable subscriptions? Yes Q. Can this happen in production too, or is it mainly a sandbox behavior? Applies to both environments. Q. If a user has multiple accounts inside the app but uses the same Apple ID, is the subscription considered owned by the Apple ID and restorable across those app accounts? Yes, the entitlement belongs to the Apple ID. The decision for granting access to another app account is up to developer. Q. Is it acceptable/recommended to keep a small “Already subscribed? Restore purchase” option visible on the paywall at all times? Yes Q. If the app wants to prevent the same Apple subscription from being used across multiple internal app accounts, what is the recommended approach? Please check https://developer.apple.com/documentation/appstoreserverapi/appaccounttoken
Topic: App Store Distribution & Marketing SubTopic: App Review Tags:
Replies
Boosts
Views
Activity
Jul ’26
requestTestNotification returns 4040007 although both notification URLs are configured and verified via ASC API (FB24069273)
Filed as FB24069273. Sandbox POST /inApps/v1/notifications/test consistently returns 404 {errorCode:4040007} for our app (Apple ID 6765662617), although GET /v1/apps via the App Store Connect API confirms both subscriptionStatusUrl and subscriptionStatusUrlForSandbox are set (V2). With the same JWT, sandbox POST /inApps/v1/notifications/history returns 200 with an empty history — so the key and app resolve correctly. No organic sandbox notifications have ever been delivered, despite active TestFlight sandbox subscription activity. Exhausted remediations (4040007 persists after each, with 30-60+ minute waits): Re-saving the URLs in the App Store Connect UI (two locales) Deleting and re-adding the Sandbox URL PATCH /v1/apps setting the sandbox URL + version V2 twice, with two different valid endpoints (verified by GET each time) Removing the Sandbox URL entirely to rely on the documented Production fallback Deleting BOTH URLs, waiting a full hour, a
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
0
Boosts
0
Views
389
Activity
Jul ’26
Reply to StoreKit returns no in-app subscriptions on TestFlight despite correct App Store Connect configuration
Same failure signature here, independent app, adding a data point since this thread seems to be the closest match I could find. App: Safe Cracker, Bundle ID com.seanfu.safe.watchkitapp (watchOS-only), Team 574P9Q3HG7. IAP: com.seanfu.safe.fullversion (non-consumable, $1.99), currently Rejected in ASC after two review rejections that both cite the IAP failing to load (failed to load even after we tapped Retry). TN3186 checklist: fully verified — explicit App ID with IAP capability, valid signing, active membership, Paid Apps Agreement active, banking and tax active, price/localization set, no StoreKit Configuration file attached to the build under test. Symptom: Product.products(for:) returns an empty array with no error (storefront resolves correctly, e.g. USA). This reproduces both for App Review (per the rejection notes) and for my own sandbox testing under certain conditions. New data point I can add: I built a minimal 3-call repro project (same bundle ID/team, only Product.products, currentEntitl
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Jul ’26
Reply to App Store Connect IAP Catch-22
I encountered the same issue when submitting a watchOS app. Although I later realized I needed to include IAP with the app in the submission. Yet, they still rejected me with 2.1(b), claiming that IAP cannot be purchased. However, purchasing via a sandbox account in TestFlight works fine, and I also submitted the recording.
Topic: App Store Distribution & Marketing SubTopic: App Store Connect Tags:
Replies
Boosts
Views
Activity
Jul ’26
Reply to NSURLErrorNotConnectedToInternet (-1009 / ENETDOWN) connecting to a local network host — only on macOS 27 Golden Gate Public Beta Summary
Reposting with improved readability. The content remains the same. Summary Our macOS app makes an URLRequest (via URLSession) to an HTTP(S) server on the local network (a device at a private IP address, e.g. 192.168.x.x). The request fails with NSURLErrorNotConnectedToInternet (-1009) whose underlying error resolves to ENETDOWN (POSIX errno 50) at the socket/connection level — i.e. the failure happens before any TLS/HTTP exchange, at connect() time. This only reproduces on macOS 27 Golden Gate Public Beta. The exact same build/binary works correctly on: macOS 26 Tahoe (shipping release) macOS 27 Golden Gate Developer Beta Based on our diagnosis, we believe the Local Network permission prompt itself is never firing for direct-IP (non-Bonjour) connections on this Public Beta build, leaving the app's Local Network TCC grant permanently stuck in an undetermined state — which then surfaces as ENETDOWN. This is consistent with the app not appearing at all in System Settings → Privacy & Security → Local Network,
Topic: App & System Services SubTopic: Networking Tags:
Replies
Boosts
Views
Activity
Jul ’26