Replies: 1 comment
|
Well... If we knew that certificates/provisioning don't work we would not generate them to begin with. Apple probably won't change a structure of certificate issuing it had for over a decade. We're using an official Apple API to get this information and the UI mirrors what we get. The idea is that the single click automation should solve the problem for the simple case of "I just want to build an app". For the "difficult" cases we want to offer the same power as a native developer and the best way to do that is to mirror what Apple is already doing and documenting. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Recent changes are an improvement, but the certificate wizard is still hard to use, hard to understand, and
basically a UI nightmare. It's not entirely your fault - Apple's certificate/identifier/profile process is a a terrible
mess, hard to use, impossible to understand or justify. The current wizard makes the mistake of mostly
trying to mirror apple's mess.
I propose that the first, and usually only screen that I see in the certificate wizard have just 3 sections
(1) the certificate
(2) the identifier
(3) the provisioning profile(s) - maybe 2 or 3.
and at the bottom, a "VERIFY" button. The contract should be that if I click on verify
and the above three things come up green, I should expect to be able to submit builds
that will not fail due to interactions with apple.
I appreciate that this isn't trivial - there are a lot of ways verification can fail due to expired, revoked,
missing or mismatched components. And the complex dance the build servers do with apple probably
isn't easily separated from actually building. The three sections need explanations of failures, fix-it buttons,
and links off to screens like the currently available screens, or some substitute.
I think its a mistake to present shadow/clones of apple's structures such as the list of profiles.
Apple is sure to screw you over by changing them, and by trying to duplicate their functionality
you're just buying into a treadmill. Maybe some screen shots showing what part of developer.apple.com
to access. The backstop for any thing that is an apparent mismatch between what the certificate
wizard thinks it should do and what apple wants is always to paste some identifier from developer.apple.com
and use the associated file retrieved from apple.
All reactions