I was happy to find a hidden gem in Rhodes 5.0.38.

Reading the release notes, one might think that 5.0.38 is all about per-app VPN (which is a really nice feature for BYOD Enterprise apps). But it's also the current official release, and it contains a hidden gem - two, actually, at least for iOS apps.

There are two new settings in rhoconfig.txt. Here are the settings that I'm using, along with a small added comment of my own:

# turn on http server traces, off by default
# This is erroneously documented as effecting only 'local server traces' - not true
# Update: as of 5.0.38 it appears this no longer traces external network operations
# I think this just traces cUrl code. So, if ios_net_curl = false, this setting
# has no effect. That makes sense - this will trace all cUrl networking, whether
# local or remote.
# Use this to get full trace on all HTTP requests OTHER than local server!
# Note that the log level does not affect this setting - it is independent of log level
# Note: this has no effect if using ios_direct_local_requests = true, becuase in that
# case there aren't any "http server" network requests!
net_trace = '1'
# If true, an old libCURL-based Net request will be used.
# This option can be enabled for regression testing or if custom proxy support is required.
# Default is TRUE but, to support per-app VPN (ex. MobileIron) this option should be set to FALSE.
ios_net_curl = false

# If true, request to local server will be applied directly, bypassing socket intercommunication,
# no network requests are involved. If false, a legacy client-server intercommunication will be made
# for local requests. Default is FALSE but, to support per-app VPN (ex. MobileIron) this option
# should be set to TRUE.
#
# Note: you will not be able to test pages by pointing a desktop browser to port 8080 if this
# is set to true. I can't remember when I last did that, since we have Web Inspector.
ios_direct_local_requests = true

Read the true/false comments carefully, it's a bit confusing!

Network code in iOS Rhodes has, up until now, been based on the cUrl library, and a rather old version of it to boot. I get the impression that it's fiddly and not something that RhoMobile has wanted to touch much, for fear of breaking it. Reading between the lines, it was probably easier to write some shiny new networking code, than it would have been to hack away at cUrl in order to include the per-app VPN capability.

And reading through the repo checkin comments, I see encouraging things like "fixed multi-part file upload..."

As well, up until now, Rhodes has exposed an IP port on which an HTTP server responds, and which handles requests from the WebView, as well as for queueing callbacks. That is normally a random IP port, but for some testing purposes, you can set it to a fixed port (typically port 8080) which allows you to point your desktop browser at it and facilities some easy testing of your pages.

I'd imagine that those developers who want to use a per-app VPN are probably doing it because they are security-conscious (duh!) and wouldn't be too happy about exposing the HTTP server on any IP port - whether fixed or random. (It only takes a few seconds to scan all possible IPV4 ports on a socket to find an HTTP server.)

So, now you have the option of not using an IP port at all for the local server. If ios_direct_local_requests is set true, no IP port is used, and internal communication is done without using or needing an IP port. This removes a vulnerability. I'd imagine there might be a technical implementation reason for this change, as well. (As in, if you use the VPN, I'd imagine ALL IP traffic goes through the VPN. And the Rhodes internal server is not at the other end of your VPN at the Home Office in Minneapolis...)

You do lose the ability to view your pages from a desktop browser, but there is little to no need for that today, because Safari supports remote inspection/debug of WebViews in an app, and you can use it with Rhodes apps either in the Apple iOS simulator, or on a real device connected by USB. (Not available for production build, so, no vulnerability there.)

The above settings are the ones I am now testing in a very large app that doesn't a great deal of network I/O to a variety of hosts (multiple APIs, Dropbox, etc.), and I have yet to encounter any issues.

Tread carefully, as this is new. I'd love to hear about other's experience with these new hidden gems!

I haven't looked at the other platforms - Android, WM, etc. to see what side-effects or benefits might be lurking in those platforms, or whether they've needed this much of a rewrite.