-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP][do not merge][RFC] feat: support for development provisioning profiles (iOS) #2071
base: main
Are you sure you want to change the base?
Conversation
cc @quinlanj - i believe you explored development provisioning profiles before and there wasn't a clear way to make this work |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brentvatne I looked into Developer profiles a while back, but it was for free developer accounts, which we discovered doesn’t work with the regular Apple API’s.
@fobos531 Thanks for this initial PR. Could you confirm my understanding of your usecase:
- You want to sign your app with a Developer profile. The only reason for this is because of an Apple restriction for the Tap To Pay feature.
- You want a similar workflow to our
internal
distribution, but use the development profile instead of the adhoc profile - You want to add your test device UDIDs to the Development profile and build your app with eas-cli
- You want to distribute your built app to your test device with the installation link we provide on the website.
If this is correct, would you be able to test building a Development profile in your local eas-cli? You can build it all under the ‘internal distribution’ codepath, but change the parameters to the Apple API to make the Development profile instead. Ideally you would be able to distribute it with the installation link we provide in the website. I’ve never tried to do this, so it would be super helpful to know if all the functionality is preserved 😮
@fobos531 also to answer your question about |
Hey @quinlanj ! Yes, that is exactly the workflow I am looking for. You couldn't have said it better. I tried testing building a development profile, but it seems that for me to do that, I first have to have a Development certificate. Creating it on the portal is easy enough, but the intended workflow of |
@fobos531 we'll need to change the servers to support development certificates properly. As a hacky workaround to test the functionality for now, can you try to upload it as an adhoc distribution certificate via the graphql API? afaict, distribution and development certs are of the same format, so it's worth a shot. If this doesnt work can you link the problematic line of code or send a screenshot of the cli workflow that is blocking you? |
Hello @quinlanj, just wanted to check - have your perhaps been able to update the servers to properly support development certificates? |
Why
When adding a Tap To Pay on iPhone feature to my app, I found myself needing to use the Development provisioning profiles to sign the app. In initial phases of the development of this feature, Apple usually only grants you this entitlement for the Development provisioning profiles - it has proven to be a big hassle to manage these profiles manually, so I'm looking into adding the support for this right into
eas-cli
How
1:1 implementation based on the AdHoc feature. Added
development
distribution method everywhere I could find. On Android, it behaves exactly the same asinternal
, so iOS is essentially the only platform where stuff got changed. I assume there might be places that require upstream changes, like e.g.@expo/eas-build-job
to fully add support for this. Right now, my implementation ends up with a lot of duplicated code in the iOS part of the implementation (AdHoc and Development) - ideally, I would like to extract the common parts and just keep the ones that are specific to AdHoc vs. Development.For some reason, when I run the build command locally, TS keeps complaining that @expo/eas-json is not installed, even though I ran
yarn
in the project root. Any idea why this would happen?Test Plan
None as of now
At the current state, this PR is a proof-of-concept, untested, and is just in its inception phase - I'm looking for your feedback on whether this is a good direction/approach to take and any API design recommendations.
Thank you!