Meteor: Built apps cannot connect to the given --server: they keep failing to connect

[SylvainBigonneau]

My app works perfectly:

• On browser, both locally and deployed
• On emulator, using either the local or deployed server
• On my device when using run android-device, using either the local or deployed server

But somehow, when I build it following these instructions, at the first server call, for example:

console.log("test1");
Meteor.call("someMethod", function (error, result) {
  console.log("test2");
});
// yes I know how asynchronous calls work
console.log("test3");

Or:

console.log("test1");
Meteor.loginWithPassword("validUsername", "validPassword", function (error, result) {
  // should print no matter if the credentials are good or bad anyway
  console.log("test2");
});
console.log("test3");

"test2" does not get printed in the adb logcat, even though "test1" and "test3" do. There is a mapbox map that loads fine, so it's not an internet access issue. Also, startup works:

Meteor.startup(function () {
  console.log("this gets printed in the adb console");
});

So it's not ALL Meteor methods. I used both my deployed and local server: there were no errors reported on the server log. I also tested hot-code push on my local server, it does reload the app on my phone! But only the first time I launch the app only after it's freshly installed. Still, there is at least some kind of connection between them.

I should also mention that I already built this app and it worked fine before, but I did not build it in a while and now it doesn't work anymore. I installed the package on two different devices and get the exact same issue.

Here is my package list if it can help, all on the latest version available:

iron:router
sacha:spin
accounts-password
accounts-base
mdg:geolocation
mrt:flash-messages
mdg:camera
useraccounts:ratchet
fastclick
alanning:roles
tap:i18n
simple:imgur

Here are the client's logs when I launch it on my local server:

I/CordovaLog(18991): Changing log level to DEBUG(3)
I/CordovaLog(18991): Found start page location: index.html
D/CordovaLog(18991): file:///android_asset/www/meteor_cordova_loader.js: Line 12 : METEOR CORDOVA DEBUG (meteor_cordova_loader.js) Error reading version file Error: Failed to resolve entry: file:///data/data/com.idz9099616fhad1150nrz/files/meteor/version
D/CordovaLog(18991): file:///android_asset/www/meteor_cordova_loader.js: Line 12 : METEOR CORDOVA DEBUG (meteor_cordova_loader.js) Couldn't load from the manifest, falling back to the bundled assets.
D/CordovaLog(18991): file:///android_asset/www/meteor_cordova_loader.js: Line 12 : METEOR CORDOVA DEBUG (meteor_cordova_loader.js) Loading from url: http://meteor.local
D/CordovaLog(18991): http://meteor.local/d7372e9a56ce9d5ddfb0fea0d5e071cfd699fac8.js: Line 111 : show showSignInLink signIn

These are all before I hit "Sign In" on my app. That last statement is just a log print from the useraccounts:ratchet package that occurs everywhere. As soon as I hit "Sign in": blank page, and zero output on the logs. (that's due to the fact that I can never actually stop logging in, as we saw earlier) The above log remains as it is forever.

When using the app installed with run android-device, it's the same exact output, except that after I click, the next page shows up and everything works fine. (logging works, as everything else) As with the non-functionning app, no more log lines show up. (except when I start using the app as usual)

What really bugs me is that it works perfectly fine on my phone when I install the app using run android-device. Even when I stop the debug and use this build as a standalone app, it works flawlessly! But I cannot decently ask users to install my app using meteor run, can I?

[ephemer]

I think I'm having this same issue with iOS bundles. It seems like DDP is trying to connect to localhost:3000 instead of the server I provide when I bundle with --server (host):(port). I didn't think to check meteor run ios-device but, it works! So there's something fishy going on with build and I suspect it's got to do with the --server argument. Online it's referenced as both --server=(host):(port) as well as without the equals sign. Neither of them seem to work for me, but it adds to the impression there's something unstable about it.

I found out about the localhost:3000/socksjs error by connecting the iPad with the computer via cable and running the Safari debugger on the WebView. Maybe you could try connecting the Chrome debugger with your Android web view. That way we could be sure it's the same issue.

[SylvainBigonneau]

Waw! Really did not expect to hear that.

You're talking about chrome://inspect? If so, I tried... I cannot inspect the running app when it's built. I can when it's using the debugging version, but... the problem does not happen in that case :sob:

So, so far I'm stuck with using the logs at adb logcat CordovaLog:D *:S (which I learned about today...) and do a bunch of console logs here and there in my code, having to uninstall/reinstall the app between each test so the code push will happen... it's horrible. Took me half a day to get to the conclusion I wrote up there.

[ephemer]

If you can get any kind of output from the js console in production, see if you can output Meteor.connection.status() - mine just said retrying the whole time (because the URLs is wrong)

On Tue, Feb 10, 2015 at 8:18 PM, BraveKenny [email protected]
wrote:

Waw! Really did not expect to hear that.
You're talking about chrome://inspect? If so, I tried... I cannot inspect the running app when it's built. I can when it's using the debugging version, but... the problem does not happen in that case :sob:

So, so far I'm stuck with using the logs at adb logcat CordovaLog:D *:S (which I learned about today...) and do a bunch of console logs here and there in my code, having to uninstall/reinstall the app between each test so the code push will happen... it's horrible. Took me half a day to get to the conclusion I wrote up there.

Reply to this email directly or view it on GitHub:
https://github.com/meteor/meteor/issues/3698#issuecomment-73763658

[SylvainBigonneau]

Just did. Mine says "connecting connecting waiting connecting waiting waiting connecting connecting..." etcetera, and etcetera.

[ephemer]

Sounds like the same issue. Maybe mine said "connecting" or "waiting" too, I'm not at the computer right now- in any case it kept retrying but always failed (the retryCount in connection.status() was slowly climbing)

On Tue, Feb 10, 2015 at 8:42 PM, BraveKenny [email protected]
wrote:

Just did. Mine says "connecting connecting waiting connecting waiting waiting connecting connecting..." etcetera, and etcetera.

Reply to this email directly or view it on GitHub:
https://github.com/meteor/meteor/issues/3698#issuecomment-73768788

[SylvainBigonneau]

Very likely yes. the documentation does not mention a retrying status and if status is failed it's not retrying and gives a reason in the reason field. I tried on my app: it does not give a reason if the status is waiting :(

[SylvainBigonneau]

So I guess I should reformulate my issue eh! Let's do this here, shall we.

[ephemer]

I'll compare your package list tomorrow to the ones we have installed. I noticed a couple of overlaps. I'll play around with removing the ones we both have installed and let you know the result.

Yes I think that'd be worthwhile - to me the crux is that the build doesn't seem to pass the --server argument correctly

On Tue, Feb 10, 2015 at 8:42 PM, BraveKenny [email protected]
wrote:

Just did. Mine says "connecting connecting waiting connecting waiting waiting connecting connecting..." etcetera, and etcetera.

Reply to this email directly or view it on GitHub:
https://github.com/meteor/meteor/issues/3698#issuecomment-73768788

[Tarang]

Are you connecting via WiFi or 3G?

[SylvainBigonneau]

Personnaly I only tried this using Wifi.

[SylvainBigonneau]

Just tried with 3G for the sake of it, only on my deployed server since I cannot play around with my office's routing... Same issue.

If that is of any interest, I tested this issue on an LG G2 and a Sony Xperia Z.

[ephemer]

@BraveKenny comparing your package list with ours, I'm left with the following overlapping plugins:

iron:router
sacha:spin
accounts-password
accounts-base
fastclick

While I don't want to rule this out entirely, it seems unlikely that any of those plugins would cause such a major issue. I did notice that Accounts does seem to make a direct DDP connection to the server though (separate to Meteor's connection), so it's not impossible. I may have misinterpreted the code I saw though, I didn't look very deeply into it.

