I have been using a microsubscription model for an MMO strategy game for iPhone/Android that I helped develop. (http://spaceuncharted.com) We charge $1/month or $10/year for access to the full game. Here are some things we've learned:
-- Apple only allows auto-renewing subscriptions for magazines, newspapers and other periodicals. So, for us, users have to re-subscribe every month, which has lead to very poor retention rates. On Android, we use auto-renewing Paypal subscriptions, and have had more success.
-- Having to manage separate billing systems for iPhone and Android adds a lot of development time and headaches. The Apple billing system is particularly time consuming because the errors you get if something isn't configured just right are not helpful.
-- Subscribers can have very high expectations for a service that is costs $1/month. When they're paying, they (rightly) demand a high quality product. We've been very liberal with giving out refunds or credits when bugs have arisen or we've had server downtime.
Is "microsubscription" already the term of art in game development circles? Because I'm talking about a quite different funding model.
If the term is already being used to describe low subscription fees I'll need to thinking of something else.
FWIW, the tech I've lodged with the patent examiners could be extended to cover games as well (and I made sure to write a game in as an example). Single payment/funding scheme for web sites, web apps, phone apps etc is possible.
Edit: some googling sees a multitude of definitions (I wonder why I didn't notice this before?). I guess good names are hard to find.
I can speak from my experience having released an MMO strategy game that runs on iOS, Android, webOS and most web browsers (http://spaceuncharted.com). JQM is far from perfect, but its compatibility has been solid. It was really nice to be able to write the app once, and use Phonegap to have it run on all the phone platforms with only minor tweaks. I originally wrote the game using the WebOS SDK in Javascript, and porting to PhoneGap seemed to be a reasonable thing to do...
On performance, we've found that on older devices, changing pages can be pretty slow, but on more recent hardware it's quite usable. Scrolling hasn't really been a problem except on fairly old hardware, such as the original Pre and some older Android phones.
We did run into one odd problem when overlaying some jQuery Mobile buttons over the HTML5 game canvas because the buttons used css border-radius, which reduced framerates by about half. We were able to switch to custom buttons that used css border-image instead, which had a much smaller impact on the canvas performance. But that really seems to be a bug in the mobile browsers rather than a jQuery Mobile issue.
We've actually taken a pretty homebrew approach and aren't using any external frameworks - just Tomcat and MySQL. On the hardware side we're using Linode shared servers so that we can quickly and easily scale up or down as needed. The game code is pretty efficient - we've run tests with thousands of players and had no problems, on modest hardware, so we're looking forward to growing quickly!
It's true that we've had some stability issues at times, but we're trying to cover a lot of platforms (Android, iOS, webOS, web) and add a lot of new features to improve the game. Now that we've officially launched (on 10/1) stability will definitely our #1 priority, though.
Interesting - since this started as a hobby, any thoughts on open sourcing the client or server code or documenting the client/server communication so the community could build clients? I figure folks would be able to pretty easily reverse engineer it with the web client now, anyways.
-- Apple only allows auto-renewing subscriptions for magazines, newspapers and other periodicals. So, for us, users have to re-subscribe every month, which has lead to very poor retention rates. On Android, we use auto-renewing Paypal subscriptions, and have had more success.
-- Having to manage separate billing systems for iPhone and Android adds a lot of development time and headaches. The Apple billing system is particularly time consuming because the errors you get if something isn't configured just right are not helpful.
-- Subscribers can have very high expectations for a service that is costs $1/month. When they're paying, they (rightly) demand a high quality product. We've been very liberal with giving out refunds or credits when bugs have arisen or we've had server downtime.