Restore ability to use SOCKS proxies for debugging

[casey-chow]

Use case

I'm trying to debug our web socket usage over the wire, and am mostly unable to use tools like Proxyman or Charles. SOCKS proxying was previously enabled but seems to have been enabled due to a Starscream upgrade (#1104) that was reverted in 0.47.0.

Describe the solution you'd like

Re-expose the useSOCKSProxy variable.

[calvincestari]

Hi @casey-chow 👋🏻 - thanks for raising the issue. I was not aware this had dropped in the Starscream changes. It looks like we'll need to reapply #1108 to bring this back. I don't have any immediate objection to doing that; @AnthonyMDev can you think of any reason why we shouldn't?

We are scheduled to rebuild the networking stack later in the year which will completely change things and I can't guarantee it for that major version release though.

[casey-chow]

The other thing we're looking at would be to set up a WebSocket client based using URLSessionWebSocketTask, which would give us the benefit of using tools like Atlantis. I'm guessing if the iOS version support range stays intact that's not going to be much of an option though.

[calvincestari]

The other thing we're looking at would be to set up a WebSocket client based using URLSessionWebSocketTask, which would give us the benefit of using tools like Atlantis.

I don't think that's going to be possible with the way the networking/websocket stack is set up at the moment. It's quite closed in terms of being able to use other libraries with it. That's one of the major changes coming in 2.0; getting back to the standard Apple stuff and giving users the option to use Apollo iOS with their own networking stuff.

I'm guessing if the iOS version support range stays intact that's not going to be much of an option though.

I'm not sure what you mean here. Apollo iOS 2.0 will probably jump up to a minimum of iOS 13/14, it's 12 right now.

[winstondu]

Hi @casey-chow 👋🏻 - thanks for raising the issue. I was not aware this had dropped in the Starscream changes. It looks like we'll need to reapply #1108 to bring this back. I don't have any immediate objection to doing that; @AnthonyMDev can you think of any reason why we shouldn't?

Please let us know!