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 wewould
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
thataren’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.
No comments:
Post a Comment