Advertisement

Keys to the Kingdom: The App Store Submission Process

  • Taylor Pierce
  • Dave Wooldridge
Chapter

Abstract

After months of extensive planning, development, and testing, you’re finally ready to submit your iOS application to the App Store! Congratulations on all your hard work! Your beta testers love your app, but will Apple’s app review team give it a thumbs-up?

Keywords

Customer Review Price Tier Distribution Certificate Product Page Info Button 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

After months of extensive planning, development, and testing, you’re finally ready to submit your iOS application to the App Store! Congratulations on all your hard work! Your beta testers love your app, but will Apple’s app review team give it a thumbs-up?

This chapter will walk you through the app submission process in iTunes Connect. If you’ve followed Apple’s guidelines, chances are good that your app submission will go smoothly. Just remember that more than 300,000 apps have already been approved, far outweighing the number of rejected apps.

Your product page in the App Store is the world’s gateway to your app, so its presentation is essential in properly communicating the value of your app. Before submitting your app in iTunes Connect, you will need to have a few items ready for the online submission form. It’s worth taking the time up-front to craft the following:
  • Your app’s title

  • An enticing app description

  • Eye-catching screenshots

  • An optimized keywords list

  • A pricing strategy

These elements will influence not only Apple’s app review team, but also your product’s marketability in the App Store.

The Politics of Pricing

One of the most important things you’ll need to determine before submitting your app is the selling price. With most of the apps in the App Store’s Top 25 priced at only 99 cents, don’t assume that’s the magic price point for your app. There are actually quite a few factors to consider before settling on a price.

Analyzing Similar Apps

Having already researched your competition (as discussed in  Chapter 2), you should know the prices and feature sets of similar apps. Although keeping your price below that of competitive apps may seem like the obvious move, don’t sell yourself short just yet.

If your app does not offer an attractive differentiator, such as an enhanced UI or killer feature, then you may be forced to price your app below similar apps, especially if they already enjoy a successful run of sales and positive customer reviews. But if you did your competitive homework, this shouldn’t be an issue, right?

If your app does bring a much desired feature that sets it apart from the competition, you may be able to do quite well in the App Store with the same price or even a higher price. If you feel similar apps selling at $1.99 will quickly copy your unique killer feature, then maintaining the same $1.99 price point might be the answer. But if you think the feature may remain exclusive to your app—for whatever reason, such as technical difficulty or licensing deals—you may be able to charge $2.99 or a slighter higher price.

If you’ve stumbled upon an untapped market where your app does not currently have any competitors, then it really comes down to determining how much your product is worth to potential customers. Usually, the more niche market it serves, the higher price threshold it can bear. For example, apps that cater to scientists, doctors, or sales reps are often priced at the higher end of the spectrum, ranging anywhere from $6.99 to $99. You’ll want to research the particular field your app specializes in to help calculate how much potential customers would be willing to spend on such a mobile application, based on the benefits it provides. You certainly don’t want to gouge your customers, but at the same time, you don’t want to leave money behind on the table either.

Room to Maneuver

Productivity apps experience a longer life span than fly-by-night, hit-driven apps, so pricing can be a little easier to determine. But for games and novelty apps that don’t benefit from that same longevity, ranking high in the App Store charts immediately after launch is usually the goal. Although most of those hit-driven apps debut at the rock-bottom price of 99 cents in the hopes of propelling them into the Top 100, you should think twice before employing this same pricing strategy.

Setting the price at 99 cents upon release is a nice impulse-buy incentive, but what happens when the initial sales boost from your launch publicity efforts eventually tapers off? When awareness and sales later drop (and at some point, they will), that’s the time you’ll want to rejuvenate your presence in the App Store with a limited-time sale offer. But with your app already priced at the minimum 99 cents, you have no room to maneuver. But with an app price of $1.99 or higher, you’ll have room to offer a special discount sale when needed to keep your momentum going in the App Store.

Games often receive complaints from consumers when released with a price tag higher than 99 cents, but don’t let the vocal few sway you. If you’ve built a high-quality game, then complaints aside, your profits will benefit from the higher price. Although most higher-priced games are from big publishers like Electronic Arts and Gameloft, many small, independent developers have also found success—for example, Semi Secret Software’s Canabalt at $2.99.

With your app priced at only 99 cents, you need to sell a lot of copies to make any decent money, especially after Apple takes its 30 percent cut. This usually requires ranking in the Top 25, with your business model relying on the boosted sales volume. And if you can get there, the visible exposure of the Top 25 can increase your sales exponentially, making the low 99-cent price worthwhile.

If you can rank high—that’s the gamble. Since there’s no guarantee your app will make it to the Top 25, or even the Top 100, pricing it at 99 cents is very risky if you end up selling fewer copies than expected. When you charge an app price of $1.99 or higher, you don’t need to sell as many units to make just as much money, which in turn makes the App Store ranking less vital to your app’s profitability.

Let’s say your app manages to sell only 10,000 units over the course of several months:
  • 10,000 × $0.99 = $9,900 – $2,970 (Apple’s 30%) = $6,930

  • 10,000 × $1.99 = $19,900 – $5,970 (Apple’s 30%) = $13,930

With disappointing overall sales, a $1.99 or higher price can still provide respectable sales numbers, and may even recoup the product’s initial development costs. A 99-cent price drastically reduces your profit margin by half!

Sustaining a Long-Term Business

Since you’ve purchased this book, it’s probably a safe bet that you’re looking to make money from your mobile app development. And you’re not just looking to bank on a single app, but ideally build a profitable business producing several iOS apps. To accomplish this, you must price your apps not only to be competitive with other similar apps, but also to provide enough revenue to pay for the actual development costs of each app and run your business. To help determine your pricing, you should first figure out what your business needs to earn each year to survive.

As a fledging business, your operating overhead may appear to be very low. Like many independent developers, you could be working from home and doing all of the design, programming, marketing, accounting, and other business tasks yourself. This is a common formula that has worked for many iOS app developers. But when calculating your financial needs, don’t focus on only immediate expenses such as advertising, web hosting, Internet access, telephone lines, health insurance, food, and your mortgage/rent. It’s important to place a value on your time as well. You don’t want to merely “get by.” Your plan should be to profit from all your hard work, earning enough money to not only fund your next app project, but also to reward your efforts with a little luxury.

As an example, let’s say your iOS app will cost $5,000 to develop. That assumes you’re doing all the UI design and programming work yourself, with a small budget to license graphics, music, or other services. To put food on the table and pay all of your bills, let’s assume your monthly overhead is $4,000. If you plan on producing three apps within a year, your total development budget and annual living expenses will be approximately $63,000. To give yourself a little breathing room in case of additional expenses and unexpected emergencies, let’s round up to $70,000.
  • $70,000 / $0.69 ($0.99 – Apple’s 30%) = 101,449 apps sold

  • $70,000 / $1.39 ($1.99 – Apple’s 30%) = 50,360 apps sold

  • $70,000 / $2.09 ($2.99 – Apple’s 30%) = 33,493 apps sold

To generate $70,000 in annual revenue, your three 99-cent apps would need to sell 101,449 copies before the year’s end! Easy enough if your three apps are best sellers, sitting comfortably within the App Store’s Top 100. But if they are ranked outside the Top 100, then charging only 99 cents per app may not get you anywhere close to your annual $70,000 revenue goal. And if you’re coming from the world of desktop software development and consulting, you’re probably used to making quite a bit more than that per year.

Just do the math. You’ll quickly see how selling apps for only 99 cents requires them to be best sellers with no margin for failure.

What if you manage a small in-house team of designers and programmers, or outsource development to a third-party company? Then the development costs for your app project will mostly likely exceed $10,000 or $20,000. I’m being conservative here, as some apps and games can cost more than $100,000 to develop. It just depends on the project’s complexity and the overhead of your staff and related expenses.

Looking to support your business with an annual revenue stream of at least $300,000?
  • $300,000 / $0.69 ($0.99 – Apple’s 30%) = 434,783 apps sold

  • $300,000 / $1.39 ($1.99 – Apple’s 30%) = 215,827 apps sold

  • $300,000 / $2.09 ($2.99 – Apple’s 30%) = 143,541 apps sold

That’s a lot of apps you’ll need to sell per year at only 99 cents each! You’ll either need a bona fide hit or to work much harder to release a larger collection of apps that can be generating revenue. Just remember that the more apps you produce, the more money you spend on development, which in turn raises your overhead.

Just because you’ve read about hit games like Angry Birds and Cut the Rope selling millions of copies, don’t assume that selling 500,000 apps is an easy goal to achieve. Sure, it would be great, and we all hope to hit the jackpot with a best-selling app. But when calculating your development budget and app pricing, keep in mind that most apps sell only a few thousand copies during their lifetime in the App Store. You’ll need to work very hard as it is to ensure your app is more successful than the rest of the pack, so don’t make your job any more difficult by pricing your app too low.

Perceived Value and Consumer Resistance

Are you starting to understand the great risk involved with the 99-cent price point? Your revenue earnings are not the only potential victim if your app does not sell well. There also seems to be a direct correlation between price and ratings, but not in the direction you would expect. The lower your price, the lower your customer ratings may sink.

It’s true that if your app is priced too high, consumers will lash out with negative ratings in the App Store. So, the cheaper your app is, then the better the reviews, right? Not necessarily. A lower price brings a broader audience of customers, many of whom acquired it as an impulse buy. After paying just 99 cents, you wouldn’t think anyone would complain, but complain they do. Quite a few users out there have unreasonably high expectations for what they will get for 99 cents. Many of them have been spoiled by the wealth of great 99-cent games. The popular strategy of dropping app prices to only 99 cents in an attempt to boost volume sales and rank higher on the App Store charts seems to have cultivated a distorted perception of app worth among consumers.

