Recent IOS Release breaks HTTP Client - Potential Fix detailed

[Robert Dunkley]

A recent IOS update seems to have broken my HTTP client (Non-SSL) in Iviewer. Not matter what I do the debug system page show now traffic for the HTTP client system. Same HTTP endpoint works fine for Safari. Switching to TCP client also works but is more complex to work with.

After some debug with Gemini it thinks a small update to the app is needed:

Hi CommandFusion Team,

Recent iOS updates have broken the native "HTTP Client" system protocol when connecting to unencrypted custom local ports (e.g., trying to send plain HTTP commands to local proxies or automation hubs on ports like 8080 or 8089). The iOS kernel now silently drops these cleartext HTTP client sockets, causing no packets to leave the device even though raw TCP connections still work.

To restore native HTTP Client functionality on modern iOS builds, could you please update the iViewer application package to include the standard Apple App Transport Security (ATS) local networking exceptions?

Specifically, the app's Info.plist needs the following keys added under NSAppTransportSecurity:

xml

<key>NSAppTransportSecurity</key> <dict> <!-- Allows HTTP client connections to local IP addresses and custom ports --> <key>NSAllowsLocalNetworking</key> <true/> <!-- Permits arbitrary loads for legacy hardware integrations --> <key>NSAllowsArbitraryLoads</key> <true/> </dict>

Use code with caution.

Adding these keys will signal to iOS that iViewer is a control application authorized to make unencrypted local HTTP API calls, resolving the silent packet-dropping issue without forcing users to migrate entirely to manually crafted raw TCP strings.