On Promotion and Marketing - A Response to Critics of Yesterday’s Article about Unread

Since posting yesterday’s article about the numbers behind Unread’s first year on the App Store, several people have asked me why I didn’t do any promotion for Unread. The answer is that, in fact, I scrounged up as much promotion as I could afford. I did not just naively dump my app on the App Store and expect the bucks to start spilling through the mail slot.

Here’s a list of the promotional activities supporting Unread (both iPhone and iPad), either directly by me or through good fortune:

Did Unread already have a significant amount of competition on the App Store? Yes. But I defy you to name a category on the store that doesn’t already have lots of competition. Could I have done a better job of marketing my app, use different screen shots, etc? Perhaps.

Arguments that I naively built and marketed an RSS reader in 2014 aren’t relevant to the heart of my article. Any polished app — in any category, with any amount of marketing or promotion — is a lottery. Increasing the marketing budget is just as likely to increase the potential losses as it is to increase potential sales. Each niche is an apple or an orange. It’s all a gamble.

The lesson to be learned from Unread is that even if you keep your costs low and your quality high, the immense scale of the App Store — 100 million credit cards — is deceptive. From the outside one might assume that an indie dev with a quality product could “fail” her way to a sustainable paid-up-front app business. The reality is that App Store sales patterns rarely support such a developer. True fans will buy her quality app within the first few days, then never give her any money again. The rest of her time will be spent trying to convince a few more users to become true fans, repeating the same short-lived, one-time purchase until she goes out of business.

|  July 29 2014




Tyler Hall’s Candid Look at the Financial Side of Building Mac Apps

Tyler Hall responds to my post from earlier today about the financials behind Unread:

Well, it’s my experience that you CAN build a sustainable software business selling to consumers as an independent developer. You just can’t do it in the App Store any longer – if you ever could.

You need to start building for the Mac, where you can charge a fair price, sell directly to your customers, and charge for upgrades. Even then, success won’t happen overnight. But it is doable.

Also, Mac sales are up 18 percent year-over-year, while iPad sales are down. It looks like the Mac isn’t just sticking around. It’s thriving.

|  July 28 2014




A Candid Look at Unread’s First Year

To my knowledge, indie developers don’t publish the kind of numbers that you’ll find in this post. My sales records are none of your business, as the saying quite literally goes. The question in your mind will no doubt be why am I writing this at all? It’s a fair question. Before I answer it, allow me to first dismiss all the unsavory reasons some readers might unfairly concoct. This is not a public whine session. I am neither a victim nor a failure. As these things go, I have been very fortunate with Unread. I have nothing but gratitude for everyone who supported me with their blog posts, tweets, pats on the back, and — above all — with their hard-earned cash.

My intention is to share the dirty details of Unread’s story with my colleagues. I especially hope that this post is useful to anyone who is considering striking out on her own, as I did last summer. Unread will no doubt be a cautionary tale for some. For others, it might be an inspiration to one-up what has been my personal best effort, proving what opportunity may still lie in the indie app market.

At the very least, I think you’ll come to agree with these takeaways:

Blood, Sweat, and Tears

I began work on Unread at the beginning of July 2013. I spent about six weeks on the overall design of the app, then plunged headfirst into Xcode, not coming up again for air until the following spring. I estimate that I worked sixty to eighty hours a week every week from July 2013 up until the launch of Unread for iPhone Version 1.0 in February 2014. Along the way were many challenges: building custom user interface navigation and controls, a vast sharing library, syncing and persistence architectures, performance tuning, etc.

Here’s what the Github punchcard looks like for Unread’s main repository:

My marriage and mental health suffered a lot because of that punchcard. I worked on Unread seven days a week, at almost any hour of the day. I think the quality and polish of Version 1.0 is due to all that extra effort, but it was physically and emotionally taxing. It’s not a sustainable way to live, and I don’t recommend it. However, if I had adhered to a saner work-week, Unread would have taken a year to finish and might not have launched at all.

Launch Week and Marketing

