What Happens When Apple Features Your iPhone App
blog.return7.com
blog.return7.com
It doesn't particularly matter to me how you explain your business model to your users (although "Boo hoo we have costs and have to feed our children" has always struck me as less persuasive in prying money out of people than "Look at how much value we give you!"). However, as long as we're just developers here, I'd just like to point out that marginal users are too cheap to meter and as long as you're continuing to sell the service there is no reason you can't fund the server costs entirely out of present sales.
Example from my app so you can see I'm not blowing smoke: my VPS costs $85 a month. My users pay $30, once. Suppose, for the sake of argument, that I can tolerate 10,000 users in one day (which is absurdly low given typical peak concurrency for my application, but we're just playing napkin-math).
This means that $85 buys me 300,000 user-days a month. Trial users typically go up-or-out within 3 user-days. Paid users consume less than 5 user-days per month. (Far less in my case but hey, napkin math.)
Assuming I like keeping half of my safe allocation available for trial users (150k user-days or, as seen above, enough to support 50k new trials per month, which is more than 1.5k per day, which is more than 10 times my best day ever), this means that I can support up to 30k paying users on one $85 / month box.
Now, hypothetically, if I were getting 1.5k trials per day, I'd be getting somewhere on the order of 30 sales per day. 3 sales per month would pay for the server. It is clearly sustainable without having to use a subscription model.
I mention this mostly because some users groups are extraordinarily resistant to subscription models and I don't want anyone to feel they absolutely must, must, must price on a subscription if they offer a service.
I'm not intimately familiar with push notifications to iTunes apps but I suspect they require something on the order of one HTTP request. If so, on a per user basis, they're too cheap to meter. I'd (personally) offer them to everybody just to increase the amount of sales I got from the daily gravy train. (Well, to the extent that iPhone sales are driven by features, which I think is pretty darn limited.)
As for push, there are two bits: client<-->server interaction and opening a socket connection to shoot data to APNS to send the notifications themselves. It was pretty fun to get together and really the hardest parts dealt more with business rules than integrating with Apple's service. I would personally have preferred APIs to hook into the phone's calendar app, but push is useful for IM apps and the like, in lieu of background processes.
BTW: Personally, regular payments (especially small ones), do put me off. But I wouldn't mind a prepaid model so much. IE, I pay for a month or six upfront and then pay again to renew. I know this kind of opt-in/out is rarely beneficial to vendors, but in some cases it might work.
There's still an awful lot of the worlds population who earn less than $1 / day.
Otherwise your footing a monthly payment with no return. Also depends on what type of deal your running, people might be more than happy to pay a subscription given that they know the plug won't be randomly pulled on the service depending on future sales.
Good work with this one, and good luck!