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.