
A Beginner’s Guide to iOS Provisioning Profiles - harisriskantha
http://www.theodo.fr/blog/2017/02/a-beginners-guide-to-ios-provisioning-profiles/
======
loevborg
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.

~~~
saurik
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.

------
Eclyps
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.

~~~
saurik
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"?

~~~
Eclyps
There's [https://fastlane.tools](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...

~~~
saurik
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".

------
saurik
> 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.)

~~~
orbitur
> 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.

~~~
saurik
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](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.)

~~~
harisriskantha
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 :)

------
Illniyar
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.

~~~
laythea
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.

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

~~~
ashark
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.

