Web Apps. Mobile Apps. Awesome!


Why Developing For a Platform Should be Easy (and Why Apple’s Isn’t)

August 16, 2012

One would hope that it should go without saying that developing for a platform should be as simple and easy as possible. It encourages developers to become familiar with your platform and incentivizes them for creating something that may only exist there if they like what they see. This is a lesson Microsoft learned decades ago when it was trying to lure developers over to its new Windows environment away from the more mature Macintosh platform.

And how’d Microsoft succeed? Simply.

When Apple was charging for its toolset, Microsoft gave theirs away. They published vast volumes of developer support documents and gave them away. It encouraged email lists and third-party publications all based around its platform. In short, as much as it could in the mid-80’s it provided as many different channels for developers to find out what they needed to know without having to search very hard for it or pay.

It’s fairly obvious how that story ended up.

You don't work 'with' the Empire. You always work 'for' it.

We’re now in the mobile world with the old players but also with some new. At 42 Solutions, I’ve had the chance to work on several Android apps and am in the midst of developing our first iOS app. And it’s perhaps because of the latter case that I find myself both frustrated and actually beginning to long for the simplicity of Android.

Is Android’s toolset better? No. Not by a mile.

Is Android’s language better? Depends on if you prefer Java better than Objective-C.

Is Android’s API better? Not at all. It’s hacky and kludged together at every turn.

So why am I looking back wistfully at Android and wishing my current project was being developed there?

Testing. Or, more to the point, device testing.

As anyone who’s ever worked on a mobile app knows, it’s not tested until its device tested. And, on first blush, Apple would appear to have a massive advantage over Android, after all, there’re only a few devices that run iOS and, hey, they’re all made by the same company, so forget fragmentation! And that would be correct. It’s everything else that… well, sucks.

First let me say that I understand Apple’s walled garden approach. They have this fancy family of devices, with no history of openness (or having to be forced open–see the first anecdote) so they want to guarantee quality by limiting access. They’ve limited both who can put what on devices as well as approving apps before they’re available in the store. I don’t like it but I understand it.

Thus, in order to get your program running on a device–not through the store, mind you–from your own computer onto your own iPhone, you must first register as an iOS developer and pay $99 for one year. If this sounds as easy as actually paying them $99 should sound, then you’d be wrong.

First of all, if you want to register as a company and not an individual, you must first register for a DUNS number with Dunn & Bradstreet. This could take up to 15-days or be cut down to five if you pay an additional $49. Then, when you get that, pray that the information is correct because now you have to link it up with the Apple account you’re attempting to register. If anything is not to Apple’s liking, you have to return to D&B, update the information associated with your DUNS number and wait seven days for it to clear, be passed back into Apple’s system, and now hopefully work. If this fails five times, then you’re also now locked out of Apple’s registration system and need to call them to have it unlocked. Of course, after five times, you’d hope the person who you’re on the phone with could tell you what their system didn’t like but, again, you’d be wrong. You just have to keep trying.

And we’ve been trying for two months. Just for the privilege to pay Apple $99 so I can put my app from my computer onto my iPhone.

So, thinks I, trying to be clever. I’ll register for a personal account, pay $99 with the expectation of paying the same again later when the company account is figured out, and go from there.

It worked on the first day but now the iOS developer center is telling me I need to register again because, for whatever reason, it doesn’t think I did the first time. I have the confirmation email. My bank says the $99 is gone. But their dev center says I’m not a registered, paid up Apple approved developer. I didn’t get an email for that one.

So, now that I’ve already paid my $99, and still have the expectation of paying it again later, I still can’t get my app onto my iPhone.**

Just as a comparison, let’s look at what it took to develop for Android:

The tools were available free on the Android developer portal, as was Apple’s XCode except that XCode requires a basic registration whereas the Android tools integrate right into Eclipse. To test on a device, I clicked “Allow external apps” in a menu then clicked “Allow USB debugging” in another on the actual device. I connected said device to my Mac using the correct USB cable. I pressed Run. A second later, the app was actually running on the device.

And that. Was. It.

Forget actually getting the app in the market. Google requires a one-time $35 registration fee and takes the standard 30% off of any paid apps. If you fill out the form correctly, enter your credit card info, and press submit, you can now post an unlimited number of apps on Google Play.*

As mentioned above, Apple requires $99 per year, even if you’re only posting free apps, also takes their 30% cut, but also mandates approval to get into their market. There are pros and cons to this approach that have been discussed ad nauseam and won’t be rehashed here again but, from a developer standpoint, it appears as if Apple’s trying specifically to weed out the casually interested developer. After all, if you’re successfully developing for another platform already, be it Android, Web, whatever, why go through all of this just to put a proof of concept together?

We’ll be announcing what our app is soon enough. And while we’ve found developing it a rather interesting process, we’re now roadblocked by Apple’s insane pathway to device testing and beginning to become extremely frustrated (as if you couldn’t tell by now).

Apple can only get away with this because they have managed to develop the premiere mobile platform. Everyone wants to develop on it. Part of the reason 42 is now involved in iOS app development is because many of our clients have expressed their interest in launching with iOS and then later, maybe, following it up with an Android release. Android may have the market share but Apple has the street cred. But, Apple should take note of developer frustrations since it may not always have this advantage.

Android is a powerhouse in Europe, Asia, and South America. And Microsoft (see, you forgot about them, didn’t you?) is about to release Windows 8. And lest anyone underestimate Microsoft, just remember that Sony probably shrugged when the XBox was announced from their lofty position in the industry at the time.

It’s good to be on top, no doubt. And being on top allows you to dictate the rules. At least for a while. But when your platform requires the participation of third-parties to make it a success, it’s wise to see if you’re making it easy to develop for. Because Android and Microsoft are both trying to do that right now.

*Google Play, of course, has its problems. It’s actually amazing the number of people who bothered to pay $35 to put their “Hello World” app out for everyone to see. These, clearly, wouldn’t be seen in Apple’s App Store, and this no doubt also provides a better user experience.

**EDIT 8/17 – In the interest of being honest, the email address I thought I registered my personal developer account with turned out to only be an address associated with the actual “Apple ID” on record, which was my personal account (for iTunes, the App Store, and whatnot). Thus, while I thought I was registering under a different account, I was, in fact, registering under my truly personal account.

This slightly undermines my point about personal developer accounts in that my not discovering it could be covered under “stupid user error” but highlights Apple’s opaque difference between Apple IDs and login addresses, under which my personal email address was registered as an email address for my Apple ID but, when logged in under, wouldn’t show the same information. Leaving me to wonder, is an Apple ID an email address or not? Because I always thought it was. Turns out, it’s not.

Back to Blog

42 Tags: , , , , , ,


Content for class "bottomYellow" Goes Here
Content for class "bottomBlue" Goes Here

42 Solutions

Working with 42 Solutions, you’ll find that it’s not the technology that’s important, it’s the idea. Regardless of whether your company is based on proprietary software or open source, we will find the right tools to get the job done.

Invite us to your office and we’ll send a pair of consultants armed with laptops and bright ideas, ready to solve your problem and offer solutions. We pride ourselves in getting to know how you do business and integrating into your process.