cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Pogue <>
Subject Xcode 8 packaging changes
Date Thu, 15 Sep 2016 20:38:16 GMT
So Xcode 8 is out, and it simplifies some aspects of code signing, but
complicates the process of packaging an app.

Currently, cordova-ios will use the "iPhone Developer" certificate when
building a debug build, and the "iPhone Distribution" certificate when
making a release build. It uses xcrun with the (deprecated)
PackageApplication option to bundle up the build into an IPA file.

Xcode 8 has automatic provisioning, which means instead of dealing with
specifying a bunch of certificate files, you can pretty much just give it a
team identifier and it will figure things out. With one catch: you need to
use the "iPhone Developer" certificate. Support for the team identifier in
build.json has already been added to cordova-ios master.

However, in order to make a build in Xcode 8 with automatic provisioning
and a distribution certificate, you need to run the xcodebuild archive
step, and then an exportArchive step to generate the IPA. This workflow has
been supported since Xcode 7.

Currently, since Cordova uses xcrun PackageApplication, it is packaging up
a release build with the development certificate. This build cannot be
submitted to the App Store.

My proposal is for cordova-ios to drop support for Xcode 6 with the xcrun
packaging, and start using xcodebuild for archiving and generating the IPA.
I suppose that would have to wait for a major version bump of cordova-ios,
unless we detected the Xcode version and kept the old code around

As part of packaging, we would need to generate a exportOptions.plist file,
indicating what type of build to package (development, enterprise, ad-hoc,
or app-store). I'd suggest we add a "packageType" or "buildType" field to
build.json for specifying this value (with a default of development).

I'm happy to start prototyping this on a branch if it sounds like the right
approach going forward.

Related info:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message