User Profile

Hi, We're looking at creating an app that allows tutors to purchase a subscription, via the app, that gives their students access to various educational content. The app would be free to download. Tutors could set up a tutor account. An in-app auto-renewing subscription would allow the tutor to pay for a certain number of student logins, which they could set up themselves within the app and that would be stored in our own database. A student with an account could sign in to the app without having to pay anything. If the tutor cancelled their subscription via the App Store, our database would be updated and the students would no longer be able to login. All seems pretty straightforward, but... We want the app to be cross platform. Which means, in theory, a tutor could pay for their subscription on any platform and students could access the content they were creating / sharing on a different platform. Concern is that would contravene Apple's guidelines on payment. From the Apple guidelines: "3.1.3(c) Enterprise Services: If your app is only sold directly by you to organizations or groups for their employees or students (for example professional databases and classroom management tools), you may use purchase methods in addition to in-app purchase to collect those payments. Consumer, single user, or family sales must use in-app purchase." Tutors presumably don't count as "organisations" so I'm struggling to think how we can achieve what we want, whilst ensuring we don't step outside Apple's guidelines. There is no way any tutor can guarantee all their students are Apple users... Does anyone have any experience with building a system that worked in this kind of way and if so, any advice on how you approached it would be really helpful. Thanks.

Hi, We are intending to offer various non-renewing subscriptions for a year's membership to our app. Each subscription would buy a number of users access to our service. For example: Up to 5 users = £19.99 per year Up to 50 users = £149.99 per year What I don't understand, is what happens if somebody purchases the first option, for 5 users and then immediately upgrades to the second option, for 50 users. The logic I've seen in the documents seems to suggest that with non-renewable subscriptions, there isn't really an option to "upgrade" as such and that we actually treat this as a second subscription, running back to back, meaning that we would add another year onto the end of the existing year and the user would have nearly 2 years worth of subscription. But we want the functionality offered by the upgrade to kick in immediately and to be able to charge the user for that increased functionality, not to have charged them for a year of 5 users and then a year of 50 users when what they would presumably get is 2 x years of 50 users. Is this just one of those loopholes that users could exploit or is there a way to handle this elegantly? The obvious approach would be to calculate how long the user has left on the current subscription and then charge them an upgrade fee to cover the remainder of the existing year, but the problem with that is that we can't submit "on the fly" amounts to the App Store for in-app purchases or subscriptions - all in-app products have to have a price registered beforehand. Auto-renewing subscriptions for shorter periods are much easier - we can take the hit of someone having increased access for a month for example if it means they are then paying a higher cost moving forward, but to do so for a whole year is a lot of free access. Any ideas / anyone who's done this before with non-renewing subscriptions, I'd massively appreciate any advice. Thanks! Ian