A Beginner’s Guide to iOS Provisioning Profiles | Hacker News Reader

A Beginner’s Guide to iOS Provisioning Profiles

theodo.fr

The tooling around iOS is a mess. Provisioning profiles, entitlements, plists, signing identities, APN certificates, keychains, targets, frameworks, service extensions are pretty much impenetrable. None of it makes sense conceptually and everything is vastly overcomplicated, so you're essentially following a wizard in XCode (the infamous "Fix problems" dialog), copy and pasting answers to desperate Stack Overflow questions or simply randomly trying things until it works.

XCode is the worst. Many pieces of functionality are only exposed through XCode rather than via a command line API. This means that you're essentially tied to a UI, Visual Basic style; building artifacts on a headless CI server requires you to jump through all kinds of hoops like unlocking a keychain. Worst of all, XCode itself is buggy more often than it is not, leading to the common advice to "close XCode and delete your Derived Data directory".

You're stuck between manually modifying the (eminently non-human-readable) project files in an editor, in which case you can see what you're changing, or going through a ever-changing UI, risking accidental breakage. From the perspective of a Unix developer, it's a wonder anyone gets anything done on iOS.

I am pretty certain you can accomplish anything Xcode can do using a combination of the openssl command line tool, Apple's codesign command line tool, and manually flipping switches on Apple's website (which is only needed to set things up, not build stuff later); but, to be honest, I am normally (but I don't think usually...) using some of my custom tooling, which means I am not 100% sure (I am the developer of Cydia Impactor, which reimplements and automates all of this stuff to accomplish "here is an IPA that may or may not be signed; I want to install this on my iOS device as if it were signed by me" on any platform, such as Windows or Linux). Do you have an example of something that you believe can only be done by Xcode? I get the impression that a lot of iOS developers just kind of assume they are locked into Xcode, but in fact I want to argue no one should be using Xcode (as it really does suck, and it is totally unneeded).

FWIW, I don't know how to use the codesign utility without unlocking the keychain, but that UI has nothing to do with Xcode, and I bet someone who is an expert with the keychain might have a non-crazy workaround for you given that I think the codesign application lets you specify a custom keychain: like, I would be surprised it you can't make a keychain that doesn't require being unlocked. To me, the most annoying thing about the official tooling is that the codesign tool uses Apple's "timestamp server" (AFAIK, in order to help make things not do devastating if you have to revoke a private key: you can use the embedded signed timestamp to trust that a binary was signed before it was revoked) and so does not work unless you have a connection to the Internet.

To be honest, I'm of the opinion that they're "automagical" fixes have made things worse. Back in my day we understood what was going on behind the scenes and subsequently knew how to fix the problems, and now that these tools exist, I frequently find them to be in the way of fixing things that I would otherwise know how to do myself.

My company manages just a couple apps for iOS. They aren't updated too frequently, maybe 3ish times per year. Few things fill me with dread more than trying to release a new iOS app after a certificate has expired. As others have mentioned, the process around provisioning profiles, certificates, managing them within Xcode, etc, is extremely complicated, and the 2-5 day review period makes things even more stressful because there's no easy way to just upload a fix when something goes wrong (like device tokens suddenly stop generating in production). Since we push updates so infrequently, every other push requires updated certificates and the large time gaps make it easy to forget how much of a pain it is until you're trying to do it.

Some things that I am thankful for:

- TestFlight. It's a pain that I have to have the app approved before I can send the beta out to my internal users. Seems like internal should let internal users update to a beta version without review (while external would still require a review). At least it lets us test with our production certificates eventually. It's still a pain if something is discovered and it requires a rebuild and a new review.

- Emergency Review Requests. I've had to submit 3 of these over the past several years, and Apple has always initiated my within 2 hours. I really appreciate this, and I'm glad that people haven't abused it so much that they've scrapped it.

Is there a service or GUI tool which, if it magically existed and understood all of these steps and so was only limited by the underlying cryptography involved, would noticeably mitigate or even dissipate your "dread"?

There's https://fastlane.tools, but I haven't looked into it a ton. It seems to require a big investment to get things rolling, but probably solves a lot of these problems after that. I'll have to revisit it at some point...

I am more trying to ask the question "what is the minimal modification to your current, depressing workflow that would have made your life easier: what is the magic artifact weapon you wish you had in your arsenal to cut through your pain points (or even just, what is your single largest obstacle in the middle of the battle, when boiled down to a single moment where a deux ex machina would have been useful)", as opposed to "would you be willing to opt into a totally different lifestyle of peace and love, it only requires that you disavow all of your current earthly possessions and relationships".

> I once even got sent a 40-character, hexadecimal string that wasn’t a valid UDID, and looked nothing like the actual one they eventually sent me. To this day, I still have no idea where they got it from.

A UDID is the result of a SHA-1 calculation: there is no such thing as a 40-character hexadecimal string which is "isn't a valid UDID" by syntax, so this is interesting to me: if the author ever sees this, did you get an error saying that from Apple (in which case we know they have a massive database of every device in existence)?

(Note that UDIDs beginning with 32-bits of F are returned by the APIs that provide app-specific advertising identifiers on the device, so if you saw one of those and decided it was "invalid", that was returned because they used a tool which tried to return a UDID but was using the older public APIs to do that from a sandboxed application.)

(edit: Oh, I just noticed there are comments on the website. I'm stupid, and will copy this there.)

> if the author ever sees this, did you get an error saying that from Apple (in which case we know they have a massive database of every device in existence)

Some sort of data is bundled up in that string: when you add a device's UDID to the Apple dev portal, the confirmation page will tell you what type of device it is (iPad 2, iPhone 7, etc).

I can't recall entering a bad UDID, so I'm unsure what that looks like.

I can tell you with 100% certainty that a UDID is the result of a SHA-1 and so there is no ability to have "data bundled up in that string"; I know this because we've reverse engineered the computation of this string, and there is now tons of software in the wild which just builds it from parts instead of using Apple's APIs. Here's information on the algorithm from our Wiki.

https://www.theiphonewiki.com/wiki/UDID

For Apple to be telling you what kind of device it is, they either have to have a database of all the devices as they are built or a database of devices which have been checking in to their servers. (I'm betting the latter is what is happening here, but the former would be fundamentally more interesting to me.)

Hello! Yes, as orbitur mentioned, Apple tells you the device type after you enter a UDID. The one that didn't work was accepted, but didn't return a device type. We tried it anyway, but the app wouldn't install, which is why I described it as 'invalid'.

> Note that UDIDs beginning with 32-bits of F are returned by the APIs that provide app-specific advertising identifiers on the device, so if you saw one of those and decided it was "invalid", that was returned because they used a tool which tried to return a UDID but was using the older public APIs to do that from a sandboxed application

It did have a bunch of Fs at the beginning, so that is probably the explanation! Thanks :)

Everything to do with iOS development and deployment is just so mindbogglingly complicated.

I dread everytime I'm forced to open XCode to compile or deploy something.

I have felt this pain also. I had a play - even spent a bit on the developer ID. What a waste. I was doing a Unity 3D* app for fun (part of the fun would be publishing it) and got all the way to the end, just to realise the amount of bureaucracy and hoops to jump through to publish, just isn't worth it. I want to write and publish software not be a source for the app store inventory sink. Instead, I will write software on a different platform all together. Apple's loss, not mine.

* Unity 3D applications are deployed to an iOS device through XCode.

As someone interested in moving slowly into mobile development from heavy web application development experience, is Android development much easier?

The provisioning? Yes, easier on Android. Getting published in the app store? Yes. Having an IDE that doesn't crash daily? Yes.

Everything else is harder/worse though. Documentation, SDK/APIs, device ecosystem (so, testing and QA). So pick which part(s) of the experience you'd rather have not-suck and go with the platform that matches it best, if ease of development is your main concern.

[EDIT] if you do decide to go with Android, look at Square's libraries and their documentation of how they develop for Android. They've done a lot to de-shitify the platform, but it means doing things very differently from how you would if you followed the official docs. If you're doing anything non-trivial you could do a lot worse than deferring to Square's judgement on how to structure your application.

Side note: have you looked at React Native? (I think) it's great! (https://facebook.github.io/react-native/)

Reply on news.ycombinator.com