Generating Provisioning Profiles with Member Account about steps-ios-auto-provision

[doomsayer13]

Hi @KoCMoHaBTa,
Thanks for reporting, we will check it ASAP.

[godrei]

Hi @KoCMoHaBTa

thanks for the detailed description of your idea!

Regarding to: Connecting Apple Developer account

I agree that using service accounts to manage various services is a good idea and yes currently on Bitrise you can only wire in Developer Portal account through an organisation member with admin role.

We decided to solve it this way, since organisation members with member role can not touch the project settings. If we would allow to use a member role user's Developer Portal account, that user could not see / modify in which Bitrise projects his portal account is used.

We are iterating on this feature and we will try to create a smoother process when connecting service accounts to Bitrise projects.

Regarding to: Xcode Automatic Code Signing and Provisioning

One of the main reasons that lead us to wire in the auto provision feature was to let our users to manage profiles (including new test devices, set new services, ...) used by the build without leaving Bitrise.

If we would use Xcode's auto provisioning feature you would still need to register your new tester's device on the Developer Portal (in order to have it included it in the Profiles) and on Bitrise as well (for being able to install the ipa through Bitrise).

Also when you use Xcode's auto provisioning feature it also registers the managed code signing files for your account, but does not allow you to see these files on the Developer Portal. For example if you create a new project and set Automatically manage signing in Xcode, Xcode will register an App ID with your project's bundle id. This bundle id will be locked, you cannot see or manage it on the Developer Portal, but if you decide to manually manage your code signing files you can not register an App ID with the same bundle id. If you would try it, you would see:

There were errors in the data supplied. Please correct and re-submit.
An App ID with Identifier 'my.new.project.bundle.id' is not available. Please enter a different string.

So Xcode definitely touches your Developer Portal account, but does not allows you to see / modify the managed files.

Regarding to: security concern

Even if we would use Xcode's auto provision you still would need to provide your Developer Portal credentials. We are researching how we could make use of (app-specific passwords)[https://support.apple.com/en-us/HT204397] to solve the auto provision,
this would decrease the security concerns.

I hope this helps, but let me know if you need more info!

[KoCMoHaBTa]

Hi, @doomsayer13

Thanks for the detailed response.
I would like to add few more points of clarification on the topic.

Regarding to: Connecting Apple Developer account

I'm looking forward to see, how this will go.
Probably connecting the Apple Developer account to the project directly by an admin account, instead of linking an account connected to an Admin user - might be more flexible, since there could be different apple developer accounts for the different repositories.
Otherwise, this would require to add users for each apple developer account that might be connected.

Regarding to: Xcode Automatic Code Signing and Provisioning

Thanks for the clarification about the goal of the step.
If I understand it correctly, from your details, it is to have single data flow that is from Bitrise to Apple Developer Portal in order to keep things simple and try to solve the struggling with apple certificates and provisioning profiles for most of the peoples. Something like "With this step, Bitrise will be able to handle everything related to provisioning and developers should not be bothered".

The idea was about having, exactly the opposite - the ability for Bitrise to only read from Apple. We leave Xcode to handle the Apple Developer Portal management and Bitrise to use what's in there. So adding a device, would require only adding it on the Apple Developer Portal and Bitrise would just start using it.
The point was to allow the users to use the step's reading functionality without using the writing one, since it does it anyway.
In case my idea is totally not the goal of the step - probably you could point me to another one that exists out there that provides this behaviour, or creation of such could be considered.

In regards to

So Xcode definitely touches your Developer Portal account ...

Yes it correct that xcode touches the Developer Portal account and since it is the only official way of doing it (the iTunes Connect API is not yet public) - we prefer to use it.

However regarding

... but does not allows you to see / modify the managed files.

This is true, only for personal free accounts - company accounts can see and modify everything that was managed by Xcode and also, any change Xcode request to do, requires explicit action from the developer.

Regarding to: security concern
Its about permissions to write to the portal - having different kind of authentication would not prevent the step from modifying stuffs from the Apple Developer Portal.

[godrei]

Hi @KoCMoHaBTa ,
thanks fo the infos! I will talk this through with the team.

[yonaskolb]

Hi. Are there any updates on this? Has anything in this space changed since Dec?

[godrei]

Hi @yonaskolb , yesterday we released a new version: 1.0.0. The new version prepares the step to work with Xcode managed signing enabled iOS projects.

If you want to avoid to let the step generate codesign resources for you, use Xcode managed signing in your project, this way the step just registers the Bitrise test devices (if any missing in from the Developer portal) and downloads the Xcode managed profiles for your project.

I'll close this issue, but if you need more info/help just let us know and we'll reopen it!

[KoCMoHaBTa]

Sounds promising, just a quick question - i know that admin access is needed to register a new device, so the question is - if the user does not have admin access, will it at least download the Xcode managed profiles?