Add CFBundlerIdentifier to darwin manifest support

[orther]

I somehow missed this earlier. It makes sense to use the nwjsBuilder.productName for darwin plist field CFBundleIdentifier.

[orther]

NOTE: I may have another pull request coming behind this one that solves an issue (the .app that is built wont open when downloaded, instead it shows an error dialog with the option to move the app to the Trash Can) I am having when I build with custom name that doesn't match the original project name. Right now I am unsure what is causing this problem so I am not sure if it is solved in my project or in nwjs-builder (or both).

Also I will probably add correct formatting of the the CFBundleIdentifier (it is more strict than npm manifest name validation). I am investigating what the best way to handle this but I'll likely just replace all non a-zA-Z chars and give an escape hatch prop that allows you to manually define this in the manifest file.

[evshiron]

Thanks. It makes sense. BTW I read about CFBundleIdentifier and think it's much like the package names on Android/Java. The current implementation doesn't give users much freedom though. I am considering adding a property for it in nwjsBuilder. Any ideas?

[orther]

I am just starting to look at the plist keys for the first time (it always just worked before) so I don't have an informed suggestion yet but I was thinking the same (add property to nwjsBuilder). My expectation is by the end of my trouble shooting this app being "corrupt" when downloaded, I will have enough of an understanding to suggest a path forward.

[evshiron]

So is it confirmed to be an issue with the CFBundleIdentifier? Are the Darwin builds corrupted only after redistributing? And what version of Mac OS X do you use? I think there are changes in macOS Sierra Gatekeeper though.

[orther]

Actually NO after some more debugging I believe my issues are related to adding dependencies that are installed by nwjs-builder. If I remove dependencies from package.json OR use an invalid name in package.json (e.g. spaces in name) which causes the darwin build npm install to fail and not install dependencies my app opens (although those deps are missing so it's broken). Previously I was using nwjs-builder include functionality to copy deps and that works so I am I'm looking into the diff between that built app and one with dependencies.

I will definitely keep you posted if there are changes to nwjs-builder that make sense for my particular issue. I'm still pin pointing the exact cause of this issue but I am pretty sure it is NOT due to CFBundleIdentifier.

[orther]

I'm using OSX 10.11.5 and yes the builds are only corrupted after redistributing (to test I am just using python python -m SimpleHTTPServer to serve a .zip of the built app locally). If I run the app built locally it works.

[evshiron]

node.js looks up node_modules in every parent/ancestor directory so it might work right in the build directory. Maybe you can try moving it to another directory where there is no previous node_modules and see if it works.

[orther]

I'm not exactly sure what the problem was but my issue was related to the npm package applescript@0.2.1 which was a dependency of auto-launch@1.1.1. I had to manually remove npm packages from the app, resign and re-download until I found the package that was causing the issue (sadly I for no obvious reason went in reverse alphabetical order so applescript was literally the last package I tried 😢 ). Once I updated to auto-launch@2.0.1 (which uses applescript@1.0.0) my issues went away.

In the end this issue was a problem with the code signing of the nwjsBuiltApp.app/Contents/Resources/app.nw/node_modules/applescript folder and don't think nwjs-builder needs to be changed to help in this situation.

BTW we've been using an invalid CFBundleIdentifier (it has spaces in it) for months without problems and now that I have confirmed it isn't related to my corrupt app issue we can probably leave it how it works until we have reasons to change it.

[orther]

I'm hoping you can publish w/ version bumped to 1.12.4 so I can use it with my automated production builds moving forward.

[evshiron]

@orther LOL and glad to know the issue has been solved. I have added support for custom bundleIdentifier instead of creating an identifier from productName (which I think is for displaying not identifying), and the previous behavior should remain unless a bundleIdentifier is provided. nwjs-builder has bumped to 1.12.4 and feel free to try it out. Cheers!

[orther]

Looks good. Thanks for the quick turn around!