ATS on watchOS is fundamentally broken for generic client apps. Why is Apple killing innovation?

I spent the entire day debugging a network issue on my Apple Watch app, only to realize the problem isn't my code—it's Apple's inflexible design.

The Context: I am building a generic MCP (Model Context Protocol) client for watchOS. The nature of this app is to allow users to input their own server URLs (e.g., a self-hosted endpoint, or public services like GitHub's MCP server) to interact with LLMs and tools.

The Problem: When using standard URLSession to connect to widely trusted, public HTTPS endpoints (specifically GitHub's official MCP server at https://mcp.github.com), the connection is forcefully terminated by the OS with NSURLErrorDomain Code=-1200 (TLS handshake failed).

The Analysis: This is caused by App Transport Security (ATS). ATS is enforcing a draconian set of security standards (specific ciphers, forward secrecy requirements, etc.) that many perfectly valid, secure, and globally accepted servers do not strictly meet 100%.

The Absurdity:

  1. We cannot whitelist domains: Since this is a generic client, I cannot add NSExceptionDomains to Info.plist because I don't know what URL the user will input.
  2. We cannot disable ATS: Adding NSAllowsArbitraryLoads is a guaranteed rejection during App Store review for a general-purpose app without a "compelling reason" acceptable to Apple.
  3. The result: My app is effectively bricked. It cannot connect to GitHub. It cannot connect to 90% of the user's self-hosted servers.

The Question: Is the Apple Watch just a toy? How does Apple expect us to build flexible, professional tools when the OS acts like a nanny that blocks connections to GitHub?

We need a way to bypass strict ATS checks for user-initiated connections in generic network tools, similar to how curl -k or other developer tools work. The current "all-or-nothing" policy is suffocating.

Answered by EricTerminal in 866292022

CORRECTION: A crucial piece of information in my original post is incorrect, and I want to correct the record immediately. The endpoint https://mcp.github.com was used as an example, but it has been confirmed that this is not a public or active MCP server. My apologies for using an outdated example and for any confusion this may have caused

UPDATE: Despite this specific example being wrong, the core issue remains unchanged. The fundamental problem with Apple's App Transport Security (ATS) still prevents generic client apps on watchOS from connecting to a wide range of user-defined, self-hosted, or community-provided servers that do not perfectly align with Apple's strict, non-negotiable TLS standards. My central argument and frustration with this inflexible policy still stand.

Accepted Answer

CORRECTION: A crucial piece of information in my original post is incorrect, and I want to correct the record immediately. The endpoint https://mcp.github.com was used as an example, but it has been confirmed that this is not a public or active MCP server. My apologies for using an outdated example and for any confusion this may have caused

UPDATE: Despite this specific example being wrong, the core issue remains unchanged. The fundamental problem with Apple's App Transport Security (ATS) still prevents generic client apps on watchOS from connecting to a wide range of user-defined, self-hosted, or community-provided servers that do not perfectly align with Apple's strict, non-negotiable TLS standards. My central argument and frustration with this inflexible policy still stand.

ATS on watchOS is fundamentally broken for generic client apps. Why is Apple killing innovation?
 
 
Q