In 2009, Hog Bay Software’s Jesse Grosjean decided to experiment with the pricing of his acclaimed WriteRoom app, dropping from the regular $4.99 price down to free (for a weekend) and then 99 cents. The test was to see whether the limited free offer and then the later subtle increase to 99 cents would spur enough of a boost in overall sales volume to make up for the decreased profit per sale. Although sales did increase, they eventually tapered off again—proof that for the longevity of this niche productivity app, the higher price ultimately generated more revenue in the long haul.

Jesse Grosjean had planned to end up at a lower price point such as $1.99 or $2.99, but during the sales experiment, he watched WriteRoom’s App Store star ratings “go from mostly fours and fives to evenly distributed between five and one star.” Even though the cheaper pricing did increase the number of new users, it also yielded a perception that users were overall less satisfied. The experiment revealed a lot about App Store behavior. After the sale ended, Jesse opted to return to his original $4.99 price tag.

At a higher price, you may attract fewer customers, but they buy your app because they genuinely want it. Then they have a vested interest in the app’s survival and success, so their posted App Store ratings tend to reflect a more positive tone. A higher price can also give your app a greater perceived value. Psychologically, many people relate price to quality, believing that you get what you pay for.

So if 99 cents is too low for a large percentage of apps, then what price is too high? It is generally believed that apps ranging from $0.99 to $1.99 are perceived as impulse buys. A price of $2.99 seems to be the threshold that causes people to think and evaluate the app with a higher degree of scrutiny before making a purchase decision. Real resistance kicks in at $4.99 and higher, which requires a particularly high-quality game or app with strong features. There are a handful of best-in-class apps that have prospered at the higher end of the price spectrum, such as The Omni Group’s OmniFocus at $19.99 and Cultured Code’s Things at $9.99.

One of my favorite games, Firemint’s Real Racing, was originally launched at $9.99 to great fanfare. To sustain continued sales after several months of release, Firemint eventually dropped the price to $6.99 and then again to $4.99. This has enabled Firemint to extend the product’s life span and remain competitive among the new releases in the App Store without sacrificing too much revenue.

When the highly anticipated sequel, Real Racing 2, was released, Firemint tried once again with a $9.99 price tag. It initially did quite well, taking advantage of those early adopters and loyal fans who couldn’t wait to play it. But sales eventually began to slowly decline, and Firemint reduced the price to $6.99 to help maintain its position on the App Store charts.

Real Racing is not one of those games that can be developed for only a few thousand dollars. It’s a state-of-the-art virtual racing game that required a large development budget and many months of programming. It should be priced accordingly, reinforcing the perceived value. The reduced price of $4.99 for Real Racing and $6.99 for Real Racing 2 seems like a steal for those consumers who were hesitant to buy those games at $9.99. Yet the games still retain a profitable price tag to help support continued development of updates and new games.

iPad apps appear to command a much higher average price than iPhone apps. With its larger tablet screen, consumers perceive the iPad as more of a mobile computing replacement for netbooks and laptops, so there’s a belief that iPad apps are more powerful and feature-rich. This raises the overall price threshold, where an iPad version of an app can fetch at least one or two more dollars (if not more) than its iPhone counterpart. For example, the best-selling Angry Birds game is only 99 cents on the iPhone, yet Angry Birds HD for the iPad does quite well at $4.99.

While you can certainly make more money per app sale on the iPad, it’s still a smaller audience than that of the iPhone and iPod touch. Even at a lower price point, an iPhone app can still make more total revenue than its iPad counterpart due to sheer sales volume. But that’s only relevant if you offer two separate versions of your app: one for the iPhone and one for the iPad.

A universal app is designed for both the iPhone and the iPad, yet is assigned only one price. A lot of work goes into optimizing an app’s UI for both devices. So, unless you have a good reason to price your universal app at 99 cents, it’s in your best interest to go with a higher price based on the perceived value, your competitors, and what the market will bear for that category.

Just keep in mind that once your app has been released in the App Store, it’s much easier to later reduce your price than to increase your price. After a few weeks of sales, if you’re experiencing a lot of pushback from consumers over your app price, you can always experiment with sale prices or permanent price drops. But if you already established a set low price, raising the price at a later date can often cause friction with consumers who are angered by the increase.

Improving App Discovery: The Art of Keywords and Names

An app’s description in the App Store used to be searchable, which allowed developers to fill their app descriptions with tons of optimized keywords and text phrases. It was also a source of abuse, because many developers tried to “game” the system by including competitor app names and irrelevant, popular keywords in their descriptions in the hopes of ranking better in search results. In the summer of 2009, Apple changed the iTunes search algorithm to prevent this kind of misuse. In its place, Apple introduced keywords, which developers can assign to their submitted applications.

Now, the only elements that are searchable in the App Store are your app’s name, keywords, and company name. Because of this change, it’s more important than ever that your app’s submitted name and keywords are search engine-optimized to improve your app’s visibility in related App Store searches.

Assigning Keywords

iTunes Connect limits the Keywords field to only 100 characters, so make every keyword count!

Keywords can be single words or multiword phrases. For best results, Apple recommends separating multiple keywords with commas.

Since your company name listed with your application is already searchable in the App Store, there is absolutely no need to include it in the Keywords field. Doing so is only a waste of your precious 100 characters.

Although the Keywords feature may seem a lot more limiting than the lengthy text blocks of app descriptions, Apple has done you a small favor by making keywords hidden from public view. This prevents your competitors from easily copying all of your keywords! Of course, it’s a double-edged sword, in that you don’t have easy access to their keywords either.

Since the keywords you select play such a crucial role in your app’s discovery in the App Store, it’s important to do a lot of search experiments of your own to find out which apps are included in the search results based on certain search queries. I mentioned this in  Chapter 2 when discussing the benefits of researching your competition before developing your app.

Your goal is to build a list of keywords that you think would benefit your app’s visibility in consumer searches. Sure, you’ll want to include keywords that work for your competition, but you’ll also want to use a thesaurus to figure out all the possible keywords related to your app’s feature set. You want to cover all the keywords that users might possibly search for. If you find a few terms that seem like intuitive queries and are not used by your competition, those may be valuable keywords to include. The fewer similar apps that appear in a user’s search results, the less competition you have when the user decides which listed items to explore.

Here are some guidelines for picking keywords:
  • Use relevant keywords. Stick to relevant keywords for best results. If you’re selling a niche app, such as a writing tool or parked-car locator, it might seem like a good idea to include popular terms such as fart or bikini in an attempt to push your app in front of a broader audience, but that strategy won’t help you in the App Store. Not only do unrelated keywords hurt your search relevancy—lowering your search ranking in your actual genre—but including them is also a good way to get your app flagged by Apple during the review process.

App Rejection Warning

Keywords cannot contain words or phrases that are irrelevant, offensive, or refer to other products, brands, and registered trademarks. Don’t try to be clever by including the names of competitive apps in your keywords list. And be very careful not to include trademarked names or celebrity names that you do not have licensed permission to use. Doing so will only get your app rejected! For example, if your app is an independent movie listings guide, including keywords like Moviefone, Netflix, Fandango, or even actor names could get your app booted from the App Store. Apple says that “improper use of keywords is the fourth most common reason for App Store rejections.”

  • Avoid overly common keywords. Common, generalized keywords will produce a huge list of search results, making it much more difficult for your app to be discovered. Honing in on more specific keywords that will produce fewer search results will not only improve your search relevancy, but will also make it easier for your app to be included closer to the top of the search results list. For example, if your app is a flying game that requires users to navigate a spaceship through a three-dimensional maze of stars and planets, don’t use general keywords like game or fun, which basically describe every game in the App Store. Narrow your keywords to more specific terms that game lovers might search for, such as spaceship and mission.

  • Avoid repetition. Since you’re limited to only 100 characters, don’t repeat the same words in both your app name and keywords, since both are included in App Store searches. For example, if your app name includes the word spaceship, there’s no need to waste valuable characters by including spaceship in your keywords.

  • Cover all your regions. If you’ve localized your app to more than one language, it’s important to include localized keywords in the Localization section of iTunes Connect for every region your app supports. If you’ve decided to make your application available in both English and German App Stores, you’ll want to submit keywords in both English and German so that your app is searchable in those related regional App Stores.

Take special care in crafting your list of keywords before submitting them in iTunes Connect. You will be able to edit them again only upon uploading a new binary app version or if your app has been rejected and needs to be reviewed again. This precaution is in place so that Apple can approve your keywords during the app review process. It prevents the keywords system from being gamed or abused by developers. It also makes it vital that the keywords list submitted is perfectly optimized and free of typos, since you won’t be able to go back and revise your keywords until the next time your app is officially reviewed by Apple.

Tip