Are you using the --mobile-settings flag, by chance? I wonder if that has anything to do with it. Our app won't work without the flag so it's hard to test with and without. I've been meaning to clean up our code so it works either way though, so maybe this will be a good excuse to do so.

[ephemer]

Ok so the --server attribute in the bundle is definitely being taken into account.
The problem is that the cordova app then connects to the server, which updates the index.html file in app/Library/NoCloud/meteor/(hash), notably this part of the <script> tag:

__meteor_runtime_config__ = {
"meteorRelease":"[email protected]",
"ROOT_URL":"http://192.168.1.12:3000",
"ROOT_URL_PATH_PREFIX":"",
"appId":"cqs7771rezqbtk5espx",
"accountsConfigCalled":true,
"autoupdateVersion":"8d0bdd1fea8159d8b2e550b951587b9a163458c9",
"autoupdateVersionRefreshable":"8bb078f46b0af07d122535ff5e453fb2f1b12ea6",
"autoupdateVersionCordova":"41bf5c472ebc4121a6a64cbe92690710d4c9100f",
"DDP_DEFAULT_CONNECTION_URL":"http://192.168.1.12:3000"
};

In my case the DDP_DEFAULT_CONNECTION_URL and ROOT_URL get updated to localhost:3000. I just changed this part of index.html file to the above (with the correct server IP) and restarted the app. It then loads as it should (but will almost certainly break when I update anything in the app again).

Given this knowledge, I'm now playing around with the --mobile-server flag of the meteor CLI tool (which I didn't know existed, it's not mentioned in any of the "release your app on iTunes" guides or anything). I had already played around with the the ROOT_URL env variable – it has no effect on the settings above. I assume --mobile-server will fix the issue though, I'll get back to you shortly.

What I don't get is why it's even relevant. From here it seems counter intuitive that I'd bother passing a --server option to meteor build if it's just going to get overwritten again immediately, especially by a stupid value like localhost:3000 which will obviously not work in > 99% of cases from a mobile device.

[ephemer]

It appears to work when the server app is run with the --mobile-server 192.168.1.12:3000 flag (obviously with your own IP address / hostname).

I have been testing this for the last 30mins with updates to both the meteor bundle and to the built cordova project and both types of changes work and update fine.

So to any MDG people reading: please consider updating the documentation to make mention of the --mobile-server option on the command line tool. Seems like everything breaks without it.

[SylvainBigonneau]

I'm away from keyboard at the moment, so I cannot investigate. But no, I never used --mobile-settings so far. What I can say is that I already built my app succesfully before and it worked, without ever using the --mobile-server option when running the server.

Also I wouldn't still understand why then this option is unnecessary when using the run android-device --mobile-server version of the app, which is basically a standalone, functionning version of the app. Just slightly larger in size.

[SylvainBigonneau]

Honestly I wish I wouldn't have to use this --mobile-server flag at all like I never had to before, and like I still don't now in any other case than when using an app built using meteor build.

I deploy my servers using meteor-up and am unaware of any way to give it flags for the server launch.

[SylvainBigonneau]

I can confirm from my side too: it works only when --mobile-server is specified with the correct public address when running the server with meteor.

[alpjor]

so how can I pass the --mobile-server option to a server that is built with meteor build and run directly with node, rather than with the meteor wrapper?

[alpjor]

FYI, I seem to have this same issue with iOS builds

[SylvainBigonneau]

I got it working by setting the server's "DDP_DEFAULT_CONNECTION_URL" and "ROOT_URL" environment variables as the public access point, such as "http://serveradress:3000".

This made the server listen to my app again.

[alpjor]

I keep seeing:

JSON.stringify(Meteor.connection.status());
< "{"status":"waiting","connected":false,"retryCount":7,"retryTime":1423854558657.934}"