Thanks to the generous support of many independent writers — Federico Viticci, Shawn Blanc, Stephen Hackett, and others — Unread had a great launch week. If you use RSS or Twitter to read about what’s new in the iOS world, chances are good that you saw it mentioned once or twice.

After a huge spike in sales the first day, sales dropped in what is (to my knowledge) a typical launch week curve for iPhone apps. The week after launch, Unread was featured on the main page of the App Store. This feature did not lead to a spike in sales. Rather, it kept sales from dropping any further for that week, then tapered off. I conclude from this that an App Store feature may not be as helpful as positive, prominent reviews from influential writers.

Cumulative iPhone Sales

Here is a graph of cumulative iPhone sales, from launch to the present. The orange dotted line is the averaged trend line:

Here are the highlights from this graph. Note that these numbers are after Apple’s 30 percent cut and before I’ve set aside a portion for self-employment taxes and healthcare premiums:

Half of the lifetime sales of Unread were generated in the first five days1. It would take another 170 days (24 weeks) to generate that same amount again.

Unread for iPhone Version 1.2

Unread’s biggest mid-run spike accompanied the launch of Version 1.2 for iPhone. This was a huge update with lots of new features: two new RSS services, an image viewer, a quick way to jump between articles, etc. Version 1.2 was released on April 21st, nine weeks after the previous update.

It’s difficult to assess how much money Version 1.2 earned by itself. A close approximation might be to determine the cumulative sales between the launch of Version 1.2 and when the sales trend line returned to the previous average trend. By my estimates, this happened around May 4th, about two weeks later. That would mean Version 1.2 earned about $4,000 extra in sales, plus or minus $1K.

Since it took two months to develop, Version 1.2 earned me around $2,000/month in sales. Subtracting 40 percent for self-employment taxes2 and a $350 health care premium3, my take-home pay for that work was about $850/month.

Cumulative iPad Sales

In the interest of brevity I won’t go into detail about Unread for iPad. Here is the cumulative sales graph to date:

Suffice it to say, so far it looks like a scaled-down version of the Unread sales history:

The Bottom Line

Unread for iPhone has earned a total of $32K in App Store sales. Unread for iPad has earned $10K. After subtracting 40 percent in self-employment taxes and $350/month for health care premiums (times 12 months), the actual take-home pay from the combined sales of both apps is:

$21,000, or $1,750/month

Considering the enormous amount of effort I have put into these apps over the past year, that’s a depressing figure. I try not to think about the salary I could earn if I worked for another company, with my skills and qualifications. It’s also a solid piece of evidence that shows that paid-up-front app sales are not a sustainable way to make money on the App Store.

Conclusions

There are lots of things that I haven’t tried with Unread. I haven’t done any major promotions I tried several forms of promotion, for example $400 worth of promoted tweets on Twitter, coinciding with the launch of Version 1.2.4 I could have tried more. I haven’t added any in-app purchases or subscriptions, either. But Unread is a good test case nonetheless, for the following reasons:

Despite all of these circumstances, Unread still only earned $42K in sales ($21K after taxes and expenses) and is on a course that doesn’t promise much growth. I conclude from all this that anyone who wants to make a satisfying living as an independent app developer should seriously consider only building apps based on sustainable revenue models. I suspect this means through consumable in-app purchases, like those in Candy Crush Saga or Clash of Clans, or through recurring subscription charges, like those in WhatsApp. Furthermore, I have grave doubts that any solo developer would have the capacity to ship and maintain either kind of business working alone. She would probably have to consolidate her business with other indie developers in the same position. The marketing budgets of the major competitors makes me doubt that even a consolidation strategy is tenable.

Update – On Promotion & Marketing

Since posting the above, several people have asked me why I didn’t do any promotion for Unread. The answer is that, in fact, I scrounged up as much promotion as I could afford. I did not just naively dump my app on the App Store and expect the bucks to start spilling through the mail slot.

Here’s a list of the promotional activities supporting Unread (both iPhone and iPad), either directly by me or through good fortune:

