It seems to me that the simple way is pretty much what the grandparent described. Classify API/mobile access as a value-add and charge extra for it.
For a web-based SaaS, I could see them doing something like "Web-only access including mobile web, $10/mo" and "Web + native mobile/API access: $15/mo" -- then only offer the latter option in-app.
I suppose you could try to classify Android and iOS API access differently, but I suspect that might be a little over the line in terms of trying to slip it through the app store review process.
I do still wonder how third party apps to hit a subscription API are going to work, though. I suppose a lot of those will be for-pay so Apple gets their vig from that anyway, but it's always possible someone will decide to release a free one...
Another way: have entirely separate accounts for mobile access. If you have access to both a web-interface app account and a mobile app account, they can be "linked" such that the data is synchronized between the two. This would also be the only way mobile accounts could share data with non-mobile accounts.
This would work for apps where the mobile UI is only an adjunct for doing real work on the desktop version.
Keep your high-priced mobile access plan to yourself buddy! Or at least keep it with iDevice users. Us Android folks have gone with a corporate parent that doesn't abuse us or our vendor friends.
For a web-based SaaS, I could see them doing something like "Web-only access including mobile web, $10/mo" and "Web + native mobile/API access: $15/mo" -- then only offer the latter option in-app.
I suppose you could try to classify Android and iOS API access differently, but I suspect that might be a little over the line in terms of trying to slip it through the app store review process.
I do still wonder how third party apps to hit a subscription API are going to work, though. I suppose a lot of those will be for-pay so Apple gets their vig from that anyway, but it's always possible someone will decide to release a free one...