How can TestFlight users test a subscription app without renewing the subscription multiple times a day?

I'm working on an app that requires a subscription. Subscription times are drastically shortened in the sandbox, including during TestFlight. This is fine for internal testing, and perhaps during initial TestFlight testing, but for the most part I want my users to be testing the app, not the subscription process. As it is, even a yearly subscription only lasts an hour, and will only auto-renew six times. It's absurd to expect my testers to renew their subscription every day, let alone multiple times a day.


Is there a recommended way to deal with this? It seems like a major oversight. The only good solutions I can think of are:


  1. Offer a one-time purchase to unlock the app for life. I don’t want to make this available on the App Store, but I guess I could create it and just never publish it…? Would that work?
  2. Add a completely custom way to handle this. For example, if the app has an account system users can log into, then accounts could be flagged a being beta testers, and that info could be communicated back to the app. This is a possibility for this app, but I’d like people to be able to test the app without signing in if they prefer. If I require my testers to all use the app in some specific way, it's not going to get tested very well.
  3. Check the receipt URL to determine whether the app is using the sandbox. This seems the most prone to failure since it is not documented and could change. (It also seems the least secure, for example if someone wanted to crack the app on a jailbroken device.)


Another big downside is that either my beta testers spend far too much time testing my subscription code, or they have some way to fully unlock the app and at that point they never test my subscription code at all. Both of these are awful.


Does anyone have a recommendation?

Up vote post of robotspacer Down vote post of robotspacer
3k views
Posted by
robotspacer
Reply
Add a Comment

Replies

Your app is responsible for cutting off a user's access to content/code when the subscription expires. When testing in the sandbox, don't do that.

Posted by
PBK
Up vote reply of PBK Down vote reply of PBK
Add a Comment

Thanks. I got some suggestions elsewhere reminding me that the receipt itself (or the server-side validation endpoint) can tell me if a receipt is for the sandbox. That's a much more secure way to check for the sandbox than just looking at the receipt URL as that Stack Overflow post suggests.


I think that gives me enough to figure out a solution. I'll probably artificially extend the subscription period for sandbox receipts for now—maybe to a week or so. That way my subscription code can get plenty of testing without being a constant hassle. Since I'm doing server-side validation I could potentially even adjust the expiration date from there, making it shorter or longer as needed.

Posted by
robotspacer
Up vote reply of robotspacer Down vote reply of robotspacer
Add a Comment