Xcode 8.3.3 will archive and export, but 9.0.x won't export


Owen Hartnett
 

Building an enterprise app. I can archive the code with Xcode 8.3.3 and export my enterprise app. It does the right code signing.

On 9.0.x Xcode, it will archive, but even though I have automatic signing turned on, it asks me for a profile. None of these are the automatic profiles (which begin with XC). I can tell it to download one of the XC profiles, but then it says it can’t use it, because I have automatic signing on! If I turn automatic signing off, and try to select the XC profiles, it says I can’t select them because they are automatic profiles!

Any suggestions?

-Owen


Peter Hudson
 

Catch 22 comes to mind.

On 25 Oct 2017, at 22:11, Owen Hartnett <owen@clipboardinc.com> wrote:

Building an enterprise app. I can archive the code with Xcode 8.3.3 and export my enterprise app. It does the right code signing.

On 9.0.x Xcode, it will archive, but even though I have automatic signing turned on, it asks me for a profile. None of these are the automatic profiles (which begin with XC). I can tell it to download one of the XC profiles, but then it says it can’t use it, because I have automatic signing on! If I turn automatic signing off, and try to select the XC profiles, it says I can’t select them because they are automatic profiles!

Any suggestions?

-Owen


Sak Wathanasin
 

On 25 Oct 2017, at 22:11, Owen Hartnett <owen@clipboardinc.com> wrote:

Building an enterprise app. I can archive the code with Xcode 8.3.3 and export my enterprise app. It does the right code signing.

On 9.0.x Xcode, it will archive, but even though I have automatic signing turned on, it asks me for a profile. None of these are the automatic profiles (which begin with XC). I can tell it to download one of the XC profiles, but then it says it can’t use it, because I have automatic signing on! If I turn automatic signing off, and try to select the XC profiles, it says I can’t select them because they are automatic profiles!

Any suggestions?
Does the account you use have the privs you need to create a prov. profile from the distribution certificate? I think you need to be a team agent or admin. Our distribution cert expired a month or so back and it took me much hair-pulling to get our CI build box to work again. As I remember it, I had to get a grown-up to regenerate all the profiles that were linked to the expired cert, then I ended up deleting all the profiles on the build box and making XC download them again.

Be that as it may, if you dig into the build logs, you should see lines like this:


