We released a new version (1.0.1) of iOS Auto Provision step.
Changes:
We have some problems with the device registration. The auto provisioning step checks if the device is registered on the developer portal (it is), but the device is not included in the provisioning profile that is used later when archiving the project.
This is the affected build: https://www.bitrise.io/build/f15a3d2ba9352803
My device ID starts with “752b”.
The project uses Xcode managed signing.
As I understand it, the Auto Provisioning step pre-1.0 always re-generated a provisioning profile which was then used in the archive step (using manual signing). Since 1.0 the Auto Provisioning step does not create its own provisioning profile anymore but instead uses Xcodes automatic signing.
But the problem here is, that Xcode will not automatically add new devices to the provisioning profile. When building in Xcode and the connected device is not in the profile, Xcode will show you a warning and you can then add the device with a click.
What we want from a Bitrise build though is that all test devices (devices from all the users added to the team) can install the build without manual intervention when new devices are added. Pre-1.0 this worked great, after adding a new device or team member, the UDID of the device was added in the next build. Now, this isn’t the case anymore and I am not sure if that’s on purpose or what’s the suggested solution.
This is actually the same problem as described here: iOS automatic provisioning does not use a profile with all devices included
the thing is that if an Xcode project used Xcode managed signing, in some cases the pre 1.0.0 functionality (which you described correctly) was not able to regenerate the provisioning profile, since the bundle id was locked. You can read more about this here: https://github.com/bitrise-steplib/steps-ios-auto-provision/issues/11.
To solve this issue we introduced the new functionality, which you described well: if the project uses Xcode managed signing, we just download the profiles.
However this way the step relies on the Xcode managed profile existence (Xcode created the desired profile or not) and state (Xcode updated the managed profile or not).
I think a better solution would be if the step would work as previously (generating profiles and forcing the project to use the generated profiles) and as a fallback it would try to download the managed profiles if the project uses Xcode managed signing. Or may this switch would be controllable by a new step input.
We will discuss this question with the team, but i would be happy to hear your opinion as well.
I think a switch such as “allow Bitrise to generate provisioning profiles” would be great and it would give the user the option to opt-out of the pre 1.0 behaviour if needed.
Regarding the pre 1.0 issue: does it help if one creates a provisioning profile manually afterwards? Ususally Xcode only uses the automatically created profile if there is no other matching profile.
I have never had the problem with locked bundle ids and we always use Xcode managed signing …
Hi @matthias.buchetics,
a new version of the step is released: iOS Auto Provision v1.1.0, which allows you to use the pre 1.0.0 functionality, even if your project uses Xcode managed signing.
Hi @godreikrisztian, first test was successful! I used the generate_profiles flag.