Did Unread already have a significant amount of competition on the App Store? Yes. But I defy you to name a category on the store that doesn’t already have lots of competition. Could I have done a better job of marketing my app, use different screen shots, etc? Perhaps.

Arguments that I naively built and marketed an RSS reader in 2014 aren’t relevant to the heart of my article. Any polished app — in any category, with any amount of marketing or promotion — is a lottery. Increasing the marketing budget is just as likely to increase the potential losses as it is to increase potential sales. Each niche is an apple or an orange. It’s all a gamble.

The lesson to be learned from Unread is that even if you keep your costs low and your quality high, the immense scale of the App Store — 100 million credit cards — is deceptive. From the outside one might assume that an indie dev with a quality product could “fail” her way to a sustainable paid-up-front app business. The reality is that App Store sales patterns rarely support such a developer. True fans will buy her quality app within the first few days, then never give her any money again. The rest of her time will be spent trying to convince a few more users to become true fans, repeating the same short-lived, one-time purchase.


  1. Unread launched at an introductory price of $2.99 USD. I rose the price to $4.99 two weeks later. In retrospect, I think I left a lot of money on the table. Demand was never as high as that first week. I should have priced Unread accordingly. If I had launched at $4.99 and got the same amount of downloads, I probably missed out on an additional $16K in sales. Eep. 

  2. This seems ridiculous to anyone who hasn’t been self-employed, but it is absolutely the reality. In addition to regular federal and state income taxes, self-employed people have to pay the full amount of FICA taxes — 15 percent of income. If you work for a company, your employer pays half of that 15 percent over and above what you actually earn. Since I live in Indiana, my income taxes total around 40 percent of my income. 

  3. For me and my son, both of whom have no major medical conditions. I have mild asthma and seasonal allergies. 

  4. Which means my take-home pay for those two months working on Version 1.2 is, in effect, $650/month. 

|  July 28 2014




JTSActionSheet – Simple, Customizable Replacement for UIActionSheets on iPhone

If you’ve spent any time working with UIActionSheet, then you’ve probably bumped up against some of its frustrating API limitations. My new open-source replacement, JTSActionSheet, will help you if your project has any of these requirements:

Check it out on Github. Feedback is welcome. The above screenshots are both made with JTSActionSheet. It will be a significant part of my next iOS app, code named “Time Zones.”

|  July 25 2014




Shawn Blanc’s Delight is in the Details – New Version has an Audio Interview with Yours Truly

It’s 2014. Books you already own can be updated with new stuff, which is awesome. If you own Shawn Blanc’s Delight is in the Details, there’s a new version out today with new chapters, videos, and audio interviews.

Shawn invited me to record an audio interview for this new update. I’m really satisfied with how our conversation turned out. Give it a listen if you’d like to hear me speak candidly about my creative upbringing, healthy shame, and how the sausage gets made when I’m working on an app.

If you haven’t read Shawn’s book already, there hasn’t been a better time to buy it. As a person who does creative work, I found it simultaneously challenging and reassuring.

|  July 23 2014




UIFontWeightTrait Ignored When Creating a New Font – TextKit Bug or a Jared Goof?

Given the following code and a device running iOS 7.1 or later:

 NSDictionary *fontTraitsDictionary = @{UIFontWeightTrait : @(-1.0)};
 NSDictionary *attributesDictionary = @{
                                       UIFontDescriptorFamilyAttribute : @"Helvetica Neue", 
                                       UIFontDescriptorTraitsAttribute : fontTraitsDictionary
                                       };
 UIFontDescriptor *ultraLightDescriptor = [UIFontDescriptor fontDescriptorWithFontAttributes:attributesDictionary];
 UIFont *shouldBeAnUltraLightFont = [UIFont fontWithDescriptor:ultraLightDescriptor size:24];

 NSLog(@"%@", shouldBeAnUltraLightFont);

I would expect the value of shouldBeAnUltraLightFont to be an instance of HelveticaNeue-UltraLight, but instead it is:

