Suddenly can't run on iOS, help!


#1

Out of the blue, now when I do meteor run ios-device, my app on iOS shows the splash screen and the first entry screen, but no login/signup buttons. Web works as before, no suspicious error messages as far as I can tell.

I rebooted. I rolled back to an older version. I even did meteor remove-platofm ios and meteor-add-platform ios. Nothing helps.

Saffari developer tool now says connection to 127.0.0.100-something times out. That’s the only error message I am getting. I’ll follow up with the exact message later tonight.

It worked last night and stopped working first thing in the morning, without any action on my part as far as I could tell.

I need it to work tomorrow. Please help!


#2

The error messages I am getting at Web Inspector:

failed to load resource: Could not connect to the server. http://192.168.0.100:3000/sockjs/info?cb=t7qu....

When trying to click on the link on the Macbook, I am getting “an error occurred trying to load the resource”.

Trying to reach 192.168.0.100:3000 in Chrome times out.

localhost:3000 works fine


#3

Actually, I don’t even know whose IP address is that. It’s neither my Macbook nor my iPhone. Besides, why is it even trying to access LAN when it’s connected via USB?


#4

What do you mean by ‘it’s connected via USB’? Just that it is plugged in, or have you set up a personal hotspot? If the former, that USB connection has no bearing on the way your app connects to your server. The app will need to know the local address of the server, and that server needs to be reachable over the network. That usually means your development machine and the device will have to be on the same WiFi network.

meteor run ios-device tries to detect the local address of your development machine. 192.168.0.100 seems reasonable, but if that is somehow not the address you need you can specify a different one using --server.

Note that if your local address has changed, there is currently an issue with hot code push that requires you to delete the app from the device first before running/installing.

Another thing to keep in mind is that Meteor actually needs to be running on your development machine. meteor run ios-device both opens Xcode and keeps running the server code, so make sure not to stop the process while you’re running the app.


#5

can you run the simulator? i ran into this issue https://github.com/meteor/meteor/issues/4560 recently. i could not get io9 simulators or devices to connect to the server. i just switched to using ios 8.4 on the simulator and an non-updated ios device.

you should also be able to allow non-ssl connections by editing the app from within xcode before running on the device - see http://stackoverflow.com/questions/30731785/how-do-i-load-an-http-url-with-app-transport-security-enabled-in-ios-9

i should note that i also need to run with specifying the --mobile-server option to be the ip+port of my development machine (192.168.1.XX:3000 for me)


#6

After a few days, the problem disappeared as suddenly as it appeared.

I am almost positive that it favors some local IP addresses over others. I.e. it works when my Macbook has address 192.168.0.101, but not when it has 192.168.1.101. Running with --mobile-server did not help (neither with local mobile server, nor when it was the real server on AWS).

I could connect Safari to iOS, and could see that Meteor.status() was either “waiting” or “connecting”, never “connected”.

Thank you everyone for your help! Much appreciated.


#7

Forgot to mention. I did delete the iOS app before every redeployment, rebooted, etc.

I also could not run in simulator. In simulator, got stuck even earlier, in the splash screen.

(BTW, is there any way to get console output from simulator?)


#8

Found the problem. The phone was on a different network, on and off. Silly me! (but then, as could be seen from my post, I thought the phone speaks to the Mac via USB).

Still don’t understand why it would not talk to the aws server, but maybe the phone had no Internet at all.

It would be nice if this condition was tested for, at least at deployment time, with a nice error message.