AIDAB Official Documentation

Eight_Quarter_Bit's picture


Joined: Jan 12, 2016
Your rating: None (2 votes)

Help! I've downloaded and I can't get started!

OK, so you've downloaded the Apple ID Automation Builder (AIDAB, for short,) and now you're wondering where to go from here. Some of you may have used my old Batch Apple ID Creator, and were surprised when you found that AIDAB operates quite differently. Others might be new to this particular rodeo, and are still blissfully ignorant to some of the odd backflips you have to go through, as well as some of the things you have to consider when creating Apple IDs.

This little document aims to cover the basics of mass Apple ID creation with AIDAB, as well as some of the things you should keep in mind from a deployment and workflow perspective. Before we get into all that however, it's worth briefly reviewing why mass Apple ID creation is important in the first place, and some of your options. A lot of what I will be covering comes from the perspective of using iOS in education, because that's what I'm experienced with, but a some of of it impacts iOS management in big business as well. For those who have already earned your marks in this arena, and are sold on mass-creating Apple IDs, feel free to skip on down to "Go-go gadget Apple ID creator!" for the guts of what AIDAB is and how to use it.

Why Mass-Create Apple IDs?

Something that many of you may be wondering is why creating Apple IDs en-mass is even worth doing in the first place. This is really deeply-rooted in the deployment methodology of iOS, and trying to discuss why mass-creation of Apple IDs is a good thing without touching on deployment methodology is next to impossible. There are a couple different approaches to rolling out iOS devices across an organization, but for the most part these break down into two categories:

1. Sharing iOS devices among users (cart systems)
2. 1-to-1 rollouts and limited deployments (no sharing of devices among individuals)

I won't delve too deeply into the first deployment scenario. iOS devices are not designed to be shared among multiple individuals, and trying to force them into that mold leads to all manner of problems. I strongly recommend against such deployments, but there are times when budgets are the controlling factor, and it's either shared devices or none at all. If devices are being passed around between individuals, then individual Apple IDs aren't a big concern, because everything on the device is going to be one big free-for-all anyway.

Scenario two is where individual Apple IDs becomes very important -and I really do mean individual Apple IDs. When every user has a device that only they will use, giving each individual their own Apple ID is the only way to go. I've seen rollouts where every user has their own iOS device, but they share an Apple ID across all those devices. Most of the time this is done in the pursuit of simplifying the rollout, particularly in education. When you have several hundred to several thousand children with their own devices, the idea of walking them all through the process of setting up their own Apple IDs is a daunting prospect. In addition, due to some of the legal verbiage in Apple's Terms of Service, individuals under the age of 18 aren't allowed to have their own Apple IDs. I'll talk about this more in a moment. For now let's focus on why sharing an Apple ID across multiple users is a bad idea.

  • iCloud Backup

iCloud Backup is amazingly handy. For one thing, it makes swapping one iOS device for another much easier. Without it you are stuck with not backing up at all, or relying on USB or wifi sync. Both of these represent greater expense (USB sync carts instead of their much cheaper charge-only brethren, for example) or increased management overhead (building iTunes sync servers, keeping inter-device content bleed on sync under control, creating a sync relationship between a computer and every iOS device, etc.)

  • iMessage and Facetime

iMessage and Facetime are completely useless with shared Apple IDs, for obvious reasons.

  • Photostream

Photostream becomes one giant mish-mash of everyone's photos, and can be a privacy or policy compliance concern. All it takes is one high schooler saving porn to his iPad to ruin everyone's day. Want to figure out who saved the naughty pictures to the photostream? Good luck with that.

  • Keychain Sync

This upcoming feature in iOS 7 is probably one of the biggest privacy nightmares you can think of if you are sharing Apple IDs. I'll just let your imagination fill in the blanks.

  • iWorks in the Cloud

Yep. Tied to an Apple ID. Don't want one user seeing another user's documents? Too bad.

  • Any App that syncs its preferences

The implications of this one are almost boundless. The chaos that can spread with apps sharing settings across multiple people is a nightmare.

Sure, many of these servies can be turned off, but that means killing a useful service. If you still aren't convinced, allow me to outline the ultimate nightmare: the password to the shared Apple ID being compromised.

