Hello

If the remote debug console works when your computer is connected to your iPhone hotspot, it means the problem can be solved.

FYI, the IP of your computer is stamped into your app *at build time* so that the remote debug console can pick it up at the earliest possible moment during your app startup. It then connects to that IP over a couple TCP ports (one for standard output and one for standard error) and proceeds routing all messages sent to the stdout/stderr file descriptors to these channels instead. It means that, *if the IP that is stamped in your app at build time is wrong, the remote debug console will send its logs to the wrong location*, and your computer won't receive anything. This is most probably what's happening here.

Most of the time the problem is that the builder UI fails to pick up the right LAN IP address of your computer (that's the IP address in the text field next to the "Enable remote debug console" checkbox). When you build your app, especially when your computer obtains a dynamic (i.e. ever-changing) IP address through a home Wifi router that has a DHCP server, before hitting the build button, you need to check that the IP address that's written there actually corresponds to the *local* IP address of your computer. In your case, it should have been 192.168.1.38 ; if that IP is not the IP of your computer at the moment you hit the build button, you need to correct it.

I don't think you require that level of explanation, but in case you wonder how to figure out your computer's current local IP address, you can use the "ipconfig" command in a command-line window. It will display the current IP addresses of all your network interfaces (a.k.a "network cards"), whether they be Wi-Fi, Ethernet, or even virtual interfaces (those are typically created by virtual machines). Make sure you pick the IP address of the interface that corresponds to your *primary* interface, i.e. the one through which packets pass when they go back and forth between your iPhone and your computer.

If your computer obtains its IP addresses through DHCP and you frequently use the remote console, I suggest that you set it with a fixed address instead, one that never changes. This way, apps compiled with the IP that was valid two days ago will still be able to send their logs to your computer, because its IP address will be the same. When setting a fixed address for your computer, make sure to select an IP address that is at the same time :
- unused
- on the same network segment as those the DHCP server offers, and
- outside of the range that the DHCP server offers, so as to avoid collisions.

For example, if you're on a class C network 192.168.1.XXX and your DHCP server offers addresses that range from 192.168.1.10 to 192.168.1.100, you can pick 192.168.1.101 for your computer, but not 192.168.1.99. Assuming, of course, that no other device already uses that address. To find that out, turn them all on and try to ping that address. If nobody responds, you may use it.

Let me know if I'm mistaken and the problem is elsewhere, and we'll look for other causes (firewall, etc).

Another common cause, second in frequency, is a stupid setting that Windows enforces when it connects itself for the first time to a network. When it happens, Windows typically asks you what type of network is that (home/office/public), so as to know which firewall rules to enforce (open/restricted/closed) on that network, but sometimes it doesn't ask you at all, or the dialog window is hidden behind a fullscreen window - and then it defaults to the most secure network, i.e. "Public" and you aren't even notified about it. When that's the case, each time your computer connects to that network, the most restrictive firewall settings are automatically and silently enforced, which means no incoming connection is allowed - and this prevents the remote debug console app from receiving messages from your iPhone - until you go into the Windows Network settings and change that very network type to "Home" or "Office". Make sure to check that too.

Let me know if the problem persists. Best regards,

Excellent diagnosis.

Another issue that appeared in recent iOS releases is the following: newly installed apps are required to ask the user for permission to access system resources. This is done at iOS level, and is true for network access, which the remote console uses. As long as you haven't told iOS that you allow your app to access the network, it won't allow network access, but since the allow pop-up dialog fires up *after* the remote console tries to connect, this results in a remote console connection failure the first time you launch the app.

It is necessary for the remote debug console to kick in at the earliest possible time, that's why it can't delay its connection until after iOS decides to ask the user for permission.

I usually work this around by opening the app once, waiting for iOS to ask my permission to grant this app network access (meanwhile, the app complains that it couldn't connect to the remote debug console), then I explicitly close the app in the iOS task manager and open it again. This time the remote debug console works.

Let me know if that sounds like a description of your problem.

:: @Pierre-Marie Baty added on 06 Jul ’21 · 09:15

Also, it is possible that locally enforced security policies on your iOS device silently deny network access to your app, and you are never asked about that. If it's the case, it should be fixable in the iOS Settings.

Why it would work when your device is acting as a hotspot is somewhat intriguing though ; maybe iOS fails to handle this case.

This is getting interesting. I can attest that there is no caching of any sort in the remote debug console code. The code is actually quite simple : your computer's IP is hardcoded into a const char array (a string). The app's entrypoint is rerouted to a proxy function with the same prototype. When iOS launches your app, that new entrypoint is called instead of main(), and the remote debug console code kicks in. Then, if that const string with the IP exists, two TCP connections are made to that IP, and upon success the file handles associated with stdout and stderr are duplicated using dup2() and redirected to these TCP connections. Then, the app's original entrypoint i.e. the original main() is called. It all boils down to 20 lines of code in the app.

Considering all this, and knowing that it works when you use a particular provisioning profile and doesn't work when you use another, I am tempted to believe it's iOS that refuses network access in one case and not in the other.

It would be interesting to compare the PLists that are in the old provisioning profile and in the new one. With the exception of the bundle identifier, are they the same ? Maybe your app has a conflicting requirement or entitlement that needs to be handled specially.

So it tends to confirm it's a device problem rather than a provisioning problem.

Does your teammate use the same signing identity as you, or a different one ?

Does the console behave differently when he builds and deploys the very same project that doesn't work with your device ?

What is the model of his iPhone and what's yours ?

As I can't reproduce the problem here, I'll need you to set up a few methodical test cases with your teammate, until the trigger of the problem can be pinpointed as accurately as possible. Thank you for your understanding and cooperation.