If you had asked me yesterday which Swift would be the topic of conversation among iOS and Mac developers today, I would have put money on it being the programming language and not the music star. And I would have been wrong, because Taylor Swift set the world of Apple watchers abuzz today by airing complaints about Apple’s new Apple Music service on her blog. In her post she lays out a well-reasoned argument that Apple Music’s payment policy is unfair to artists since creators aren’t compensated for listens by Apple’s customers during a three month trial period. As a result, she explains, she will not be releasing her newest album on the service. After reading Swift’s post and the resulting banter on the Internet, it’s tempting to dismiss the entire argument with some handwaving. “Of course Apple’s payments are unfair to creators. The entire music industry is built on exploiting creators. So get over it, because it’s a better deal than you’ll get from anyone else.” But forward thinking developers should take notice, because this controversy may hit closer to home than they expect.

First, no one is saying that Apple is doing anything legally wrong. They negotiated a contract with terms that are favorable to them. That’s what big companies do. And Apple will have every legal right to stream most artists’ music without compensation during that three month trial. So no one – not even Taylor Swift – is saying that Apple is breaking any laws. What Swift is saying, and what I agree with, is that it’s a bad deal for artists. Creators should be compensated for the use of their creations.

This debate is important to app developers because, whether we like it or not, digital music has been devalued – just as our digital creations have been. In just a few short years people have gone from paying tens of dollars for an album, to paying 99 cents for a single track, to paying pennies or even nothing to stream an entire library of music. This parallels in a rather frightening way the history of the App Store where, in an even shorter amount of time, mobile software that once sold for tens of dollars now is lucky to sell for 99 cents. Just as the music industry, now including Apple, has moved to an “all-you-can-eat” subscription model to bring down the per title cost of music below that 99 cent threshold, it now doesn’t seem unreasonable that a similar all-you-can-eat subscription model might be used to allow per title pricing of apps to fall below 99 cents as well¹.

I think that such an all-you-can-eat subscription deal would be disastrous for indie developers, but a full explanation of my reasons for that belief is more than I want to tackle today. Today what I want to point out is that this fight for fair compensation is not just a fight for musicians. It’s a fight for software developers as well. Apple is a great negotiator, and the company will take everything that it thinks it can get away with. Our problem as developers is that we’re in an even worse position than a lot of musicians. Musicians at least have alternate channels for their work. iOS developers only have one – the App Store. Mac developers who distribute solely through the App Store are in a similar position. If you don’t think that Apple would impose similarly unfavorable terms upon its developers when it’s Apple that holds all the cards, you’re fooling yourself.

So if you are a developer who thinks that apps may one day be subject to a similar all-you-can-eat pricing model, it’s in your interest to lend your voice in support of Swift’s argument, because the terms under which musicians work may one day be the model for the terms under which you work as well. Tweet about it. Tell your friends. Lend your voice in support of the notion that digital creations have value for which their creators should be compensated. And after you’ve done that, start investigating ways to strengthen your own position. If you’re an iOS developer, start looking at ways to take your app to Android. If you’re a Mac developer, investigate Windows. And everyone should probably be looking at web-based software as a service. Start making plans now for a day when you might have to bravely say “No” to a bad deal, just as Taylor Swift has done.

1. Credit to Dave Wiskus for first putting this idea in my head. https://twitter.com/dwiskus/status/607977149560033281 ↩

Read More

I was reminded recently of episode #216: The Hustle of David Smith’s excellent Developing Perspective podcast. “Reminded” isn’t really the right word, though. It’s more that it’s stuck with me since I originally listened to it in April. In that episode, David talks (among other things) about the importance of hustle for an indie developer. And he’s right. Hustle is an essential part of indie life.

As an indie, you have to always be on the look out for the next opportunity. When you find it, you have to grasp it. And when you don’t, you have to manufacture it. You’ve always got to be looking for the next client, the next line of business, the next marketing opportunity. You’ve got to hustle. You’ve got to recognize and exploit any advantage you have over often larger competitors. And even when you don’t find opportunity or advantage – especially when you don’t find opportunity or advantage – you’ve got to take steps to create it.

