I have problem in building the app (refer image 1.png, 2.png, 3.png) It fail to build as used the wrong signing identity (by view the error log 3.png). However, it is ok previously. But now fail.
I tried to removed the ad hoc cert and download the mobileprovision file again. However, still not work.
You can see 1.png I used the correct cert, ad hoc build, mobile provision (1.png) where the cert export from my keychain (2.png). But it still fail (3.png)
Here is my env:
XDK v3522
MAC OS: Sierra
Link Copied
Arthur -- when you create a new cert you should create a new provisioning file to go with it, and then reference that new provisioning file in the build settings of the Project tab. The XDK uses the provisioning file you specify on the Build Settings, it is provided by you via your project. We do not pick a provisioning file, we use the one your project provides to us. If it matches the cert you are using it will work, if not, it will fail.
Arthur -- I recommend you create a clean set of Apple certificates and use those. Sometimes the certificates are no longer valid due to a time expiration or changes in your Apple Developer account. The simplest solution is to create a new set and start over. Unlike Android apps, with an iOS app you can use a different set of certificates to update your app, as long as they came from your account.
Arthur, I'll ask XDK engineers if they have any suggestions. In the meantime I assume you've seen these articles regarding using certificates:
https://software.intel.com/en-us/xdk/articles/walkthrough-obtain-ios-appstore-adhoc-cert
These threads might also help:
https://software.intel.com/en-us/forums/intel-xdk/topic/621641
https://software.intel.com/en-us/forums/intel-xdk/topic/584198
https://software.intel.com/en-us/forums/intel-xdk/topic/607965
https://software.intel.com/en-us/forums/intel-xdk/topic/607998
Same to XDK v3619. I download the cert and provision from Apple again and sure the cert is valid (not expire). Then import the cert to my imac keychain (link up with my private key). Export it as p12 and import to XDK's server (remove the old one first). But XDK build system still use a wrong identity to sign the ipa.
I'm sorry Arthur that you're still having problems with the certificate for the build. If you'd like to give it another shot you can follow the instructions here: https://software.intel.com/en-us/xdk/docs/intel-xdk-certificate-management#ios-create-p12
When it asks you “would you like to use keychain?” answer 'No' and follow the “I answered no” instructions further on.
As I guess, problem remain and it is not related to how I generate the p12 file. It is problem of the server build system which fail to choose a correct cert to sign the ipa.
However, I found out the reason. It is the provisioning file. It can only link to 1 cert (the one suppose used to sign the ipa) As my provisioning file included other certs (this provisioning I currently used in XCode and so it links to multiple certs). It causes the problem. But it should be the XDK server build system problem as it should look to the cert I choose to sign it instead of found from provisioning. After I create another provisioning for XDK and only link to 1 cert. It build without issue. So again, it is XDK server build system bugs as it works before.
Arthur -- when you create a new cert you should create a new provisioning file to go with it, and then reference that new provisioning file in the build settings of the Project tab. The XDK uses the provisioning file you specify on the Build Settings, it is provided by you via your project. We do not pick a provisioning file, we use the one your project provides to us. If it matches the cert you are using it will work, if not, it will fail.
I know I have to use a new provisioning file whenever a new cert used. The point is the provisioning file need to link with ONE cert only. Otherwise it will fail to build even though everything specified correctly. However, Apple not restricted the provisioning file can only link with one cert. That's why I fail and I suspect the new coding at your server build system now restricted it as it works before.
For more complete information about compiler optimizations, see our Optimization Notice.