We work with a lot of different clients here at Fluid Pixel, when we aren’t developing our own stuff, and sometimes that could mean a whole lot of different UDID’s getting sent to us so that our clients can have a look at the Work In Progress (WIP) and test out what we’re developing for them. This can be a bit of a problem as Apple only allows 100 Devices to be registered per year per developer account, and these tend to run out pretty quickly.
The solution for us was to get an Enterprise Developers account as this allows us to do an enterprise distribution build that lets us avoid having to register any UDID’s also we can distribute the WIP build to clients wirelessly through our own Development website, all through the browser on their iOS device.
There’s already a great guide to setting this up posted over at Jeffrey Sambells website, however we also do flash development and have been looking at getting a few Flash projects moved across to iOS by making use of the Adobe Air 2.6 SDK, there are enough guides out there for getting this set up to build an app for testing and for App Store submission, but we needed to do a testing build for some clients. So we had to find a way to get this done, in the end it turns out to be a relatively painless operation.
We made a distribution build of our app using the Air 2.6 SDK with our enterprise distribution certificate, making sure that the bundle ID was the same as the one used in our distribution provisioning profile.
Now the ‘hacky’ part seeing as the Air SDK wont let us build for archive, but will let us do distribution and ad-hoc, we built for distribution, as that’s what we intend to package this up as. Now ensure that you already have an Archive build for any other app already in XCode (we’re using XCode 4, but I imagine this will work just as well in earlier versions) by having a look through the organiser, if you don’t then open up one of your XCode projects and ‘Archive’ it.
If you bring up the organiser you can ‘Show in Finder’ on this Archive (Right/Command click the Archive) or have a look in “User”/Library/Developer/Xcode/Archive/”AnyDate”. You want to locate the “.xarchive” file for one of your archived apps.
Duplicate this, then rename the duplicate Archive to suit the name of the project you’re wanting to distribute. In our case “Revolve”, but keep the date and time part of the file name. Now on the xarchive file “show package contents”.
You’ll be presented with two folders ‘dSYMs’ and Products and an Info.plist file. We’re going to need to edit the plist, so fire up the property list editor. You’ll want to change Name to the name of the app, or whatever the .app file is called that the Air SDK generated, as well as the SchemaName to the same thing.
Expand the ApplicationProperties Dictionary, and look at the ApplicationPath property, you’re going to edit this one to be “Applications/<name>.app” where <name> is the name of the .app file that the Air SDK generated.
Also the bundle identifier may need to be edited to math the bundleID that the App was built with, and check that your icon names match up (they shouldn’t need changing if you follow Apple’s standard naming conventions). Now Save this pList.
Navigate through the “Products” directory you’ll get to the Applications folder, remove anything that’s already in this folder, and replace it with the .app that the Air SDK generated ( this should then make what was entered in the Applications Path valid, ie copy revolve.app into ‘Products/Applications’ so that ”Applications/revolve.app” is now the correct applications path.
We can safely ignore the ‘dSYMs’ folder for this.
Right now back into XCode if we now bring up the Organiser and look at the Archives tab we should see the Archive in there for our recently stitched up app, in our case we now have an Archive for Revolve. Now we can share this using the same technique as described on Jeffery Sambells website, and we now have an Enterprise Distribution of our Flash App that runs on iOS devices.