In my time at Macworld, I’ve reviewed and tested numerous iOS apps. I’ve also reported on the challenges that iOS developers face. But it was only recently that I built my first iOS app, along with developer (and frequent Macworld contributor) Marco Tabini. The experience left me with insights into the iOS development process that I probably would never have otherwise discovered, and a better understanding of what the developers of many of our favorite apps go through on a regular basis.
The app that Marco and I built is an iPhone game called Let’s Sing, available in free and $5 ad-free versions from the App Store. Here’s a behind-the-scenes peek at just what goes into building an app.
It’s awfully hard
Don’t let anyone tell you otherwise: Building iOS apps is hard work, for a lot of reasons.
Perhaps you’ve come across the occasional awful app. Perhaps you’ve even spent time telling anyone who will listen about the incredibly lousy experience you had with that bad app. (Heck, it’s part of my job description.) But let me assure you, even the lousiest app is the result of some serious time and dedication to the craft of developing it.
Testing, testing: All programming presents challenges. But iOS programming adds in several added layers of complexity. One big challenge is testing your in-progress app. You can run the app you’re building on the iOS Simulator, a virtual iPhone or iPad that runs as a standalone application on your Mac. But—as any developer will tell you—the Simulator isn’t a substitute for the real thing; you need to test your app on actual iOS devices, too.
That’s a challenge in its own right. Apple limits iOS developers to testing their apps on 100 devices. That might sound like plenty, but keep in mind that you want lots of folks to test your apps, on multiple iOS devices and models, running different versions of iOS. That way, you can work out early bugs, interface issues, and settle on features. What’s more, you want those testers to span a wide range of experience levels to ensure that they mirror your potential App Store customers.
But despite the ease of using the iPhone itself, it’s not easy to become an iOS tester. Services like TestFlight, which Marco and I used for testing early betas of Let’s Sing, aim to simplify the process—which requires that we know your iPhone’s UDID, and that you manually install a provisioning file along with a copy of our app. But the fact that TestFlight needs to exist at all is surprising; Apple could and should make the testing process much simpler for developers and testers alike. We devoted hours just to helping people get set up to test our app appropriately. We lost testers during the beta period because they had trouble using TestFlight. It was frustrating for both us and our volunteer testers.
Power features: In order to make Let’s Sing feel like a real iPhone app, we needed to take advantage of certain features that Apple offers. For example, we want to tell you when it’s your turn, and we want to let you purchase extra features within the app to enhance gameplay.
To tell you when it’s your turn, we use push notifications. Without going into the complexities of how Apple’s Push Notification Service works, suffice it to say that it’s complicated.
Among other things, notifications require the creation of unique certificates so that Apple can validate that your app is in fact the one that should receive the notifications that you send. That process alone requires trips to Keychain Access, Apple’s developer website, and your own server. When it’s time to test your push notifications, you need to send them to a testing server that Apple runs—but once your app is actually live, those notficiations need to use a different server—with a different certificate. So you can’t actually verify that your push notifications will work with the real live app until you yourself can get the app from the App Store.
If you run multiple versions of your app—in our case, free and paid versions—you need to configure multiple push notification certificates and process them separately. It’s a lot of work.
I was even more surprised by the complexities involved in testing In-App Purchases; I figured Apple would bend over backward to make that process simple, since the company probably enjoys its 30-percent cut of proceeds. In fact, testing In-App Purchases presents a variety of challenges.
As with push notifications, the In-App Purchases process requires separate test and production servers on Apple’s end. On its own, that makes sense. But Apple requires that you sign out of your main App Store account and create separate ones to test In-App purchases. Surprisingly enough, creating and juggling those testing accounts is not particularly effortless. And, of course, any sane developer will want to test that purchasing still works once the app is live—remembering to switch back to a real App Store account first.
Expectations: Perhaps the single hardest thing about building an app for the App Store is that we’re all so accustomed to great apps. Sure, we’ve all seen a few lousy ones, but Apple sets the bar high with its own software ( GarageBand, anyone?), and plenty of third-party developers offer up excellent apps of their own.
That’s not a complaint. But it is a challenge. Marco and I struggled to figure out how we would expect the app to behave, and then to determine whether average users would share that expectation. We worked with our designer to make sure buttons looked tappable enough, and that elements that aren’t tappable didn’t invite the user to stab at them in futility.
Going up against the cream of the crop on any software platform is tough. But iOS presents unique challenges of its own: Though there are standards, apps can implement custom everything, with no menu bars, no cursors, and no other crutches that developers can leverage on, say, the Mac to help new users understand what’s going on.
Though part of what makes iOS great is the fact that the screen can become any sort of interface at all, designing a finger-driven custom interface that both looks good (and unique) and is immediately understandable by new users requires considerable effort.The aftermath
Finally, you pull the trigger and release your app. Well, first you submit it to the App Store for review. For us, that was a six-day process; we had no visibility into what was going on until the process was complete.
We launched Let’s Sing on Tuesday. And though we attempted to ensure that the game’s backend was prepared for an onslaught of new users, we did run into a couple issues. Push notifications stopped working for a bit, and our Amazon-hosted servers crashed a couple times.
Ultimately, we did what we could: We scrambled to fix things and to keep the servers running smoothly. Of course, to customers who downloaded the game or tried it out during a 15-minute period where it mostly just threw errors onto the screen, Let’s Sing is a terrible app. Understandably enough, a couple users who had that lousy experience left us equally lousy App Store reviews, advising others not to get the game. That goes with the territory.
I sympathized with App Store developers about the difficulties of life in the App Store before I joined their ranks, but my firsthand experience has given me a deeper empathy for their plight. I can’t reply to the customers who post scathing reviews that our app is error-ridden, or try to help them resolve their issues. Their unhappy reviews simply sit there, potentially discouraging other customers.
Widespread use of an app also exposes issues that one doesn’t discover in early testing. For Let’s Sing, we’ve already submitted a bug fix update to the App Store to correct these sorts of errors. Developers can—on rare occasion—request an “expedited review” from Apple, which aims to get your emergency fixes into the store more quickly. But even that expedited process takes a couple of days; in the meantime, we hear the same bug reports repeatedly and attempt to assure users that a fix is coming soon.
Worth it
Given all these manifold obstacles and difficulties, would Marco and I do it again? Absolutely. Building Let’s Sing was tough—especially given that we both have other full-time day jobs. But we enjoyed the process of building it, even when there were serious challenges in putting it together.
We often said to each other that we were stunned that Apple didn’t make parts of the process easier. We also often said that we were stunned the App Store is steadily closing in on 1 million apps: That’s a lot of developers putting in a lot of work, and it’s remarkable.
But the best part is that we like playing our game, and the good news is that it seems we’re not alone. Being able to point to a game on my iPhone, knowing that I helped build it, feels great, and knowing that my game is entertaining strangers around the world feels even better.
And I guess the best news of all is that, in theory at least, the next app Marco and I build together should be at least a little easier.
[When he’s not developing apps, Lex Friedman is a Macworld staff writer.]