SignalR connect fails on iOS MAUI (.NET 10) — _conn.Start() throws 500

Thank you for reaching out.

The issue is that the SignalR connection fails after negotiate, during _conn.Start(). This means the server is throwing an error while handling the actual connection request from the iOS app, even though negotiate succeeds.

What you can do to resolve this:

• Check the server/IIS logs at the time _conn.Start() is called from iOS. You will find a server-side exception for /signalr/connect or /signalr/start, which explains why HTTP 500 is returned.
• Verify that the server supports the transport used by the iOS client (for example WebSockets). If WebSockets are blocked or not fully enabled in IIS, proxy, or firewall, the start request will fail.
• Compare the iOS request with Android (headers, transport, URL path). You will usually see a difference that explains why only iOS hits the server error.

Once the server-side exception or transport issue is fixed, _conn.Start() will succeed on iOS as well.

References:

• ASP.NET Core SignalR connection troubleshooting Troubleshoot connection errors
• Troubleshooting guide for Azure SignalR Service common issues Please let us know if you require any further assistance, we’re happy to help. If you found this information useful, kindly mark this as "Accept Answer". So that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

The 500 error on _conn.Start() indicates a server-side failure during the SignalR negotiation/handshake for this specific iOS MAUI client, even though Android and Safari succeed. The context provides general SignalR troubleshooting patterns that apply here.

Use the following steps to isolate and fix the issue:

1. Check server logs for the 500 details
   A 500 from SignalR is almost always explained in the server logs. On the server:
   • Enable detailed logging for SignalR and the app.
   • Look for exceptions thrown when the iOS client connects (time-correlated with the iOS _conn.Start() call).
     The generic guidance is that the details of a 500 error should appear in the server’s event log or via debugging.
2. Verify platform support and client compatibility
   • ASP.NET SignalR (Microsoft.AspNet.SignalR.Client) is the classic SignalR stack; MAUI on .NET 10 is a modern client platform. Ensure the server is not relying on unsupported transports or assumptions about the client platform.
   • Confirm that the iOS MAUI app is using a supported HTTP stack and TLS configuration compatible with the server (for example, no outdated TLS/cipher requirements that iOS rejects or vice versa).
   • If possible, test with ASP.NET Core SignalR and the modern .NET client, which is explicitly supported on MAUI and mobile platforms.
3. Check for CORS / cross-domain and auth differences
   Even if Safari and Android work, the iOS MAUI client may differ in:
   • Origin or headers sent during negotiate/connect.
   • Cookies or authentication tokens.
     Misconfigured cross-domain or auth can cause server-side exceptions that surface as 500. For classic SignalR, cross-domain misconfiguration can cause silent failures or 403/500 responses; verify that the server is configured to accept the MAUI client’s origin and auth method.
4. Inspect for generic SignalR 500 causes
   Classic SignalR troubleshooting notes that:
   • A 500 can be caused by mismatched .NET framework versions or configuration on the server.
   • Firewalls or proxies that rewrite headers or block WebSockets/long polling can cause 500 or “Unexpected response code: 500”.
     For this scenario, check whether iOS traffic is routed differently (VPN, proxy, corporate Wi‑Fi) compared to Android and Safari.
5. Enable detailed SignalR diagnostics on the server
   For ASP.NET/ASP.NET Core SignalR, enable detailed logging to capture the handshake and transport selection:
   • For ASP.NET Core SignalR, integrate with ILogger and set Microsoft.Azure.SignalR or Microsoft.AspNetCore.SignalR categories to Debug in configuration.
   • For classic ASP.NET SignalR, enable tracing in web.config as documented.
     Then reproduce the iOS failure and inspect the logs for:
   • Exceptions thrown in hub constructors, OnConnected, OnConnectedAsync, or authorization.
   • Transport negotiation failures specific to the iOS user agent.
6. Compare request details between working and failing clients
   Use server logs or a reverse proxy to compare:
   • Request path and query (/signalr/negotiate, /signalr/connect, /signalr/start).
   • Headers (User-Agent, Origin, Accept, cookies, auth headers).
   • Chosen transport (WebSockets vs. Server-Sent Events vs. Long Polling).
     If the iOS client is forced to a different transport that the server or hosting environment does not fully support, that can cause a 500.
7. Validate that the hub and routes are configured correctly
   Classic SignalR troubleshooting highlights that:
   • The MapSignalR route must be added before other routes.
   • IIS configuration issues (extensionless URLs, outdated cache) can cause unexpected 500/404 behavior.
     If the iOS client hits a slightly different URL or scheme (e.g., https with a nonstandard port) that triggers a different route or module, that can surface as 500.
8. If using Azure SignalR Service
   If the endpoint is backed by Azure SignalR Service:
   • A 500 during negotiate can occur if the app server is not connected to Azure SignalR.
   • Enable server-side logging for Azure SignalR categories and check for connection errors between the app server and the service.

In practice, the next concrete steps are:

1. Turn on detailed SignalR and application logging on the server.
2. Reproduce the issue from iOS and capture the exact exception and stack trace on the server.
3. Compare the iOS and Android/Safari negotiate and connect requests to identify any difference in headers, auth, or transport that could trigger server-side exceptions.

References:

• Troubleshooting guide for Azure SignalR Service common issues
• SignalR Troubleshooting
• SignalR Troubleshooting (SignalR 1.x)
• Troubleshoot connection errors
• ASP.NET Core SignalR supported platforms
• iOS: Loading Overlay Sometimes Fails to Dismiss After Async Operation - Microsoft Q&A