Hiya guys, so I’ve been going back and fourth trying to get my app approved in the Apple AppStore but I finally hit a roadblock as this part is a bit beyond my level of experience. Would anyone here be kind enough to lend me a hand? I’m so close, this is the last bit before approval it looks like.
We found that your in-app purchase products exhibited one or more bugs when reviewed on iPad running iOS 14.7.1 on Wi-Fi.
Specifically, we were still unable to complete in-app purchase.
Next Steps
When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code “Sandbox receipt used in production,” you should validate against the test environment instead.
Resources
You can learn more about testing in-app purchase products in your development sandbox environment in App Store Connect Developer Help.
Hiya, guys so I really could use some help here, even after a few days cleaning up what I thought they were looking for I still got rejected due to the Guideline 2.1 error.
Surely someone here can help me get over this hurdle? I’m at a lost at this point, and it’s the only thing holding up my app approval.
Hiya guys, I’m really beginning to lose hope here, I’ve been at this for the last week and tried everything I can think of… Lastest build today rejected again… I have another question, should I be using Non-Consumable or Consumable? Does that make a difference? @mike-minimumstudio
This is becoming extremely discouraging especially after busting my butt for the last month, being genuinely excited to release, only to hit a roadblock like this
hey @tbel did are you sure your IAP sku is set as Consumable? Receipe validation should not be required by the guidelines for that.
I’m sorry you’re running into these issues but apple is always insanely cryptic with their rejections. Make sure your IAP is of type Consumable first and resubmit. Let’s see if that works first, if not please report back here with the rejection message so we can figure it out.
Awesome! Will do that, I think that’s partially to blame, also I had some info in the app not reflect 100% the info on Connect, so I’ll do another build again Appreciate you getting back.
Hiya Youssef, I’m pretty much at the point where I’m ready to give up, I’ve been at this for over a week and Apple reviewers refuse to get pass this point… What am I doing wrong here? I can’t omit this feature of my app as it’s vital to its longevity.
Guideline 2.1 - Performance - App Completeness
We found that your in-app purchase products exhibited one or more bugs when reviewed on iPad and iPhone running iOS 14.7.1 on Wi-Fi.
Specifically, the In-App Purchase loaded with error as displayed.
Next Steps
When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code “Sandbox receipt used in production,” you should validate against the test environment instead.
Resources
You can learn more about testing in-app purchase products in your development sandbox environment in App Store Connect Developer Help.
hey @tbel did you verify on a TestFlight build + a real iphone if the payment succeeds?
At least this time the error makes sense, the reviewer can’t make the purchase because of an error.
The component returns an error code magic text in the error action. Could you create something in your database (like a log) that saves this under a user?
Then run a build, test it yourself on TestFlight on a real iphone (not simulator), check your db for an error an post it here.
That error will be specific and we’ll know what’s wrong.
Ok so I resubmitted to Apple, but I can’t seem to simulate the error on my end anymore. It simply just backs out and doesn’t throw me to the error modal anymore. I’m guessing this is because it’s now set to “Consumable” ?
Hiya, so it has been rejected again as expected with the same error and no error log has been recorded in the DB… I’m just about done at this point.
I initially submitted my app without iAP but the reviewer/s forced me to include it, now I can’t get approved no matter what. I’m trying to be patient but it’s holding up my launch and I’m not sure what to do anymore.
Should I be using “Update” or “Create” for the error log? And further, how do I force an error on my end?
There’s also one thing I don’t understand in the docs
Treat Purchases as Restorations - For Non-Consumables and One-time subscriptions
The App Store and Play store require a way to restore previous purchases from your users to a new device. Even though in Adalo, all of this information is tied to their account, and stored on our servers, this action is still required to exist in your app.
When this is toggled on for a button, this button will look up the purchases made by the user, and verify if they have purchased this item in the past. If they have, it will return successful and you set your actions, if errored, it means the user has not purchased this in the past.
The toggle? Where is that? And what is “IN RESTORE MODE”?
@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.