Database Reference
In-Depth Information
I know that, in spite of the last week fire-drill, the day that my iOS app went live in the
store was one of the proudest in my life. As I type this, I can look up and see a framed
copy of the marketing poster for the app, which hangs in my office at home. I sincerely
hope that your launch day is as happy and trouble-free as ours was.
Things to Worry About in the Month After Launch
Most likely, you'll already be deep into your 1.1 or 2.0 project planning. But this will
also be the time that your first bug reports will start trickling in. My project was a bit
of an aberration, in that it required customers to install a new release of the backend
server product, something we knew any of our customers were unlikely to do in the
first few months of the release. So we knew that, literally, no one would actually be
using our software until close to our 2.0 release.
It's unlikely that you'll be in the same boat. And, in fact, we found some problems that
were introduced by a maintenance release of the backend, which broke the mobile
clients. So, even though no one was using the clients, we had to do a 1.1 release (and
a subsequent 1.1.1 release) in the months following launch.
As part of your initial (and ongoing) discussions with your support and production
groups, you should have a plan in place for what should go out in follow-up releases,
and when they should be released. The App Store gives you a great deal of latitude to
get critical bug fixes out to the users quickly, but the existing groups are unlikely to
want you to “cowboy” fixes into the Store without proper release controls.
The App Store is the primary way to distribute applications, but it may not fit every
customer's needs. In the next chapter, we'll look at alternate (legal) means of distrib-
uting applications.
