This is a bug hole in the in-app purchase simulation process. There is no supported way to simulate the cancellation process or to simulate the manage subscription process from a users iTunes app. This limitation also exists with TestFlight version of the app. When you submit the TestFlight build of the app to a user and they test the app, the user account is actually operating in the sandbox environment. You've verified this because the TestFlight app won't appear as a managed app in the TestFlight users iTunes managed subscription section. That's because the app is in the sandbox environment, which the iTunes app knows nothing about.
It's been a while since I've responded on this forum, however, the best means to verifying that the application will handle the auto-renewing process is to verify that the app also handles the detection of auto-renewing subscription renewals via the transactionObserver properly. For example if you purchase a 1 mo subscription in the sandbox environment. Then kill the app, wait 6 minutes, then relaunch the app, does the transactionObserver detect that there is an incompleteTransaction (the compressed one month renewal) to be processed.
This is very similar to what happens in the case that the user restarts a subscription in the iTunes subscription management page. The transaction is recorded by the iTunes store and an incompleteTransaction for the user account / app bundle ID is enabled. When the app starts up and activates the transactionObserver (via a call to addTransactionObserver) the incompleteTransaction is detected and the updatedTransaction delefgate method called to process the renewal. The app can then validate the applicationReceipt to verify that there is now an in_app array item for the auto-renewing subscription item that has an expire_date greater than the current date and knows that the auto-renewing subscription product_id is active.
As for testing that an auto-renewing subscription has been canceled, this again needs iTunes Store server support to simulate. However, receipt validation process works daily and can detect which in_app array item is the most current for the auto-renewing subscription, then detecting if the cancel_date is set tells the app that the subscription was canceled. As a note, just detecting that the cancel_date field for any element can result in a false positive. The user might have canceled an auto-renewing subscription earlier, then decided it wasn't so bad any more and re-purchased the item. For this reason, the logic needs to making sure that the cancel_date field is set in the most current in_app array element to know that the current subscription has actually been canceled. One issue which I'm trying to determine - if a canceled item will have the expire_date moved up to the cancel_date so that an canceled subscription can appear the same as an expired subscription. Seems like the right move - but this information is controlled by the iTunes Store server team.
If you want to pursue a mechansim for simulating these features of the production store environment in the sandbox, I suggest that you submit an enhancement request using the Apple Developer Bug Report web page. Please select the iTunesConnect Product for the bug report, as the suggestion is something for the iTunes Store to simulate, not iOS.
rich kubota - rkubota@apple.com
developer technical support CoreOS/Hardware/MFI