Indies need to create those opportunities and advantages because they don’t have a lot of room for error. Pick the wrong product at the wrong time, and you’ll soon find yourself looking for work. Pick the wrong client or the wrong rate, and you’ll find your contracting business in peril. Hustle is a force multiplier. It gives you wiggle room to recover from a mistake. It gives you another path to pursue when a door shuts in your face.

I didn’t use to think that I had hustle. If you had asked me 10 years ago, “hustle” wouldn’t have been a word that I would have used to describe myself. But, as it turns out, I was wrong. Over the last several years, particularly since I started my business, I’ve discovered that I hustle pretty well. But if you don’t, don’t worry – it’s a learnable skill. Keep an eye out for areas of expertise that you have access to, and then brainstorm products that might come from them. Look for an audience for your product or service, and then approach that audience. Find resources you have access to, and then use those resources. In short, find your advantage and then take action. Today.

Read More

If you’re a U.S. taxpayer with apps on the iOS or Mac App Store, you may have received from Apple a Form 1099-K, Payment Card and Third Party Network Transactions, which reports to the IRS your gross revenue from App Store sales. You may have also noticed that the amount reported on your Form 1099-K doesn’t bear much resemblance to the payments actually received from Apple.

There are a couple different reasons the amount Apple reported might not match the amount you received. First, the payments that are reported on From 1099-K are gross payments that you received before taxes, fees, and (notably) Apple’s 30% cut. Second, the amount on your Form 1099-K may not represent your worldwide revenue. Apple only reports revenue on Form 1099-K for regions that have more than 200 payments and more than $20,000 in total gross payments in the year. Because the thresholds are reached on a region-by-region basis, you may exceed those thresholds (and thus have your revenue reported on a Form 1099-K) for the U.S. and Euro Zone, for example, but not in India or Russia.

As you can see, it all gets very complicated, very quickly. In theory, the amounts reported by Apple on Form 1099-K should be able to be reconciled to payments received from Apple using the financial reports available in iTunesConnect (since those reports list every sale, its region, fees, currency conversions, and more), but in practice this is a task that is beyond most developers. Most independent developers I know look at the Form 1099-K when it arrives, scratch their heads a bit, and then move on.

The problem with that, of course, is that Form 1099-K is an official tax document that is sent to the IRS, and when the IRS sees an amount of revenue reported, it expects to receive tax on that amount. So if you find yourself in the situation where the amount reported to the IRS on Form 1099-K is more than the amount you reported on your income tax return, you can expect that some questions will be asked. You might even find yourself with an extra tax bill.

Apple only began issuing Form 1099-K to App Store sellers starting with the 2013 tax year. (Affected developers would have received their first Form 1099-K in January 2014.) So until recently, any problems that developers may have faced because of discrepancies between amounts reported to the IRS by Apple and those self-reported by the developer were only theoretical. That may be starting to change, though:

So what’s a confused developer to do? How should you deal with a Form 1099-K that doesn’t seem to match your payments from Apple? Well, first of all, get yourself a good accountant if you don’t already have one. I recommend finding a Certified Public Accountant that deals regularly with small businesses. You might also want to start reporting your revenue gross with an offsetting expense, instead of net. In other words, instead of recording a $7,000 payment in your books, you might want to record $10,000 in revenue with a $3,000 expense that represents Apple’s 30%. This should prevent the troublesome situation where Apple reports more revenue to the IRS than you do. As always, though, don’t take my word for it. Ask your accountant.

For more information about Form 1099-K, see the IRS’s 1099-K FAQ or the Instructions for Form 1099-K. For more information about Apple’s policies regarding From 1099-K, see the Banking and Tax FAQ in iTunesConnect.

Read More