So, you're a year or two into your rollout of iOS devices, you've got dozens or perhaps even hundreds of applications tied to the Apple ID you use for rollouts, and some enterprising individual just figured out the password to the shared ID. He logs in, changes the password, security questions, and email address tied to the ID, and in one fell swoop he's "stolen" every app you ever tied to that ID. Every app on every device will be stuck at the version they are at now.

These are just the problems that you will run into today and in the near future. In the years to come Apple will continue to roll out new products and services, many of which will be dependent on individual Apple IDs. Save yourself and your users the headache, and start with individual Apple IDs from the beginning. It's the way Apple intends it. Anything else is a hack that will eventually bite you.

So, that's the why. Now what about the how?

The Trials and Tribulations of Mass Creation

We need individual IDs, that much is clear. Now, how do we go about creating them?

In big business the answer to this might be to have everyone create their own IDs. This is a perfectly acceptable solution with a minimum of problems. It works just fine. Having the IT Department create the IDs is just a courtesy in this case. It's handy, but not totally necessary. It can mean a touch more consistency, because you can be sure that absolutely every user in your organization will have an Apple ID, but that's about it.

The situation gets a little crazier in education. For one thing, trying to walk a classroom of thirty first graders through creating an Apple ID is about as effective as herding cats, and for another it's a breach of Apple Terms of Service. I seriously doubt you would ever get in trouble for it, and Apple clearly intends for the iPad to be used in K-12 classrooms, but if someone ever wants to make a stink about it, you're the one "in the wrong."

