3

OK I'm working on a app where the user purchases the app from the App Store, gets access to the app for a year, and then after the year has passed they are sent to an In-App Purchase screen where they can purchase a subscription for continued access.

(this is not the subscription model I'd implement if it were up to me, but the client insists that it follow this model)

In order for it to work, though, I need a reliable way to check when the app was purchased, in order to calculate when the first year of access ends. Following the suggestions in one of the answers in...

iOS App Purchase Date

...I've gotten the app receipt and I can find all the data fields that the documentation says there are, but there are also a few others including "original_purchase_date" (not the one in the IAP receipt array; the one for the app receipt itself). This would appear to be what I want. However this field is undocumented.

As far as I can tell, Apple security operates via a form of "Security Through Obscurity/Diversity", so it's been difficult to find further information about these undocumented data fields. My concern is that I might use the data from this field, and then discover that it was only there in sandbox mode and actual receipts don't have it. Worse, what if I reference that field and then Apple releases a new iOS update that completely discards that field from its implementation? Undocumented features are even less reliable than deprecated features, after all.

My question is this: is there a reliable source of information somewhere where I can find out what Apples intends regarding this field? Or better yet, is there another, safer way of achieving the system my client wants?

Community
  • 1
  • 1

1 Answers1

4

You have to implement it as a free app that requires a subscription IAP. Paying for an app cannot be its subscription cost.

Check rule 11.12 here: https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies

Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Program License Agreement

Implementing it the way your client wants will result in rejection.

Almo
  • 14,789
  • 13
  • 64
  • 91
  • 1
    Well that makes my life a HELL of a lot easier - early in the design I thought that it would be easier to do it the way you suggest but they nixed it. Now that I have something to point to to tell them the app will get rejected otherwise. Thanks a lot! – Leo Flaherty Nov 05 '15 at 17:28