Combatting Ringtone App Pricing Pressure With Application Suites And Shared Pasteboards

I’m self employed, work from home, and earn a living as a blogger. Consequently, I don’t have much of a work-life balance. I’m reading Feeling Good by David Burns to rectify this. It’s basically Getting Things Done meets Life Hacker for mental health.

The book is brimming with, for lack of a better label, workflow/procedures/metrics/instrumentation for feeling good. Every one of these belongs in an app on the iPhone. A couple of examples: The Burns Depression Checklist — 25 questions to calculate a weekly numeric mood score. Mental Biofeedback — golf ticker for daily negative thoughts.

While reading, as part of back of the envelope return on investment calculation, I kept a mental tally of how long it’d take to implement the items. I had a target price for the application in mind; unfortunately, even the most optimistic volume numbers didn’t justify the time investment. Jacking the price up wouldn’t help; it’d price out of the market.

The features shared some common data and felt (pun intended) like they belonged together. Most often, this pairing would be expressed by putting each feature into e.g., individual tabs in a single app. However, most people mix and match the tools they use from the book; so most users wouldn’t use most of the tabs. This would violate the principle having apps with elegant but compact functionality.

So, there were two strikes against doing this work. I was ready to move on and sat down to write an earlier piece on using pasteboards in iPhone 3.0 applications. While writing the piece it dawned on me that I could knock down both problems using a shared pasteboard:

Instead of creating one large app, I could create many and use a shared pasteboard to share data and URL launching to tie them together into a suite.

These apps could each be priced at or around my target price, with maybe one or two for free as loss leaders. Buyers would pick up apps, each more or less with ring tone pricing, as they mixed and matched their way the book. My intuition tells me that this would net at least 3x the revenue over one big app.

Plus, you get more placement (and the resulting sales bump) in the new/updated lists when you stagger your update releases across more numerous smaller apps than the single shot you’d get by updating a monolithic app.

Using Shared Pasteboards

Creating a shared pasteboard whose contents persist when one application closes and another opens take only two lines:

UIPasteboard *suitePasteboard = [UIPasteboard pasteboardWithName:@"suitePasteBoard" create:YES];
suitePasteBoard.persistent = YES;

Thereafter you can use the pasteboard with the same ease that you’d use the system pasteboard. See our article New In iPhone 3.0 Tutorial Series, Part 3: Copy & Paste With UIPasteboard for pasteboard usage.

In-App Purchase

You could use in-app purchase for the same end. Aside from the previously mentioned new/update bump these compare and contrast the two methods:

I wonder about consumer push back on in-app purchase. I already paid you for your app and resent you asking me to pony up again. Separate apps are, well, separate. Plus, I suspect that consumers will expect purchases of non-perishable items (e.g., new features, not poker chips) to be priced well below the initial purchase price; there’s probably more pressure to go to $0.99 here than in the app store.

Using small apps with pasteboards and URL schemes is a loose coupling. In-app purchase is more monolithic. Discuss amongst yourselves whether the overhead of creating, maintaining and getting multiple small apps into the store is easier than creating and updating a large one. There’s probably a second article on this one, but that’ll have to wait for another time.