Since publishing my piece on revenue distribution in the App Store yesterday, I’ve gotten some feedback from readers asking how valid my extrapolated data is. Some have pointed out that I’m working with a limited data set from only one app that might not hold for all apps. Others have pointed out that the daily revenue data that Marco Arment provided did not include any data from the period when Overcast was at the top of the U.S. Top Grossing list, so it’s possible that the curve isn’t really a strict power curve all the way up the charts.

These are valid criticisms. So let me respond by releasing more data; the only other useful data that I have available. In response to Marco’s post, William Wilkinson published financial data from his own app, Manual. Manual is a photography app that did well on the U.S. Top Grossing list (reaching as high as number 104) in September 2014, so the Manual revenue data is both contemporaneous with Overcasts’s and useful for examining the upper reaches of the App Store. The problem with the data Wilkinson released is that the daily revenue graph has a very low resolution. In reading the graph, I could estimate daily revenue to only ±$133. That’s not such a big deal at the high end, where daily revenue is measured in the tens of thousands of dollars, but in the long tail where revenue is measured in the hundreds of dollars, a $133 error is quite significant. With this limitation in mind, below is the graph of Manual’s data overlaid onto Overcast’s.

As you can see from the graph, the revenue curve for Manual breaks upwards a little before Overcast’s does, but overall they are very similar curves. In particular, notice that the “head” end of these graphs (U.S. Top Grossing #1 to about #1000) follow similar paths. It seems likely to me that the differences between the graphs can be accounted for by the daily fluctuations of the App Store, differing ratios of U.S. to global sales, and the inherent inaccuracy that comes with estimation.

So what does this mean? Well, it makes me think that I was on the right track with my original post. While the the exact revenue figures that I cited in The Shape of the App Store may be off little, it seems likely that they are at least in the right ballpark. They may even be somewhat conservative estimates if Manual’s revenue figures are to be believed. Whatever the exact figures, one thing is clear: Revenue is heavily skewed towards the top of the charts, to a much higher degree than I, at least, expected.

Read More

Every developer knows how tough it can be to make a living on the App Store. There’s a lot of money being made there, but it’s not spread very evenly. Those at the top of the charts make the lion’s share of revenue, while the vast majority are left to fight over the scraps. But exactly how lopsided is it? And how does that affect an indie developer’s chances of finding success? For a long time, I was resigned to never really knowing the answers to these questions, because although there’s wide consensus that the distribution of revenue in the App Store is best represented by a power law, I had no way of knowing how sharply or gently the graph of that power law curved. My own apps haven’t spent enough time on the Top Grossing list to collect the data I would need to make a prediction, and Apple sure isn’t sharing it.

And then on January 15, Marco Arment gave me (well, all of us) a belated Christmas present. In his piece titled Overcast’s 2014 Sales Numbers, Marco shared the financial performance of his podcast player, Overcast, through a series of statistics and graphs. Because the information he shared was so detailed, and because Overcast has been so successful, I realized that Marco’s post could provide some insight into how an app’s rank on the U.S. Top Grossing list correlates with its daily revenue.

Before we get to the results, it’s important to first discuss their limitations. The figures that Marco provided for Overcast were very detailed, including daily revenue information, but they weren’t complete. Of particular importance, the revenue figures that Marco published were for global revenue. There was no breakdown of the revenue provided by nation. This means that it’s possible only to compare rank in the U.S. App Store to global revenue. It’s not a perfect apples to apples comparison, but since the U.S. App Store is the largest national App Store both by downloads and by revenue, I think it’s a reasonable comparison to make.

To provide some context to the results, you may be familiar with the Pareto distribution. It’s the origin of the classic “80-20 rule” that’s used to explain so many phenomena that obey a power law. “Twenty percent of the people in an organization do eighty percent of the work.” “Twenty percent of the population control eighty percent of the wealth.” You hear these types of statistics a lot, but they’re usually not very accurate. Often, they are useful as a first estimate at best. So I didn’t actually expect App Store revenue to obey the 80-20 rule. In fact, I expected it to be a much sharper curve, representing even greater disparity in the distribution of revenue than the 80-20 rule would suggest – maybe a 90-10 split, or even a 95-5 split. As it turns out, the revenue distribution curve of the App Store is even sharper than I imagined.

I expected a “hockey stick” curve that’s characteristic of power law models, but I didn’t expect one like this. The hockey stick breaks upwards at around position 870 on the U.S. Top Grossing list. With about 1.2 million apps in the App Store at the time the data was collected, that arguably puts 99.93% of apps in the “long tail” of the App Store. The “head” of the App Store, those 870 top grossing apps that make up 0.07% of the App Store population, collect over 40% of the App Store revenue that’s paid out.

Luckily, there’s a lot of money to be made in that long tail. At the top of the long tail, in position 871 on the U.S. Top Grossing list, an app still makes over $700 in revenue per day. That’s almost $260,000 per year. Even number 1,908 on the U.S. Top Grossing list makes over $100,000 per year. In fact all apps above number 3,175 on the U.S. Top Grossing list produce enough revenue to at least make its developer the United States household median income for 2014 ($53,891). And this is just for a single app. Most indies I know develop more than one app simultaneously. Developers who can put together a collection of apps that rank at about 6000 on the U.S. Top Grossing list (about $25,000 in revenue per year) stand a good chance of building an app business that can sustain them and their families.

Now, all of that is not to suggest that it’s easy to build a sustainable app business. It’s not. But, by doing some basic business things right – like finding a profitable niche, solving a painful problem, effectively marketing apps, and generally doing the things that have been suggested time and again at conferences and on podcasts – a developer can dramatically increase his odds of out performing the multitudes that just slap any old thing up on the App Store and hope for the best.

So, with even fewer people than I expected making “yacht and helicopter money” in the App Store, I remain hopeful for my fellow developers. There’s a lot money circulating in the ecosystem, and a developer operating at indie scale only needs a little bit of it. It seems that even with the revenue curve tilted so heavily towards the big hits, the shape of the App Store still allows room for sustainable businesses to develop in the long tail. It seems that developers who work hard, mind the details, and treat their business like a business have a real chance of making it.

Note: I’ve posted a follow-up to this article titled, The Shape of the App Store, Redux that responds to some valid criticism that’s been received regarding the data set used here.

Update Jan (20° 20°)15: This post was updated to clarify that an app’s rank in the U.S. Top Grossing list is being compared to its global revenue.

Read More

In episode 206 of his podcast Developing Perspective, David Smith talks about the idea of the App Store being “full.” He makes the argument that with almost 1.5 million apps in the App Store, there are now enough apps to choose from and that all the good ideas have been taken; that for any basic type of app that you’re likely to think of, an app already exists to fill that need. I agree in large part with David’s observation that the App Store is now full, but the App Store being full is, I think, merely a side effect of something more important: The App Store has matured.

Yes, the shelves of the App Store are now fully stocked, but you’d expect to find that in Target or Tesco, or any mature market. What’s more significant is that the shelves of the App Store, more than ever before, are stocked with products from bigger players that compete at a higher level. These big players have more time, more money, better connections, and more collective talent than any single independent developer. They have the resources it takes to compete in the mass market that the App Store has become. These big players have money. They have reach. They can create mindshare and build valuable brands in a way that most indies just cannot afford to. The sad reality is that we indies generally can’t stand toe to toe with large corporate developers and hope to win. And so we shouldn’t try. Let the big guys duke it out over most of the market. We don’t need the whole pie. We just need a sliver. We need just enough to live our life, pay our bills, and maybe save a little bit too.

To get our sliver of the pie, though, we need to adjust our strategy. As David correctly points out, novelty is no longer a viable business plan. In an App Store that’s full, indies can’t depend on new ideas to attract the attention and the audience we need. Instead, we need to go where the big players aren’t. We need to compete in niches, where there isn’t enough opportunity to justify the attention of large corporate developers. Don’t try to create a new bookkeeping app – Intuit will eat you alive. Instead build a bookkeeping app that’s tailored specifically for veterinarians or, even more narrowly, for large animal veterinarians. Don’t build a general purpose word processor – Microsoft has that space all locked up. Instead, build a word processor that’s specialized for a particular field like academics or screenwriting. Each of these niches offer plenty of revenue opportunities for a single developer. The big players won’t be interested, though. After all, a niche with potential annual revenue of $250,000 might be an amazing opportunity for an indie, but for the big players, $250,000 won’t even cover their engineering costs.

By competing in niches where the big players don’t want to be, indies level the playing field. They avoid going head to head against large companies with massive resources. They avoid struggling against slick advertising campaigns for the competiton. They avoid having to compete with venture capital backed companies that give their products away for free. By competing in niches and avoiding match-ups that they can’t hope to win, indies reduce both the quantity and the quality of the competition that they face in the App Store. And that gives them a sort of freedom. The freedom to seek out only the most valuable customers. The freedom to charge sustainable prices for their work. The freedom to stay profitably small.

The real beauty of this strategy, though, is that it means, for indies, it doesn’t matter if the App Store is full. There’s always room for another niche product. Just as there’s always room for sand to squeeze into the gaps between large rocks, there will always be room for indies to enter markets that aren’t big enough – aren’t mass market enough – to support large companies with teams of developers. It’s in these gaps between mass markets where indies can make their living. It’s in these niches, within an already full App Store, where indies can find success.

Note: I expanded on this topic in a talk I gave at NSNorth this year. NSNorth has posted the video of that presentation online.

Read More

As you’ll hear on this Monday’s episode of Release Notes, some of the new features of iOS 8 have me wondering about the future. Based on what we saw at WWDC, it seems pretty clear that Apple intends to introduce devices this fall with screens of different dimensions. The introduction of size classes and other features all point in this direction. The rumor mill has also been hinting at larger iPhones for some time. In particular, rumors have been flying about a new iPhone that will come in both 4.7-inch and 5.5-inch sizes. No one knows for sure what Apple has planned, but at this point I think the rumors of a larger phone are likely true. Assuming that’s the case, what might that mean for the iOS ecosystem?

The most obvious change, as this image from MacRumors makes clear, is that we would no longer be dealing with two distinct device sizes as we have to this point. Instead, the addition of a 4.7-inch and 5.5-inch iPhone would blur the lines between “iPhone-size” and “iPad-size” devices. We’d have a spectrum of sizes, with the 5.5-inch iPhone almost the size of the iPad mini. In fact, a 5.5-inch iPhone in landscape mode might actually be wider than an iPad mini in portrait.

As the lines between “iPhone-size devices” and “iPad-size devices” blur, interface conventions might blur as well. Taking the assumed 5.5-inch iPhone as an example, it might have a “compact” horizontal size class in portrait mode, and therefore conform to the interface conventions that we today associate with the iPhone (e.g. single table view presentations, no popovers). In landscape, it might have a “regular” horizontal size class and take on some interface conventions that we today associate with the iPad (e.g. split view controllers with both a master and detail view). In short, the bright line that has always existed in the minds of developers between an iPhone interface and an iPad interface may start to become not so distinct. And this is where things start to get really interesting from a business perspective.

Since the introduction of the iPad, Apple has consistently pushed developers to create “Universal apps,” or apps that run on both the iPhone and the iPad with a single purchase. A lot of developers view that as leaving money on the table, though. Today in the App Store, it’s not uncommon to find the same app present in both iPhone and iPad flavors that are available for separate purchase. This is especially true in the Productivity category, where top apps such as OmniFocus, Things, Launch Center Pro, and even my own apps are available with separate versions intended for the iPhone and iPad.

Having separate iPhone and iPad versions makes perfect sense from the perspective of a developer. It takes effort to provide a great experience on both the iPhone and iPad. Why shouldn’t we be compensated for the extra value that we provide? Contributing to that line of thinking has been the clear dichotomy between the iPhone and the iPad. Up until now, the iPhone interface was seen only on the iPhone, and the iPad interface was seen only on the iPad. As a result, it was a fairly straightforward to explain to customers why they had to purchase an app twice: “They’re two different devices.”

Developers who currently sell separate iPhone and iPad versions of their apps would be well advised to start thinking about how they plan to handle the blurring of lines between these devices. If your customers no longer see a difference between the iPhone and iPad, how will you justify to them the need for separate purchases? If Apple no longer sees a clear dichotomy between the iPhone and iPad, might they no longer accept app updates that are not Universal? If you find yourself in the position of having to give away what you once were paid for, how will you make up the lost revenue? I don’t have answers to these questions, but I’m convinced that I need to find some. Maybe sooner than I’d like.

Read More

At last week’s Worldwide Developer Conference (universally referred to as WWDC), Apple gave independent developers a lot to be thankful for. In fact, Apple gave us many of the things we’ve been requesting for a long time – things like app bundles, preview videos in the App Store, better options for beta testing, and App Store analytics. One thing that Apple didn’t give us, though, is upgrade pricing, or the ability to charge owners of our current software a reduced price for the next major version of that software.

Upgrade pricing is a staple of the non-App Store software market, and its absence from the App Store has long been considered one of the biggest obstacles to creating a sustainable software business within Apple’s ecosystem. Wil Shipley wrote the seminal piece on the subject back in 2012, but complaints about the omission of upgrade pricing in the App Store go back much further. It seems clear at this point that Apple has no desire to add upgrade pricing to the App Store, so conventional wisdom has been that developers had better adjust to the new reality and get on with the business of building software.

But Apple may have unintentionally cracked the door to upgrade pricing with one of its announcements last week. In the latest episode of Release Notes, you can hear my podcast co-host Joe Cieplinski wonder aloud at the possibility of using app bundles as a form of upgrade pricing. His comment was off-the-cuff, so the idea wasn’t fully developed, and we both quickly dismissed it, but upon further consideration it appears that it might be possible to simulate upgrade pricing through the use of app bundles.

First, a little background. In the WWDC Keynote, and later in Session 302: The New iTunes Connect, Apple announced that they will soon allow developers to create bundles of their apps. The gist of the information provided is that developers will be permitted to bundle up to 10 of their apps and make them available to be purchased as a group for a reduced price. One of the key features announced about app bundles is that consumers will be able to complete a bundle at a “discounted price” if they already own some of the apps in the bundle. It was never defined what exactly was meant by a “discounted price,” but it seems reasonable to assume the simplest case – that customers will just have to make up the difference in price between the cost of the bundle and the cost of the sum of the individual apps that have already been purchased. For example, if an app bundle costing $14.99 contains two apps, App A (priced individually at $9.99) and App B (priced individually at $9.99), then a person who already owns App A could “complete the bundle” and receive App B at a cost of $4.99.

But what if instead of bundling two different apps, we instead bundled two different versions of the same app, released as two different SKUs? Modifying the example above, what if our $14.99 app bundle contained My App (priced individually at $9.99) and My App version 2.0 (priced individually at $9.99)? That would allow people who owned My App to purchase the new version 2.0 at the reduced price of $4.99, while still requiring new customers to purchase version 2.0 for full price. This is exactly the effect that we have been seeking with upgrade pricing all along!

Using app bundles to simulate upgrade pricing would not be without its pitfalls, though. Bundling two versions of the same app would probably require that the old version remain available for sale individually. This would inevitably lead to customer confusion and probably cause some customers to purchase the wrong item. It seems like this problem could be alleviated, though, by being generous with promo codes (or app gifting) with customers who contact you with problems. Nonetheless, it’s probably desirable to limit the time that the app bundle is available so that the original version can in a timely manner be removed from the App Store and officially discontinued.

While I still hold out hope for genuine upgrade pricing in the App Store, I realize that it’s unlikely to be introduced any time soon. Until that time, app bundles appear to offer many of the advantages of upgrade pricing with manageable disadvantages. I’m hopeful that Apple will not take action to prohibit this type of bundling, and that this type of simulated upgrade pricing will allow more complicated, higher priced apps to find a sustainable market in the App Store. So thank you Apple!

Read More