CONCEPT THROUGH RELEASE

As you would imagine, there are many inefficient ways to complete the development of a software title. The most common early methodology (and the one used most often until perhaps very recently) stemmed from a 1970s paper by Winston Royce named the “waterfall method.” As shown in Figure 5-1, this process chops up development into several distinct stages that occur one after another:

• Concept and planning
• Design
• Code and assets
• Test
• Release

FIGURE 5-1: The “waterfall” development method

Development that follows the waterfall method attempts to lay down a solid (but rigid) foundation early so that risks are mitigated. However, the most common problem with waterfall development is that lots of time and money are spent and accumulated throughout the early stages. By the end of development, the product may not look exactly how you envisioned, yet was locked into its design at the outset.

Although this may still be a feasible method for some projects, for complex projects, it's simply not the best way to achieve success and user approval. Unless you are an absolute genius at design and planning, there are systems that you're going to want to iterate on and change as a result of actual testing — systems that even the best designers cannot possibly foresee.

Maximizing Your App through Agile Development

Thankfully, there is one methodology that has been used more and more frequently over the past ten years, with quite a bit of success. The agile software development method is often paired with what are called “Scrum” project management techniques. These aren't just slick terms, but instead represent proven processes for what's called lightweight software development. In other words, these are processes of development that can be adaptable to change more quickly than by using traditional methods such as with waterfall development.

What kinds of changes are we talking about? These include valuable user feedback, market shifts, financial changes, new technology, perhaps a CEO with a kid who likes red balloons, or anything that can cause the software to “need to be changed.”

The fundamentals of lightweight software development were fleshed out in the mid 1990s. In 2001, a group of developers met to discuss lightweight methods, and the outcome was a new process they referred to as an “Agile Manifesto” (available for your viewing pleasure at www.agilemanifesto.org).

It reads exactly as follows:

The essence of agile development is to deliver higher-quality software faster and with more end-user acceptance (because of constantly adapting to feedback) than can be achieved by using traditional methods.

The group also created 12 principles to back up this manifesto. The principles revolve around a team-centric approach to quick software turnarounds and high adaptability, with iteration based on feedback from others, as well as meta-feedback from the team itself.

Table 5-1 provides a brief look at how the 12 agile development principles can help with developing an app. Once you understand the principles, you'll begin to understand how this method can help solve traditional problems.

TABLE 5-1: The 12 Principles of Agile Development