from the safari attached debugger. So I know that my connection is not working yet. :(

@BraveKenny My app is running on https://xxx.domain.com, but it's running behind an nginx proxy on port 8888

ROOT_URL=https://xxx.domain.com/ PORT=8888 DDP_DEFAULT_CONNECTION_URL=https://xxx.domain.com /usr/bin/node /usr/local/storm/current/main.js

do you think I need to append :8888 to the DDP connection URL as well?

[SylvainBigonneau]

No I didn't. But I did append 443 to my addresses, so like this:

ROOT_URL=https://xxx.domain.com:443 PORT=8888 DDP_DEFAULT_CONNECTION_URL=https://xxx.domain.com:443 /usr/bin/node /usr/local/storm/current/main.js

You can likely remove the port on ROOT_URL.

[alpjor]

@BraveKenny you rock! it works now. thank you.

[asmakam]

@BraveKenny Thanks a million for diagnosing this! I was going crazy with the same issue! Managed to get it working with mup by adding the required env variables for the server

[SylvainBigonneau]

You are very welcome guys. But most debugging credits go to @ephemer who actually found out about that DDP_DEFAULT_CONNECTION_URL variable mismatch.

[rjakobsson]

I've got the same issue I think. Will try your solutions.

[rjakobsson]

What worked for me was
meteor run ios-device --mobile-server=https://domain:443
and then using that build as my "build".
Running meteor build didn't work.

[SylvainBigonneau]

Yes we all had to do this as well. But not anymore since we ran the remote server with DDP_DEFAULT_CONNECTION_URL=https://domain:443 and ROOT_URL=https://domain. Have you tried doing that?

[rjakobsson]

It didn't do any difference for me. I'm using Modulus, which allows the user to set environment variables. I tried it, but it didn't work.

[Slava]

(I almost understood the whole thread)

Here is a short explanation:

• --port option for meteor run sets the port and hostname for the server
• --mobile-server option for meteor run sets the port and hostname for the mobile apps to find the server
• --server option for meteor build is the same as the --mobile-server above but for the build command

I would like to improve the docs if this is confusing or incorrect in any written text. Please give me the direct links?

[SylvainBigonneau]

The problem is this: even when we build our app just as the docs say, like this:

meteor build ../output --server http://my.server:3000

Once installed on the phone, the app does not reach the server and the connection status keeps being down. So far we have managed to make the app reach the server by running the server using:

meteor --mobile-server http://my.server:3000

Or, by setting the DDP_DEFAULT_CONNECTION_URL variable when launching the server:

DDP_DEFAULT_CONNECTION_URL=http://my.server:3000 meteor

Which is documented nowhere, and probably should not have to be done, correct?

Important to note that I have not tried again with 1.0.4, as I keep DDP_DEFAULT_CONNECTION_URL set at all times now. I shall try when I have time.

[Slava]

meteor build ../output --server http://my.server:3000 basically sets DDP_DEFAULT_CONNECTION_URL internally. I don't see it wouldn't work.

[SylvainBigonneau]

We couldn't either, that is why I created this issue.

[Slava]

@BraveKenny I might have missed the flow of the conversation here. You figured out how to make it work, but it wasn't --server option?

Then I guess, we need to keep it open as a bug.

[ephemer]

Hi Slava, read my post right up the top of this thread about what actually happens when the mobile app first connects to the server you specify: the DDP_DEFAULT_CONNECTION_URL gets overriden to localhost in the bundle it pulls, at which point everything fails without the extra steps listed here

On Wed, Mar 25, 2015 at 9:35 AM, Slava Kim [email protected]
wrote:

Reopened #3698.

Reply to this email directly or view it on GitHub:
https://github.com/meteor/meteor/issues/3698#event-264078478

[SylvainBigonneau]

Yes, sorry, it's not very easy to explain clearly.

To make it work, I _build_ the app using:

meteor build ../output --server http://my.server:3000

And I launch the server using:

meteor --mobile-server http://my.server:3000

EDIT: Just to make it clearer, that is what I do in order to make the app work. I am aware that it's not the way it should be, but right now it's the only way I can make it work. (that or specifying DDP_DEFAULT_CONNECTION_URL environment variable)

[Slava]

@BraveKenny oh! I see what is going on here! The server is not accepting the connections as it is expecting the requests to be targetting localhost:3000 if you don't have the --server option. We should explain this better, it is a general confusion problem with ROOT_URL (which is set by the --server option or --port too).

[ephemer]

Hi Slava,
The problem is on the app side, not the server side. When the mobile app connects (to the server you specify when running meteor bundle --server), the server sends a new bundle containing its own data, including its own ip. Unless you set it with --mobile-server, this ip will be localhost:3000

[chandika]

This happens to me on 1.1.0.1 as well and cannot even get it to work with run ios-device.

I've tried the following

• meteor run ios-device --mobile-server=https://domain.com:443
• meteor build ../build server=https://domain.com:443

and however you run it, the ios app tries to connect to localhost:3000

inspecting via safari shows that meteor_runtime_config is

DDP_DEFAULT_CONNECTION_URL: "http://localhost:3000"
PUBLIC_SETTINGS: Object
ROOT_URL: "http://localhost:3000"
ROOT_URL_PATH_PREFIX: ""
appId: "hum9j41la1abo86btrx"
autoupdateVersion: "0ee596d4d9c5496d286ea2bc5d7fbb3249f1bc70"
autoupdateVersionCordova: "f25c7d02a26ee8eff2075c7814ee69d2d3d78fa8"
autoupdateVersionRefreshable: "c2c3df1d33b57ce4d2041e91d9c1929bf93b0bd6"
meteorRelease: "[email protected]"
__proto__: Object

I don't understand how this has anything to do with the server. The above runtime_config should point to the server var we pass on?

---

Correction - run ios-device works now and it seems there was a cached version of the app previously that caused it. However the build issue still persists.

[Poliuk]

Well, it works with

meteor run ios-device --mobile-server ip:port

Still don't understand what happens with the build command and the -server parameter.

[patrickml]

@Poliuk what exactly are you doing to get it connect to the remote server because im still having this issue unless im connecting to a meteor hosted server.

Update:
The issue seemed to be a problem with the ROOT_URL configuration in mup deploy "ROOT_URL": "http://xxxxxxxxx" Since I hadn't pointed the domain and was still accessing the site via the IP I had to change the ROOT_URL within mup to be my servers IP. I hope this helps someone else out.

[yaserabdelaziz]

I have the same problem, despite running command meteor build . --server https://ip and deploying server file with ROOT_URL=https://ip, when I run the android apk built of the past process, it couldn't connect to server.

[SylvainBigonneau]

@theyaserfox and if you add DDP_DEFAULT_CONNECTION_URL=https://ip to your server file deployment, does it work then?

[yaserabdelaziz]

@BraveKenny no still not working, knowing that the same mobile device work when meteor run android-device --mobile-server https://ip command is executed, so it seems no problem with the server.

[SylvainBigonneau]

Believe it or not, it's a change in how we started the server that fixed it for the most of us. Not in how we built the app.

Which does not mean the problem lies within the server! Just that this weird tweak in the server makes the app work again.

[yaserabdelaziz]

Well, then have you meant with DDP_DEFAULT_CONNECTION_URL=https://ip to run it preceded with export like this:
export DDP_DEFAULT_CONNECTION_URL=https://ip
as I am not using mup, and should I do any other step before trying to run the app again on mobile?

[SylvainBigonneau]

If you're not using mup, you could try running the server using:

meteor --mobile-server https://ip

Then maybe your app built using the build command can reach it. I know it's not normal to give the mobile-server option to the server command, but it prove to work with me/us.

[yaserabdelaziz]

I couldn't figure out how to run

meteor --mobile-server https://ip

from bundle folder.
However there is something weird happening, it works by swapping meteor build . --server https://ip (ssl) with meteor build . --server http://ip:port (no ssl) for about 4 seconds then the app disconnects again from the server.

[dkouvdis]

@theyaserfox this is the exact issue I am having here, check my video recording below
http://gph.is/1HPDM6J5
The left side - is my app viewed from the browser. On the right is the emulator of the android app. After clearing the cache, I can see my data only for a second.

[benjick]

Having the same issue. When I'm bulding with meteor build --server=http://apk.domain.se ../build I lose connection (ios only device and emulator, Android works fine).

What works is meteor run ios --mobile-server=http://app.domain.se, even meteor run ios-device works fine if I choose emulator

[maxtor3569]

Hi same problem here
Server hosted on ubuntu ngnix with upstart script :q export BIND_IP=127.0.0.1
export ROOT_URL=https://mydomain.com
export MONGO_URL=mongodb://localhost:27017/mydatabase
export HTTP_FORWARDED_COUNT=1
export PORT=8080
export DDP_DEFAULT_CONNECTION_URL=https://mydomain.com
meteor --mobile-server=https://mydomain.com ( I try also with exec node /home/mydomain/bundle/main.js)
And android build with server=https://mydomain.com

The android app is not connecting to the server. I don't know how to debug this.

[aramk]

Heads up to anyone who's testing this with Xcode 7 beta 4 - it doesn't appear to work even though the URLs in the config were correct when running:

meteor run ios-device --mobile-server 192.168.1.101:3000

It works fine in Xcode 6.4.

[derwaldgeist]

I'm also using Xcode7 beta 4, and it seems to work for me. [EDIT: It's strange, sometimes it works in Xcode 7, sometimes not.]

