Skip to main content

I’m developing an app with a feature (that involves a request to the backend) that I would like to allow all new users 10 free uses of. After those 10 uses are used, the user would need to subscribe to a monthly subscription that confers unlimited usage. 

I’ve tried implementing this by keeping track of this on the backend based on the app user id, but it appears that while I can validate whether a given app user id has subscribed to a paid plan, there is no way to prevent the client from faking an app user id (i.e. by reinstalling the app or by directly talking to the backend API with randomly generated app user ids) to seem like a new user and replenishing their 10 uses. Is there a way to get a stable (anonymized?) app store ID that persists across re-installs?

Another approach I’ve considered is making the 10 uses opt-in by requiring the user to start a free trial--but from my research it appears that on the App Store trials can only be time-limited? I’m not sure how I’d implement 10 lifetime free uses (i.e. the trial never expires if the uses are never used), and after the uses are all used require them to upgrade to a paid subscription.

Hey @ishaan,

What’s the current transfer behavior that you use? Your use case could be one for our “Block” behavior - it is stricter, and we don’t recommend it unless an app requires all customers to create an account before purchasing, and has strict business logic that requires purchases to only ever be associated with a single App User ID. But this could ensure that users would always associate their single app user id back to their store account, which would show a previous trial with your app. 

Hi Kaitlin,

We use the default transfer behavior (which is what we want since if a user subscribes to the product, uninstalls the app, and then reinstalls the app, we want them to be able to restore the purchase). What we want is simply a trial that allows them to use the feature 10 times, and after that they need to purchase the product.

We currently validate access on the server by keeping a count of uses per app user ID, but obviously this is easily bypassed if a user simply reinstalls the app and generates a new app user ID (or bypasses our app and talks to the server directly with a randomized spoofed app user ID).

Ideally, we’d like to be able to keep a count of uses per app store account (i.e. the apple ID or google play account), as presumably it would be more difficult for a user to have to create another app store account and would also prevent someone from being able to spoof a random access token for our backend. However, after some research it seems like a stable app store account ID is not exposed to apps.

Given this, do you have any guidance?

Reply


Terms & ConditionsCookie settings