Oh, not at all. It's simply hell.
There are a vast amount of conflicting docs out there and Apple's docs are rather thick.
Even going through Apple's assistants or wizards (barf) take you through different paths, and the GUI's flow appear to have originated in different teams.
I even spent the time to inform our new developers to the basics of the process of simply getting set up and he ended up sending me a document for Apple's Xcode docs that was for Provisioning and Distribution for Apple Push Notification.
Apple Push Notification? How did he end up thinking that this was the reference for provisioning and deployment?
The thing is that this guy wasn't even able to see that Provisioning and Distribution and for Apple Push Notification is NOT iOS Application Provisioning and Distribution.
He's not an idiot.
There are just too many docs spread all over the place with parts of the information and it's a simple mess.
Sometimes, when you make a request for a cert or a provision through a web page, it goes into a "pending" state. Then sometimes, you refresh the page and you'll see that it's been issued and ready to download. It will never refresh on its own and state that "your request is competed and ready". Other times, an admin (me) will need to OK it. How are you to tell what is the case?
This is just BAD process GUI design.
Look. Here's the outline - with pieces missing no doubt. I'll be going through Enterprise to start.
You need an Enterprise account.
You need to install an Apple dev cert in your keychain
You need to request a cert for yourself. - if inspected, It will say that it's signed by an untrusted authority - this adds confusion
You need to submit that cert to developer profile
You need to download your approved cert/whatever and install it in your keychain
You need to create an app id back in the provisioning portal.
You probably need to download that and install it - not into your keychain, but into Xcode - I think.
You need to create a developer provisioning profile for that app BUT WAIT...
you have to add all provisioned devices to that profile WHICH ARE HARD CODED INTO THE DAMN PROFILE
This means that if an IMPORTANT PERSON on the OTHER SIDE OF THE PLANET gets a new device, you have
to contact them, get their device's ID, add it to the development provisioning, redownload and import the profile,
rebuild, rearchive, resign and repost your app. Why can't we simply email a damn app and have it install from
the device or from iTunes?
After one of our Cs found out that he had to click on the serial number of the device in iTunes to get the UDID to
send me, he replied: "Stupid Apple." Yeah, I feel the same way
Why the HELL doesn't the development provisioning profile automatically look up from "the cloud" the devices
that should be in the development distribution provisioning profile and update it? It's a damn look up table
after all! AND this is for DEVELOPMENT, not distribution. Why, for the love of puppies and the baby Jesus
are the device profiles hardcoded into the development provisioning profile?
All this to let someone who is not in your office use a development version of your app. WTF?
Then you have to create a distribution provisioning profile, download, install and distribute that. And the profile can be wrong. It can completely not work with your own Enterprise account's own apps.
Distribution profiles can be shown as Active in the provisioning profile, but when you sign in as the account owner, you'll find out that they are EXPIRED and nowhere is this mentioned if you sign in to the Provisioning profile with Agent privs.
To build and distribute the app, Apple has this "OTA" ("Over the Air" - whoop dee doo) distribution method it appears that manifest file only takes one URL. What if I have more than one and a staged delivery? Does the URL support wildcards? Can the dialog sheet where you enter this info even be expanded to accommodate long URLs? (No, it can't) Do I have time now to read up on this or wade through the thick docs to even find this info?
Why is this so damn overly complex?
When installing an app ala the OTA method onto a device, the install will start, go to about 3/4 of the way, THEN BACK UP (yes, the installer progress bar will back up) and fail saying "it can't be installed" if one character in the manifest for the URL that the app is to be distributed from is wrong, OR if the OS on the device is not supported OR if the device that is being deployed to is not in the hard coded developer provisioning profile.
But will the installer or the logs actually tell you what is wrong or why the install failed?
Nope.
I remember when the Apple experience used to not suck, when the products used to be a pleasure to use and work with.
And I haven't even gotten to the final deployment of a released product within the enterprise yet.
This is easily an overly complicated, time consuming, maddening, expensive and ultimately shitty process.
Honestly. It's in Apple's own best interest to remove conflicting information and STREAMLINE this process, add descriptive error messages and remove the pain out of the developer setup and deployment process.
It's really not that hard.
Apple needs to add this process to the starting point for developers on iOS.
Before you get going:
- Get a list of all the people you will need to add to be developers for this account
- Get all the device IDs of all the devices you will currently be using in development
SUPER IMPORTANT NOTE: You will need to remake and reinstall the dev provisioning file for any app if you get new devices.
- To distribute your file, you can choose these methods:
- x, y, z
- to prepare for those methods, you'll need to have this and to this.
- A, B, C
- once you get all set up, here is a sample app you can test building and deploying with.
- Link here
- once you're all set up with the above, click on the link below to read the rest of the guide to get your app built in the simulator, on a device, then distributed to another developer device. After that, there is one more doc on deploying to your company/group that will take you through a simple case.
USE AND PROVIDE a SIMPLE CASE example (Hello World is lame, use a drill down TVC that is storyboarded) to guide developers through the process.
The important part is that ONCE YOU ARE GUIDED THROUGH THE PROCESS IN A SIMPLE, NON MISSION CRITICAL APP, it all becomes a hell of a lot easier.
Now, back to the joy of actually programming.
On Jun 22, 2012, at 9:47 AM, Roland King wrote:
I think this is a little unfair. The provisioning process isn't that bad, it was originally, but it's now pretty good and the documentation has improved massively. This is a good document
TN 2250 ~ iOS Code Signing Setup, Process & Troubleshooting, but it has to be read in full and it takes a while, it's thorough and clearly tries to address lots of misconceptions the author regularly came across. I think a lot of people dip into it and that doesn't work.
I hate the auto provisioning stuff in Xcode, it hides the process and fills your keychain up with countless certs and keys, and when you need to understand what's going on, you don't.
If by 'leading numbers' you mean AppID, that's an important concept. If that is what you mean I'd say that has been slightly less-well documented, it took me a while to come to grips with it and I feel the best practice has changed over time. Originally lots of different AppIDs with wildcards were recommended .. then push turned up, wildcards are a bad thing there and in the end the segregation which different AppIDs enforced was rarely useful and now just having one, using it for full paths, and adding iCloud entitlements as needed seems to be a better way to go. The docs on that have improved however, but you need to read them when you aren't in a panic deploy situation. It's true that just flapping at deployment and trying random things is probably not going to be productive, but the process is not that complicated and the totality of documentation is now pretty good.
On Jun 22, 2012, at 10:24 AM, Alex Zavatone wrote:
Yeah, thanks Jim.
The deal here is that the provisioning file that was made somehow has a different set of leading numbers, so if these are important at all, this will never work.
This was quite fun and ended up with a 4:30 AM run to the office the next day as well.
I must admit, this is a simply terrible process with conflicting and inadequate docs.
I'm instructing a team member to outline this process from the start as a new user. Maybe our outlining of this and "when this goes wrong, do this" will help all of us.
Thanks again.
Cheers.
On Jun 21, 2