I've also noticed that calling the server with --mobile-server fixed another very weird problem for me:

Without the --mobile-server flag, everytime the app hot-reloaded the server code, the app got broken completely. The hot load script only picks some of the files, and then stops working (can see this in Xcode). Even stopping and restarting the app completely did _not_ fix the problem. Obviously, the hot coded files were stored locally, in a non-recoverable state. Hence, the app remains broken, which is a killer problem in a productive environment.

After calling the server with the --mobile-server flag, this problem disappeared; hot code pushes are working now as they should. [EDIT: No, unfortunately the problem is still there, but it does not happen every time anymore.]

I guess that somehow the hot push algorithm overwrites the IP originally set in the --server flag during build time, and that the --mobile-server flag prevents this server misbehaviour.

[woniesong92]

I am also having the same problem. It's intermittent.
For me, doing run ios-device DIGITAL_OCEAL_IP used to work, but it doesn't now.
Is it necessary to pass in DDP_URL parameter?

Edit
For me, the error was that ROOT_URL environment variable must be the same address as you pass into --mobile-server parameter. I think it might be a good idea to output a warning if they are not equal.

[Chicooz]

we are having this same issue with xcode beta, our app is very simple and this is our packages

iron:router
sacha:spin
accounts-password
accounts-ui
dispatch:stored-var 
mrt:reactive-store

[astout]

If you're developing with Xcode7-beta, Apple has introduced App Transport Security to Swift 2.0 and iOS 9. If you are unable to connect the deployed app from your iOS device to your server, try this:

0) Quit Xcode Beta (or at least close the meteor project)
1) Delete any installs of the app from your iOS device
2) Delete the [project-path]/.meteor/local/cordova-build directory
3) run: meteor run ios-device --mobile-server [ip]:[port]
4) Don't let it run on your device. If it does, kill the app and delete it from the device.
5) The Xcode project should be up. In the navigator, open Resources -> [app-name]-info.plist
6) Click the '+' on the root node Information Property List
7) Set the name of the new node to NSAppTransportSecurity, and set its type to Dictionary
8) The new node should now have a drop down, expand the node (click the sideways arrow to make it a down arrow)
9) Click the '+' to add a new node called NSAllowsArbitraryLoads and set its type to Boolean
10) Set the value of the NSAllowsArbitraryLoads node to YES
11) Now run it to your device, and it should be able to connect to the server

Your plist should look something like this:

I hope this works for others. It took me an afternoon to get the data to load on my device.

Happy coding :smiley:

[sherifnegm]

how can I thank you :+1:

