Combatting Ringtone App Pricing Pressure With Application Suites And Shared Pasteboards

On July 29, 2009

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.

0 responses to “Combatting Ringtone App Pricing Pressure With Application Suites And Shared Pasteboards”

  1. I like the idea of separate apps, it creates the idea of ‘one app one task’ and with the speed of the iPhone 3GS it’s not a hassle to switch apps (with my original iPhone I dreaded it.)

    The in-app purchase route is interesting, however I think that you are right in saying users will see it as a rip off to have to pay for more features, App Store shoppers are already thrifty as it is.

    Thank you for this article. I was planning on doing one app with two loosely tied together features, but it may be much better to do it as separate apps that talk to each other.

  2. Cavendish McKay says:

    I’ve read Burns’ book, and I agree that it’s chock full of diagnostic and treatment tools which would work well as apps. However, it seems pretty clear to me that these tools are Burns’ intellectual property, and that he views them as such. After all, he sells a “Therapist’s Toolkit” which includes licenses to reproduce these (and other) tools.

    While your post dealt more with technical details, the question of licensing does affect the economics. I’m curious: how do you, as a self employed blogger/developer, approach this issue?

  3. Dan Grigsby says:

    Cavendish: Mostly I implement my own ideas; then it’s not an issue. In this case, I wrote Burns and asked about working together. I’m not shy about partnerships and business development. We’ll see if anything comes of it.

  4. pTracker says:

    This is a great idea, Dan. I have been considering something similar for my apps (many of whom are still only in my head).

    In a similar vein: as one of my apps is a “tweet reader”, and thus not a full-featured twitter client, and I want to keep it that way for simplicity/focus/price/etc I have been wondering about partnering with an established twitter client app developer, so my users can do something with a tweet they find in my app, by “passing” it to their twitter app. Either that or write my own twitter client that would interface with the various tweet readers I plan to make.

    One gotcha I see is that there needs to be a way to know if the other app is on the device. If there’s no possiblity of carrying out action X on another app, the button for it should not appear in the original app. Or, the button is there, but directs the user to download the missing app. Is there a way to programatically discover the existence of other apps?