Very useful this guide, thanks guys!
One item that could use a bit more explaining is the section on mobile-config.js. Is there a one to one mapping from the Config.xml to mobile-config.js?
These two specifications have a few things in common, but a lot is unclear to me: http://docs.meteor.com/#/full/mobileconfigjs vs https://cordova.apache.org/docs/en/latest/config_ref/index.html and https://cordova.apache.org/docs/en/latest/config_ref/images.html.
Struggling a bit to use Cordova plugins with the ES6 module system – what’s the proper import path? I’ve tried both 'meteor/cordova:plugin-name', 'cordova:plugin-name', 'plugin-name', and 'meteor/plugin-name', and all of that doesn’t seem to find anything.
@aspin: Cordova plugins don’t really support modules (neither CommonJS or ES6). Cordova has its own module system for loading, but plugins then add themselves to the global scope depending on settings in their plugin.xml. So you should just keep using them as before.
Well I feel silly. Errors are gone after taking out the import statements hahaha. Thanks.
After struggling for a couple of days with a seemingly elusive bug, I’d like to share what happened and suggest a couple of small improvements in the guide that would have made finding the issue much easier:
What I experienced was very weird: When running on android with meteor run everything was fine. But when building an apk with meteor build and installing it (via adb or the play store) the app had extremely long load times for the first run, sometimes ending with complete stuckness. When reloading the app the second time was usually working fine - but sometimes not.
For a while I believed that this has to do with the launch screen package and tried some manipulations there. But after a while I realized it’s not that.
The first real smart thing I did was to build a debug apk and inspect it on my device with chrome. And here is my first suggestion: Explain in the guide how to do exactly this. Creating a debug apk (which is the only way to later debug an apk with the chrome devtools) is not documented anywhere in the mobile guide and yet it’s an incredibly powerful tool which I’m super glad I found out about.
Actually, the --debug flag is also not documented in the build tool guide. If searching for “meteor build” or “meteor build --debug” on google you get either to the above-linked guide or to this page which are not useful for this at all. So the only place you can learn about it is in command line help meteor build --help.
In short, what I’m trying to say here is that there’s a very powerful tool for mobile development in hiding 
.
After successfully building debug.apk (took me a bit also to realize it’s not release-unsigned.apk when using the --debug flag, this isn’t documented in the command line --help) and installing it, the rest was easy: my Meteor.settings was undefined, which caused errors where in the first pages of my app I’m using Meteor.settings.public.
It was undefined because I was building my app using this line:
meteor build ~/build-output-directory --server <host>:<port>
Which is the canonical example in the guide. I did not add a --mobile-settings flag. This caused the first run of the app to throw errors, and the second run to work ok since it was already after a hot code push with the settings on the server. Once I realized that this was the problem everything was fixed.
And here is my second suggestion:
the --mobile-settings flag isn’t even mentioned in the mobile guide. It should definitely be there.
That’s it. Sorry for the long rant and thanks a lot for a wonderful platform!!
I have secrets I want my (android-only) mobile Meteor app to be able to use at runtime. I don’t want to store these in the APK. Based on https://docs.meteor.com/#/full/mobileconfigjs I think I want to use App.setPreference()or App.configurePlugin(), I’m just not sure where to go from there. How do I get/set my secrets while the app is running?
I can’t find a specific example for storing and retrieving secrets, but perhaps one of these links leads down the right path…
Hello,
If I only want to create an APK, and test it without using the Play store (I want to send it to me and my friend for apha use and debug), do I need to sign the apk ? For now I tried to send the unsigned-release.apk to my phone, but it failed the phone do not recognize the apk. (I enabled installation of ext app). The correct apk is unsigned-release.apk right ?
Last thing, do I need to explicit the settings (env variable) if they are all defined on the heroku app and I build with --server my_app_on_heroku:3000 ?
@voyag3r in regards to signing, the apk needs to be signed regardless. If you’re using debug, the build process/android studio should sign with its own keystore automatically (you’ll end up with a something-debug.apk). But the release version is not automatically signed. If you want to test the release version you need to generate a signed version from android studio using your keystore. You can also sign using android studio’s debug keystore from the command line using something like this:
jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android path/to/some-release-unsigned.apk androiddebugkey
In regards to the guide, would it make sense to add a section/note to elaborate on deployment environments geared for mobile apps? The Deployment Guide has a good section on how to properly define a Development/Staging/Production environment but I’m left with unanswered questions when mobile comes into play. Recommendations on the following would be welcomed:
When promoting a build from Staging to Production, the build has to re-issued to update the ROOT_URL. While I understand the need to have this fixed URL in the bundle itself, having to rebuild adds some risk. I’m thinking of having both builds issued back to back even if said build might not be promoted to production to reduce this risk. Alternatively I might need to setup our own dns server with some kind of dns-splitting to point to production or staging depending on where you’re connected but this obviously has some drawbacks as well.
More general thoughts on how to easily switch between staging and production environment during testing. To allow both staging and production versions on the same device for testing purposes (wether it’s to connect to a different ROOT_URL or to test a different native code base), I’m thinking I’ll be stuck with manually modifying mobile-config.js during the build process. More specifically the App id, to allow for the two versions to coexist side-by-side.
Thoughts?
I still feel like there are some critical holes in this section of the guide, where we’ve figured things out or sourced workarounds from the forums and stack overflow. primarily
A massive benefit of the Meteor platform, and definitely a reason for me choosing it often for client projects is the possibility of mobile being easier than with other options. Ideally, to cover the many complexities that come up with building cross-platform hybrid apps with Meteor, we really need a barebones boilerplate or tutorial that encapsulates all of the necessary bits to go from zero to store with Meteor.
Secondly, a critical aspect that I believe could be beneficial is regarding using Meteor with native app development, we’ve recently done this with fantastic results, Meteor really shined as a mobile server in this setup, but it definitely required some work, and even introductory content would be beneficial.
Yes, more details on deployment environments, both for staging and production, would be helpful.
Also, @pushplaybang you’ve also hit on some key issues we ran across for mobile as well.
I’d like to suggest that both of you submit a PR for the Meteor Guide to add your ideas. I’ve submitted a number of PRs to help flush out other areas.
Thank you for writing about this. Solved my issue !
A couple of things that could be clearer about hot code push.
I’m getting this error after the build … Any ideas why?
meteor build …/surflifemobile --server https://www.gosurflife.com:8080
Error: {“errno”:34,“code”:“ENOENT”,“path”:"/Users/Firas/Meteor/surflife1.3/.meteor/local/cordova-build/platforms/ios/Surflife.xcodeproj/project.pbxproj",“syscall”:“open”}
This is an issue for me in 1.3.2.4
Meteor.settings is undefined using Safari debugger. I believe this is correlated to the ROOT_URL and DDP_DEFAULT_CONNECTION_URL getting reset to localhost:3000 instead of https://mywebsite.com
So far, I’ve tried including --mobile-settings explicitly, but that did not solve the problem. This problem appeared after upgrading from 1.2.x to 1.3.2.4
The same exact app (1.3.2.4) on Android works just fine!
Edit:
A quick fix to the problem is to use meteor run ios-device ... and then use that build, since it does not result in the ROOT_URL being set to localhost:3000.
I have not tested whether or not production apps can be uploaded to the Apple store coming from the meteor run... command…
Wouldnt it be better to make 2 different sections for android and ios, not as merged as it is now?
just like with code, really long scripts with mroe than one major concern get tiresome and harder to follow, I totally agree it would be awesome to break this up into smaller chunks.
Great article. Very informative. But I have a question…
The article states that, " that all your assets are bundled with the app." Does this include server-side code or is it just client-side? If server-side is included, what’s the point of bundling server-side if we need to connect to an external server anyway?