<UICTFont: 0x908d160> font-family: "Helvetica"; font-weight: normal; font-style: normal; font-size: 24.00pt

I am following the Apple documentation as far as I understand it. Why is the font family and font weight information completely ignored?

Things I’ve Tried

Here are some of the things I’ve tried:

Regardless of these changes, the font returned is always a vanilla instance of Helvetica at normal weight. The only exception is when I remove the UIFontDescriptorTraitsAttribute key/value pair from the attributes dictionary. This results in a 24-point, normal-weight instance of whatever font family I specified.

Things I Can’t Use

Why This Matters

A design calls for an ultra-light system font, which in practice should be an instance of Helvetica Neue UltraLight. I could manually specify something like this:

font = [UIFont fontWithName:@"HelveticaNeue-UltraLight"];

The problem with this approach is that it’s prone to errors. When iOS 7.0.3 was released, Apple quietly renamed all the Helvetica Neue italic font filenames, which broke a lot of apps that were manually specifying the old font names. So I need a solution that is resistant to future errors of this kind, but still allows me to get a specific weight of a system font.

I’ve cross-posted this to Stack Overflow if you have an answer.

|  July 23 2014




Why are Inflation and Deficits Bad?

My old college friend, writer and philosopher Adam Kotsko, on the misleading common rhetoric about defecits and inflation:

A disproportionate amount of political debate centers around vague abstractions: government spending, deficits, and inflation. The latter two are supposed to be particularly horrible, leading to hyperinflation (and therefore Hitler) or else mountains of debt that are impossible to pay off (and therefore Hitler).

A moment’s reflection will reveal that these three technocratic abstractions are actually code words for “stuff that makes rich assholes powerful.”

|  July 11 2014




Birthday Cake M&M’s – The Dawn of a New Era

I tried Birthday Cake M&M’s for the first time tonight, and they are far stranger than I had expected. I had assumed that, like their Peanut Butter or – crucially – their Pretzel forbears, each candy piece would contain a morsel of actual cake. The truth is that Birthday Cake M&M’s are concocted to taste like fake processed chocolate cake – an artificial artificial flavor.

I’m tempted to cite the Jelly Belly’s Dr. Pepper jelly bean as a precursor, but that’s merely intended to amaze the customer with a feat of flavor science. In contrast, Birthday Cake M&M’s take food engineering as a given, presenting the (synthetic) synthetic cake flavor as an end in itself. Birthday Cake M&M’s assume that the customer already craves artificial chocolate cake for its own sake, not because it tastes like a slice of Real™ chocolate cake (which it doesn’t).

In the ontology of Birthday Cake M&M’s, it isn’t:

artificial chocolate cake flavor

but instead:

artificial chocolate cake flavor

It’s essential to point out that artificial chocolate cake flavor cannot exist independently of Birthday Cake M&M’s. On the contrary, it is Birthday Cake M&M’s that bring artificial chocolate cake flavor into being, as a pond ripple is born from a stone.

Birthday Cake M&M’s shift the boundary between the real and the artificial forward by many millenia. It’s as if everything that came before artificial chocolate cake has now been blessed. Agricultural advancements, technological innovation, manufactured goods, indeed the whole of human ingenuity, have been adopted into the family of the real – at least up through the point in human history that cake mix started shipping in a box.

Thus, through the second-order synthesis of the Birthday Cake M&M, the first-order synthetic is no longer distinct from what is genuine. The synthetic is synonymous with the real. Technology is nature, and vice versa. The Buddha is at home in a Xanax bottle.

A new era has dawned.

|  July 11 2014




“The Best of Both Worlds” – Yours Truly on CMD+Space

I was a guest on today’s episode of Mike Hurley’s CMD+Space podcast. Check it out if you’re curious about my thoughts on the past and future of App.net, the strategy behind the design of Unread, and my feelings on the decline of the indie iOS software business.

|  July 03 2014




They Make Such Bloody Good Cameras

