My question is not about the programming part, but the UI best-practices for IAP.
Situation: I have a single IAP ("Unlimited version") for my app, where I have a "Purchase" button, which will show inactive and change the text to "Activated" when purchased.
In case of a reinstall, the "Purchase" button would restore directly, which got my app rejected because of "Guideline 3.1.1 - Business - Payments - In-App Purchase" which says in the end, that automatic restores do not comply and a "Restore" button needs to be displayed.
So I added a check for previous purchases when entering the Settings page which is showing the "Purchase" button which will then change the button text from "Purchase" to "Restore". However, this is not instantly (depending on the connection), so this version also got rejected.
Objective: For a seamelss user experience, I didn't want to show both "Purchase" and "Restore" buttons next to each other for a single IAP line. On the other hand, if checking for previous purchases right at app startup, this could raise a AppStore login request (then unrelated to user action), which would also be awkward.
Question: does anyone have experience whether a button showing "Buy / Restore" would be accepted by AppStore Review? Or how do you usually position Restore button? I understand that, for apps with multiple IAPs it makes sense, to have ONE Restore button, but in my case it doesn't look right, because the user must know/decide whether he already purchased the IAP or not (which is completely unnecessary).
Thanks for any advice.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…