[connorblack]

@BraveKenny you're the man.

If anyone is deploying through modulus and running into this issue, just go to project -> administration -> environment variables and set add a new entry called DDP_DEFAULT_CONNECTION_URL. My project is running on SSL so I set it to https://my.domain:443. I also have ROOT_URL set to https://my.domain.

To run the app I do this:

meteor run ios-device --mobile-server https://my.domain:443

[danlg]

same issue for me on android. cannot deploy the app using
meteor run android-device --mobile-server=http://my.domain:8000
whereas deploy is working ok on ios

[SylvainBigonneau]

I am afraid that this topic is becoming a catch-all for all issues regarding the mobile app creation in using meteor. So let me rephrase very simply what this specific issue is about.

What should work but does not

Building the app as documented using:

meteor build <bundle path> --server <host>:<port>

And then launching the server from <host>:<port> using:

When launched, the app fails to connect to the server.

The undocumented workaround that works for me and others

Building the app as documented using:

meteor build <bundle path> --server <host>:<port>

And then launching the server from <host>:<port> using either:

meteor --mobile-server <host>:<port>

or

DDP_DEFAULT_CONNECTION_URL=<host>:<port> meteor

What this issue is not about

This issue is about having trouble when connecting production built (meteor build) apps with the server. Not for issues regarding "debugging" apps (meteor run). I never had any issue when running:

meteor run android-device --mobile-server=http://<myserver>:<myport>

And that is very normal, since it has always been the documented way to do so.

If your issue has to do with meteor run or something other than what I just explained, I advise you to create another issue, as it cannot be proven that the two are related, and it messes up the discussion with everyone talking about their particular issue.

[pors]

I tried all possible solutions mentioned here, but what helped in the end was to not use port 3000 in production (port 80 or 443 worked fine!). For some reason the first bit of data transfer went fine with port 3000, but after a few seconds the client tried to make calls to different hosts (in the local network) which ended up in showing a white screen (both on iOS and Android).

My case might not be related to this issue, but if you do use port 3000 (or something high) in "production" you might want to change the port to give it a try. If you use Meteor Up, see here for making it work with virtual hosts: https://github.com/arunoda/meteor-up/wiki/Using-Meteor-Up-with-NginX-vhosts

[sachinkrishna]

Guys,
Without any hustles of specifying DDP ROOT and all, I got the thing working by simply "Deploying the app to meteor ie myapp.meteor.com " and then I specified the "myapp.meteor.com" url with "--server" option of build command, and it worked.

[SylvainBigonneau]

@sachinkrishna, I do hope the official, documented process to deploy apps (which is what you described) works for certain (if not most) people's apps, otherwise it would be a critical bug that would have been fixed by now.

Although I have not tested it, the answer to this bug should definitely not be "just deploy to meteor.com": meteor.com is only a testing platform, not meant to host production apps.

[sachinkrishna]

@BraveKenney Yes. I agree that. But this seems to work for testing purposes.

[SylvainBigonneau]

Ah, I mean if you _do_ have the bug when using a production server _but_ it works when using meteor.com deployment, that is relevant information indeed.

[lastcelebration]

@astout Thanks a million, that was driving me crazy.

[sheniyas]

Hi,

I have same issue (working fine with 'meteor run' but IOS App is not connecting to the server with 'meteor build'.

Any fix?

[Loschcode]

Guys, it's 10 months this issue is going around and i'm still having it.

[sheniyas]

Hi,
Solved !!!
It worked for me after hosting the meteor or angular-meteor app with NodeJS instead of running the app using #meteor command. After hosting the app, run your Mobile App from your device and the app display should be fine.

Issue:- I was running the app by running the #meteor command inside the app directory and then accessing the Mobile app from the Mobile device and it gives blank white screen or not displaying the app properly.

Solution:- Instead of running the app with #meteor command, I hosted the app bundle directory by installing the NodeJS & MongoDB separately and then from my Mobile (Both Android & IOS iPhone/iPad) it worked fine.

[ephemer]

@sheniyas, what most likely solved the issue was in the second last line you posted, namely exporting the ROOT_URL :)

On Thu, Nov 26, 2015 at 6:26 PM, sheniyas [email protected]
wrote:

Hi,
Solved !!!
It worked for me after hosting the meteor or angular-meteor app with NodeJS instead of running the app using #meteor command. After hosting the app, run your Mobile App from your device and the app display should be fine.
Issue:- I was running the app by running the #meteor command inside the app directory and then accessing the Mobile app from the Mobile device and it gives blank white screen or not displaying the app properly.
Solution:- Instead of running the app with #meteor command, I hosted the app bundle directory by installing the NodeJS & MongoDB separately and then from my Mobile (Both Android & IOS iPhone/iPad) it worked fine.
1, Build the app using meteor build

meteor build --directory ../app-build/ --server http://your-app-url

2, #cd bundle ( to the build bundle directory)
3, run below below commands inside the bundle directory

npm install fibers

npm install underscore

npm install source-map-support

npm install semver

Now host the bundle directory but not with MUP, by installing the NodeJS & MongoDB manually (Follow the below steps to setup a Meteor App Hosting Server with NodeJS & MongoDB in RHEL or CentOS)

RHN_Register (If using RHEL - If you are using CentOS no need)

