How can you permanently change iOS app configuration in Meteor Cordova?

Question

Every time I meteor build, I have to open XCode and do the following:

• remove and add an item from "Link Binary With Libraries" (Facebook SDK)
• add a URL Type (custom URL scheme for my app)
• add a "Required device capabilities" to "Custom iOS Target Properties"

How can I edit my Meteor project to have these steps done automatically, and to auto add things to AndroidManifest.xml?

In some way use mobile-config.js or cordova-build-override?

Answer 1

Unfortunately plist values (and assumably AndroidManifest.xml as well) can only be changed by a plugin:

Add entry to iOS .plist file via Cordova config.xml

Answer 2

I'm happy to see another guy who is trying to build a hybrid application using Meteor / extending a Meteor Cordova iOS app, since I'm facing the very same issues. So I'm very happy to share my experiences and approaches with you. :-)

So far, I ended up with the following approach:

1. I created a base template for my iOS app using meteor build (not meteor run ios-device, since I did not know if Meteor does some optimizations for production code).

2. Then, I copied the whole Xcode project under /platforms/ios to another loaction and used this new project as my "master" project from then on. This project is being enriched with native code, e.g. it also includes the Cocoa Pods I'm needing.

3. Of course, I also did not want to copy files each and every time I trigger a new Meteor build. At least, I would like to have the Staging/www folder updated, as this is happening quite frequently.

So my first (rather naive) approach was

• delete the Staging/www folder in the master project
• replace it with a relative link (using Xcode's linking functionality) to the Staging/www folder inside the .meteor/local/.../ios/ project

This approach did not work, since the shell script used in the Meteor Xcode project can't handle these links.

My second approach is to create a symlink on the filesystem level instead. This works as it should, and I'm able to build the project in Xcode as it should.

I could have followed the same approach for the Cordova plugins folder, but I've decided to replace the plugins manually in order to get a better control over them, even it means a bit more effort then.

Having the symlink in place also means that Xcode's version management (and also SVN which I am using for everything) will ignore everything below Staging/www, which is good in my opinion, because I'm already versioning the webapp code in the Meteor project itself.

BTW: I've started a discussion thread on hybrid mobile app on the Meteor forums as well, but so far it did not get too much attraction:

https://forums.meteor.com/t/building-a-hybrid-meteor-cordova-app-share-experiences/8212

Maybe we could follow up on Meteor-specific things there, to have the Meteor community participate in the discussion?

EDIT: I would also like to share an approach that failed completely, at least for me, maybe I was too dumb... Before I used Meteor's Xcode template as the starting point, I also tried it "the other way round", i.e. I started with my already existing Xcode app project and tried to include Meteor's / Cordova's part by hand. Using this approach, I never managed to set everything up correctly. I had lots of troubles and also had to tweak a lot of the compiler / linker flags to even get the code compiling. This grew me a lot of gray hairs. But even after I managed to get everything to compile, Meteor hang during startup - and I never figured out why.

One remaining problem I'm still facing is that Meteor's hot code push functionality seems to have some severe issues on iOS, that are also documented as GitHub issues. It can happen that the iOS app gets completely broken and needs to be reinstalled. I tried the mdg:reload-on-resume package, but this did not work as it should and made things even worse. As far as I can tell from the GitHub discussions, one should better disable hot code push until the Meteor team has addressed these issues. Breaking the app completely due to code pushes is not what my users would expect.