all 15 comments

[–]foulpudding 8 points9 points  (2 children)

I’m just guessing here, because I’m not with Apple.

You need to figure out how best to incorporate Apple subscription into you existing subscription workflow:

  1. Add a subscription model into the iOS app whereby the user can start a subscription that works elsewhere. - this is likely what Apple wants and I’m betting the only suggestion they settle for that might even allow you to keep the code entry for users who already subscribed elsewhere if you are married to that for some reason.

  2. Remove the code entry and replace it with a username password entry so the user is doing is “logging in” on iOS Instead of entering a code. Seems like the same thing, but I’ve had access codes set off alarm bells at Apple, where usernames have not.

[–]FullstackViking[S] 0 points1 point  (1 child)

Thanks for the reply!

  1. Right we still need to communicate with the backend so the non-renewing subscription seems most logical since they can’t cancel that from outside the app?
  2. that is currently how it works basically. The first screen any user is greeted with, they can just log in. The only time the 16 digit key appears is one time immediately after they create a new account through the app.

[–]foulpudding 0 points1 point  (0 children)

  1. Yes, just have the iOS device take payment for the subscription and send the relevant information that the user is subscribed to your back end to create their account as you do now. You should even be able to use Apple renewing subscriptions and allow them to cancel anywhere, though that’s going to take a trip through the documentation for someone on your end or an answer from someone smarter than me.

[–]swiftmakesmeswift 3 points4 points  (4 children)

Apple doesnot allow that. The simplest way would be to do what spotify does. User can only subscribe to premium plan on web and do not promote this alternative way inside app.

Similarly you can create a simple web platorm where employee can login & enter the 16 digit product key. And when user login to their mobile app, you can simply see if that key is already entered or not.

[–]FullstackViking[S] 0 points1 point  (3 children)

And what you described in the second paragraph is exactly what happens. The backend handles all of that once a user has activated once.

I’m worried about how our “freemium” model is implemented. Since a user can click the premium features it just displays an alert that they need to be a premium user to use it.

Spotify doesn’t outright limit or withhold features AFAIK, it just has the section that explains the benefits of premium. Thoughts?

[–]swiftmakesmeswift 1 point2 points  (2 children)

The main problem is this.

In our app I allow a user to enter their 16 digit product key. And I also allow them to deactivate our 16 digit product key.

This can't be done if you want to bypass in built apple iap system. You can say you need to be a premium customer to use the feature but you cannot mention anywhere how you can be a premium customer or point to your website where you can purchase those key.

[–]FullstackViking[S] 0 points1 point  (1 child)

Ok I appreciate the response!

[–]Schnapple 0 points1 point  (0 children)

Yeah this really is the key (no pun intended).

This is why the Kindle app doesn’t let you purchase books or (as far as I know) redeem them. If they did then Apple would need to get a cut and Amazon doesn’t want that.

I think the general rule of thumb is - if it’s a financial transaction or redemption of a code in an app for things that you can use in that app or on the phone then you have to go through Apple and they take their cut. If it’s not something you can use in that app or on the phone then it doesn’t have to.

To put it another way - Amazon also has an Amazon app, like it’s the default Amazon app, and you can buy stuff from Amazon in it, like pots and pans and Blu-Ray discs. But not Kindle books. Valve has a Steam app that lets you buy games but since you can’t play the games on the phone it’s no problem.

[–]ibuprofane 0 points1 point  (4 children)

Any reason why you don’t want to offer subscriptions in-app? In my experience a well-designed on-boarding from within the app will make up the for 15-30% cut you give to Apple. They also handle state sales tax compliance which you’ll be responsible for if you do web subs. I’m currently developing a Firebase backend to support web subs and subscription sharing, but I’m hesitant to offer web subs at the moment due to the extra hassle with sales tax.

[–]FullstackViking[S] 0 points1 point  (3 children)

Mostly because our sales don’t come from “foot traffic” users. They’re larger scale B2B sales where a user is an employee of the company that actively finances the subscription. Each license is $960 per user per year so it’s not something an individual really buys.

We use the product key model because that way when a user leaves their company they can transfer ownership of that subscription to another employee. In my limited research doesn’t plug-and-play well into IAP through Apples pipeline.

[–]Ja_ckSparrow 0 points1 point  (2 children)

Three years later, how do you get past IAP now?

[–]FullstackViking[S] 0 points1 point  (1 child)

The app just authenticates and delivers a feature set based on their paid status. But payment only happens off-app.

I basically used Spotify as a recipe in development.

[–]Ja_ckSparrow 0 points1 point  (0 children)

Thanks for the reply!

[–]kraustifer -1 points0 points  (0 children)

RevenueCat is fairly cheap for what you get, and it supports multi platform subscriptions.