Retrieving and Presenting a Paywall Yourself

This does the following:

1. Gets the paywall view controller.
2. Handles the cases where the paywall was skipped.
3. Catches any presentation errors.
4. Implements the delegate. This is called when the user is finished with the paywall. First, it checks shouldDismiss. If this is true then is dismissed the paywall from view before launching any features. This may depend on the result depending on how you first presented your view. Then, it switches over the result. If the result is purchased or restored the feature can be launched. However, if the result is declined, it checks that the the featureGating property of paywall.info is nonGated and that the closeReason isn’t .forNextPaywall.

​

Best practices

1. Make sure to prevent a paywall from being accessed after a purchase has occurred.

If a user purchases from a paywall, it is your responsibility to make sure that the user can’t access that paywall again. For example, if after successful purchase you decide to push a new view on to the navigation stack, you should make sure that the user can’t go back to access the paywall.

2. Make sure the paywall view controller deallocates before presenting it elsewhere.

If you have a paywall view controller presented somewhere and you try to present the same view controller elsewhere, you will get a crash. For example, you may have a paywall in a tab bar controller, and then you also try to present it modally. We plan on improving this, but currently it’s your responsibility to ensure this doesn’t happen.