The iPhone makes it so easy to feel like a great photographer. The following photo was made in two steps: a quick one-off shot straight from the lock screen camera, and a VSCO Cam filter (with a minor crop).

My wife and son.

This is one of the best photos I’ve ever taken, and it took less then sixty seconds to shoot, edit, and share it. Here’s the untouched original:

Untouched original.

Bravo, Apple.

|  July 02 2014




I Love Teleportation - A Summary of a Wishful Day

|  July 01 2014




I Hate Flying – A Summary of Our Day:

Nota Bene – If you are one of the many people expecting to meet with me in person or over Skype tomorrow, my apologies for probably missing our appointment.

|  July 01 2014




OvershareKit to be Maintenance-Only for iOS 8

Last fall, after I had finished the model controller layers of Unread, I felt a pit in my stomach. The next big task in front of me was sharing. I knew I wanted Unread to have lots of sharing options, but I dreaded writing them. I had already written tons of them in the course of making Riposte for App.net. Great sharing features are non-trivial to write. It’s even harder to make them reusable (Riposte’s were not). There are many concerns to think about:

There was no way to tackle all of these issues within the limitations of UIActivityViewController on iOS 7, which is why I decided to make OvershareKit. You can read the reasons in detail on OvershareKit’s Github page, but here are the highlights:

Those are just a few of the reasons why I decided to build something like OvershareKit for Unread. Justin Williams was in a similar position with his projects around the same time, so we decided to integrate his code for managing system accounts into the broader framework that I had conceived.

Bear in mind that at the time OvershareKit was being developed, it was still unclear whether Apple would ever provide better inter-app communication and sharing APIs. After seven OS’s, it was easy to believe that Apple frankly didn’t care. I was frustrated by their lack of concern, and dissatisfied by the lack of an open-source framework to bridge the gap. It was my hope that OvershareKit would become more than just a pet project between me and Justin.

But now that the iOS 8 developer preview is here, with its powerful Extensions APIs, what should be done about OvershareKit? Extensions are Apple’s answer to the problem that OvershareKit was created to solve. It seems to me that it’s better for all involved – both developers and users – for any app that’s using OvershareKit to migrate to Extensions and the UIActivity frameworks.

OvershareKit is now an unnecessary middleman between users and services like Pinboard and Instapaper. Almost any service that users want to access via OvershareKit already has great first- or third-party apps on the App Store. The burden of responsibility should belong to them to provide great sharing features via iOS 8 extensions.

I think this should apply to all future OvershareKit development, too. For example, many of Unread’s customers ask for Evernote support. Evernote has a rich and complicated API. It doesn’t make sense for outside developers like me to spend limited resources building support for Evernote. I want Unread to have Evernote, but the costs outweigh the benefits. It’s a sacrifice I was willing to make back when Apple provided no alternative. But now that Extensions are coming, the math has changed.

I don’t plan on adding any new features to OvershareKit. I will make sure that all of its existing features continue to operate bug free on iOS 7 and iOS 8. It may take several months (or longer) for extensions to be developed for all the services that OvershareKit currently supports. In the interim, I want to be sure that apps like Unread can continue to rely on OvershareKit.

If you have an app or service you can’t live without, I urge you to write to its developers and ask them to consider adding support for UIActivity extensions in iOS 8.

|  June 27 2014




Preferred Orientation

I’m pretty sure the following generalization is true, with few exceptions: every iPad app has been designed for a preferred orientation. I think this is true whether the designer was conscious of the preference or not.

iOS lock screen, awkward in landscape.

I’m not saying that the non-preferred orientations are poorly designed, nor am I saying that they’re not useful. I mean only that every iPad app has an orientation in which it looks and works best – the way we say of a person’s appearance that he or she has “a good side.”

Here are some examples, off the top of my head:

Landscape

Portrait

Notable Exceptions

|  June 26 2014




Happy Birthday, Henry

The boy turns one year old today.

Happy Birthday, Duders.

|  June 26 2014





Links