Replies: 3 comments
|
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. |
|
You have more faith in apple than I do. Every time I run something on my M5 Mackbook, apple warns me that the tool Apple has a long history of crapping on developers. They decide. You follow or else. Specs and interpretations change |
|
No. Apple is actually very good at announcing deprecations and phasing out old unsupported stuff. The problem is that it's hard to keep track, we solved that problem: https://www.codenameone.com/blog/platform-deprecation-watch/ What you're seeing is Apple killing its intel support which is good. These old apps eat up your battery and you don't even notice. Since we're running on top of their platform they decide anyway and we need to align. We can make the landing softer but there will still be a bump. |
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