If you somehow escaped the runaway success of the iPhone, iPad, apps, and Apple’s App Store, you probably wouldn’t be reading this book. It’s likely that a family member, friend, colleague, some random person on the street, or Apple itself got to you. As a result, you’ve learned about people leaving their day jobs to pursue their dreams in Steve Jobs’ App Store. You’ve seen—or rather heard—sophisticated apps such as the infamous iFart. You may even be talking about mobile and apps at work just as people did 10 years or so ago with the Web.
On that point, it’s been suggested that mobile is the new Web. What is meant by such a statement in the context of the current mobile market is that mobile apps are the new Web. That is, apps—these small pieces of software that run on mobile devices—represent the next opportunity to fundamentally shift the way business and society use technology. This is perhaps a brash perspective for an upstart like the App Store, which is less than three years old. And yet, research shows that the iPhone has grown faster than other market-disrupting launches. For example, the iPhone and iPod touch subscriber base is already eight times larger than AOL’s was two years after its launch.
If that seems absurd, that’s because it is. Since July 2008, when Apple opened its App Store—the marketplace where consumers can browse and install free or paid iPhone and iPad apps—the number of apps has grown so drastically that it’s not even worth trying to keep track anymore. In about a year, the App Store went from fewer than 1,000 apps to about 50,000. In July 2010, the App Store’s two-year anniversary, there were more than 200,000 apps that were downloaded more than 5 billion times in total.
Apple’s “There’s an app for that” marketing campaign has arguably been as successful as the company’s idea for an App Store. Unlike with most marketing campaigns, however, Apple’s campaign statement is somewhat true. There really does seem to be an app for almost everything, and that’s where the trouble begins.
Not only is there a metric ton of apps in the App Store today, but everyone seems to have an idea for a new one. As in the dot-com era, the success stories and accessibility of the medium have enticed would-be entrepreneurs to think, “Why not me?”
In fact, it didn’t take much effort to put some nice cash in your pocket when the App Store first opened. Earning a royalty check from Apple wasn’t as simple as sneezing, but most of the apps that people bought then aren’t even being downloaded for free now. At the launch, it was a simple case of supply and demand, with a relatively small number of diverse enough apps available compared to the large number of people who were intrigued by the newness of iPhone apps.
Circumstances are different today. The App Store is a highly competitive marketplace consisting of a delicately balanced interplay among Apple, developers (those who build the apps), and consumers (those who download the apps). Whereas Apple absolutely relied on a small, select group of developers to help populate the App Store when it launched, that’s no longer the case. Estimates put the developer count at over 50,000, with Apple reviewing more than 15,000 new apps per week.
Within the context of the new App Store ecosystem, anecdotal evidence as well as actual analysis confirms that a get-rich-quick mentality to developing apps can be emotionally devastating and financially costly. It’s true that the top developers do extremely well, with the most popular apps with the broadest appeal—typically games—such as Angry Birds and Doodle Jump yielding 4 million and 5 million downloads, respectively. Given the $0.99-per-download cost and the focus on these colossal hits, it is easy to look at the App Store and see nothing but dollar signs.
These tremendously popular hits, however, skew the realities of the more typical App Store application. The analysis that is available is fairly striking, and reveals that half of all paid applications receive fewer than 1,000 downloads and, after Apple’s cut, earn just less than $700 per application per year. Those numbers may even be optimistic, because the downloads for the very top applications—such as Angry Birds and Doodle Jump—are so much larger when compared to most apps.
Does that mean that if you are new to apps or building software in general, you should give up now? Not necessarily, but I do want to give you a reality check: recognize that with the current environment of the App Store, there are few who venture into it and launch an extremely popular app the first time around. That does not mean it’s impossible for that to happen, but many successful iPhone developers create at least one app before building one that achieves their goals. Part of the value in pursuing your first app, in particular, will be the experience and process of building the app itself. Even with the head start you are getting from this book, the knowledge and experience of others cannot substitute for your own.
This reality check may be troubling to you, but my advice is to think broader than an app. Build something that has value to you beyond just the app. Successful developers usually decide from the outset of entering the App Store that they will be committed to it over a period of time, viewing app development as an investment opportunity and not a lottery ticket.
The more experience you gain and the more time you spend in the App Store, the smarter you will be at identifying the right opportunities. By approaching the App Store as an investment, you’ll cultivate important relationships with peers, customers, and the media, as well as create development and design assets that can be reused for other applications. In conjunction with the reality of the App Store’s economics and the collective wisdom in this book, these relationships and assets are going to provide you a considerable advantage over those wandering into the App Store. Unlike others, you will not approach the App Store emotionally charged and with visions of grandeur about the viability of your idea. Instead, you will, as objectively as possible, assess the opportunity for your app and figure out if you should invest your time, money, and effort into it.
To fully evaluate the viability of your idea, you should understand the landscape of apps on the App Store, assess what the value of launching your app is to you, and be realistic about your ability to get it into the App Store. I’m using the words “you” and “your” here, but this might include multiple people such as a team at work or friends and contacts who are working with you on this idea. Whether you are evaluating this idea by yourself or with others, the following framework will provide you with a more structured approach toward thinking about your app.
The App Store really is the starting point for gauging your app idea. The App Store—whether on iTunes or the App Store app on the iPod touch, iPhone, and iPad—is not just a place to browse and download apps. It’s a battleground, a place to gather intelligence behind enemy lines and learn from those who are doing things right (and wrong).
Apple has made it easy for you to start mixing it up in the App Store. If you have an iTunes Store account, you’ll be able to use those credentials to install free or paid apps from the App Store. You can also create that account directly from your device (http://support.apple.com/kb/ht3575).
Make it your business to know what’s happening in the App Store. Apple typically does a more substantial refresh of its Featured apps toward the end of the week. Featured apps are an extremely small subset of apps that are carefully selected by Apple and highlighted across all the stores each week (see Figure 1-1). This is a great way to see the types of apps Apple considers unique or interesting. Continue to visit the Featured apps section of the App Store after you’ve done your initial research so that you’ll always be aware of what’s grabbing Apple’s and, subsequently, consumers’ attention.
Look at the apps they pick and you’ll begin to notice patterns across them—they’re simple, they’re creative, they have a great design, and they’re well built. The Featured apps aren’t always the most unique, but they are better—for one reason or another—than other similar apps. When an app is “Featured,” it’s a game changer for that app. The amount of visibility, and thus the increased number of downloads, for an app featured by Apple is sizeable, and is one of the more rewarding accomplishments an app creator can ever hope to achieve.
Beyond the Featured section, you can browse the App Store through Categories. There are 20 categories total, with the Games category also having 20 subcategories. When you browse on a device (iPod touch, iPhone, or iPad), each category highlights the top 100 paid and free apps in it (Top Paid and Top Free). When you’re on iTunes, you’ll see the top 200 paid and free apps. There’s also an overall Top Paid and Top Free listing called Top 25 on the iPhone and Top Charts on the iPad.
The Categories view is possible because developers must assign their apps to a specific category. More technically, apps are assigned to a primary and secondary category (see the section Version Information in Chapter 7). Choosing the category for an app is a strategic decision. Books, games, and entertainment have the highest number of applications, and thus more competition. For example, if an app could exist in both the Lifestyle and Entertainment categories, placing it in the former would offer a better chance for it to move onto one of the top lists. Getting too creative, however, could result in the app being ignored by consumers. Check out 148Apps (http://148apps.biz/app-store-metrics/) and uquery (http://www.uquery.com/stats) for breakdowns of all apps by category to get a better sense of the most crowded categories.
Figure 1-2 shows a graph from 148Apps. Notice that the Books, Games, and Entertainment categories have the largest number of apps. That does not imply that you should give up on your idea or place it in a completely unrelated category. Just be aware that you’ll face higher competition in those three categories.
Remember that one of your main purposes in exploring the App Store is to identify and learn from applications that are similar to your idea. So, although the Categories view will be helpful to discover apps that are somewhat related, from a competitive research perspective the Search area of the App Store will be the most useful to you. Unlike Categories, Search will reveal any apps that are more directly comparable to your idea.
Search operates in three ways: querying by application name, by company name, or by keywords. Of course, if you don’t know the names of the apps you consider competitive to your idea, searching for them by name will not be particularly useful. And even if you think you know all the competitive apps, there might be a few surprises waiting for you.
So, try typing in some keywords: words that describe the features, functionality, or uses for an app. Like a category, Apple requires developers to assign keywords to their applications (see Chapter 7). So, if your idea is to create an audiobook app and you type “audiobooks” into the search bar, Apple will return a list of apps with “audiobooks” in their name along with apps in which developers specified “audiobooks” as a keyword. Due to the number of applications in the App Store, though, the search results are also weighted by the popularity of the apps. This means that searching by keyword will help you find your top competitors.
Figure 1-3 shows a keyword search. The results will appear as you type letters and words into the search bar. Try various combinations and even nonobvious alternatives to find all the apps comparable to your idea.
Whether you browsed to an app through Categories or through Search, you will eventually arrive at the app’s App Store listing. Understanding the anatomy of the App Store listing is important both in this research phase and later, when you will submit your own app to Apple (see Chapter 7).
The App Store listing consists of a number of items that the creator of the app controls, including the application icon, application name, developer (company) name, application description, and application screenshots. The App Store listing reveals the sum total of how a developer markets his app to be downloaded. Give special attention to the language and features in the description area and the screenshots that are highlighted, as this information emphasizes what the developer considers most compelling about the app.
Figure 1-4 shows an App Store listing and its various components. Components labeled in white are controlled by the application developer while those in orange (labels 6 and 7) come from customer feedback about the app.
Key for Figure 1-4:
1 Application Icon
2 Application Name
3 Developer (Company) Name
4 Application Description
5 Application Screenshots
6 Customer Ratings
7 Customer Reviews
The customer feedback areas of the App Store listing—Customer Ratings and Customer Reviews—are populated by the input of customers who download the app (see Figure 1-5). Apple verifies that a person owns the app by requesting that a customer verify account credentials before a rating or review will be shown. This also allows the customer to update the rating or review going forward.
An app’s rating ranges from one to five stars, with five being the best. The review includes a title and a description, along with the name of the reviewer. Explore the Customer Reviews section for any app that is competitive or complementary to your idea. In this area, you can read the pros and cons of an app and what customers like or dislike. In particular, identify what customers are frustrated with or what they feel is lacking, as these represent opportunities for your app.
At some point, you may consider your exploration of the App Store and the app landscape done. Remember that hundreds and hundreds of applications are submitted to Apple every day, with the same amount being approved into the store. So, you’ll want to be sure to keep track of these new entrants by viewing apps through the Release Date area of the Categories view for your primary category at least once a week (see Figure 1-6). On a weekly basis, you should also continue to review the top apps for your category and the new Featured apps.
I can’t stress enough how fanatical a consumer of apps and a student of the App Store you should be. For example, don’t be stingy about installing paid apps. Give yourself a budget dedicated to checking out apps that you find interesting, are featured by Apple, are mentioned by press outlets, or you consider competitive to your idea. There’s no better way to understand the app ecosystem than to continually be immersed in apps.
Overall, the goal of investigating the App Store is not to help you identify how to make an awesome app. Instead, it should be to help you get a sense of how many apps are similar to your idea and whether there is a highly competitive or a nonexistent market for it. Both of those extremes have implications. If you found many apps related to your idea, you’ll have to build an app that is supremely better or more compelling than alternatives. If you found no or few apps, there’s a chance that your app idea has little demand. I’m making generalizations in both cases. The good news is that even when dealing with these extremes, you will see examples of app developers who succeeded in crowded categories or by being pioneers.
There’s a reason, or some number of reasons, you want to build your app. Maybe you are interested in experimenting with new technology. Perhaps your job has required you to oversee the building of your company’s app. Whatever those reasons may be, you still need some sort of justification for it—or what I’ll refer to as “quantification”—because as mentioned earlier, building an app will require time, money, and effort.
In fact, that’s not really possible, and even if it were, the numbers would fluctuate extremely rapidly.
You are still in the idea stage. You will begin to build assumptions about features and validate them in Chapter 3.
Be sure you are clear on why you are pursuing your app. Are your motivations personal or professional? Is your objective to maximize downloads or revenue? Do you want to drive awareness of a charity or complement an existing product? Whatever you determine as your goals, they will influence how you proceed in quantifying your app and will be particularly important in the type of revenue models you select for your app.
A big issue with the Web is that even some of the most popular websites have struggled with turning a profit because of the absence of a simple payment mechanism. That’s not a problem in the App Store because payment is facilitated through an iTunes account and Apple has reported it has 150 million credit cards on file.
There are a number of pricing methods for distributing an app in the App Store. Some are explicitly defined by Apple and others are clever ways of avoiding Apple’s policies and limitations. Choosing the style of your pricing or, for that matter, deciding to make an app available for free should flow directly from your goals and the market data you’ve researched.
The Apple-defined pricing methods include an app being free and paid. There’s also a feature called In App Purchase, which allows a customer to purchase something from within the application itself. Initially, In App Purchases were only allowed for paid apps, but Apple changed that restriction so that they also are allowed in free apps.
With so few options, you might think that choosing a revenue model is straightforward, but that’s not the case. Even allowing In App Purchases for free apps and the launch of the iPad have drastically changed the way developers think about pricing and distributing their apps. Entrepreneurs also saw opportunities to bring other revenue streams such as advertising to the iPhone platform. Apple joined in the advertising game by purchasing mobile advertising platform Quattro Wireless in January 2010. Apple integrated Quattro’s technology to create the iAd platform, which was announced as part of iOS 4. The following are the various revenue model options:
Releasing an app for free may be a mystifying prospect to you. Why give anything away for free that involves any amount of effort? The answer relates directly to your goals.
The App Store may just be another channel for you or your organization to have a presence. If it is, it is less important to make money from your app. The Gap has apps for its various brands that it gives away because it wants to sell clothes, not apps. Facebook—one of the more popular free apps in the Social Networking category—is free because its website is free. The Salvation Army’s app—its famous bell—is free because it wants to raise awareness of its cause and mission.
I’m going to immediately bias you about advertising as a way to monetize an app you release for free. Unless you have a large number of apps or an extremely successful app to advertise in, you are likely going to make more money charging even a nominal price for your app.
Many advertising options, including Apple’s iAd, take 40% of the revenue generated. If you do decide to integrate an advertising platform into your app (see Chapter 7), make sure you do it in a way that is not intrusive or you will frustrate customers. Ensuring that the advertisements are relevant will also reduce the number of annoyed customers. The Pandora music app is a good example of how to properly leverage advertising. Apple’s iAd is addressed in more detail in iAd in Chapter 2.
A paid app is the second of the Apple-defined pricing methods. For paid apps, Apple takes 30% of any app sale. As I’ll cover in Chapter 7, Apple uses a tiered pricing model, with each tier associated with a particular price (ranging from $0.99 to $999). Pricing your app appropriately is both an art and a science. It’s one of the few elements that can quickly impact the number of downloads, and thus the revenue you make from your app. I’ll provide more detail about initially pricing your app later in this chapter, and will cover promotional pricing strategies in Chapter 8.
Allowing customers to demo or try software before buying it is a fairly common practice. A major criticism of the App Store is that it lacks this function. Consumers can’t try out paid apps and have to purchase them to use them.
Although it is less popular today due to the availability of In App Purchases for free apps, during the earlier days of the App Store developers began to circumvent the absence of a trial function by offering separate “lite” and “pro” versions of their apps. Typically, but not always, the lite version is free and the pro version is paid. Lite versions, as with trial software, usually either will not have all features available or will have some other limitations (e.g., a game may have only one level).
In App Purchases is the final official Apple method for monetizing an app. As with paid apps, Apple takes 30% of any In App Purchase.
Since Apple changed its policies to allow In App Purchases for free apps, the lite and pro model has increasingly become abandoned in favor of this option. Many developers use In App Purchases to turn on additional “premium” features or sell new levels in games. Using this approach versus a lite and pro model gives developers significantly more options to control how customers interact with and experience the app. Check out ngmoco’s We Rule (http://werule.ngmoco.com/) and notification service Boxcar (http://boxcar.io/) for good examples of how to integrate In App Purchases.
Once a person buys your app, she owns it indefinitely. If you continue to invest in that app and produce updates that help improve it, any customer who owns the app will receive the updates for free through the Updates area of the App Store (learn about updates in Chapter 9).
That process has been another sticking point for developers because it’s a common software practice to charge customers for significantly different or enhanced versions of an application. Under the Apple App Store system, unless In App Purchases are used, the lifetime value of a customer is the initial price paid for the application. That means an app that cost a customer $0.99 will yield a total of $0.70 for a developer and never a penny more.
Although not extremely common on the App Store—except in the case of iPad apps—some developers decided that system doesn’t work for them. So, after improving a version of an application for some period of time, they released a brand-new version of it under a different app name. Consider it a sequel of sorts.
Two examples of this approach include the popular Twitter client Tweetie (now owned by Twitter and renamed Twitter for iPhone) and a puzzle game called Enigmo. In the case of Tweetie, developer Loren Brichter felt so strongly about how much time he had invested in the next major version of his app that he shut down the first version and removed it from the App Store after launching Tweetie 2. Enigmo pursued a slightly less controversial path, which was to think about the next version as a true sequel; both Enigmo and Enigmo 2 are still available on the App Store.
It is worth reiterating that the Tweetie case is bold. Removing the original version of the app from the store meant the app name could not be reused (as defined by Apple) and the ratings and reviews for the app would not transfer. Be very careful about this approach. Although it can offer the possibility of higher revenue, it could alienate existing customers if pursued solely for that reason.
For some more background on how to select a revenue model, including specifics around advertising, see the interview at the end of this chapter with Krishna Subramanian, cofounder of the mobile advertising exchange Mobclix.
Table 1-1 summarizes the various revenue model options.
Used for brand awareness apps or where the app itself is not the end goal
The Gap; Facebook; The Salvation Army Bellringer
Free + Advertising
Used for apps with a large number of customers and high interactivity
Used for the majority of apps; 70% of the revenue goes to the developer
Lite + Pro
Unofficial method to let customers test app without paying for it; now less common due to In App Purchases
Labyrinth Lite; Labyrinth
In App Purchases
Used to let customers buy new features
We Rule; Boxcar
Unofficial method to persuade customers to pay for new versions of an app
Enigmo; Enigmo 2
iPhone applications work on the iPod touch, iPhone, and iPad. When on the iPad, iPhone apps run either at their original iPhone resolution (1× mode) or at twice the horizontal and vertical resolution (2× mode), to account for the larger iPad resolution. In 2× mode, your app will not appear very crisp, as each pixel is scaled up to occupy 2 × 2 pixels.
iPad applications are the simplest of cases. They are apps that are built for the iPad and run on it only. When browsing the App Store you will see that complete iPad application listings will appear in iTunes and the iPad App Store but not on the iPhone App Store.
Universal applications run on the iPhone and iPad as optimized applications using a single binary (see Chapter 7 to learn more about binaries). That is, a Universal app submitted to Apple knows how to function properly on whichever device it’s installed on. Universal apps are supposed to help developers avoid maintaining two separate codebases—but can reduce the opportunity for additional revenue. On that point, Universal apps are consumer-friendly because customers pay one price for an app that works properly on the iPhone or iPad.
With the launch of the iPad, the “new” versions of apps, mentioned in the “New Versions” entry in the earlier list, have become more common. Many developers found that developing for the iPad is unique and that the amount of effort to make an iPhone app work on the iPad was not always trivial, making Universal apps less desirable. As a result, many iPad-specific versions of apps were developed. For apps that already existed on the iPhone, developers began adopting labels such as “HD” and “for iPad” for the iPad versions of their apps. “HD” generally is used for game titles while “for iPad” is a typical choice for apps in other categories. For example, the popular iPhone app game Flight Control was launched as an iPad version called Flight Control HD.
More details about differences between developing for the iPhone and iPad will be explored throughout the book, but especially in Chapter 3 and Chapter 5. For now, recognize that the option(s) you choose will impact your revenue potential.
Mike Rundle, creator of Digital Post, provides some context on choosing the right app type and working with Universal apps in an interview at the end of this chapter.
At this stage, you only need to understand a general price point for your app. Your new familiarity with the App Store and the apps comparable to your idea should provide you a good sense about pricing. For instance, if others are charging $3.99 for similar apps, you probably won’t be charging $14.99, but could charge $5.99 provided you did something that made your app worth the extra money.
Due to the general price sensitivity of App Store consumers, your app’s price will have a significant impact on the number of downloads for your app. Even small changes such as shifting an app’s price from $1.99 to $0.99 can impact download numbers. And yes, these are the sorts of pricing numbers most of you will be using for iPhone apps. The average paid iPhone app price is around $1.99. iPad apps are priced higher because the apps are often more complex, and in some cases they can even feel more like traditional desktop software. The average iPad app price is closer to $4.99.
Beware of pricing your app at $0.99. The lowest price in the App Store can lead to quick, impulse purchases. People buying your app before understanding what it is about can result in an onslaught of negative ratings and reviews when they find it doesn’t do what they expected.
It’s useful to think about some scenarios behind price points, especially if you are preparing to invest in the App Store over the long term. Consider an iPhone app that is priced at $2.99. If, on average, that app received 15 downloads per day over the course of a year, its gross sales would be around $16,000 (15 × $2.99 × 365) with the developer’s portion being around $11,000 ($16,000 × .70). Bumping the price will almost always reduce downloads because rankings typically worsen with higher prices. For the sake of this example, consider that a $4.99 price cut sales by one-third, to 10 downloads per day. The result may not be intuitive, but the gross sales would actually increase to approximately $18,000, with the developer’s take being around $12,500.
Figure 1-7 shows an analysis from Distimo that provides anecdotal evidence that a higher price negatively impacts rank. Once this developer raised the app’s price to $1.99 (shown as $2 in the figure), the rank plummeted outside the top 25, reducing the app’s visibility, and potentially, its overall revenue. You should experiment with price to determine what yields the most revenue for your app. That won’t necessarily be the lowest price with the highest rank and most number of downloads, but it could be.
For many of you, if you’re launching only a single app, these numbers would reflect a losing financial proposition based on what it will cost to build an app. But if you have a portfolio of apps, these economics can scale nicely. A second app that had similar success could begin producing supplementary income for many individuals.
You can use your app’s revenue model, app type, and price to size the market opportunity for your app. One way to do that is by calculating an addressable market. Your addressable market is a best case scenario for your app, where every possible customer downloads or purchases your app. The addressable market is a theoretical ceiling of the maximum downloads or sales of your app, which is equal to the number of customers for your app multiplied by the price associated with it.
What may not be clear to you initially is how to discover the “number of customers” for your app idea. Jonathan Wegener’s excellent article “The Definitive Guide to iPhone App Market Sizing” (http://blog.jwegener.com/2009/08/03/million-dollar-iphone-app-market-sizing/), discusses an example of how to discover this type of information. Jonathan writes a blog called Back of the Envelope and is the creator of the iPhone app Exit Strategy NYC (http://www.exitstrategynyc.com). While I was preparing this book, I spoke with Jonathan, and he shared an update to the scenario in his original guide, providing a detailed example of how to calculate an addressable market:
Exit Strategy NYC is the ultimate tool for New York Subway riders. The application shows you exactly where you should be on the train to exit efficiently (for example, stand at the second door of the third car and you’ll arrive directly in front of the station’s exit). Using the app shaves minutes off each subway trip.
Before starting the project, I ran some market sizing to make sure the sales would potentially be worth the effort. If I were launching the application today, here’s how I would estimate the potential sales.
First, see how many Apple devices there are in the world that could potentially buy the app—start by getting the latest sales numbers. As part of its iOS 4 announcement in early April 2010, Apple said 50 million iPhones had been sold to date and an additional 35 million iPod touches. Exit Strategy NYC works equally well on both of these devices, so we can use the combined 85 million figure. If every single person bought our app at $0.99, we could potentially have gross sales of $85 million. But our app has a limited appeal: it targets New York City subway riders.
Next, let’s see how many of these devices are in the United States. AdMob’s Mobile Metrics report shows that roughly 50% of the devices are in the U.S., which means 43 million devices. There are 300 million Americans, so 21.5% of the population has either an iPhone or an iPod touch. Now, let’s figure out how many of these devices are in our target market of NYC Subway riders. There are 8 million NYC residents and the MTA’s website tells us there are 5 million subway riders on any given weekday. So, let’s say 6 million ride the subway. Given the 21.5% device penetration we calculated earlier, this means there are 1.3 million devices among subway riders.
But how many people will buy the app? To determine an upper bound on app sales, look for sales figures from top app sellers. Doodle Jump, a popular game, sold 3.5 million copies through early 2010. Across the 80 million devices, this represents an app penetration of around 4%. So, we can reason that if Exit Strategy NYC does well, it might get on 4% of the devices in our addressable market, which would be 1.3 million × 4% = 52,000 users. If it were a $0.99 app, it could potentially earn $52,000—before Apple’s cut. And if it were priced higher, it could potentially earn even more!
Similarly, market sizing can also help you figure out if you’re targeting too small of a niche. Perhaps you want to make an app to help wheelchair-bound Boston residents better navigate the city. Consider that Boston has 750,000 residents and about 0.5% are in wheelchairs, which means a target market of 3,750 people. If 21.5% have Apple devices and 4% at maximum will buy the app, that’s about 32 customers. You obviously won’t get a return on your investment serving those 32 customers.
If you plan to release an app with In App Purchase, be sure you use the sum of all possible purchases in your calculation (initial purchase plus all available In App Purchases). Similarly, account for a Universal app—one price for two apps—or if you are going to offer a separate iPhone and iPad version of your app. Although I am focusing on sales, an addressable market explicitly reveals the number of potential customers for an app, so it is useful for free apps as well, where the metric is not sales but downloads.
I want to reiterate that the addressable market number is not a promise of how much you will make from an app. Instead, it reflects the app’s maximum potential by showing the possibilities if every single person interested in your app downloaded or purchased it.
Rankings are another way to assess how your app might fare on the App Store. Check the overall and category rankings through the Top 25 (iPhone), Top Charts (iPad), and Categories views—Top Paid, Top Free, and Top Grossing—to see if competing or complementary apps you’ve identified are showing. Rankings are important because they generally correlate to the number of downloads an application receives. Downloads, in turn, dictate the amount of revenue earned by the application.
Although viewing the rankings of these apps is not very scientific and won’t reveal the actual download numbers for them, the rankings do provide another source to evaluate your idea. If you see that apps like the one you want to build are not ranking for their category, this may indicate that:
There’s not enough demand and interest for the type of app you have in mind because these apps are not being downloaded very often.
There’s an opportunity for you to do better.
In the iTunes App Store, you can view the top 200 apps for a category, while on the device App Stores you’ll see only the top 100. The App Store is only a snapshot of what’s happening now, though, and provides no sense of historical rank trending. To overcome this limitation, you can turn to tools such as PositionApp (http://positionapp.com/), MajicRank (http://majicjungle.com/majicrank.html), Mobclix’s App Ranking (http://www.mobclix.com/appstore/), or APPlyzer (http://www.applyzer.com/), which can show you extended rankings across all stores.
The data available to you in apps such as PositionApp and MajicRank is invaluable. Later, you can use these tools to track the rankings of your own apps. Now, however, you will want to track all the apps you consider competitive or complementary to your idea.
MajicRank, shown in Figure 1-8, provides you the opportunity to track comparable apps’ rankings over time. If you track a fairly well-done app that has positive reviews, yet you find that it’s not ranking, it could indicate that there’s no market for the app. Conversely, apps ranking on any of the top charts show a promising market with the downside being the existence of viable competitors.
You may have the next must-have iPhone or iPad app with a persuasive addressable market, but if you can’t take your idea and execute against it, it’s just an idea. The good news is that even if you do not possess the experience to transform your idea into an app, you can find others who do. Still, when evaluating whether to proceed with your idea, you can’t overlook inexperience, or conversely, your prowess, in designing and launching software products similar to apps for the market you are entering.
The ideal situation is for you to have experience both in the market or industry where your app will be relevant and in producing digital products. If you have experience in neither of these areas, you’ll have a harder time launching an app.
Birthing ideas from problems you experience daily, and thus knowing the mindset of the person who will use your app, is indispensable. You will definitely have the opportunity to learn from customers throughout the process of building your app. But being a customer yourself will start you with a solid set of assumptions and features for your app. Familiarity with your market or industry should also provide you with a nice list of potential customers, partners, and press contacts for your app.
If you have an idea that is outside your particular area of knowledge, try to surround yourself or consult with subject matter experts. That could be as easy as working with those who are using similar apps. The same holds true if you are clueless about building websites, software, and other digital products such as iPhone apps. Find accomplished designers and developers who don’t just talk about app development, but show you their apps on the store. Team building and identifying help will be explored in Chapter 4.
You don’t know exactly what your app is going to cost you yet...and that doesn’t matter. It could, for example, cost you a grand total of zero dollars if you are building the app at work or with friends. There are still costs in both of those cases, though. In the first situation, your employer is footing the bill. In the second, you and your friends have an opportunity cost for something else you could have done with your time instead of building the app.
It’s unlikely that a quality app would cost less than $10,000. This varies significantly based on features, complexity, and your experience with building software. Estimating app costs will be discussed in Chapter 4.
An app costing you no money out of your pocket highlights a key point. Independent of the amount of money you’ll need to turn your idea into an app is a commitment to actually submitting it to the App Store. That commitment could cost you your nights and weekends if you’re developing the app as a hobby. The commitment might also represent your company heavily investing in mobile and apps as a strategic initiative.
Thus, money is not the only thing to be lost in unsuccessfully launching your app, and yet it is something to be lost. When considering that half of all apps on the App Store make less than $700, you can start to understand why it’s important not to invest too much in a single app. Regardless of what you’ll learn about the costs to develop your app in Chapter 4, be firm in terms of what you are willing to invest into building an app, especially your first app. Start with a conservative budget and let the app prove itself on the App Store before using any of Junior’s college fund.
Position: Creator (design and development)
Background: Digital Post is a virtual newspaper application for the iPhone and iPad. The iPad application debuted as part of the iPad App Store launch in April 2010.
Ken: Describe where you got the idea for your app, Digital Post. What were your goals in launching it? Do you feel you achieved those goals when it launched?
Mike: Digital Post started out as a very different type of application with a different name and totally different concept. In early March 2010, I had the idea to build a dedicated “Internet search” app for the iPad, called SearchPad, with the goal for it to be available in the iPad App Store on the first day. I planned on pulling down information from Google (regular search results) as well as pictures (Google Image search) and displaying them in a nice way, better than you’d find if you used Safari. I had some interesting interface ideas for the image search; images would drop onto the screen and then could be manipulated using Multi-Touch gestures like in the movie Minority Report. The regular Google search results would be displayed in a list view, similar to how they’re shown on the Web, but with better typography, spacing, and colors to make it more polished and feel like an app and not a website.
The more I thought about this concept the more I realized I was approaching the device in the wrong way, an easy thing to do when you’re developing for a device you’ve never actually used before. I thought about how people would use the iPad and then tried to match it with the overall idea for SearchPad, and it just didn’t mesh well. Before its launch, the iPad was mainly seen as a device for casual consumption of information: movies, emails, tweets, music, games, etc. It was being billed as an entertainment appliance where interesting information would be displayed for you to interact with. SearchPad wasn’t going to display anything interesting to you when it opened; its first screen would essentially be an empty void until you typed in a term. SearchPad wouldn’t be an app you launched when you wanted to be entertained for a few minutes, and after a few days of careful thought I realized that “instant interestingness” is the niche I wanted to be in, so I scrapped SearchPad and started thinking about similar concepts.
Many months ago I began an iPhone application called, simply enough, Interesting for iPhone. It would cull various RSS feeds that I predetermined and show what was interesting on the Web at the moment. I never finished it, but I took the kernel of that idea and applied it to the iPad. For information sources, I thought I’d use newspaper articles since they’re of a high quality and precurated, and then it struck me to build the interface as a pseudonewspaper design.
My goals for Digital Post were simply to build something I was proud of and perhaps to make some money. I’m definitely happy with how it all came out, especially since I went from idea to 1.0 in about three weeks’ time, only working nights and weekends. The sales have been good and fairly consistent as well, which was a shock to me. I thought there would be a huge jump at the beginning and then a tapering, but with Digital Post that was not the case.
Ken: What sort of background research did you do to assess that Digital Post was a good idea? What convinced you it was the “right” app to pursue?
Mike: The iPad lends itself to media consumption and the newspaper idea seemed to make a lot of sense for the form factor. I knew that the New York Times had an app in the works, but from seeing the interface when the iPad was introduced I saw a lot I could do to improve on the concept of simply browsing news articles. Their single-article view is excellent, but on the main view they try to emulate the newspaper version too much and only show four to five articles due to long excerpts. From my background in usability testing (and especially eye tracking), I know that people mainly read headlines to determine how interesting something is, so showing paragraphs of text for an article they don’t want to read is a waste of space. In Digital Post, I use a list layout and display many more articles per screen, so it’s easier to scan for something interesting to read. As soon as I knew it’d be an app that I’d use myself I knew I was on to something.
Ken: With the launch of the iPad, Apple began offering the option for developers to create Universal apps. Digital Post started on the iPad, but you decided to build an iPhone version too. Will it be Universal? What went into that decision-making process?
Mike: When Apple first announced Universal apps I thought they were a terrible idea, and so did many of my developer friends. Why would someone completely rework the interface for the iPad’s resolution with brand-new features and not make it a separate app with a different price, especially if they have to rehire a designer to do it all? It didn’t make sense to me at the time, but I’m slowly coming around, mainly because it makes your current users really happy, and that keeps the buzz and word of mouth going. From reactions on blogs and on Twitter, users are ecstatic when a developer releases a Universal version, because it’s like a reward for being an early customer.
For Digital Post, I’m planning to have separate iPad and iPhone versions. That decision is based purely on price and the economics of each store. At $2.99, I think Digital Post for iPad is priced pretty well in the News category, and also relative to other apps in the App Store. For an iPhone app, however, a $2.99 price is definitely on the expensive side, considering the functionality it has. It’s not a big enough app to warrant people thinking $2.99 is a good price for it. My plan is to do an iPhone version and price that at $0.99. In the future, I may drop the iPad version’s price to $1.99, but that’s not really for sure.
Ken: Share some perspectives on how best to price an app. More specifically, how did you determine the price for Digital Post?
Mike: The economics and business of the App Store interest me more than anything. Because the iPad was brand-new, no one really knew what the prices for apps would be like, so it was an exercise in game theory—your app’s price is partially based on everyone else’s price—and you don’t want to look too expensive or too cheap. OmniGroup gambled the most and put out a $50 app, which seemed to raise a few eyebrows, whereas the big media companies had some great apps available for free. I priced Digital Post at $2.99 because some existing news apps in the iPhone App Store were around that price and it felt right to me for the amount of effort I put in and how much value someone would get out of it.
Ken: Since you have a background developing software on other platforms, what makes the iPhone platform different? Where will those who may have experience in other media get tripped up when first dealing with Apple’s iOS? Conversely, what will they enjoy more or find easier, if anything?
Mike: When I first started learning Cocoa it was for Mac application development. It wasn’t until later that I got into the development APIs for the iOS. I also have a deep background developing apps for the Web. I never learned C, so learning Objective-C meant I had to learn header files, pointers, and memory management as well. It’s a challenge, especially since Objective-C’s syntax is quite different from other languages someone may be coming from (Java, PHP, Ruby, etc.), but once you get the hang of it, you can fly. The Cocoa Touch frameworks are excellent and extremely high-level; you can do very complex things in one line of code. Apple’s known for quality interface design, and they provide developers a wealth of built-in components that you can use without any customization to build solid apps. Of course, if you want to go the extra mile and do custom interface development, that’s very straightforward as well.
The iPhone is one big constraint—no keyboard, small screen, few buttons—so designing applications for the iPhone is an exercise in building smart, simple software. It’s all about removing everything until you still have the main features available and then executing those perfectly so that the interface is pixel-perfect and the overall user experience is smooth and flawless. Bloated apps full of half-baked features don’t do well in the App Store, so it’s better to omit a feature than to not get it exactly right. Compared to Android apps that I’ve used, an app’s interface matters far more on the iPhone, so make sure it’s a top priority.
Building applications for the iPad is very interesting; it uses the same frameworks as the iPhone, but applications feel so different. They feel more like full-screen desktop applications than simple mobile apps. However, the same elegant design principles from iPhone development apply, and the screen is very large, so there’s more room for error. It’s fairly simple to use the default built-in interface components for an iPad app, but when they’re blown up to full-size they look awkward. Developers can create decent iPhone apps without hiring a designer, but you just can’t get away with that when building an iPad app since there are more pixels to fill and errors are magnified. Hiring a designer to work on your iPad app is a must.
Ken: Besides being tech savvy and a designer/developer, you’re very involved in several different technology-oriented communities. All are huge assets that make putting an app into the App Store a somewhat less risky proposition compared to someone who is just starting out with app development. What advice would you give to those who find themselves in that position?
Mike: As with all products, the better they are the more they do the marketing for you. If you don’t have an exciting, engaging product, it takes more to convince people to write about you and spread the word. I’ll be the first to admit that a curated, filtered news reader isn’t the most exciting application in the App Store, but I did my best to execute the concept as well as I could. That’s the only variable you really control: quality of execution. A decent idea with world-class execution will do well; however, the very best app idea in the world can be spoiled with poor execution.
How do you get world-class execution in an app for the App Store? Pay attention to the details: every pixel, every color, every font, every button. If you’re not the type of person who can do this, make sure you hire the best interface design person out there, and no, they’re probably not that expensive. I personally know people under the age of 20 who I’d consider world-class designers, guys with half my experience but twice my skills who are just insanely talented. Every few months or so one of them gets snatched up by Apple. These are the types of people you want on your project, not some gigantic iPhone consulting firm with a dozen people on staff treating your project like a paycheck. Unless you’re building the next killer 3D platform, your app can probably be built with just a few people working on it if you get the right people. Finding these people is tricky, so you have to go where they are, such as forums like Dribbble and deviantART. Quality interface design is what turns a so-so idea into a fantastic app, and a great idea into a million-dollar app.
Mike: My three “to-do” items for success would be these:
Build an app that you will love to use every day.
Sweat every single detail or hire someone who will.
Always remember the constraints of the platform since you don’t want your app looking out of place (or people saying it belongs on Android!).
Background: Mobclix is one of the largest mobile ad exchanges, enabling 20+ ad networks to reach a targeted ad inventory across apps on the iPhone platform, Android, BlackBerry, and mobile web.
Ken: Mobclix has been a leader in the mobile advertising space. Having seen many apps across multiple platforms, what are some of the characteristics of successful apps? Conversely, what traits are evident in apps that struggle or fail?
Krishna: Apps that serve a simple purpose and do it well are always successful. Casual games that are fast-paced, like ngmoco’s Maze Finger, keep users engaged. Apps that make use of the rich features of smartphones are always exciting—Need for Speed, for example, incorporates the iPhone’s accelerometer. Meanwhile, apps that tap into users’ online social circles can become extremely viral. For instance, Newtoy’s Words with Friends and FlipSide5’s Touch Hockey both allow users to play against each other over network connections.
Consumers only want to spend three to five minutes to perform a task or interact with data and objects. Understanding this behavior has been essential to the developers who’ve made successful apps. This is because the longevity and sustainability of an app can be determined by its ability to invoke high levels of consumer engagement (e.g., magazine apps and multiplayer games), help users perform a task well (e.g., productivity and navigation), check and consume data (e.g., Twitter clients and instant-message clients), or interact in an entertaining fashion (e.g., casual games). Likewise, apps with simple designs and good functionality can also expect to do extremely well on the App Store.
Apps that fail or fall out of favor with users have three main traits in common:
Not enough functionality
Me-too apps are apps that try to replicate the behavior of successful apps. Often, these copycat developers will miss key features or will fail to understand the key mechanics needed to engage their users. Two good examples of this are Doodle Jump and PapiJump. Both apps have the same functionality; however, Doodle Jump succeeded by providing consistent updates and engaging their customer base. PapiJump, on the other hand, released updates at random intervals that didn’t make any significant changes to the app. Moreover, apps that serve as app wrappers of web content, soundboards, or joke cards don’t provide enough user value to have a sustainable life cycle in the App Store.
Ken: Choosing a revenue model (e.g., free, paid, In App Purchase, advertising, etc.) is often confusing for new developers. Based on Mobclix’s experience, how should developers approach determining what works best? Can a business model change over time?
Krishna: When the App Store first launched, developers were only able to release paid apps and free apps. In other words, they had two distinct audiences that they could market to. Free apps typically drive the widest audience for developers and guarantee them revenue through advertising. In the early days of the App Store, we heard of one-off companies making millions on $0.99 apps (e.g., iShoot, Pocket God, etc.). Most of the time, developers would first focus on maximizing the number of downloads of their free apps, and then try to drive those users to download the paid version of the app.
As of late, we are seeing more traction in the In App Purchase model across free apps, largely because this model offers quicker and increased revenues via in-app incentives.
Ken: When does it make sense for a developer to choose advertising as the right business model to monetize an app? For those that fall into that category, what are some good practices for incorporating advertising properly? What should developers definitely not do when choosing to use advertising?
Krishna: Best practices include leveraging all of the available types of advertising. This means having a good mix of banner, interstitial, and rich media advertising. That being said, developers need to think about advertising and how it will fit into the app from day one by building the user experience around ad creatives. Often, developers wait until the very end to add in advertising, making for a poor user experience. Right now, we are starting to see developers create better engagement around the banner ads as a way to drive higher click-through rates (CTRs). ngmoco’s GodFinger app is a good example.
Developers also need to understand that impressions are not the only or even most important drivers of revenue. The mobile advertising ecosystem is still evolving, and CTRs are an important measure of performance right now.
Ken: Related to the previous question, what are some ways for developers to estimate what they might be able to make from advertising in their apps? Is there any market data or tools available to help them have even a broad understanding of whether their app can offer a better return on investment through paid downloads versus advertising?
Krishna: Some good tools include the estimators and calculators that are available via Mobclix. A good rule of thumb is to take 70% of the expected purchase price and compare that to the total estimates that advertising can provide.
Krishna: The iPad will provide a new user base for developers to attract and make great apps for. Mobile advertising will continue to grow and innovate, and with the proliferation of the iPad device, it will continue to drive marketers and advertisers to devote more of their budgets on mobile. Advertisers will be able to leverage the iPad’s functionality to drive higher engagement with creative ads.
You will also start to see a shift from mobile ad networks to online ad networks in terms of ad dollars being driven to the iPad since the ad unit sizes correlate more to IAB (http://www.iab.net/) standard sizes.
Mobclix provided the first monetization solution on the iPad and has the largest display inventory across the board on the iPad today. We were able to do this by leveraging our online ad network relationships to help developers start generating revenue when the iPad App Store launched.
Ken: How will the introduction of the iAd impact Mobclix and other mobile advertising options? Does the iAd appeal to all developers and advertisers or to only certain segments?
Krishna: There are certain types of advertisers looking to reach a certain type of app and iAd will bridge that gap. For sure, the iPhone platform advertising market will continue to flourish and have multiple winners. iAd will increase the overall advertising earnings available to iPhone and iPad app developers. At the same time, scaling rich media campaigns across 30 billion impressions will be a monumental challenge. Plus, HTML5 creative adoption will be an ongoing process. At the end of the day, advertisers will continue to focus on cost to acquire new customers and brand equity.
Whether they use a rich media brand buy or a targeted text ad, they will want to answer the same question: how much is it costing me for a new user? As for developers, the best plan of action for them will be to have multiple sources of revenue to maximize the value of their user base.
When deciding whether you should move forward with your idea, consider everything you learned or uncovered in this chapter. To help you keep track of this information, I created a way for you to logically organize your research. It’s available at http://kenyarmosh.com/appsavvy, and I think you’ll find it helpful to see all of your information in one place.
Don’t be discouraged if you’ve gone through the steps in this framework and subsequently decided that your app idea is not worth pursuing. The same is true if your app was already in progress but you shut it down. Should you find yourself in either of those scenarios, you are to be applauded because you’ve successfully digested and applied the content of this chapter. Ultimately, you’ve saved precious resources being applied to a failing proposition. The likelihood is that you’ll get another idea soon. If that one leads you to a brighter conclusion, you’ll be in a better position to explore it.