Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What about Apple's rule that the in app subscription needs to be the same or better than available elsewhere?


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.


Keep your high-priced mobile access plan to yourself buddy!

All of my apps are planned to be free, ad-supported, with in-app purchases.


You could just offer them both in both places. It would be an interesting to see the conversion rates in both environments.


This plan relies on consumers being dumb enough to choose a plan with identical access, but a higher price.


Not necessarily. They'd presumably need to pay the higher price (or some sort of premium) to access the content on their iDevice.


I understood that Apple required that the app and service offer the same subscription plans, so you could not force a consumer to pay a premium (even to cover the 30% fee to Apple). I suppose one could create both plans and prominently feature the iOS one in the app, and the regular plan on the website.


Don't think you need the same plans, just need to make sure that whatever plan is made available through Apple is the same rate as the plan made available through any other channel and that any plan that grants iOS access is made available through Apple. Doesn't mean you can't charge extra for iOS access or have a set of plans that has nothing to do with iOS.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: