@tbel do your payments succeed tho on testflight? Or does just nothing happen?
After going through the password / touch id flow it should take a while (5 sec) for a dialog to pop up with ‘the purchase was successful’.
Create is fine for the log
Those docs are for a future update of the IAP component but that’s not something that’ll help if you get rejected at review. Sorry for the confusion.
I think the bottom line is that the reviewer can’t get a successful purchase on production. If we can somehow recreate this on testflight we’ll be able to see the error.
Could you invite me to your testflight (if you want)? I’ll send you a DM with my email.
I managed to generate an error “E_UNKNOWN” Not very helpful I know hah.
My recent build is set to Non-Renewing Subscription this time with a new Product_ID, and of course this works flawlessly in TestFlight.
Hey tbel, thats very interesting. Usually non-renewing subscriptions require a restore button (which adalo doesnt support).
As you have said above, it really depends on the reviewer. I had a situation where I loaded my app onto the appstore on different apps with non-renewing and sometimes it is accepted and sometimes not accepted as some reviewers request specifically the “Restore Button” which Adalo doesn’t currently support. I found that consumable usually work without issue.
Thx! And yeah could be the reviewer. However during my testing when using non-renewing, I was actually given the option to restore my previous purchase, so this might’ve changed?
The modal came up when I repurchased in TestFlight, it wasn’t implemented by me, so I’m not 100% which end is in control. This however may only be in TestFlight, I have no way in testing in production without purchase for realz
I have just re built another testflight, and I am testing this with a non-renewing subscription. It does yes recognise that you have purchased the subscription in the past. But obviously it doesn’t recognise if it is expired as the Plan End Dates are not handeld within the iAp, only on the Adalo database. So It will be interesting to see if this satisifes the Apple Review Process. My main fear for this workflow is that the user must click “Subscribe” then Sign in, before they will know if they have or havn’t purchased the subscription in the past, some may feel this is a step to close to “repurchasing” it again as opposed to a simple check if they have or haven’t purchased in the past. I am going to resubmit to apple and see if this satisfies their review process. Previously I tailored the purchases to consumable, calling it “credits” or something similar.
For me this documentation references a toggle or a mode that we cannot access or change/toggle?
@Experts@ben1@adalojosh can any of you guys clarify this? As far as I can see, I do not think the Digitial iAp is set up to restore non-renewing purchases correctly as per Apples Guidelines, from experience, it’s completely hit or miss whether Apple will approve the non-renewing subscription or not. I’ve had it accepted once, but refused three times on 2 different apps, applied very similarly. All relating back to restoring purchases.
Can anyone clarify this “restore mode” or “toggle” thats being referenced?
@tbel So I resubmitted again with the non-renewing iAp after it failed several times. This time it was accepted, and I think I can give some indication as to why it passed this time and not before. Some requirements I gathered from the process to improve your chances of approval. I know you already got yours approved @tbel so the below is to shed some light on improving the likelyhood of passing for others reading this post.
You can use both iAp Consumable and Non-Renewing. But be careful using consumable for subscription type purchases.
The iAp Consumable cannot be used to deceive the customer or mislead the customer to make it feel like a subscription when it is not.
Apple need to see a list of “Subscriptions” that your app offers, and a list of Subscriptions the logged in user has purchased. So you are best clearly having two lists for the logged in Users, such as “My Subscriptions” (Filter these by the subscriptions the user has bought) & “All Subscriptions” (Filter these by the subscriptions the user has not bought)
For the “All Subscriptions List” set up your iAp Purchase button, and update > logged in user > add current subscription. Name the button something like Subscribe, Purchase or Buy. Clearly define what is being bought, duration, and what it unlocks. Be sure to update the iAp metadata with a screenshot for their review and for the store promo iAp image.
For “My Subscriptionsc List” i.e. the ones the user has purchased successfully there’s a couple of things that were important for Apple review process:
5.1. Clearly define when the subscription is due to end.
5.1 Clearly rename the Adalo iAp button with “Restore/Renew” NOT buy or purchase. As this product should be in the users previously purchased list, we know that it will also be recognised for the Apple Users account based in the iAp ID that they purchased in the past.
To be double sure, I added the same purchased list into the users settings page, and a clearly defined “Plan End Date”.
A tutorial on this would be highly beneficial.
But in short, non-renewing subscriptions are possible. If you stick with something similar to the above.
If you are wondering how to set up a subscription type model in your app without waiting on the Auto Renewing Subscription iAp component this is a proven solution below that I set up in mine.
Set up an action when a user arrives to the home screen which will redirect (sometimes) if the current users plan end date is before current date.
If the user end date has passed they will be redirected to the paywall where I have set up to allow the user to purchase +60 days from today. +90 days +180 days etc…
When the iAp google/Apple payment is successful, I update the current user end date by +60, +90, +180 days from current time (today).
This checking process will then make the user hit a paywall to then manually purchase more days/credits.
To add a trial of 14-30 days, when a user signs up I set user end date by +14 or +30 from today.
Hope this helps, someone, as it’s very easy to give up ! Consumables are easy to get passed usually for non subscription type purchases, like unlocking a feature, or work out, or training plan.
This is precisely what I did, the text states how long it’s for and when they user “purchases” I print out their end date (in my case 30days) on purchase and in their profile page.