Install EPEL (http://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F)

yum install httpd

chkconfig httpd on

1, #yum update
2, #yum groupinstall "Development Tools"
3, #reboot
4, #cd /tmp
Install NodeJS version v0.10.39 64 Bit
5, #wget http://nodejs.org/dist/v0.10.39/node-v0.10.39.tar.gz (TO chnage the version replcae the version umber in this url)
http://nodejs.org/dist/v5.0.0/node-v5.0.0.tar.gz
6, #tar -xvzf node-v0.10.39.tar.gz
7, #cd node-v0.10.39
8, #./configure
9, #make
10,#make install
11,#mkdir -p /data/apps
12,#mkdir -p /data/db
13,#chmod -R 775 /data/
Install MongoDB Server version 2.6.10-1 64 Bit
14,#vi /etc/yum.repos.d/mongodb.repo
[mongodb]
name=MongoDB Repository
baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/
gpgcheck=0
enabled=1
15,#yum install mongo-10gen mongo-10gen-server
16,#yum install mongo-10gen mongo-10gen-server
17,#chkconfig mongod on
18,#vi /etc/mongod.conf
Uncomment #port-27017
Replace dbpath
dbpath=/var/lib/mong to dbpath=/data/db
Copy the Database files to the dbpath
19,#cp /data/apps/booking-app/.meteor/local/db/meteor.0 /data/db/
20,#cp /data/apps/booking-app/.meteor/local/db/meteor.ns /data/db/
Change the permissions
21,#cd /data
22,#chown -R mongod:mongod db/
23,#chkconfig mongod on
24,#service mongod start
25,#vi /data/apps/start-up-script.sh

!/bin/bash

export PORT=3000
export MONGO_URL=mongodb://localhost:27017/meteor
export ROOT_URL=http://app-s.gbm.local
/usr/local/bin/node /data/apps/booking-app-prod/bundle/main.js #(App Build Directory bundle/main.js)
26,#chmod +x /data/apps/start-up-script.sh
Install Meteor version 1.1.0.2
27,#curl https://install.meteor.com/ | sh
28,#cd /data/apps/booking-app
29,#mkdir -p /data/apps/booking-app-prod (Build the App to this directory)
Install Android Studio

yum install java-1.7.0-openjdk-devel

yum install libstdc++.i686 (also to install 32 bit as it is a must)

wget https://dl.google.com/dl/android/studio/ide-zips/1.2.2.0/android-studio-ide-141.1980579-linux.zip

unzip

cd to bin dir

./studio.sh
Package the App with Meteor Build and run the app from your Mobile Device (Android or IOS)
Note:- If you need the app in android device issue this command inside your app direcory- #meteor add-platform android

If you need the app in IOS device issue this command inside your app direcory- #meteor add-platform IOS

Reply to this email directly or view it on GitHub:
https://github.com/meteor/meteor/issues/3698#issuecomment-159845621

[ghost]

Any updates for this issue?
Is it not possible to change the server after the first install(android)?

[patrickdevivo]

Also hoping for updates, currently hitting the same issue as described above: pass a URL to a running meteor app to 'meteor build' via --settings, but mobile app still wants to connect to 'localhost'

[methodbox]

It sounds like a lot of people are having issues related to export ROOT_URL which are similar to an issue I recently had due to iron:router not currently respecting the URL_PREFIX.

I my case my app lived on an Nginx server and required a "/prefix" after the ROOT_URL, but it would be wiped after landing in / (home) page of the app after navigating to any sublinks.

I found in the github for iron:router another user experienced the same thing and isolated that iron:router doesn't currently respect the prefix.

He released clinical:router which is a fork of iron:router and supports all other iron:router packages,

I simply removed iron:router and meteor add clinical:router and all is good.

[methodbox]

Just a note that export ROOT_URL=http://domainname.com should be performed at the directory where main.js lives, assuming you're using a standard meteor build.

This would not be performed where your index.html lives if it's not in the same directory.

The URL_PREFIX is defined in your router.js (or wherever your routes are defined) prior to each route value:

Router.route('/prefix/home', function () {
      this.render('home');
});

[maronk]

SOLVED - see update below:

This thread has become a bit confusing as to which problem it is covering, but at least I got here with the problem of my android build loading the initial template and then not being able to load any other screens, it was as if the full application never loaded on the phone.

I tried starting our productions server with ROOT_URL and DDP_DEFAULT_CONNECTION_URL - this didn't help. We are using forever to launch in production and the IOS build has been working fine and is listed in the App Store already. I also tried adding --mobile-server to our forever command line to no avail.

What did work was to run

meteor run android-device 

and use the build that came out of that, however, that is a debug build and I'm now trying to figure out an easy way to make a production ready build - as the meteor build --server= command results in a production .apk that doesn't connect properly to our server.

I feel unsure after reading the above that everyone is talking of the same issue, but pretty sure that in my case I'm either doing something astronomically wrong or I'm misreading the documentation. Anyone else with the same setup? Did you end up in publishing the debug apk (is that even possible)?

UPDATE:
This ended up being a different problem in my case - everything behaved exactly like the above mentioned problem and over the course of 10 hours I have tried every single aspect of solving it. I then found out there was an issue with my intermediate certificate. If you have tried everything in this thread check your SSL certificates here: https://www.digicert.com/help/ and fix all errors - this fixed the issue for me.

[methodbox]

Again, read my post. Most of you have reported issues using a URL prefix, which isn't supported in iron:router and never will be.
A quick fix is to use clinical:router, a real, long-term fix is to refractor to use flow router.

[chansdad]

Hey Meteor Folks , WAKE UP!!! this is one issue that really is going to block new developers to start using Meteor for hybrid apps. I have two apps both now on Meteor 1.2.1 , One app just connected to the remote ddp server , while the other did not . I have used the meteor create "project" and added one by one all the plugins . I can access the apps through browsers just fine , but the built apps using meteor buildfolder --server=http://server:port loaded in android or ios did not work same goes with the meteor run ios or meteor run android.

I tried with xcode 7, xcode 6.4 , one app somehow it started to communicate and iam not rebuilding it for the fear of loosing conneciton to the DDP server , all html changes on the server are being updated on the app throught hot code push ..

Another app intermittently connected to the remote server and then when i rebuilt to make sure i get the process right , it stopped connecting ....

My apps are in development stage and iam starting to wonder if my decision to go with Meteor is the right one looking at this unstable build .....

FYI .. both the apps use iron:router package ,

one app is serving mobile clients on port 3000 and the other one on 3010

Both the apps can be accessed via browser , one on port 3000 and the other on 3020

[casg0993]

Hello, @maronk solution worked for me, I check my SSL certificate and it had some errors, I fixed them and then everything works.

[methodbox]

Did ANYONE read my post?

As I said, iron:router doesn't respect the URL_PREFIX.

Most, if not all the issues described can be resolved by either switching directly to clinical:router or reconfiguring the app to use flow:router.

Your issues with SSL are likely more related to your server config not proxying requests from port 443 to your app port.

You can't configure a proxy on port 80 and expect it to work with SSL. Servers require the request to come on 443 to serve the SSL. You also can't change the default port from 443 or you'll get browser warnings.

The rest of you are running into inherent limitations of iron:router.

[falwickster]

I have the same problem. Initially android app is connecting to the given server, but after 3 seconds it refreshes and connects to local address http://10.0.2.2:80.

Application is running on external server with ROOT_URL and MOBILE_ROOT_URL env variables.

ROOT_URL="http://(host):(port)" MOBILE_ROOT_URL="http://(host):(port)" meteor --port 80

For mobile app I used two commands with the same result as stated above

ROOT_URL="http://(host):(port)" MOBILE_ROOT_URL="http://(host):(port)" meteor run android-device --mobile-server (host):(port) --production

ROOT_URL="http://(host):(port)" MOBILE_ROOT_URL="http://(host):(port)" meteor build ../dir --server (host):(port)

I used meteor build command and opened a project in Android Studio to edit code, and rebuild the project.

SOLUTION
Autoupdate is preventing my app to connect to the server, the solution is here:
http://stackoverflow.com/questions/33004988/meteor-cordova-how-do-i-prevent-autoupdate
I used meteor build command, and opened the outputed project with android studio, then i searched "autoupdate" in project which pointed me to a [long_hexed_name].js file in www/application directory. Then I changed t=30,s=5 to t=0,s=0. Finally I selected Gradle on the right side, and chose option Execute Gradle Task, and typed "assemble", the outputed .apk file will be in [bundle-dir]/android/project/build/outputs/apk.

[lpender]

@methodbox thanks for sharing! I'm installing clinical:router now to see if that fixes my issue.

EDIT: Installed clinical:router and I'm still having issues

[jonmc12]

Meteor version 1.3 may provide a fix. With some help from @rdickert I was able to determine that my root cause of URL problem was #5973 and that Meteor 1.3 will provide a fix.

Testing with the beta version of 1.3, I was able to run successfully build my app and point to remote server, whereas with version 1.2.1 I had experienced the nature of problem described above.

meteor run ios-device --mobile-server <URL> now seems to work as expected

[lpender]

Here's what fixed it for me:

Reinstall meteor:

rm -rf ~/.meteor
curl https://install.meteor.com/ | sh

I wonder if it had to do with meteor caching certain plugins.

I first got the inkling when I noticed that, after upgrading to 1.3-b3 and encountering many new Cordova errors, I wasn't able to downgrade by reverting to an older version of meteor.

Seems like quite a few issues wrapped up in here. Makes me pretty nervous...

[ThomsCass]

I'm using Mup with Nginx on my remote server.

Got the same error when I deploy my app in production on an android device.

I don't understand really what to do to get it work? I use meteor 1.2.1

What I found so far is that the app try to reach meteor.local here is the debug from android studio

02-10 14:16:58.431  30341-30341/? I/chromium﹕ [INFO:CONSOLE(0)] "XMLHttpRequest cannot load http://my-domain/sockjs/info?cb=_yp3a_79gx. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://meteor.local' is therefore not allowed access.", source: http://meteor.local/login (0)
02-10 14:16:58.471  30341-30377/? V/meteor.cordova.updater﹕ remapUri http://my-domain/sockjs/info?cb=xo4guec2nu

I add this line App.accessRule("*");

and now here is what I get :

02-10 15:07:37.691    7238-7279/? V/meteor.cordova.updater﹕ remapUri http://my-domain/sockjs/info?cb=q7cx96og6l
02-10 15:07:37.691    7238-7279/? D/meteor.cordova.updater﹕ Host is not intercepted: my-domain

Could it be a ssl problem ?

Thanks guys

[martijnwalraven]

Could you try if this is still an issue with the latest Meteor 1.3 beta? https://github.com/meteor/meteor/issues/6266

Closing this issue in the meantime, please reopen it if you feel this needs further discussion.

[camrongodbout]

@martijnwalraven I have my meteor server deployed at wandrlust.co and want to run meteor run ios-device --mobile-server wandrlust.co so I can connect to prod data. This does not work. Do I have to build the server a specific way to allow this?

[martijnwalraven]

In general, that should work. Do you receive any error messages in the Xcode or Safari remote debugging console?

If I look at your server, it seems it is not configured for Cordova hot code push. Make sure the ios or android platform has been added. Also, you seem to be running on 1.3-rc.2, so I would suggest upgrading to the final release as a lot of issues have been fixed since.

[camrongodbout]

@martijnwalraven Thanks for the speedy response. Upgrading and adding iOS platform fixed it.

[Streemo]

iOS apps continue to connect to localhost:3000 instead of --server https://specified.url

I feel this issue should be reopened, since I am getting the _exact same_ behavior mentioned in the first couple of posts.

With Meteor 1.2:
App worked wonderfully, built using meteor build . --server ... and deployed via mupx hundreds of times.

After upgrading to Meteor 1.3.2.4:
The exact same process _works_ for android, and fails for ios. The app loads in ios, but all of my subscription data hangs. Using Safari debugger shows that the app is trying to connect to localhost:3000, instead of my URL. Thus:

var handle = Meteor.subscribe('posts');
handle.ready() //always false, since it's trying to connect to localhost:3000

I do not think mentioned solutions like "disable hot code push" or "switch to another router" are valid solutions. I have not yet tried specifying DDP_DEFAULT_CONNECTION_URL in mupx.json, nor do I see why this should suddenly be a requirement, as I am using the --server flag mentioned by @Slava

EDIT:

I am getting this error in the Safari Console (note, there are no errors in browser, or android)

Uncaught Error: TypeError: undefined is not an object (evaluating 'Meteor.settings'):222:http://localhost:12192/18873e24beea6b9d6317ee2e5628a9c4877479ff.js?meteor_js_resource=true

Furthermore, Meteor.settings is undefined.

[Streemo]

As mentioned above, there is an unsatisfactory fix to the problem:

//works, does not set ROOT_URL to localhost:3000
meteor run ios-device --production --mobile-server https://mydomain.com --settings settings.json
//fails, sets ROOT_URL to localhost:3000
meteor build --server https://mydomain.com --mobile-settings settings.json

Note that I have not tested uploading builds created with meteor run to the Apple store.

[rcy]

I ran into issues with this last night, and found that it finally worked when I did --server=domain.com:80 rather than --server domain.com:80 (with = as per the documentation).

I did both and looked at ios/project/PROJECTNAME/index.html to confirm that ROOT_URL was being set correctly when using =.

[Streemo]

@rcy What version of Meteor do you use?
I ask because my "index.html" is located at:
ios/project/www/application/index.html

[rcy]

@Streemo 1.3.2.4

[Streemo]

@rcy thanks! It looks like including the = worked. I thought I tried it before...

It's a shame that a single = sign can bring down an entire app build process. I'd have imagined there would be a simple check in the CLT which allows many common --flag syntaxes. Perhaps this is a possible area of improvement!

[rcy]

@Streemo glad it worked for you. I struggled with this for awhile yesterday before adding the = and getting it working.

Also, about the path to index.html above, my path is the same as yours (ios/project/www/application/index.html), I misread some output from my screen.

[Streemo]

@rcy the odd thing is that I'm getting the index.html to sometimes output ROOT_URL as localhost, other times as mydomain. I haven't changed a single setting explicitly.

Here's something very fishy I observed:

> mupx deploy //deploys app to server
> meteor build ... //using the equals sign and everything, builds the app
> cat bundle/ios/project/www/application/index.html // ROOT_URL is localhost.
> meteor build ... //using the exact same arguments as before
> cat bundle/ios/project/www/application.index.html // ROOT_URL is mydomain.

[perak]

The same problem here. I tried everything written here (with and without = in --server argument, setting DDP_DEFAULT_CONNECTION_URL in mup.json but no luck.

Android - works perfectly.
iOS emulator - accessing remote server - works perfectly.
iOS - connected to USB but accessing remote server - works perfectly.
iOS - bundled to production - somehow tries to connect to localhost:3000

Temporary solved by downgrading from Meteor 1.3.4.1 to Meteor 1.2.1 - the same build commands now works like a charm.

[activeperception]

I have a problem similar to one of the 250 different issues in this thread.

My Android release APK cannot connect to https servers (deployed with mupx).

if I try to fetch https://domain/sockjs/info?cb=3by07g9lsv with JQuery get it gets stuck too without error.

Any idea?

Works with _meteor run android-device --mobile-server=..._ or when connecting to a http server and it doesn't seem to be a CORS, accessRule, autoupdate issue.

[activeperception]

SOLVED - intermediate certificates problem. Make sure you check you certificates with a service like https://www.sslshopper.com/ssl-checker.html because some android browsers are picky about intermediate certs

[elie222]

Would let's encrypt work?

On 20 Jul 2016 15:24, "activeperception" [email protected] wrote:

SOLVED - intermediate certificates problem. Make sure you check you
certificates with a service like
https://www.sslshopper.com/ssl-checker.html because some android browsers
are picky about intermediate certs

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/meteor/meteor/issues/3698#issuecomment-233933732, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC8oX4ohomkZKmzM_YsvM0IjWAL5Wmrmks5qXhOUgaJpZM4DePct
.

[activeperception]

@elie222 as long as you install their intermediate certificates on your web server it should work just fine

[JWPapi]

This is still an issue. I tried everything in this thread. Ill downgrade now. I set the correct root url, but it still doesnt connect

[JWPapi]

Ok, i just figured something out. In the meteor guide its stated:

As mentioned before, mobile apps need to be able to connect to a server to support hot code push. In production, you will need to specify which server to connect to when building the app using the --server option. The specified server address is used to set ROOT_URL in meteor_runtime_config, which is defined as part of the generated index.html in the app bundle.

In addition, you will need to configure the server with the right connection address. This happens automatically if you’re using meteor deploy to deploy to Galaxy, but when deploying to your own server you’ll have to make sure to define the ROOT_URL environment variable there. (For Meteor Up, you can configure this in mup.json.)

The reason this is needed is because updates delivered through hot code push replace the initially bundled index.html with a freshly generated one. If the ROOT_URL on your server hasn’t been set, it defaults to localhost:3000, and this would leave the app unable to connect to the server, both for data loading and for receiving further hot code pushes. In Meteor 1.3, we protect against this by blocking updates that would change the ROOT_URL to localhost, but the consequence of this is that hot code push is disabled until you configure ROOT_URL correctly.

I deployed my app on a windows computer moving the folder to my mac Virtual Machine where I build the IOS App. Since i didnt deploy there again, the url was set wrong. I then deployed the same project again to meteorapp.com and after that built again. And it worked. Reason is above.

[lpender]

For me it was the force-ssl package.

[NawazKhanMd]

do we need a virtual host to run my meteor app on mobile?

cuz am running meteor run android-device -p MyIp:3000 --mobile-server virtualHostIpToWhichMobileIsConnected:3000

this gives me a blank screen

am i doing it wrong pls Reply :)

[perak]

You don't need that -p argument, the rest looks OK

[NawazKhanMd]

Okay how does the mobile connects to the server which is running in the desktop on localhost:3000
where mobile is connected via a cable and has internet connection
@perak