PRINCIPLE	Comments
(1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.	“Early” and “continuous” are the key words here. Think of your app launching early to satisfy a growing niche, in addition to frequent updates to maintain the community.
(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.	Whether the market shifts or competitors beat you to new innovation you thought you'd come out with first, it's to your advantage to be able to change your direction — even late in development. This is simply not possible with traditional methods.
(3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	The process of agile development is to have shorter blocks of complete software cycles — planning, design, code, test, release. This allows ample feedback and iteration possibilities while adapting to any changing requirements. For apps, about two weeks per iteration cycle is a good standard to aim for. This includes design of any new features, implementation, and testing.
(4) Business people and developers must work together daily throughout the project.	Communication from business needs to the development team typically is filtered through the Producer, but should occur frequently.
(5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.	For smaller teams especially, this is crucial because everyone's role is amplified. With outsourcing so popular in app development, this can be somewhat difficult to do. But effective and frequent communication and feedback can help mitigate support issues, and motivate even remote teams.
(6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.	One word for those not able to communicate in a true face-to-face fashion (which is becoming most common nowadays): Skype (www.skype.com). Nothing beats the immediacy and resolution of an instant chat or face-to-face. E-mail is actually becoming more ineffective as a communication device when compared to instant messaging (IM) or conferencing software simply because of IM's lack of a delay in the resolution of issues. There are many other capable conferencing solutions as well, including GotoMeeting (www.gotomeeting.com).
(7) Working software is the primary measure of progress.	Agile development pushes working software over separate contained system milestones. This is simply because you get to see how it all interacts as a whole, and analyze it as a complete entity (often raw and unfinished, but as complete as can be). The alternative is making assumptions about how feature X will interact with feature Y once implemented, and that's highly unpredictable.
(8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.	Because of consistent feedback loops and flexibility to change requirements, in addition to continuously building on a complete whole rather than plugging in many systems at once (and hoping for the best), these smaller increments in software production produce fewer large errors capable of derailing the project and/or team.
(9) Continuous attention to technical excellence and good design enhances agility.	Adhering to excellence and good design early reduces mistakes, and therefore, more resources remain open to change direction or iterate when the time comes.
(10) The more your team focuses on technical excellence and good design, the less mistakes are made and therefore the more resources remain open to change direction when the time comes.	By keeping things simple (and thus maximizing the amount of perhaps unneeded waste that is able to be trimmed from your software), you keep cost and complexity low, allow for maximum agility when changes are needed, maximize speed to market with simpler coding, have less testing for complex systems, and keep resources open for future iteration.
(11) The best architectures, requirements, and designs emerge from self-organizing teams.	When a team works together as an organic, integrated whole to devise and plow through the implementation of new systems rather than as a group of separated specialists, the working result of any iteration of a project becomes intrinsically stronger. It is capable of mitigating and making less chaotic the unpredictable (but inevitable) shocks that occur during development. It sounds a little glossy-eyed, but it's true, and no different really than much of the newer research about evolution on a nano-scale, such as getting a bunch of bacteria in a Petri dish to “work out” a problem organically through many generations of rapid evolution, rather than have a programmer or current computer solve the same process. As you may guess, it's much, much faster when figured out organically.
(12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.	On any given software project, a number of tasks get relegated to the “backlog” and eventually prioritized. In order to evolve, the team should make a priority of self-monitoring the way things are being done, and be flexible enough to adjust to more efficient methods if possible. The team should also take notice when tasks that used to be important are now just waste.

With that brief look into the merits of agile development, it is time to start delving into the actual process of developing an app. In the next section, you won't find as much detail on each stage as you might in some books focused solely on software development. But you will come away with a good idea how each stage pertains specifically to iOS application development, in addition to a Case Study on the development timeline of “Archetype.”

Planning — Envisioning Your Vision

Rolling out an app occurs in six main stages:

• Concept
• Pre-Production
• Production
• Testing
• Launch
• Post Release (which encompasses all the others)

The Post Release stage is where you bring out new features and customer feedback fixes (hopefully not too many bug fixes) in paid or unpaid updates.

Depending on the size of your iOS software, you can expect the entire process to take anywhere from 3 or 4 weeks (for a very simple utility app) to quite possibly more than 12 months or more (for a fully realized 3D game). This is true regardless of the size of your design and programming staff. In other words, software development takes a certain amount of time to be created, even with “more” of everything — more libraries, more designers, and so on.

In his book The Mythical Man-Month: Essays on Software Engineering, Second Edition (Boston: Addison-Wesley, 1995), legendary IBM manager Fred Brooks wrote, “Nine women can't make a baby in a month.” Brooks is famous among programmers for Brooks' Law, which states, “Adding manpower to a late software project [only] makes it later.”

One unfortunate reality is that your app will likely take longer and cost more than you expect. No matter how well you lay those plans, or how awesome your rock star programmers and designers are, your app will run into unforeseen difficulties. Take a preventative deep breath and get it out now. Some nasty bug will rear its ugly little green head, or a missing feature will jump out and smack you in the face during testing. Expect problems and work through them with the meekness of a battering ram.

Steve Jobs is right: “Real artists ship” and the rest are phonies. Don't let development delays kill your dreams. You're simply building character by beating down every last problem that gets in your way. Software development can often be a long, hard slog, but the rewards are intoxicating.

Scheduling

There are three truisms in this world:

• People will always die.
• Taxes will be too high.
• Software development will run late.

The best schedules will almost always slip because people typically have trouble meeting deadlines. Not on purpose, mind you. It's a fundamental flaw in the human psyche that makes us rarely on time, and it's one that you must prepare for. But that doesn't mean you have to accept it.

There are many methodologies for scheduling software projects, and many are more in-depth than can be covered in this book. But the basics for new developers/publishers to get through an app are provided here (along with a little more for those who wish to really streamline the process).

If you have a set amount of time to deliver your app (“I must ship this in four months,” for example), one method is what former Microsoft manager (and now a program management guru) Scott Berkun calls the “rule of thirds.” That is, divide your allotted time into three phases:

• Planning/design
• UI/art and coding
• Testing

Devoting the final chunk to testing may seem superfluous, but it isn't. You only get one chance to make an impression on the App Store, and no amount of updates can rescue an app's initial tattered reputation.

If you haven't decided on a set timeframe to deliver your app, or you prefer other options, which method used ultimately isn't the most important factor. What matters is having the flexibility to tweak your schedule as you go. The more you learn about the intricacies of your project, the more accurate (u002 the word “more”) your schedule can be. Keep in mind the “twice the time/cost” warning though, and prepare fallback plans in case schedule and cost overages begin affecting your app.

Simple Scheduling Formula

There's a bit of uncertainty with any schedule. To help with this, program managers have for quite some time used a simple formula to estimate the time it takes for any project or task. What this does is provide weights to three different outcomes to produce a reasonable expected duration, while accounting for uncertainty. The original project management formula is this:

This can be summarized as follows:

This works, but you may want to use the modified one Dan Irish recommends in his book, The Game Producer's Handbook (Upper Saddle River, NJ: Prentice Hall, 2005), because game development in general has a bit more uncertainty. Here is a simple tweak that gives more weight to the Worst Case Time (and, therefore, skews the expected time in that direction):

This can be summarized as follows:

As an example task, let's imagine you need to hook up Facebook Connect with your app as stated in the design doc. You ask your programmers for a best case (which they say will be 1 week or 5 days), worst case (3 weeks or 15 days), and most likely case (2 weeks or 10 days). Plugging this in to the equation, you get the following:

Therefore, the Expected Time equals 11.67 days, so you round up to 12. If you extrapolate this over the course of a project, the end result can be dramatically different than if you simply go by most-likely scenarios and also appropriately account for risk, as well as can be expected at least.

Critical Path

App development will be segmented into a series of measurable deliverables called milestones, which most of you have likely heard of or used on past projects. These are how you're going to evaluate your progress and third-party deliverables, as well as base your payment schedule. It's very important that you balance your project cash flow with money you'll pay out for milestones, in addition to keeping to the critical path early in order to keep risks low.

In project management, the critical path is the route of sequential activities from where you are now to the end of the project that takes the longest time to do. In other words, what activity must get done before another in order for the project to continue, then what must be done after that, and so on, until the end, where their total time to complete would be longer than the time of any other activities to complete.

At the start of a project, the critical path determines the total duration of the project. If you want to shorten the development cycle, you will need to run more activities in parallel, which is called fast tracking. The only other way to shorten development time (without cutting features) is what's called crashing the critical path, or putting more resources on any activity.

In app development, the critical path might be to prototype a UI shell, then add a series of features that are dependent on one another. For example, in order for the app to be a success, you need feature C. But for feature C to be implemented, you first need feature B, which is dependent on feature A. The time it takes to do A to B to C is the critical path.

There will likely be other paths with different tasks that are dependent on one another that do not take as long overall to complete. Although important, these would not be on the main critical path. Figure 5-2 shows two different paths, the left one being the critical path (taking eight weeks), while the other one is projected to be seven weeks.

FIGURE 5-2: Following the critical path

It will be up to the project manager (again, typically the Producer) to continually manage the critical path and update/revise it as milestones are completed. In app and game development, things change constantly, so don't expect the critical path to remain static throughout, or that another one won't replace it. And remember that, within each milestone, there will be critical paths to completing it, just as there is an overall critical path to completing the app. Focus most of your energy on getting these out of the way, and you'll be much less likely to overrun on time.

Calculating Risk

At the start of development, it's a good idea to lay out potential risks in the planning stage. Likewise, when creating a schedule and prioritizing tasks for the next iteration or milestone, it's important that your team be on top of factors that could slow down or stall development. This can be done rather elegantly with a simple risk analysis matrix, which is designed to point out your highest risk factors so you can plan to take action.

Table 5-2 shows a worksheet that demonstrates what some of the factors were for “Archetype” at project kick-off. Column 1 lists the potential risk, column 2 the probability of the risk occurring, column 3 the potential impact if it occurred, and column 4 multiplies columns 2 and 3 together to get an overall rating

TABLE 5-2: Risk Analysis

These were a few for illustration purposes, but, of course, there were many more. So, what do you do with the numbers? You assign those with the highest overall rating to be your next immediate action items. It's your call as to what the cutoffs are for unacceptable risk versus acceptable risk. But anything over 80 percent is definitely unacceptable, and at about 33 percent you generally have a safer risk situation. In-between items should be examined and likely acted upon to reduce risk.

Once again, in the essential resource for producers, The Game Producer's Handbook, Dan Irish lists some fantastic tips to reduce risk, as paraphrased here with additions:

• Don't start production without a mostly complete design. By doing this, you'll save a lot of time by not figuring things out (and wasting time and money) as you go along.
• Eliminate the unknowns early by figuring out what it is you don't know, then do the research to know what to expect over the course of the project.
• Have a backup plan in case something goes wrong. This would be especially true for highest risk factors.
• Prototype first if possible. Don't get too far into your app only to have various pieces come together, and find out it just doesn't work.
• Put the best talent on highest risks first, thus significantly reducing (or eliminating) these risk factors and paving the way to smoother future development.
• Use third-party tools or other solutions for anything that your team lacks the expertise to do.
• Eliminate and cut features early and often. (These are his exact words, but absolutely true — if it can be simplified, do so.)

Reducing Feature Creep

Feature creep (that is, adding in features that weren't planned for) is typically detrimental to the product schedule and cost. Thus, it can be extremely risky if not controlled.

Feature creep is common on projects with a lot of flexibility, or with very ambitious designers, coders, and even execs. To reduce it, maintain and prioritize a feature request or “I'd like to have” list. When prioritizing, keep in mind cost and risk in terms of implementing, the feature's value to the end user, and its relevance to the controlling idea or vision of the app.

Coordinating Outsourcing and Effective Communication

Outsourcing is almost always required for a small to medium-sized developer, and can include everything from complete coding, art asset development, through QA and marketing. Have a Producer on hand or someone who handles those responsibilities and comes up with separate milestone schedules for each source of outsourcing.

Because it's important that everyone on your team communicates effectively and together to solve, be informed, and ideate on issues, there are a few tips for effectively making these things happen:

• Use some sort of online project management software. A great example is Basecamp, available at www.basecamp.com. The one used for “Archetype” was GoPlan, available at www.goplanapp.com. Several other full-featured project management and online collaboration software solutions are available, but those are two that are recommended, with the leg up in support and functionality going to Basecamp. In each case, they'll offer full collaboration and notifications for new issues, milestone tracking, planning, issue tracking, and file management.

  It's important to note that full software development companies will likely use their own versioning software and methods of check-in or asset management. But these online solutions are good for coordinating the entire team.

• Have an instant chat and group video conference solution. As of this writing, the best is Skype (available at www.skype.com), though other reasonably easy-to-use methods exist for just instant messaging (such as Gmail chat). Skype offers invaluable face-to-face video conference meetings and/or free calls to anywhere in the world (user to user).
• Use Google Documents available from docs.google.com (or other cloud-based document solution) for any documents that you need your outsourcers to see, but you're unsure whether they have the exact version of Excel or Word that you do (and this includes most people). It's just better to be sure than to waste time in most cases with the back-and-forth versions. Plus, new versions are always updated, and you can set people to just “view” your documents, which is handy. Note that anyone viewing in private (safe from the public) must also have a Gmail account. But they're free to sign up for, and Gmail makes it easy and fast. Plus, it's the best free e-mail out there.
• Be specific and detailed with requests, and use clarifying questions a lot, especially when a heated or controversial issue arises. Some (or many) of your outsourcers may be from other countries. Therefore, it's not uncommon for a portion of communication to be naturally lost in translation. Those in some countries in particular (not that this is a bad thing) can tend to be very literal with meaning, so avoid using colloquial slang or language that is open to interpretation.
• Being specific also saves time, thus saving money. A misunderstood request to a translator can mean them having to do the work again, and, being in different time zones, that can produce a bottleneck in the workflow.

Localization

Unless you are absolutely sure you're not going to ever translate your game into another language (and even then…), you should plan for localization (translating your software into other languages) wherever there is text in your app.

Many languages aren't as concise as English in terms of size, and there are a couple you'll want to watch out for. For example, French and Russian have a tendency on the whole to be more lengthy. In general, though, it will be up to you or the Producer in charge of localization to direct the translator to stick within the interface or window boundaries as much as possible. In some cases, it's just not possible if your text area is too small.

Over the course of the app, text and phrasing can (and will) change, so it's important that you begin the localization process as early as possible. This should be when the writing is mostly locked down if, indeed, you are planning to localize and release in multiple markets simultaneously. For most projects, this means starting the process during the last one-third of production so that, when implemented during the testing stage, localization bugs — most of which are a) text too long instances, b) text missing, or c) context not correct — are reported, in addition to the normal ones.

When laying out new graphic user interfaces (GUIs) or writing dialogue, it's important that localization be considered. Here are some tips:

• Use more iconography that doesn't need translation — checkmarks, close icons, and even some small words like “OK” work for most languages these days. That said, all iconography must be intuitive and consistent.
• For “cells” with headings, titles, or short phrases without the use of scroll bars — that is, static boxes of text — keep in mind the space and font size. As a rule, allow for roughly one-and-a-half times the size of English text when you can.
• Standard Arabic numbers work in most all languages, so space considerations for these rarely need to be considered.
• Many phrases and colloquialisms in English don't translate well to other languages. So, keep these to a minimum, or be prepared to let your translators know that they can be creative when coming up with an appropriate colloquialism in their native language. This most often occurs when it's time for marketing.
• Include context u002s whenever you can so that you reduce the amount of questions translators have.

Production and Stages of Development

So far, this chapter has discussed elements of production such as how to be agile, plan, schedule, and reduce risk. Production is the process of officially starting to create code or assets for the design. If you can, it's often a very good idea to have your programmers throw a prototype together first using art asset placeholders whenever possible. With this, you find the fun and/or prove out the concepts first, then commit to going full-scale with production, and iterate on that throughout.

As mentioned, with agile development, each of these stages is meant to be rolled into a single iteration. At the very beginning, however, it begins with a controlling idea or vision for the app. Next, you'll want to develop a concept document.

Concept

As mentioned, the concept is defined in a brief document (typically one to three pages — the fewer the better to fully present it) with some visual aids in the form of a screen grab, mockup or two, and a concise bullet point list of primary features according to the vision of the app. Who's this for? It should be discussed and passed around to everyone who makes decisions on the app's design: Producer, executive management, lead designers/coders, and so on, for feedback and feasibility. Expect this to be iterated on somewhat as it goes around the table a few times in the process of ironing out its main features.

Scott Berkun recommends creating a marketing requirements document (MRD), in addition to the concept document, except that he uses the term “vision document.” The content of the MRD can be included in the vision document, but may contain sensitive data that shouldn't be circulated. The MRD is a summary of your market research. What opportunities do you see in the App Store that aren't being exploited? Are there competitors in your chosen genre or subgenre of app? If so, what areas are they ignoring? What assumptions (either by end users or software developers) can be overturned or re-imagined?

The MRD should also serve as the foundation for beginning the discussion on features — both to be added and avoided. Remember that analyzing the market for your app means fleshing out what it is and isn't; where you are specifically not going is often just as important as where you aim to succeed.

As with the concept document, remember you are not trying to impress or convince anyone with the MRD. Providing clear, concise (but easy-to-understand) answers is more important than buzz words and marketing-speak. As you write these documents (or direct them to be written), imagine the horror of a feature gone wrong because your lead programmer misunderstood portions of your controlling idea, or made wrong assumptions based on marketing answers.

You should roll your concept document into the beginning of the main functional spec or design document — the less to keep track of, the better.

The rule of thumb is, if it's a game (or app), it can just be a design document, and it's up to the team to decide how much detail goes in. Sometimes, the less detail the better, because design of a complex project is highly iterative. If you're implementing agile development, it's more important that you build in the fun and/or usability, rather than knowing that the exact ammo capacity of your shotgun cartridge is 4 or 12, or that you can filter 250 messages at a time instead of 500. These things change quickly with real user testing. For that example, it's good enough to know that shotguns use up shotgun shells, or that the messages can be filtered. The exact number can be set by the designer/programmers.

Once concept/MRD is completed, you will need to proceed to the Pre-production stage, also known as Design. If you're building a prototype, it's often a good idea to do both simultaneously.

Pre-Production (Design)

This is where the handwringing really begins — the hair-pulling, gut-wrenching process of solving problems, one after the other, until you're happy with the results. The designer Paul Rand (famous for creating the iconic IBM logo, Steve Jobs' NeXT cube, and plenty of others) once said, “Design is everything!” And he's right.

The good news is that your spec is not written in stone. It remains a fluid document, with open issues and incomplete information, until you've solved each particular problem or resolved each issue. Some will tell you a spec is never truly finished, even right through the end of final bug testing. But as long as you continue updating the spec throughout development, your app will benefit from the efficiency.

Expect this process to take anywhere from two to four weeks for a rather simple app, or more with some iteration for a very complex app or game. One writer should author the document throughout. A consistent voice is important and design-by-committee (other than including them in brainstorming or team discussion) is typically never a good foundation point for a document. The design doc will likely be from about 20 or so pages, up to more than 100 for complex apps/games with many assets. At this stage, you needn't worry about it being too fleshed out in terms of exact details. (Those will come with play and user testing, but no one wants to read a spec as big as the local phone book, so diagram and use visual aids as much as possible.)

There is one caution about too little information. Past experience as a designer has proven that programmers, if given too little information, must guess at exactly how many tasks are supposed to work. It's usually not necessary that you spell out every last detail such as timing (which can be tweaked), especially if it's commonly seen in similar designs. But don't take for granted that the end result will be what you originally envisioned if you don't take the time to clearly (but concisely) state some of the key logic and flow.

Pre-production (Design) is also where you'll be setting up your production systems and plans, such as asset management, version sourcing, team communication resources, assembling your team, and getting contracts ready.

Production

Make milestones, lock down core features while iterating on peripheral features to reduce waste (core features should have been found and locked down by now in Pre-production), and utilize agile development whenever you can for each iteration.

For each milestone, ensure that you have a concept, planning, production, and testing phase (even if it's just the owners) before moving onto the next.

Testing and Post-Production

In general, you're happy with your app and its functionality, but it needs much polish, be it in art, execution, optimization, interface, controls, gameplay tweaking, timing, and so on.

Testing and Post-production is the stage where you'll work on ensuring that the entire experience lives up (and hopefully goes beyond) the original vision, and is what a user would expect from a competitive app in the same genre. Namely, this is your final testing and tweaking push to iron out all issues before release.

An app or game generally goes through two main test stages prior to launch: alpha and beta. The later the stage, the less tweaking is done to core gameplay elements, and the more stability and usability are required.

Alpha

Once all the major issues have been worked out in the Production stage, it's time to jump into the trenches. An alpha app will have most features complete, perhaps a few peripheral features incomplete, and may be using some placeholder art, but the core functionality will be in place. Some major show-stoppers may be present (for now).

Alpha-stage apps are sometimes demonstrated to the press, but that should be discouraged. You may be eager to show your awesome new app to the world, but showing too soon may yield inaccurate expectations among your potential users (either positive or negative). Users and the press will also begin the release countdown, too, and interest may wane well before your final release date nears. Unless you absolutely must, save demos for late beta or (preferably) release candidate stage.

Beta

In beta, all major features detailed in the design spec are in and working to a degree. Many problems still exist, but major pipelines are in place, and functioning properly. Entire app testing begins in earnest as the last peripheral features are added and tweaked, and all art is in.

You may find yourself updating the spec document throughout beta as your app's remaining feature sets are coded, tested, iterated, and finalized. In late beta, the app is some significant percentage complete (hopefully 80 percent or more); some issues remain, and the focus in testing is wiping out crash, major gameplay, and other instability bugs first and foremost. Testing has been ongoing (and tested on every generation iOS device you can get your hands on — right?). The entire team should be using the app on a daily basis. In fact, if by late beta you don't want to ever see your app again, you're in good shape.

Release Candidate/Launch

Often, multiple release candidates are issued as new bugs crop up and are beaten back to where they came from. Your app is almost ready to submit to Apple — huzzah! But resist the very strong urge to toss any remaining bug reports out the nearest window. It may be tempting, but you will regret not hanging on for those last few weeks when the negative reviews come pouring in. The App Store is so crowded that apps with even minor annoyances are often set aside without a second thought. Your app should be the one that performs flawlessly.

If you're near your budget (or worse, over it) and you have no choice, release your app and consider noting specific fixes being worked on in the description. Don't — repeat don't — promise features or fixes you aren't working on. It just sets you up for failure if you can't deliver. Plenty of developers over-promise in the App Store, and nothing enrages iOS users more.

It goes without saying that the cardinal sin for apps are crashes. If your app crashes, and you absolutely, positively don't have to submit, don't! Nothing says “amateur” like a crashing app. Users don't care if they really should have rebooted their device or closed out all those extra Mobile Safari Web pages first. It doesn't matter; they will not hesitate to leave bad one-star reviews for apps that crash. Never release apps that crash under any circumstances. It is the death knell for any iOS app, period.

How do you know what bugs to ignore? Cutting features shouldn't be an issue at this stage. If it is, you're confused as to what stage your project is in. Bugs should be prioritized on a scale from “major” to “minor,” and anything at the bottom of the “minor” list is a candidate to be fixed after release. Use your common sense to decide. Ask yourself, if you only had (insert price of your app here) to spend this month and you bought this app, would you be upset if this bug happened? Be honest with yourself here. Otherwise, seek help from friends and family.

Finally, u002 that Apple's review process is merely a series of checks on your app. They don't do bug testing of any kind. If you find bugs that need to be fixed after submission, you can request they suspend the review. But you'll have to resubmit and restart the process once the bug(s) are stomped.

Post Release

Prior even to Production finishing, you should start making plans to expand or update your app, because updates (especially free if you can) tell your community that you are invested in the life of the app along with them, through thick and thin. Think of this as following through with your wedding vows, because that's pretty much how the consumers see it when they fork out the difficult $0.99. Well, to be honest — at $0.99, it's more like a budding relationship, hoping it might go somewhere. When you go for anything $1.99 and up, suddenly it's like marriage, and divorces can be ugly — especially on the App Store review page.

Seriously, though, you should start working on your first updates after your submission, and have the first ready very soon after you launch. Your post-release plan should be developed sometime during production (if there is one) with minor content updates regularly occurring throughout the afterlife of release. These can be holiday-related (as in themes), graphic upgrades, compatibility with new devices (iPad, retina display), new languages added, and so on. Users want to see that you care, and they will hang around and continue to spread the word if you do.

Coordinating Marketing

It's tough to predict when your app will be rejected or (hopefully) approved, but a good rule of thumb is two weeks from submission. The review rosters surge during certain times of the year — particularly October through December in anticipation of the Christmas holiday.

One tool you can utilize for marketing planning is to set the release date far enough into the future that your app will almost certainly be approved. It's still risky, because anything can happen, but if you happen to be developing in safer genres (for example, games or uncontroversial books), it's a good way to lock in advertising. Almost all reputable websites will work with you to change your ad schedules if needed. (It's a common practice; ad schedules change all the time.) If they don't, look elsewhere in the future.

One caveat though is to be sure to finish all your marketing plans, get your promotional videos and websites done, and anything else you need to finalize all before you submit your app. The last thing you need is to be frantically rushing crucial marketing material because your app was approved well before you expected.