-[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path '/var/folders/50/w9h_mj9n3vb_54kfll2kb79r0000gn/T/xxxx_2017-09-14_00-35-43.865.xcdistributionlogs'.

** EXPORT FAILED **

If you then look into that log folder, you can get additional info as to why it failed.

Sak


Owen Hartnett
 

On Oct 26, 2017, at 6:13 AM, Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:


On 25 Oct 2017, at 22:11, Owen Hartnett <owen@clipboardinc.com> wrote:

Building an enterprise app. I can archive the code with Xcode 8.3.3 and export my enterprise app. It does the right code signing.

On 9.0.x Xcode, it will archive, but even though I have automatic signing turned on, it asks me for a profile. None of these are the automatic profiles (which begin with XC). I can tell it to download one of the XC profiles, but then it says it can’t use it, because I have automatic signing on! If I turn automatic signing off, and try to select the XC profiles, it says I can’t select them because they are automatic profiles!

Any suggestions?
Does the account you use have the privs you need to create a prov. profile from the distribution certificate? I think you need to be a team agent or admin. Our distribution cert expired a month or so back and it took me much hair-pulling to get our CI build box to work again. As I remember it, I had to get a grown-up to regenerate all the profiles that were linked to the expired cert, then I ended up deleting all the profiles on the build box and making XC download them again.

Be that as it may, if you dig into the build logs, you should see lines like this:


-[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path '/var/folders/50/w9h_mj9n3vb_54kfll2kb79r0000gn/T/xxxx_2017-09-14_00-35-43.865.xcdistributionlogs'.

** EXPORT FAILED **

If you then look into that log folder, you can get additional info as to why it failed.

Sak
Thanks for the reply, Sak. The distribution certs and profiles are all current, and the build logs never get to the point where anything is recorded on this. It only displays invalid profiles, and doesn’t display the valid ones.

To keep us going, we changed over to manual signing for all our apps. This is a chore as each target has 4 profiles: app, watch app, watch extension, decryption extension. All I can say is that automatic signing is irretrievably broken in Xcode 9.0.x. Tough for me, as I was the one who pushed for it “to save time” maintaining all the multiple profiles, only to waste time tracking this thing down.

-Owen


Alex Zavatone
 

Watch extension?

This clarified what you are going through.

When making my previous iOS app, we had 3 build configs.  Dev, Ad-Hoc and Distribution.  

As soon as we added a sharing extension, this cratered our build process when making an distro build.

Does your app offer push notification?

As soon as we added an extension, we had to make sure we had info.plists for each of our build configs, because when Xcode exported the archive, it checks against the info.plist for the right set of entitlements or the export will fail.

EVEN THOUGH dev/release for push matters when really issuing push, Xcode didn’t care when exporting - UNTIL we added an extension.  

Our solution was to name the info.plist with the product name and the build config so that it would dynamically would pick the proper info.plist for the app that we were creating, and the build config we were building to.  The naming of the info.plist was set to be the $PRODUCT_NAME and then the config name and then .plist.

We could then set the proper settings in each plist for each product and we were able to run and export each of our products that came off of each of our build configs.

I know, because the buck stopped with me and I had to make sure that all of the builds worked and didn’t trust anyone else to make the provisioning profiles.  

BUT HERE IS THE PROBLEM.

You do this over TIME.  Provisioning profiles build up in your profile folder.  Xcode will PICK THE FIRST PROVISIONING PROFILE IT FINDS THAT MATCHES THE REQUIREMENTS SPECIFIED NOT NECESSARILY THE NEWEST ONE OR A VALID ONE.

Xcode OFTEN will pick a 6 month old provisioning profile.  

As the Admin, I would make sure that I had downloaded the latest provisioning profile for the app AND FOR THE EXTENSION.

When Xcode was exporting prior to 9.0, there is a little -> on the right (that the idiotic UI designers have obscured) indicating the profile it will use and you click on it and display the profile.

When signing, it is CRITICAL that you locate and view the  the profiles being used and that you preview the profiles.  We avoided a lot of problems this way.  Xcode 9 helps with this somewhat.

Your provisioning profiles are here:

~/Library/MobileDevice/Provisioning\ Profiles/

How can you preview a provisioning profile?  With this:


Details here:

With tool, you can see if your code signing will match what is in your info.plist.

MANY OF THE CODE SIGNING ERRORS ARE NOT ERRORS IN CODE SIGNING.  The errors do not say this though, but are in fact errors in the criteria specified in your app’s info.plist do not match what the code signing provisioning profile has in it.

We used this manual process, and we knew it would work because we could control it.  

By setting up the info.plist naming to map the file to the name of the product and name of the build config profile allowed us to set up info.plists that would always work for all of our build configurations, including weekly App Store distributions.

Here’s hoping this helps you get a little more info on the nature of why it may be failing.  

Glad you have some resolution to the issue, even if it is a manual one : /

Alex Zavatone





On Oct 30, 2017, at 12:07 PM, Owen Hartnett <owen@...> wrote:


On Oct 26, 2017, at 6:13 AM, Sak Wathanasin <sw@...> wrote:


On 25 Oct 2017, at 22:11, Owen Hartnett <owen@...> wrote:

Building an enterprise app.  I can archive the code with Xcode 8.3.3 and export my enterprise app.  It does the right code signing.

On 9.0.x Xcode, it will archive, but even though I have automatic signing turned on, it asks me for a profile.  None of these are the automatic profiles (which begin with XC).  I can tell it to download one of the XC profiles, but then it says it can’t use it, because I have automatic signing on!  If I turn automatic signing off, and try to select the XC profiles, it says I can’t select them because they are automatic profiles!

Any suggestions?

Does the account you use have the privs you need to create a prov. profile from the distribution certificate? I think you need to be a team agent or admin. Our distribution cert expired a month or so back and it took me much hair-pulling to get our CI build box to work again. As I remember it, I had to get a grown-up to regenerate all the profiles that were linked to the expired cert, then I ended up deleting all the profiles on the build box and making XC download them again.

Be that as it may, if you dig into the build logs, you should see lines like this:


-[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path '/var/folders/50/w9h_mj9n3vb_54kfll2kb79r0000gn/T/xxxx_2017-09-14_00-35-43.865.xcdistributionlogs'.

** EXPORT FAILED **

If you then look into that log folder, you can get additional info as to why it failed.

Sak


Thanks for the reply, Sak.  The distribution certs and profiles are all current, and the build logs never get to the point where anything is recorded on this.  It only displays invalid profiles, and doesn’t display the valid ones.

To keep us going, we changed over to manual signing for all our apps.  This is a chore as each target has 4 profiles:  app, watch app, watch extension, decryption extension.  All I can say is that automatic signing is irretrievably broken in Xcode 9.0.x.  Tough for me, as I was the one who pushed for it “to save time” maintaining all the multiple profiles, only to waste time tracking this thing down.

-Owen