Add a package/publish command for iOS

[fealebenpae]

Right now a lot of our users rely on opening the Xcode project in platforms/ios and manually going through Xcode's Archive step in order to submit a binary to the store.

xcodebuild has an archive action that performs the same kind of build. Xcode's toolchain attaches additional meaning to archive builds - for instance, only archive triggers full Bitcode generation as opposed to markers-only generation in regular builds of projects that enable Bitcode. So it's not the same as doing a normal build in the Release configuration.

I propose that a new command is added to the CLI, one that invokes xcodebuild archive internally, and depending on switches either reveals the created archive in Xcode's Organizer, runs a validation or even initiates App Store publishing right from the command-line. Ideally, this new command will be hook-able so that actions that make sense for App Store builds can run.

I'm not familiar whether there's a special kind of build that has to be done for Android in order to get the app in Store-ready state, but I think that what this command can do for both Android and iOS is to always codesign with distribution credentials and allow the resulting package to be saved in a custom location, rather than the platform folder.

Examples:
tns package ios --archive - perform xcodebuild archive and open the archive in Xcode. Could be the default action.
tns package ios --output <path-to-new-ipa-location>
tns package ios --verify - run itmstransporter's verification on the archive
tns package ios --publish - run itmstransporters publish step interactively
tns package android --output <path-to-new-apk-location>

[rosen-vladimirov]

I like the idea, just to mention that we already have --copy-to option that can be used to copy the .ipa, .apk to a specified location :)

[PanayotCankov]

I think an exported IPA does not contain debug symbols, while xcodearchive does.
With the support for 3rd party libraries I think the --archive for iOS is a must.
It will allow debug symbols to be preserved and sent to the App Store so that better native call-stacks can be retrieved later.
I hope this issue won't be ignored after the support for --release --for-device --copy-to was introduced.

[fealebenpae]

@PanayotCankov a regular build in Release already produces a dSYM bundle so --release --for-device --copy-to can be extended to copy that as well in the mean time.

Regardless of the way the dSYM bundle is produced, it's up to the developer to preserve it in order to manually symbolicate crash reports from apps built for Ad-hoc and Enterprise distribution, but I like your idea about submitting the dSYM bundle to iTunes Connect - if possible a hypothetical publish command should do that as well.

[teobugslayer]

These Gists can be helpful: 1 and 2

[stephenfeather]

We use a CI server to test, then post a properly signed adhoc IPA to installr for testing.
Command line options to choose the correct signing cert && appropriate provisioning file would be needed as well. (cross reference #635)

[rosen-vladimirov]

Implemented for ios

[Mitko-Kerezov]

iOS' implementation includes the following two commands
tns publish ios [<Apple ID> [<Password> [<Mobile Provisioning Profile Identifier> [<Code Sign Identity>]]]]] - for producing a release build and publishing it to iTunes Connect, along with
tns publish ios [<Apple ID> [<Password>]] --ipa <Ipa File Path> - for using an existing build for publishing to iTunes Connect.

For more information about both run tns publish ios -h

[dtopuzov]

Command is available, so this issue will be closed.
Related issue: #1790

[PanayotCankov]

We still can't produce xcodearchive from the command line.