The solution is to have the institution own the IDs. As far as my uneducated interpretation of the ToS goes, as well as the interpretation of several other much more qualified individuals both inside and outside of Apple who must remain nameless and their opinions not considered legally binding (don't you love our legal system?), this is completely within the ToS.

Essentially this is what we are already doing with shared Apple IDs, but we've already established that's a bad idea from a technical standpoint. All we need to do is take the concept of the institution owning the ID and scale it up to a number of IDs that equals the number of users that will be using the IDs. We even give users access to the IDs and tie it to the email address we also own, but they use. Nevertheless, we own the IDs, and thus as an institution we are the one entering into the agreement of the ToS.

Now that the legal backflips are out of the way, it's back in the realm of technical implementation. How on earth do we create hundreds to thousands of Apple IDs with unique information tied to each?

Go-go gadget Apple ID creator!

Automation! Automation is fantastic. I don't know about you, but the idea of creating several thousand Apple IDs by hand is enough to make me want to curl up in the fetal position and rock back and forth in a corner somewhere.

Automating the process of creating Apple IDs has been something of an ongoing hobby of mine for the past few years. A little history on where we've come from is useful in illustrating how AIDAB is different, and why it's better than previous solutions.

Apple ID Automation, a Brief History

Some of you may have had the misfortune of using my previous foray into Apple ID automation, called the Batch Apple ID Creator This was originally designed to be a tool used internally by my organization, and I honestly never expected it to leave my lone MacBook. Then, one day, I happened to offhandedly mention my script here on Enterprise iOS, and, well, the rest is history.

The Batch Apple ID Creator was limited in numerous way, and was fundamentally flawed at a design level. Aaron Freimark made some valiant effort to keep it up to date every time Apple made some minor change in the setup process, but it was an endless battle. It also didn't support users in other countries or using other languages, and the internal layout was a complete nightmare. It worked.... sort of... but it was ugly.

Theoretically one could reverse-engineer what the forms are sending to Apple's servers and then just send this data directly, customized with our user's information. The problem is this all takes place inside iTunes, over an encrypted connection. Breaking into this black box is difficult. Perhaps someday I'll crack it and produce a tool that just handles the form posting commands, but we aren't there yet. Until then, we are stuck mashing the buttons presented within the signup process. Automating this button-mashing is called GUI scripting, and is the core of how the Batch Apple ID Creator made accounts.

The problem with GUI scripts is that GUIs aren't designed to be stable, programmatically referenced things. GUIs are designed for squishy wetware that adapts easily to subtle changes in layout. This was vividly illustrated by the uphill battle Aaron and others had to fight to keep the script working. Any time the process changed it meant delving back into the code to change where the clicks and keyboard events were pointing, because every UI element was hard-coded into the script.

How AIDAB differs from its forebears

This was on my brain one day when we just so happened to be going to lunch with our Apple rep and engineer, when I came up with the core concept of what would bloom into The Apple ID Automation Builder. AIDAB is still a an AppleScript-based GUI script, but it's different from the old Batch Creator in one key way: the references to the GUI elements aren't hard-coded into the script. Instead, AIDAB is designed to have you teach it what to click with a handy dandy GUI of its own. That's right: this is a GUI controlling a script to build a script that controls a GUI. Still following? OK.

When you download AIDAB you don't have an application that will create Apple IDs. Rather, what you have is a tool for building an application that will create Apple IDs. You don't have to know any AppleScript, that's all squirreled away under the hood. All you have to do is walk through AIDAB's GUI, teaching it a process of button clicks, text field filling, etc. When you've finished teaching AIDAB the process, it spits out a completely independent application (which I will refer to as a constructed process) which contains all the actual AppleScript for performing the actions you taught AIDAB. Nifty, huh?

AIDAB itself has an icon that looks like this:


(I didn't design this icon, by the way. Rather, I got it from here)

A process constructed by AIDAB looks like this:

Constructed Process Icon

(Which is an icon you can get here)

Constructing processes takes about ten to fifteen minutes once you know what you are doing, and can be used until Apple changes the setup process. Once the steps for creating an Apple ID change you can chuck the broken "constructed process", build a new one, and get on with your life. The turn-around time is much faster, it no longer depends on someone else to fix the code, and it has the added benefit of working with any combination of system language and iTunes store. You don't need to know any AppleScript, and teaching AIDAB is a pretty straightforward process.

So, without further ado, let's get to it.

Constructing a Process with AIDAB

Gathering Ingredients

The first thing you will need to consider, before actually getting down to the business of virtual button mashing, is what your user info source will be. If your user management system has the ability to export user information in a CSV file, you should go ahead and export a small batch of them to be used while constructing a process.

For the purposes of maintaining individual Apple IDs, all you really need per user is their email address, a unique password for the account, and unique security questions/answers. Everything else can be general information tied to the organization, and thus not contained in the CSV. You can choose to tie more end-user information to the created accounts if you so choose, such as first name, last name, title, etc. AIDAB is designed to be flexible, allowing you to chose if you want to fill in a field with the same information every time, or looking up a new row in a CSV for each new account.

It's also worth noting that, unlike most tools that import a CSV which depend on a specific order of columns, AIDAB only depends on a case-insensitive textual match to the "header" of a column. Every time a CSV is imported into a constructed process AIDAB looks at the first row of items in the CSV, matches the text to the columns each action references, and checks to make sure all the necessary columns are present. This means that, while your columns can be in any order, you should make sure the first row of each column contains a description of what that column contains, and not actual user data.

If, for some reason, you don't want to build a signup process that matches the output of your user management system, you can use a "default" set of headers that are packaged within AIDAB instead of importing a CSV. This default set is a list of text items that are good descriptors for what a column would contain (such as "first name", last name", etc.) If you choose to use this default set of headers you must ensure that the CSV you load into your finished process contains the same headers as the ones you selected from the default set.

Something else to think about, before we get into the actual meat of building a process is if you rolled out per-user email addresses some time ago, some email accounts may have already have Apple IDs tied to them. If AIDAB tries to create an Apple ID and there is already one tied to the email account, creation for that Apple ID will fail. This might not be a big deal to you, but it's worth pointing out. Something you may want to consider is using email alaises for Apple ID creation. Or, if you are using Google Apps, you can use the trick of adding some text to a user's email address after a plus sign. For those not in the know, a GMAIL account of will actually deliver mail to For that matter, will also deliver mail to, and vice-versa. This is a useful trick, because while Google ignores everything after a "+" in an email address (except the domain name, of course,) Apple will treat and as two different accounts.

Now that we've taken into consideration the various elements we will need to input into AIDAB, it's time to start actually constructing a process.


I generally look at the actual constructed process in two parts: the kickstart and the actual process. The kickstart is everything the script has to do to actually get to the signup form. This involves making sure iTunes is running, signing out any active account, and starting the process of creating a new account.

The script automatically assumes you will want to launch iTunes, so there's no need to build that step. Signing out an account and starting the creation of a new one will vary depending on the system language and could potentially be changed by Apple down the road, so these aren't hard-baked into AIDAB. Instead, AIDAB has all the tools necessary to interact with the iTunes in such a way that you can teach it how to perform the tasks.

There is a pre-built kickstart included with AIDAB that you can choose to use if you won't want to build your own. This works with current version of iTunes, running in english, but I'll go ahead and run through the process of creating your own.

Signing out any existing Apple IDs

The first thing we want to do is teach AIDAB the process of signing out an Apple ID. If an Apple ID is signed in then all other steps in creating a new ID will fail, so it's critical that before we do anything else, we make sure no ID is singed in. So, fire up iTunes and sign in an Apple ID, in preparation.

Go ahead and launch AIDAB (if you haven't already,) load your users CSV file (or use the default headers,) and select the option for building your own kickstart. At this point all you have to do is teach AIDAB what menus to click to sign out an active account.

Unlike other actions added to a constructed process which label an account "failed" if any of the actions didn't execute correctly, clicking menu items ignores any failures. This is important, because if there is no account already signed in, the sign-out action would fail and cause the rest of the process to grind to a halt. Because the menu clicking action ignores failures, we can add it as "insurance" to make sure all accounts are signed out, without having to worry about if the action fails or not.

Loading a free app page

The next thing we want to do is load a link to a free app. This is critical if we want to create Apple IDs with no payment information attached, because the only way Apple allows us to do so is if we start the account creation process by attempting to download a free app. Yes, it is rather silly. If you start the process of creating an Apple ID by selecting the menu option you will be locked into selecting a payment method.

AIDAB supports the ability to load a link to an iOS app (many thanks to Aaron for smoothing out this process in the original Batch Creator. His improved method was carried forward into this version.) which is a much more reliable method of actually getting to a free app page than trying to script clicking buttons in the iTunes store.

The link to iBooks is built in to AIDAB as a default option you can select, after choosing to load an app link. You can also select your own app to use by finding the app in the store, clicking the disclosure triangle beside the "free" install button, and choosing the "copy link" option. Once you have this link, just replace the "http://" with "itms://", which will force the link open in itunes, and paste it into the AIDAB dialog for opening an App link.

The Account Details Stage

We're now at the point where we can start teaching AIDAB the actual account signup process. Have AIDAB click the "free" button on your selected app and from there you're off to the races!

Everything from here should be pretty self-explanatory, just pointing AIDAB to various UI elements and instructing it where the data should come from for filling out the fields. There are two small caveats that I want to cover here, however.

First of all, pop-up buttons are really ugly when it comes to GUI scripting. Because of the way AIDAB works, it tries many times a second to set a UI element, logging how many time it failed and how much time has elapsed. Unfortunately, where other UI elements have unique identifying characteristics (such as the title of a checkbox or button, or the 'help text' in a text field,) pop-up buttons are rather difficult to identify. Because of this, if you choose to set a pop-up button as the first item on a new page, sometimes AIDAB can get confused about what pop-up button is being set. Because of this, it's something of a "best practice" to NOT set pop-up buttons as the first UI element on a new page. Set some text fields or check boxes first, then start to set the pop-up buttons. This results in a more reliable process, and should lead to fewer incorrectly "failed" accounts.

Second, at the very end of the account creation process you are presented with an "OK" button on a page informing you that a verification email has been sent. Until the account is actually verified, clicking this button just informs you that you haven't finished verifying the account, and thus adding it as an action in AIDAB is kinda pointless. Just ignore the button and finish the setup process in AIDAB.

Running Your Constructed Process

At this point you should have a completed setup process as a separate application that you can use to create Apple IDs. You can either launch it and load CSVs with the button in the interface, drag one or more CSVs onto the constructed process, or even use the "open with" dialog. You can send this application to others within your organization without including AIDAB, or move it to other systems you'd like to run the setup process on. If you would like to keep the custom folder icon for account creation data, I recommend distributing your constructed process in a DMG or on an HFS+ formatted volume. It's not necessary from a functional perspective, but it's a nice little visual element that gets lost when you distribute in a .zip or on a non-HFS+ volume.

Because the constructed process is a GUI script, and thus sending button clicks and keyboard events, you should not use your machine while the script is running. A few tricks I've used to stay productive while letting the script do its thing are letting the script run on one of our OS X servers, creating a new user on my local machine and using "fast user switching" to return to my normal account, and running the script run in an OS X VM. Running the script in a VM is probably the best option, since it makes it easy to monitor the script while still giving you access to your system.

As the constructed process iterates through creating accounts, it will update three CSV files in a dated folder in the same directory the source CSV file was loaded from. The CSVs contain accounts that have been successfully created, are still pending, and that encountered errors. After the script completes, I highly recommend running the "errored" accounts back through the constructed process, as sometimes the cause of the error is something transient like the iTunes store simply not loading, or the process getting interrupted by accidental user input.

Source Code

While it might not be immediately obvious, the source code for both AIDAB and your constructed process is readily available. Both AIDAB and your process are what's known as an application bundle, and within this bundle resides the un-obfuscated AppleScript source code. To see the guts of the application just right-click on it, select "show package contents", and browse to contents > resources > scripts.

Because AIDAB weighs in at about two and a half times larger as its predecessor, it's been split into a handful of individual script files.

Actions contains the code for all internal data manipulation that doesn't interact with the user or other programs. This contains stuff like the CSV parser and list item manipulators.

MenuRouter is all the code dedicated to interacting with the user. This is primary portion of the code that runs when you're constructing a process. It's also some of the most complicated code, because AppleScript isn't really designed with creating large-scale GUIs in mind.

UI Element Operator is all the code designed to actually interact with the UI elements of iTunes. This handles locating the actual elements within iTunes for you to pick from when constructing a process, as well as all the snippets that define saved actions.

Main is dedicated to bringing all the other parts of the script together. Main loads the other scripts into RAM, and handles some of the intercommunication between the individual parts.

Prototype is the framework for a constructed process. As you are using AIDAB to select UI elements and data sources, this is being packaged up in a list of actions for Prototype to execute. Once you choose to save a constructed process, a copy of the prototype is created, and then your actions are dumped into a persistant variable (called a property, in AppleScript terms) within the prototype.


For most people, you shouldn't have to actually get down into the code of AIDAB. The whole reason AIDAB exists is so that IT guys can adapt to a changing setup process without having to know any AppleScript. However, AIDAB is still beta, and so you may encounter problems. AIDAB tries to be intelligent about when it reports a problem, so copying down any error it spits out will be very helpful in letting me know what went wrong. However, sometimes AIDAB never even gets a chance to display a bug to the user, and that's where the Console comes in.

If you encounter a bug that doesn't display an error message from AIDAB, reading what the system reports is really handy in diagnosing the problem. OS X has a nifty little tool for this called Console, which can be found under the Applications > Utilities folder. Watching the console when AIDAB or a constructed process crashes can often times reveal clues as to why it failed, and is often vital in fixing the problem. If you're going to post a bug, please include anything that pops up in the console output when the crash occurs.

If you want to get into the code for yourself, you can certainly do so! However, debugging the code of a constructed process isn't quite as easy as it was in the Batch Apple ID Creator. Part of the reason for this is because the actual process for creating accounts isn't just textual references to UI elements, it's actual code snippets saved in property list. These code snippets are built with AIDAB, and all the constructed process is doing is executing them one at a time, while matching the action's required data up with the correct information from the loaded CSV, checking to make sure nothing has failed, and spitting out CSVs containing what accounts are created, pending, and failed. Even the code for outputting CSVs, operating on the loaded CSV data, and checking UI Elements are actually code loaded from "Actions" and "UI Element Operator", saved in persistant variables within the prototype when the process is saved.

The trick is, when you load the source code of your constructed process and compile it, the persistant variables are wiped out. To actually debug a process you have to copy the constructed process, load the copy into your script editor, uncomment the "debug" section near the beginning of the script and point the line that reads "set fullyPrototypedScript to load script file " to the original process you want to debug.

This will pull all of the saved properties from the original constructed process and save them in your "debugging" copy dynamically on every run of the debugging version.

And they all lived happily ever after

That pretty much concludes everything I have to say about AIDAB. If you have questions, please feel free to respond to this thread. If you have a specific bug to report for beta 1, you can do so here. If you are having trouble constructing a process, you can create a new post on the forum about it. I am notified over RSS any time someone creates a new post, so I should see it, and I will do my best to respond as quickly as my free time allows.

Harrison_ack's picture


Joined: Aug 3, 2013

Apple ID - Creator, Hire?

Your rating: None


I am looking to hire someone to setup 10,000 iTunes accounts with payment information attached to each account.

The accounts will need to purchase one track from the iTunes store in Australia. They will need to be Australian accounts.

For payment information, I can provide different prepaid VISA cards to use for billing.

I will also need 10,000 accounts to download the one track from the iTunes store.

If anyone can help me do this, please be in touch.




Who is online?

There are currently 0 admins, 0 users and 19 guests online. Connected users: .

Recent Activity