Still not sure what keywords to use for optimal results? As mentioned in  Chapter 10, Google’s AdWords keyword tool (https://adwords.google.com/select/KeywordToolExternal) can be a helpful resource. Although Google designed that web tool to help people refine their SEO plans and ad campaigns, it can also help you identify and compare the popularity of specific keywords. The data is not App Store–related, but it does give you a good idea of what people are searching for online as it relates to your app’s subject matter. For those of you having trouble pinpointing strategic keywords via App Store searches, Google’s keyword tool provides much better answers than simply making wild guesses on your own.

The Name Game

In  Chapter 2, I stressed how important it is that your app name be short enough to display in its entirety on iOS’ home screen without being truncated. Having a short app name also serves you well when displayed in search results in the App Store. A shorter app name ensures that the entire name is displayed without being truncated. Tap Tap Tap’s Voices and Convert app names are very easy to read, leaving room to add a descriptive caption to the title (see Figure 11-1).
Figure 11-1.

With Voices and Convert, Tap Tap Tap kept its app names short for easy readability, and added descriptive, keyword-rich captions to their name titles in the App Store

That’s right, your application’s name in the App Store isn’t limited to only the app name itself. It’s perfectly acceptable to add a descriptive caption to the App Name field. Just be sure your app’s name comes first, followed by any additional descriptive text, so that the actual name will always be visible when listed in search results. It’s fine that the embedded caption shown in Figure 11-1 is truncated, since it will be displayed in full on the app’s product page (after tapping the selection in the list). The simple app names Convert and Voices are listed in the App Store as follows:
  • Convert—the unit calculator

  • Voices—fun voice changing!

That added caption—usually separated from the preceding app name with a simple hyphen or colon—helps describe the application’s core functionality. This eye-catching trick not only draws the viewer’s attention, but also lets the viewer know what your app does without needing to first read the lengthy description. Since it would appear that not many people actually take the time to read long app descriptions anymore, this extended app title can really benefit your marketing efforts.

The other major benefit of this extended name technique is that it gives you the opportunity to fill the searchable App Name field with related keywords! As an example, consider “Convert—the unit calculator” and one of its competitors, “Convertbot—The Amazing Unit Converter” by Tapbots:
  • If a user searches the App Store for convert, both Convert and Convertbot are listed in the search results, because both of them include that term in their app names.

  • If a user searches for calculator or unit calculator, only Convert appears in the search results, since its app title includes those terms as part of its extended name. (It appears that Convertbot’s keywords are not optimized for unit calculator or calculator.)

  • If a user searches for converter, Convertbot is included in the search results, whereas Convert is not.

Keep in mind that the app name you choose for display within the App Store can be edited only when submitting a new app binary for review or if your app was rejected and requires resubmission. Like your keywords, your app name is subject to Apple’s review team to ensure that no one tries to abuse the opportunity with unlicensed trademarks or irrelevant and inappropriate words. So, all of the same rules apply here as they do for submitted keywords. Attempts to cheat the system will prevent your app from being approved.

Treat the app name as a marketing extension of your related keywords. When your keywords list and the app name are working together in unison with highly optimized words and phrases, you’re increasing the chances of your product being discovered in the overcrowded App Store.

Perfecting the Sales Pitch of Your App Description

Although a product’s App Store description is not searchable, it does still serve as a primary marketing tool for users who are interested in learning more about your app. Someone has gotten as far as viewing your product page in the App Store, and this is your one shot to convince that person why his life is not complete until he has purchased your app! The three influential elements on your product page are the description, the screenshots, and the customer reviews. We’ll be exploring all of these items in this chapter, starting with the anatomy of a good app description.

What Is It?

If you’re not using an extended app name (and you should), or if it’s still not obvious what your app’s primary function is, then the very first thing you should include in your description is a brief explanation of what your app does and why people should buy it. Remember my  Chapter 10 discussion of “the quick pitch” on your app’s web site? This is no different.

Just as with your web site, visitors to your App Store product page will take only a few seconds to scan the description and screenshots to see whether the app captures their interest. Your job is to make sure to provide enough of a sales hook that they are motivated to continue reading.

Although the iPhone version of the App Store displays the full app description on product pages, the iPad and desktop iTunes versions of the App Store display only the first three or four lines of text, with a More link to reveal the rest. Unless users are captivated by your screenshots, odds are good they won’t take the time to click that More link. With this in mind, it’s more important than ever to optimize your app summary into a couple of brief sentences placed at the very top of your description text so that it will be included on your app’s product page. If that brief text summary interests users, they will most likely click the More link to view your complete list of features and benefits.

Awards and Testimonials

Ideally, when you were generating a little prerelease buzz (covered in  Chapter 10), you managed to get a few prominent media reviewers to check out your app and provide you with some choice quotes. When your app is new in the App Store, you’ll have very few (if any) customer reviews posted, so it’s best to include a few winning testimonials in your app description to help convince consumers of the app’s quality. And even when your app does receive a lot of customer ratings, there’s nothing more influential than praise from respected bloggers and magazines. This is also a perfect place to mention any awards your app has won.

It may be tempting to place eye-catching awards and testimonials at the very top of your app description, but not at the expense of your quick-pitch app summary. If a stellar quote or an award-winning reference can be included along with your app summary within the few lines of text that are visible in the iPad and desktop iTunes versions of the App Store, then great! But if those accolades use up too much space at the top, and your app summary is truncated (by the More link), that could pose a problem. Consumers may not care that your app won an award if they don’t know what it does or how it could benefit them.

App Features and Benefits

Most people won’t bother reading dense blocks of text, so don’t describe your app’s features in long paragraphs. Break it up into brief sections for easy eye-scanning. Better yet, if you have a lot of features to mention, structure it as an easy-to-read bulleted list instead.

Don’t ramble on, listing every single last detail about the app. Less is more. Space and attention spans are limited, so consolidate your list to just the major features and benefits. This includes the core features that consumers are looking for, as well as the differentiating factors that set your app apart from the competition. If you think a specific feature is a key selling point, then it belongs in this list.

It’s vital to understand the difference between features and benefits so that you can craft a more effective app description:
  • Features represent functionality in the app or game.

  • Benefits illustrate how that functionality can improve your happiness, lifestyle, productivity, and so on.

For example, a writing app’s ability to synchronize documents via Dropbox is a feature. The benefit is that it allows you to continue working on your novel from any device or location that can log in to the online Dropbox service.

Putting It All Together

For best results across all the various versions of the App Store, organize your app description elements into the following top-to-bottom sequence:
  • App summary

  • Awards and testimonials

  • Features and benefits

After reading the previous sections, it should come as no surprise that the app summary should be placed at the very top of your App Store description. This is your quick pitch that explains what your app is. As I’ve emphasized, this brief text should always be visible; clicking the More link should not be required to read the summary.

If your app description requires quite a bit of scrolling to read it in its entirety, then it’s too long. You don’t want a potential customer’s attention to stray. If you’ve included a lot of accolades, try cutting them down to only a few of the most influential awards and testimonials. And if your features and benefits are not already listed as brief bullet points, doing so can also reduce the amount of space your description consumes.

App Rejection Warning

Do not include pricing in your app description, name, or icon. The App Store caters to many regional languages and currencies, so displaying a static, text-based price is prohibited. If your English app description mentioned a price in US dollars, that could cause confusion among customers in the UK App Store, since the dynamic buy button lists the app’s price in British pounds. To avoid App Store rejection, you can promote limited-time sale offers in your app description without mentioning a specific currency. For example, if your $1.99 app is currently on sale for only 99 cents, you could refer to the sale as “Half Off” or a “50% Discount.”

Before submitting your app description, be sure to proofread it using a good spell checker! I cannot stress this enough. Nothing says unprofessional like typos and misspellings! You want to compete with the big boys like Electronic Arts and Gameloft? Then you need to double-check everything you write before it gets uploaded into iTunes Connect. Afraid you’ll miss something? Then have a few friends proofread the description as well.

Make sure that your description is easy to understand and does not in any way misrepresent your app’s true functionality. Don’t forget that this description is not only read by consumers in the App Store. First it’s read by an Apple reviewer. If something in your app description is ambiguous or misleading, or if the reviewer couldn’t locate one of your listed features in the short time the app is being reviewed, it could cause the approval process to be delayed or even result in a rejection, with a request for further clarification. Remember that you can modify your description with additional information after your app has been approved.

A Picture Is Worth a Thousand Words: The Importance of Screenshots

Since the App Store does not currently support the inclusion of video demos, the only way an interested consumer can immediately see what your app looks like is via the screenshots on your product page.

Don’t assume people will take the time to download your app just because you offer a free or lite version, or that they will jump to YouTube or your web site to view a video trailer. They are already browsing in the App Store, so they may not bother visiting other sites, especially if they are busy (and most people are). Your App Store product page needs to convince people to download the app, and probably the most influential element on that page will be your screenshots.

With so much riding on the visuals, it’s imperative that you upload screenshots that best promote your app’s core functionality and quality. If it’s a game, then your screenshots better scream fun and excitement! If it’s a productivity app, then your screenshots need to emphasize just how much better someone’s life is going to be when using this app. Your screenshots need to have impact!

Choosing the Primary Screenshot

The first screenshot that is shown is the most important. It may be the only screenshot consumers see if they opt not to tap/scroll through the rest of the screenshots. So, make sure this primary screenshot is the one that best describes your app visually. Someone viewing it should immediately understand the general concept, without needing to read the description or load the other screenshots. This is the picture that’s worth a thousand words!

Take some time to explore the App Store product pages of popular apps and games. Analyze the first primary screenshot for each one, especially similar apps that will compete with yours. When you see a screenshot that catches your eye, try to determine what it is that makes the image an effective graphic.

On the surface, it may appear that the winning attributes are simply a stunning interface design, but look closer. Many of the best primary screenshots are ones that have been set up to look good! No, I don’t mean Photoshop enhancements. I’m talking about showing the app in action! If it’s a to-do list app, don’t show a new, empty list. Fill it with tasks that your target audience can relate to, demonstrating just how productive and time-saving it could be for them. If it’s a space battle game, display the key fun factors like laser guns firing and alien crafts exploding. You want the reaction to be, “Wow, that looks exciting…I must buy it now!”

The goal is not necessarily about packing in as much action as possible into your screenshots. A compelling primary screenshot is one that instantly attracts your eye and successfully describes the core functionality in a single visual.

The App Store product page for Retro Dreamer’s Sneezies game displays a great example of an effective primary screenshot (see Figure 11-2). Without reading the app description, this visual gives me a good idea of what kind of game play it offers. At first glance, it appears the goal is to free the Sneezies from their floating bubbles. Sure enough, the app summary in the description reads, “Touch the screen to drop a burst of sneezing powder into the field of floating Sneezies and watch as they sneeze themselves out of their bubbles. Try to initiate a chain reaction to rescue as many Sneezies as you can in this family fun puzzle game.” The screenshot even shows the sneezing powder in action, with a couple Sneezies freed from their bubbles and parachuting to safety.

Figure 11-2.

Sneezies by Retro Dreamer (published by Chillingo). Without reading the app description, this primary screenshot tells me quite a lot about the game play and looks like pure fun!

The Sneezies screenshot showcases the core game objective without cluttering the screen with too much activity. It looks like pure fun, without appearing too difficult for players of all ages to grasp the basics.

It may seem obvious to show a game in action, but the same strategy should also be employed with other kinds of apps. The primary screenshot of Rogue Sheep’s Postage in Figure 11-3 (left) provides a beautiful example of the digital postcards you can create and send. The primary screenshot for Imagam’s iFiles (on the right in Figure 11-3) showcases many of its file management and export features simply by displaying its custom pop-up menu above a populated file list. Screenshots of actual app activity visually demonstrate to users how those apps could benefit their own lives or help them become more productive.
Figure 11-3.

The primary screenshots of Rogue Sheep’s Postage (left) and Imagam’s iFiles (right) visually showcase many of their features and benefits within a single image

Apple recommends removing the status bar from your screenshots, but looking around the App Store, it’s apparent that advice is not always heeded.

Apple also recommends capturing screenshots directly from an iPhone, iPad, or iPod touch, instead of the iOS Simulator. To do this, when you’re ready to take the shot, hold down the device’s Home button and Power button at the same time. The screenshot is saved to the device’s Photo Library. Although you could easily e-mail the screenshot from the device’s Photo Library to your desktop computer, you can also sync the device with your desktop iTunes, and launch the Mac’s iPhoto application to import the saved PNG screenshot.

An alternative option is to capture screenshots from a connected device within the Screenshots tab of the Xcode Organizer window. From there, they can then be dragged to the Mac desktop as PNG files.

When a Screenshot Is More Than a Screenshot

Even though Apple refers to them as screenshots, this feature is not limited to the literal definition. If your app’s core functionality takes advantage of the accelerometer or special multitouch gestures, then it’s perfectly acceptable to show a photo of an actual person using the app on an iOS device.

Smule’s Ocarina app, which turns your iPhone into a musical instrument, uses the primary screenshot to display a photo of how to “play” the app using the device’s mic and multitouch screen (see Figure 11-4). This photo does a much better job at describing the unique app than an actual screenshot could show. Since the user’s fingers obscure portions of the app’s interface, Smule smartly included the Ocarina logo in the photo to reinforce the app name and branding.
Figure 11-4.

Because of the Smule Ocarina app’s use of the iPhone’s mic and multitouch functionality, displaying a photo of a user in action is a much more effective primary image than an actual screenshot

What if you’ve built a productivity app that is so packed full of features that a simple screen capture simply does not do it justice? Not to worry. There’s no rule forbidding the inclusion of text in your screenshots if it helps explain how your app works.

A model example of text usage is the primary screenshot for Groups from Guided Ways Technologies Ltd. (on the left in Figure 11-5). It complements the embedded interface view with additional text and icons to visually promote a vast array of key features. It also boasts a nice recommendation from O’Reilly.

Figure 11-5.

The primary screenshot for Groups by Guided Ways Technologies Ltd. (left) uses text and icons to visually promote a vast array of key features. The one for Newtoy’s Words with Friends (right) showcases core features, an impressive accolade from Wired magazine, and its compatibility with several iOS device models

Another example is the primary screenshot for Newtoy’s Words with Friends (on the right in Figure 11-5). It showcases a few core features and an impressive accolade from Wired magazine. It also displays a few different iOS devices running the app, visually promoting the fact that its social game play is compatible with a variety of hardware models, so all your friends can join in on the fun.

If you do include text in your screenshots and you offer localized versions of your app in multiple regional App Stores, don’t forget to also localize your screenshots accordingly. Before capturing the screenshots, set the preferred language on the device, which can be located in the Settings app at General ➤ International ➤ Language. If you’re creating a custom image (such as the ones shown in Figure 11-5), be sure to translate the text correctly. Online web translator bots such as Google Translate can sometimes generate incorrect phrasing or syntax. To avoid confusion or even possibly offending someone with the wrong word, you might want to consult with a professional translator. When your localized screenshots are ready, simply upload them to the corresponding app language version in iTunes Connect.

App Rejection Warning

Apple’s review team will reject your app submission if any of the provided screenshots include an iAd test advertisement or display inappropriate content that does not adhere to the 4+ age rating policy. If your app displays iAd banners, then hide the banner view when capturing the screenshot. And if your app includes content for older audiences, be sure it’s not visible in your screenshots. In other words, don’t show mature media content or violent game play.

Preparing Your Application Binary for the App Store

After learning the configuration process for ad hoc distribution (detailed in  Chapter 9), you’ll be happy to know that compiling your iOS app for distribution in the App Store is almost the same process. The only difference is the provisioning profile you assign to your application in Xcode.

Have you finished beta-testing and tweaking your app? Are you ready to compile the master version for the App Store? Here’s a rundown of the steps to prepare the application binary that you’ll upload to iTunes Connect.

Step 1: Verify Your Distribution Certificate Is Still Installed

To compile your app for ad hoc distribution, you needed to generate your distribution certificate from the iOS Provisioning Portal and install it in your Mac’s Keychain system. This distribution certificate is also used when compiling for App Store distribution, so take a moment to ensure that it is still installed properly. Launch the Keychain Access application, located on your Mac at /Applications/Utilities/Keychain Access.

In the dialog box that’s displayed, select login from the Keychains list and Keys from the Category list. In the list of keys, simply double-check that your private key is still paired with your distribution certificate. In the example in Figure 11-6, my Electric Butterfly, Inc. key (which was previously created for ad hoc distribution) is paired with my imported distribution certificate. If your distribution certificate is not paired with the appropriate key in a similar manner, then revisit step 1 of the ad hoc distribution process described in  Chapter 9 before continuing.
Figure 11-6.

Verify that your distribution certificate is still paired with the correct private key in Keychain Access

Step 2: Generate and Install an App Store Distribution Provisioning Profile

Log in to the iOS Dev Center online, click the iOS Provisioning Portal link in the top-right corner of the page, and then within the main Provisioning Portal page, navigate to the Provisioning section. Select the Distribution tab, and click the New Profile button.

In the form that’s presented, be sure to choose App Store as the distribution method. Select the appropriate app ID for your application, and verify that the distribution certificate is assigned correctly. For easy reference, enter a profile name that includes the app’s name and reflects the specific purpose of this provisioning profile, such as Breadcrumbs App Store Profile (see Figure 11-7). It’s important that your App Store provisioning profile is named differently from your ad hoc distribution provisioning profile so that they are easily identifiable when listed in Xcode. Choose Submit to generate your App Store distribution provisioning profile.
Figure 11-7.

Since you’re done beta-testing, it’s time to generate an App Store distribution provisioning profile in the online iOS Provisioning Portal site

Within the Distribution tab’s list of provisioning profiles, click the Download button to save this new .mobileprovision file to your hard drive. Drag the .mobileprovision file onto the Xcode icon in your Dock. Xcode will automatically install that provisioning profile in the proper location.

Step 3: Configure Your Xcode Project for App Store Distribution

Now with the proper provisioning profile in place, the next step is to open your project in Xcode and configure it for App Store distribution. In the main Xcode project window, select the project name at the top of the Groups & Files pane, and then click the Info button in the toolbar. Within the Configurations tab of the Info window, verify that you still have a Distribution configuration listed (which you should have already created during  Chapter 9’s ad hoc distribution stage). If you don’t have one, then duplicate the existing Release configuration, naming the copy Distribution. Now close that Info window.

Next, select the Target app within the Groups & Files pane, and click the toolbar’s Info button again. In the new Target Info window that appears, navigate to the Build tab, and double-check that the Configuration drop-down menu is set to Distribution. Scroll down to the Any iOS field below the Code Signing Identity row, and assign it to your new App Store distribution provisioning profile. Even though your ad hoc distribution provisioning profile may also be listed in the pop-up menu, it’s critical that your App Store distribution provisioning profile is selected (see Figure 11-8).
Figure 11-8.

Modify your Target’s Build tab, assigning your new App Store distribution provisioning profile to the Any iOS Code Signing Identity

Switch to the Properties tab, and verify that the correct app ID bundle identifier is in the Identifier field. It should be the same as the bundle identifier listed in your Xcode project’s Info.plist file (such as the example ID com.ebutterfly.breadcrumbs).

With all of that completed, the last step is to navigate to the main Xcode project window and ensure that the drop-down menu in the top-left corner has Device and Distribution selected for the Active SDK and Active Configuration settings, respectively.

Step 4: Compile Your iOS App

Now you’re ready to compile your Xcode project! App Store distribution does not require your project to include anEntitlements file, as it does for ad hoc distribution, so save your project. Next, select Build ➤ Build and Archive. If you’ve configured everything correctly, your app should compile successfully.

If you get build errors that are related to the project settings, retrace your steps to ensure that you’ve followed every single task outlined here, no matter how insignificant it may seem. Build errors can often be caused by the smallest mistakes, such as a misspelled bundle identifier or a mismarked check box. If problems persist, and you’ve ruled out code bugs and faulty configuration settings, clean out your project’s build directory, reopen the project in Xcode, and try another build attempt.

App Rejection Warning

Do not utilize undocumented private Apple APIs in your app. Apple has rejected dozens of apps for tapping into private iOS APIs that are not officially sanctioned for public use. The app review team is rumored to be using a static analyzer tool to ferret out calls to restricted, private APIs. So, even if your app includes the code but doesn’t execute it, your app may still get flagged for the code presence alone. To avoid App Store rejection, stick with the authorized APIs.

Apple will accept only iOS applications that were compiled with an App Store distribution provisioning profile. Unfortunately, an App Store distribution provisioning profile and an application compiled with that profile will not work on your test devices, so there’s no way for you to test this version of the app before submitting it to Apple. With this in mind, it’s important to do as much testing as possible—keeping a close eye on build logs and error messages—before configuring and compiling for App Store distribution.

After you’ve compiled it using the Build and Archive option, you’ll find the app in Xcode’s Organizer window. In the left pane of Xcode Organizer, select Archived Applications, and you should see your newly compiled app in the applications list that’s displayed. With the app selected, you’ll notice a Submit to iTunes Connect button at the bottom of the Xcode Organizer screen. But wait! Don’t click that button yet.

Before submitting your app binary, you first need to create your app’s listing with required metadata in iTunes Connect, which I’ll show you how to do shortly. The very last step in the submission process will be uploading your app binary, so we’ll revisit Xcode Organizer again very soon.

Ensuring Apple Has Processed Your Contracts and Payment Settings

Before submitting your app, make sure all of Apple’s required contracts, tax forms, and banking information have been properly submitted and processed. As I mentioned way back in  Chapter 1, this process can often take a fair amount of time, so it’s best to get it taken care of while you’re in the initial stages of development. That way, when you’re ready to submit your application to the App Store, there’s no lingering paperwork holding you back.

To check your current status, log in to iTunes Connect at http://itunesconnect.apple.com , and on the main page of iTunes Connect, visit the section called Contracts, Tax, and Banking to view the contracts you currently have in effect. As discussed in  Chapter 1, you should have the Free Applications contract already activated by default, which allows you to submit free iOS apps to the App Store. To submit paid apps to the App Store, you should have already requested a Paid Applications contract and completed the related banking and tax forms. Without that information submitted, Apple is unable to pay you any revenue you earn from app sales. Instead, it will hold your accrued earnings in trust until the required forms have been processed.

Are We There Yet? Submitting Your App in iTunes Connect

After months of development and testing, you probably can’t believe that you’ve finally arrived at this point: ready to submit your application to the App Store. It’s a moment filled with both excitement and trepidation, uncertain as to the fate of your product in the hands of Apple’s app review team. But not to fear, you’ve planned your application very carefully, methodically following all of Apple’s guidelines, so you should be in good shape. Now you’re ready to take the plunge.

Plan on adding your new app in iTunes Connect on a day when you have plenty of time to dedicate to this process. There are several screens of online forms to complete, so you’ll want to patiently work through each section at a relaxed pace to avoid making any careless mistakes or typos.

Note

You can add a new application listing in iTunes Connect without submitting it to the App Store. In fact, you’ll need to do this in advance to test certain features, such as In-App Purchase. Your app will not be submitted to Apple’s app review team until you’ve completed the very last step of uploading your app binary. If you’ve already created a listing for your app in iTunes Connect (based on these instructions) for In-App Purchase testing in  Chapter 8 and you’re ready for App Store submission, you can skip ahead to the section titled “Step 5: Upload Your App Icon and Screenshots.”

Step 1: Create a New App Entry

Ready? Great, let’s do this! Head over to the Manage Your Applications section of iTunes Connect. Click the blue Add New App button in the top-left corner of the Manage Your Applications page (see Figure 11-9).
Figure 11-9.

In the Manage Your Applications section of iTunes Connect, click the Add New App button to get started

Company Name and Primary Language

If this is your very first iOS app submission, the first screen will ask you to provide your official company name and your application’s primary language. Please note that this information cannot be changed later, so do not make any mistakes on this page!

The company name you submit should be the name you want listed in the App Store as the official developer of your application. Because of my own paranoia about proper code signing and App Store settings, I recommend using the same company/developer name across all of the following items to avoid any potential issues:
  • Your iOS Developer Program account

  • Your iOS distribution certificate

  • Your iTunes Connect/App Store company name

I use my company name, Electric Butterfly, Inc., for all three of those items, making sure the spelling and punctuation are always consistent.

As for the primary language setting, this is the language that you’ll use to enter all of your application data during this submission process. For example, if you choose English from the drop-down menu, the rest of the online forms will require your information to be in English. After you’ve created your app listing in iTunes Connect, you’ll have an opportunity to add support for additional languages, such as French, German, Japanese, and so on.

Clicking the Continue button will send you to the next screen, where you will enter some initial app information.

App Information

Let’s examine each of the three form elements on the App Information screen (see Figure 11-10) to better understand what’s required:
  • App Name: The submitted name can be up to 255 characters long. As discussed earlier in this chapter, this field is not limited to only your app’s binary name or display name. Using an extended app name with a caption (like Tap Tap Tap’s “Convert—the unit calculator”) is recommended. But your app’s actual name should be included in that caption (preferably first). If your App Store name and your app’s display name on an iOS device’s home screen are too dissimilar, that may cause confusion among consumers, as well as possibly raise a red flag during the app review process.

  • SKU Number: This field is often the source of the most confusion for iOS developers, since Apple does not provide much explanation as to the correct format or syntax of this string. Contrary to popular belief, there is no defined template or numbering system for the SKU attribute. Even calling it a SKU number is somewhat misleading, in that it does not need to consist of numeric characters. Your app’s SKU is never shown to customers and never publicly listed in the App Store. Basically, the SKU is an internal, unique ID for your app in iTunes Connect. It’s often convenient to use an easily recognizable name, rather than a string of only numbers, especially if you have related In-App Purchase items. For example, our fictional Breadcrumbs app’s SKU is breadcrumbs, and its In-App Purchase Premium Pack SKU is breadcrumbs.premiumpack. The SKU is independent of the version number, so it does not change with every version update. In fact, once submitted, that SKU number can never be modified, so pick a good identifying name that works for you. Also, if you opt to delete an existing app listing, that SKU can never be reused.

  • Bundle ID: Your app ID should already be listed in iTunes Connect after configuring provisioning profiles for the app, so simply select it from the pull-down menu.

Figure 11-10.

The App Information form requires a unique app name and SKU, along with your app’s bundle ID

To avoid consumer confusion in the marketplace, no two apps in the App Store can have the same app name or SKU. If the system reports that either of your requested choices is already taken (even if that other app has not been approved for sale in the App Store), you’ll be forced to provide a different app name or SKU.

You may not have a way to capture a “taken” app name for use as your App Store name, but you can append a keyword-rich caption to your name to work around the issue. You want to go this route only if there is no other app available (or soon to be available) in the App Store with the same name. Identical app names could cause confusion in the marketplace, with consumers unsure as to which one is your app—especially if both apps provide similar functionality.

Even though your added caption makes your submitted name technically unique in the system, the app’s actual name is still essentially the same as the others in the eyes of consumers. This could also lead to lawsuits if your app name is infringing on an existing trademarked application name in the App Store. If you already trademarked your app’s name, then the law is on your side (at least in your country). This is why you must perform adequate competitive research and create a unique name (see  Chapter 2). Avoiding common words for your app name can prevent these kinds of problems from occurring.

Caution

Since every app name and SKU must be unique, Apple has taken measures to prevent name squatting—the act of creating an app listing in iTunes Connect simply to keep other developers from obtaining that name. After adding an app to iTunes Connect, you’ll have only 120 days to upload an app binary (which submits the app for App Store review). If the 120 days lapses without an uploaded app binary, the app name will then be removed from your account, making it available for another developer. So, if you’ve created an app listing in order to test specific features like In-App Purchase, make sure you complete your development and submit your app binary before that 120-day expiration date.

At the very bottom of the App Information screen, you’ll notice a brief reminder from Apple about specifying device requirements. Special device requirements are those that require hardware-related features, such as GPS, network access, the built-in camera, or the accelerometer. You undoubtedly already learned how to define those device requirements via the UIRequiredDeviceCapabilities key in your app’s Info.plist file when you read Apple’s iOS Application Programming Guide. If you haven’t yet done that, then you’ll want to make the necessary modifications when compiling your app for submission to the App Store.

As in the previous screen, once these fields are submitted, they cannot be changed, so it’s vital that you do not misspell anything.

When you’ve finished entering your app information, click the Continue button to proceed to the next screen.

Step 2: Set the Availability Date and Pricing

The Rights and Pricing screen presents options to choose your app’s availability date, price tier, and other selling options (see Figure 11-11).
Figure 11-11.

Set your app’s availability date and price tier on the Rights and Pricing page

Availability Date

The Availability Date setting has proven to be one of the more frustrating elements of the app submission process. Within the main category pages of the App Store, consumers have the ability to sort the list by release date, which is a great source of exposure for new app releases.

Once upon a time, developers used to be able to make quick changes to the availability date after being notified that their app had been approved, which allowed them to control when their app appeared in that valuable list. This enabled developers to closely time the launch of press releases with the product’s visibility in the App Store’s new releases list. Unfortunately, Apple has since made changes to the release date reflected in the App Store, rendering that little trick obsolete. Now, the actual release date of your app is the date it is approved by Apple.

So then why does Apple provide developers with an option to set the availability date? This still gives you control over when your app goes live in the App Store. For example, if Apple approves your app on March 1, but you would prefer to debut in the App Store on March 22 to coincide with your press release and marketing efforts, then set the availability date for March 22. But keep in mind that the app’s release date in the App Store will state March 1, so you’ll have missed that initial exposure in the new releases list, since newer releases will have already pushed your app much farther down the list.

If appearing near the top of that new releases list is more important to you than a preplanned launch date, then set your availability date to a distant day in the future (such as a few months ahead), way beyond the estimated approval date. Unless your app’s review process takes an abnormally long time, Apple’s approval date will typically be earlier than your future release date. Then after you’ve completed the submission, set your iTunes Connect user profile’s preferences to notify you via e-mail when your app status changes to Ready for Sale. This way, if you regularly check your e-mail, the moment you’re notified of your app’s approval, you can quickly log in to iTunes Connect and change your availability date to Apple’s approved date. It then will instantly appear in the App Store and benefit from the fleeting exposure in the new releases list. This e-mail notification also serves as a nice heads-up, so you can send out your press release closely following the product’s availability in the App Store.

Price Tier

For paid applications, you’ll also need to choose a price tier. Since regional App Stores support various currencies, the drop-down menu forces you to choose a tier instead of an actual price.

When you choose a tier, the corresponding pricing is automatically displayed. And if you click the See Pricing Matrix link, a table appears, revealing not only the currency conversions in several regions, but also what your proceeds would be after Apple subtracts its 30 percent fee.

Educational Discounts and Regional Availability

By default, your application will be available worldwide, unless you choose to select only specific individual countries. You can also elect to participate in Apple’s educational discount program, which enables educational institutions to purchase volume quantities of your app at a discount of 50 percent of the App Store price.

Clicking the Continue button on the Rights and Pricing page will bring you to the Version Information page.

Step 3: Submit Your App’s Metadata

Of all the forms in the app submission process, you’ll probably spend the most time on the Version Information page, specifying all of your app’s metadata (see Figure 11-12). Fortunately, you should have already prepared many of the requested elements, such as the app description, keywords, and web site URL.
Figure 11-12.

Of all the screens in the submission process, the Version Information page is by far the longest, but fortunately, you should already have many of these items prepared, such as the app description, keywords, and web site URL

As you can see from Figure 11-12, it’s quite a long form, so let’s take a closer look at each item.

Version Number

This is a fairly self-explanatory field, listing your app’s version number, such as 1.0 or 1.3.1. You should use the same version number as the value listed in your application Info.plist file’s CFBundleVersion property, so avoid including alpha characters such as “Beta 1.”

Discrepancies between your actual app binary version and the version number you enter in this field might cause delays or problems during the app review process.

Description

The description you painstakingly wrote earlier in this chapter should be pasted into this field. Just remember that the desktop iTunes and the iPad versions of the App Store initially display only the first few lines of text, with a More link to read the rest of it. This makes those first few lines of text very important, so be sure to use that limited space wisely, explaining what your app does. Since you are allowed a generous maximum of 4,000 characters, use the rest of the available characters to list features and benefits, awards, testimonials, and other key selling points.

HTML tags are not supported, but lines breaks and special Unicode characters are acceptable.

Primary Category and Secondary Category

You must choose a primary category where you want your app to be located in the App Store. Selecting a secondary category is optional, but can be beneficial as an alternative if Apple thinks your primary category choice is not appropriate based on your app’s functionality.

If you choose Games as a category, then two more menus appear, allowing you to select two subcategories from the Games parent group, such as Action, Arcade, Board, Puzzle, Strategy, and other game genres.

Keywords

The keywords you crafted earlier in this chapter should be pasted into this field. As I’ve mentioned, whether or not you’re using multiword phrases for some of your keywords, it’s always recommended to separate them with commas for best results.

Copyright

List your copyright line as you want it displayed in the App Store. There’s no need to include the © symbol, since the App Store automatically places it before your copyright line. So, for example, submitting the line “2009 Electric Butterfly, Inc. All rights reserved.” would appear in the App Store as: “© 2009 Electric Butterfly, Inc. All rights reserved.”

Contact Email Address

Apple requires you to supply a contact e-mail address, but it won’t be posted in the App Store. It is only for Apple’s internal team in the event they need to contact you during the review process or while your app resides in the App Store.

Support URL

Apple requires all developers to provide an online support URL for each app listed in the App Store. Even though the desktop iTunes and iPad versions of the App Store include your support URL as an active link on your product’s App Store page, the iPhone version of the App Store includes only your app URL. With this in mind, you’ll want to make sure your support page is also easily accessible from your app’s web site.

It’s important that your support URL points to a valid source for contacting you, since Apple will check its existence during the app review process. At the very least, give site visitors some way to contact you directly, whether by an e-mail link or by an HTML feedback form (if you would rather hide your e-mail address from spambots).

To help reduce the flood of support queries and provide 24/7 assistance even when you’re offline, it’s always a good idea to post a list of frequently asked questions (FAQs), especially if you find yourself answering the same e-mail questions repeatedly. For iOS apps that enjoy an active and vibrant user community, self-hosting an online forum, such as the popular open source phpBB ( http://www.phpbb.com ), might be a beneficial addition to your support site.

If you don’t have the time or skill set to build your own custom support offerings, there are some amazing ready-made, third-party services available at very affordable monthly rates. Here are a few options:

AN ADDITIONAL NOTE ABOUT SUPPORT

Even after providing an extensive support site, if you find too many customers misusing the App Store’s Customer Reviews section as a place to post feature requests and bug reports, it may be helpful to add some support information to your app description text. Anything you can do to redirect users to your support site may help reduce the number of unnecessary one-star reviews that are nothing more than feature wish lists! But never reprimand customers who do that. Phrase it in a positive manner that persuades customers into believing your support site is the best and fastest method of receiving quality assistance.

For example, you could insert additional wording at the bottom of your app description text that reads: “For quick support assistance, please contact us directly at http://support.breadcrumbsapp.com or e-mail us at support@breadcrumbsapp.com.” And if you prefer connecting with users via Twitter, you can also add your Twitter URL to that sentence.

Basically, the more customer care options you provide, the greater chance you have of reducing the clutter of support-related posts in the App Store’s customer reviews (which in turn, may help boost your app’s overall customer star rating).

App URL

I discussed the importance of maintaining a dedicated web site for your iOS app in  Chapter 10, so even though the App URL field is optional, you should include your site URL here. Not doing so will only hurt your app’s marketability down the road, especially now that the application URL link is displayed so prominently in the App Store.

Review Notes

Most developers won’t need to fill out this optional field, but if there are unique features in your app that you worry the reviewers may misinterpret or have trouble accessing, your including some additional notes here may help expedite the review process.

If your app requires creating a user account or logging in to a password-protected web service, you’ll want to provide a test account or login credentials that Apple can use during the review process. Those login features are definitely tested by the app review team, so if you forget to provide this information in the Review Notes field, reviewers will request this login data from you, delaying the approval process. Some apps have even been flat out rejected based on the inability of app reviewers to successfully log in to a test account or a members-only web service from within an app. So even if you do supply the required information in this field, be sure to first test that it’s a working valid login.

Be careful that whatever text you include here is clear and concise. The last thing you want is for your app to be rejected because the extra notes you added here proved to be more confusing than helpful.

Step 4: Assign a Rating to Your App

Scrolling down the Version Information page, the second section refers to the intended age rating for your app. Here, you’re presented with a survey-style list of questions that you must answer (see Figure 11-13). Apple requires all iOS apps to be assigned a content-related age rating so that the iOS parental controls can filter out specified age-appropriate applications when children access the App Store.
Figure 11-13.

Answering None to all of the content questions dynamically displays an age rating of 4+, labeling the application as suitable for both kids and adults

The possible age ratings are 4+, 9+, 12+, and 17+. As illustrated in Figure 11-13, answering None to all of the content questions will dynamically display an age rating of 4+. Experiment with various Infrequent/Mild and Frequent/Intense answers for some of the content types, and you’ll see the displayed rating change to 9+, 12+, or even 17+.

It’s in your best interest to answer truthfully, selecting a rating that’s appropriate for your app. Even if your submitted 12+ rating consists of only a few Infrequent/Mild answers, if Apple’s review team thinks your app requires a more restrictive rating of 17+, it can and will reclassify your rating before approving it for sale in the App Store.

Ratings may seem subjective, especially with vague, generalized content types like Mature/Suggestive Themes, which can mean different things to different people. Nonetheless, Apple takes its ratings system very seriously, so there’s not much wiggle room to complain if you don’t like the approved rating your app has been given.

There are three major ratings-related factors to be aware of when designing your iOS app:
  • Web browsing access: If your app gives users the ability to access any web content (some of which may be deemed inappropriate for children) via an embedded UIWebView, your app will probably be given a 17+ rating.

  • Web service data: If your app retrieves data from a web service, such as an online catalog of digital comics or e-books, especially public domain items that may contain inappropriate content, your app will most likely be saddled with a 17+ rating.

  • Violence and sex: If your app features either Prolonged Graphic or Sadistic Realistic Violence or Graphic Sexual Content and Nudity—the bottom two criteria in Apple’s list of content types—your app will be deemed unsuitable for the App Store and will not be approved. Oddly enough, there does seem to be a slight gray area where a mild degree of sexually themed content is allowed, since apps containing the third item on the list, Sexual Content or Nudity, are typically granted a 17+ rating.

Take great care when answering the ten ratings questions, because they cannot be modified after the app has been submitted for review. Also keep in mind that the rating you choose for your app needs to also reflect the content of all related In-App Purchase items.

Directly below the Rating section is a small reference to the EULA. By default, if you do not provide your own EULA, then Apple’s standard App Store EULA will be applied to your application. This appears to be the EULA that most iOS developers choose to adopt. However, if reading about end-user agreements in Michael Schneider’s  Chapter 3 leads you to believe that specific features in your app warrant a custom EULA, then Apple does allow you to upload your own, as long as it meets Apple’s minimum terms. Since Apple needs to review custom EULAs upon submission, that option could potentially slow down the approval process.

Step 5: Upload Your App Icon and Screenshots

Continuing to scroll down the long Version Information page, the next section you’ll encounter is called Images. This is where you upload your large 1024 × 1024–pixel app icon and your screenshots. To upload a particular element, click the related Choose File button below it to select the file from your hard drive (see Figure 11-14).
Figure 11-14.

The Images section of the Version Information page allows you to choose and upload your large 1024 × 1024–pixel app icon and your app screenshots for display in the App Store

App Store Icon

Since I discussed the need for creating a large, high-quality 1024 × 1024–pixel app icon way back in  Chapter 4, you should already have this icon file prepared and ready to upload. Note that this large icon must be the same design as the app icon compiled in your iOS application. Submitting app icons that are not identical in design will quickly earn you a rejection letter.

The 1024 × 1024–pixel icon should be delivered as a flat, square PNG image with a 72-dpi resolution and RGB color mode. Do not include layers, masks, or transparencies of any kind.

And this is the most important rule: do not add rounded corners or the beveled gloss yourself. The App Store automatically adds those icon effects dynamically, but will honor the custom setting of the UIPrerenderedIcon key in your application’s Info.plist file.

App Screenshots

When submitting your screenshots, they do not need to be uploaded in any particular order. Once uploaded, you should see them displayed as thumbnails in the Images section. To place them in a specific sequence for the App Store, simply use your mouse to drag-and-drop the image thumbnails into the desired order. Your primary screenshot should always be the first image on the left.

Apple prefers receiving Retina-sized screenshots if your app is optimized for Retina display. The accepted dimensions for iPhone and iPod touch screenshots are as follows:

1136 × 640 or 640 × 1136
  • 640 × 960 or 960 × 640 pixels (Retina display full screen)

  • 600 × 960 or 920 × 640 pixels (Retina display without status bar)

  • 320 × 480 or 480 × 320 pixels (full screen)

  • 300 × 480 or 460 × 320 pixels (without status bar)

The following are the accepted dimensions for iPad screenshots:
  • 768 × 1024 or 1024 × 768 pixels (full screen)

  • 748 × 1024 or 1004 × 768 pixels (without status bar)

Like the app icon, screenshots should also be submitted in RGB color at 72 dpi with no transparencies, masks, or layers. Supported image formats are PNG, JPEG, and TIFF.

The system may not accept screenshot sizes and image formats that don’t adhere to Apple’s specifications.

Note

If you’re creating an app listing in iTunes Connect so that you can test certain features like In-App Purchase, then screenshots are not required to finish the process. After you’ve uploaded your 1024 × 1024 app icon, simply click the Save button. You can always go back and upload your screenshots to the app listing in iTunes Connect when you’re ready to submit your application for App Store review.

Once you’ve completed the Version Information page, click the Save button to finish creating your app listing.

Your New App Listing in iTunes Connect

Now when visiting the Manage Your Applications section of iTunes Connect, you should see your new app listing displayed. Clicking the app’s icon will take you to its main summary page (see Figure 11-15).
Figure 11-15.

Your new app listing’s main summary page in iTunes Connect

On the app’s summary page, you can manage any related In-App Purchase items and other attributes. Click the View Details button if you need to access and edit metadata or screenshots before submitting your app binary for review (see Figure 11-16).
Figure 11-16.

Visit the View Details page (accessible from your app’s main summary page) to edit various attributes before submitting your app binary for review

Step 6: Support Multiple Languages

If your application currently supports your primary language only, then you can skip this step. Do not select additional languages in iTunes Connect until your application actually includes localized support for those languages. Those of you who did provide support for multiple languages in your app binary shouldn’t go anywhere just yet!

Within your app summary’s View Details page, there is a Manage Localizations button (see Figure 11-16). Clicking that button takes you to localizations page that enables you to designate additional languages for display in regional App Stores that support those languages. For example, if your application already supports both English and Japanese, you would add Japanese as an additional language here. Since English was the primary language you selected back in step 1, there’s no need to add English.

Upon selecting an additional language, you’ll see a new web form that looks almost identical to the app metadata form you encountered earlier. The only difference is that instead of English, you’ll be submitting localized content for App Store metadata elements like the application name, description, keywords, support URL, and even an option to upload localized screenshots. If you opt not to submit new screenshots for the new language, your primary language screenshots will be used by default.

Step 7: Upload Your App Binary for App Store Review

Earlier in this chapter, you compiled your application for App Store distribution. Now that you’ve just finished adding your app listing to iTunes Connect, the very last step in the App Store submission process is to upload your app binary.

Before you continue, take a moment to meticulously review the listed details in your iTunes Connect app summary, checking very carefully for any errors or typos. Once you upload your app binary, it will be added to the queue for Apple to review, and only a select handful of app elements can be later edited in iTunes Connect (without requiring an updated submission). In other words, now is the time to make sure everything is correct!

If everything looks good, then proceed to your app’s View Details page in iTunes Connect (see Figure 11-16) and click the blue Ready to Upload Binary button in the top-right corner of the screen. You’ll be presented with an Export Compliance page.

Export Compliance

Because of current export laws, any products that contain encryption need to be authorized for export. The Export Compliance page asks if your app contains encryption or accesses encryption (see Figure 11-17).
Figure 11-17.

Before you can upload your app binary, iTunes Connect requires you to answer an export compliance question

If the answer is No, you can move along—just click the Save button.

If the answer is Yes, then a few more encryption questions will appear, requiring answers before you can proceed. Based on how you answer those additional questions, you may be asked to upload a copy of your Commodity Classification Automated Tracking System (CCATS) document.

Since Export Compliance must review and approve your CCATS file before your application can be made available in the App Store, be prepared for a longer than normal app review period if a CCATS document is required. If you’ve never heard of CCATS before, odds are good your app does not fall into this category.

Waiting for Upload App Status

Now that you’ve imitated a request to upload your app binary, you app’s status in iTunes Connect should have changed from Prepare for Upload to Waiting for Upload (see Figure 11-18).
Figure 11-18.

Your app status changing to Waiting for Upload signals that iTunes Connect is now ready to receive your app binary upload

You won’t be able to successfully upload your app binary until your app status is Waiting for Upload. Once that’s verified on your app’s main summary page in iTunes Connect, you can finally go back to Xcode Organizer.

Submitting Your App Binary in Xcode Organizer

Remember when you compiled your app with Xcode’s Build and Archive option earlier in this chapter? Make sure your compiled app is still selected in the Archived Applications section of Xcode Organizer. At the bottom of the window, you should see three buttons (see Figure 11-19).
Figure 11-19.

When iTunes Connect is waiting for your binary upload, you can validate and submit your application for App Store review within Xcode Organizer

Note

An alternate method of uploading your app binary is via the Application Loader utility that’s included in the Xcode developer tools download. In various places in Apple’s documentation, you’re directed to use Application Loader for uploading your app binary to iTunes Connect. While that’s certainly a valid option, most iOS developers recommend compiling your app with Xcode’s Build and Archive option and uploading your app binary through the latest version of Xcode Organizer.

First, click the Validate Application button. This performs the same validation tests that Apple will run during the review process. If it notifies you of any problems with your app binary, take this opportunity to fix the issues and recompile before submitting your app to Apple.

After passing the validation checks, you can now click the Submit Application to iTunes Connect button. You’ll be asked to provide your iTunes Connect login and password to complete the submission request.

And that’s it! Once the upload finishes, your app status should change to Waiting for Review.

Developer Rejected Status

If you discover a problem or need to edit certain assets that are untouchable when in the submission queue, then you can pull the app from review by clicking the app listing’s Reject Binary button in iTunes Connect. This will change your app’s status to Developer Rejected.

When you’re ready, you’ll need to resubmit a new app binary, which will start the review process from the very beginning. Obviously, you would do this only when in dire need.

In Review Status

When your app is being reviewed by Apple, the status changes to In Review. If you were required to upload a CCATS document, you may see the status Waiting for Export Compliance while your CCATS is being evaluated.

Ready for Sale Status

If your status reads Ready for Sale, then your app has been approved! Time to celebrate the momentous occasion!

MANAGING YOUR OWN EXPECTATIONS

Tom Petty was never wiser when singing “the waiting is the hardest part.” You’ve worked so hard to get to this point that, even if the app review process ends up being much shorter than expected, the slow passing of time until Apple’s confirmation arrives can feel excruciatingly long. Patience, Grasshopper. It’s best not to dwell on it. Instead, give yourself a project to keep you occupied.

Have you finished creating all of your marketing materials, such as your press release and video trailer? And how about researching and connecting with potential media sites for reviews and press opportunities, as discussed in  Chapter 10?

If you’ve taken care of your marketing tasks, then that’s great! You’ll be ready to rock when your app does become available in the App Store. But that’s still no excuse to idly sit, feverishly watching the clock. There’s no time like the present to dive into developing your next application or begin working on new features for the existing app. Just whatever you do, keep busy, and the time will fly.

Getting App Status Notifications

Those of you who would rather not log in to iTunes Connect a million times a day, obsessing over when that status message will change, can elect to have status updates sent to you directly via e-mail. Within your iTunes Connect user profile, simply opt in to receive status-update e-mail by modifying the settings in the Notifications tab (see Figure 11-20).
Figure 11-20.

Request to receive e-mail notifications when your app’s status changes by updating the Notifications tab in your iTunes Connect user profile

But if you’re paranoid that you might miss that all-important e-mail notification, Apple also provides a handy Status History feature. On your app listing’s main summary page in iTunes Connect, click the Status History link to see which stages of the review process have already transpired, as well as when specific actions happened and who initiated them (you or Apple).

Tip

In an effort to provide greater transparency and streamlined communication, Apple also created the News and Announcements for Apple Developers site at http://developer.apple.com/news/ as an online resource for app submission tips, iOS Dev Program updates, SDK news, and recommended programming techniques. This web site even posts the latest turnaround time for app reviews, such as “Percentage of iOS submissions reviewed within the last 7 days: 80% of new apps and 92% of app updates.”

Try, Try Again: Dealing with App Store Rejections

We all cross our fingers, desperately hoping not to receive the dreaded Rejected notice, but if your submitted iOS app is rejected by Apple, do not despair. Although painfully frustrating, it is not the end of the world. The nice thing about software is that it can always be modified and resubmitted!

In the rejection letter that Apple sends, the reviewers usually explain why your app was rejected, and if you’re lucky, they sometimes even provide suggestions on how to remedy the issue. For simple things, such as inappropriate icons or the incorrect usage of a UI element, making the necessary adjustments should be a no-brainer.

It doesn’t matter whether or not you agree with the reason for rejection. The important thing is that you make the requested fixes and resubmit your application. Fortunately, there’s no limit to how many times you can resubmit an app, so get back on that horse and keep trying. You’ve come this far, and you shouldn’t let a tiny dispute prevent you from making money in the App Store.

For major rejection issues that are not so easily remedied, it’s important to remain calm and deal with this as a professional business owner. I know that just the idea of several months of your life being thrown out the window because of an unacceptable app is enough to drive any person into a screaming frenzy. Your first instinct may be to write a scathing blog post in an effort to rally the troops behind your cause. Social media networks like Twitter make it entirely too easy to gather an angry mob of online followers, but raging against the machine won’t endear you to Apple or the app review team. Yes, they do read blog posts and news sites. Although it might feel personally satisfying to have TechCrunch report on how you’re yet another victim of app rejection, that won’t help you get into the App Store.

And if Apple’s rejection was completely justified because your application violates its established terms and conditions, you really don’t have a good reason to complain. Your loud rants will only make you look unprofessional in the eyes of your peers: the developer community. And it certainly won’t win you any points with consumers who read your blog or follow you on Twitter.

If you feel that you have a legitimate reason for considering your app rejection unjust, then talk to Apple about it. Try to establish a dialogue with the app reviewers who evaluated your app. If that doesn’t work, then you can submit an appeal to the official App Review Board at http://developer.apple.com/appstore/resources/approval/contact.html . Always state your case in a thoughtful, clear manner to help the reviewers understand your reasoning. Several app rejections have been overturned because of persuasive developer arguments and a quick reevaluation.

No one has said the app review process is perfect. Just remember that the App Store is still a relatively new marketplace—one that grew in size much faster than Apple (or anyone else) ever anticipated. It’s easy to get upset over rejection, but with more than 1,000,000 apps flooding the App Store and more than 45,000 app submissions each week, Apple’s overworked review team is merely trying to do its job as best it can under such remarkable pressure.

Mistakes do happen, but Apple is constantly working to improve the process. Although that kind of sentiment may make me sound like a glorified fanboy, please don’t misinterpret my intentions. As a developer myself, I certainly get frustrated if my creativity and ambition are limited by the restrictions of the business world, but then I remember that it is a business. If I want to be a part of it, solving problems with etiquette and professionalism is the only way to truly succeed in the long run.

Apple holds the keys to the kingdom, so if you hope to someday thrive in the App Store, it’s in your best interest to maintain a good working relationship with the company and its review team.

Approved! Making It to the Promised Land

So that miraculous day has finally come. Your app has been approved and is now available in the App Store! Congratulations! It is indeed a worthy achievement that can bring you much success, especially if you’ve taken all the necessary steps to effectively market your app.

Checking on your application’s performance in the App Store is as simple as logging in to iTunes Connect to review reported sales and downloads on either a weekly or daily basis. Beware: tracking sales can be utterly addictive and destroy your daily productivity level. iTunes Connect also issues monthly financial reports that summarize your app sales and earned revenue.

Analyzing Your App Store Sales Statistics

The sales and trends reports in iTunes Connect include a lot of data for analyzing your product’s life cycle and sales performance in the marketplace. But what if you’re looking for more assistance and additional features like the following?
  • Tracking your App Store statistics from a desktop application or mobile device

  • Custom graphing your statistics to better educate your own marketing efforts

  • Automating the task of retrieving and analyzing sales and download data (when you forget to do it yourself)

Third-party tools and web-based services can provide such capabilities. There’s definitely a solution out there that will mesh well with your workflow. Although this may not be an exhaustive list, here are some options to explore:
  • Apple’s iTunes Connect Mobile ( http://itunes.com/apps/iTunesConnectMobile ) is a universal iPhone and iPad app that is free to download from the App Store and gives you direct access to your iTunes Connect sales and trend data. Regardless if you employ other services, such as appFigures or App Annie, this free mobile Apple app is a convenient way to track your app’s sales from anywhere.

  • appFigures ( http://www.appfigures.com ) is a popular web-based solution that supports the automated importing of your iTunes Connect sales reports, presenting the data in dynamic graphs and charts. Beyond tracking sales, trends, App Store rankings, and reviews, appFigures will also automatically e-mail you report summaries every day. You can choose either a free Basic account or upgrade to access all Premium features. Although appFigures’ web reports are iOS-compatible (when viewed in Mobile Safari), there is also a third-party native iPhone app for accessing your appFigures account: appTrends by David Knell, available in the App Store.

  • App Annie ( http://www.appannie.com ), dubbed “Your App Nanny,” is a comprehensive app sales tracking and trend analytics web service. It offers many of the same features as appFigures, as well as historical App Store rankings data on all apps. Its attractive online dashboard interface can be accessed and viewed from either your desktop web browser or iPad’s Mobile Safari.

  • AppSales Mobile ( https://github.com/omz/AppSales-Mobile ) is an iPhone app that downloads and analyzes your iTunes Connect sales reports. Since it’s available as open source from GitHub, you’ll need to compile the project in Xcode and run it as a debug build in order to use it. But it gives you the flexibility to customize, compile, and install the software on your own mobile iOS devices to suit your own needs.

  • AppStar ( http://www.damabia.com/appstar.php ), Damabia’s Mac OS X application, is a comprehensive desktop solution for tracking your iTunes Connect sales and trends reports, Apple’s monthly financial sales reports, and App Store chart rankings and app reviews. It also provides you with a built-in interface for organizing all of your app icons, screenshots, and marketing materials in one place. A ten-day fully functional demo of AppStar is available for download.

  • AppStore Clerk ( http://blog.fieryferret.com/2008/10/appstore-clerk.html ) is a free Mac OS X application that parses your sales reports and displays your app downloads in a simple, easy-to-read spreadsheet table. It may not include the advanced graphing features of other solutions listed here, but it’s generously offered as freeware (and the developer even provides the source code as well).

  • AppViz ( http://www.ideaswarm.com/products/appviz/ ), by Ideaswarm, is a beautifully designed Mac OS X application that can download your iTunes Connect sales data, as well as import reports that you’ve already downloaded to your hard drive. Like most of the other tools in this list, it can analyze and track your sales and downloads in visual graphs to reveal trends. It also monitors multiple apps and accounts, App Store category ranking, and customer reviews, plus sales tracking for your In-App Purchase products. A trial version of this popular, feature-rich desktop app is available for download.

  • Distimo Monitor ( https://monitor.distimo.com ), like appFigures and App Annie, is an extensive web-based app sales tracking tool. What sets this solution apart from many of the other offerings listed here is that Distimo Monitor supports all major app stores, such as Apple’s App Store, Google’s Android Market, BlackBerry’s App World, and so on—perfect for cross-platform mobile developers.

  • Heartbeat ( http://www.heartbeatapp.com ), a service of Mobclix, is a very slick, remotely hosted web application that offers an extensive suite of sales tracking, trends, crash report monitoring, usage stats, App Store rankings, revenue payment management, and more. If you’re looking for a comprehensive tool for managing your entire App Store business, then sign up for a Mobclix account to take advantage of the free Heartbeat.

  • MyAppSales ( https://github.com/Cocoanetics/MyAppSales ) is a convenient iPhone app like AppSales Mobile, but it offers quite a few more features because of the creator Oliver Drobnik’s active development. Even though MyAppSales is now available as open source, allowing you to compile and run this feature-packed app on your own iOS devices, donations are still welcome and appreciated by Oliver.

  • Prismo ( http://positiveteam.com/products/prismo/mac/ ), Positive Team’s Mac OS X application, boasts a clean and simplified iTunes-style interface design. It supports the automatic download of reports from iTunes Connect, as well as tracking the ranking and sales of your iPhone apps and In-App Purchase products. A 30-day trial of Prismo is available for download.

Beyond the solutions already mentioned here, don’t forget to also check out the many App Store ranking tools that were profiled in  Chapter 2, such as APPlyzer and David Frampton’s excellent (and free) MajicRank.

Rev Your Engines

You’re in the App Store—now what? No, it’s not time to take a break. I know you’re tired from months of development, but you need to capitalize on the short-lived momentum surrounding your app’s launch!  Chapter 12 cranks up the publicity engine to increase consumer awareness of your app’s availability.

Copyright information

© Taylor Pierce 2014

Authors and Affiliations

  • Taylor Pierce
    • 1
  • Dave Wooldridge
    • 1
  1. 1.CAUnited States

Personalised recommendations