sandbox login prompt every time app is brought to foreground

If we are not logged in to itunes, we are getting a sandbox login popup every time we launch our app

or bring the app from idle (minimized as icon) into the foreground to make it the main running app (we are not considering

multitasking on ipad at this point).


iOS10.x, build on xcode7.3


There seems to be minimal or documentation on what is causing this. We are not trying to check receipts at app startup,

we defer it for 20 seconds to avoid interfering w/ the app launch (e.g. the login popup), but yet the login popup occurs anyway.


Additionally the login popup seems to be coming from a system process not our app process because it stays on screen if we kill our app.


There were some postings about lingering partial transactions and we tried to solve this by finishing all transactions,

but that did not solve it.


Any clues?

Replies

This issue may be due to one or more of the following reasons:

-You are running into a transient bug with the App Store. The workaround is restore the device to the latest iOS version. Note that doing so will reset your device to its factory default settings.


Create a new test user account in iTunes Connect. Make sure that you are signed out of the Store on your device before starting to test In-App Purchase on your device. Build and launch your app on your device, enter the new test user account when prompted by StoreKit to authenticate the purchase. Be sure to always use sandbox test user accounts created in iTunes Connect to test your In-App Purchase products. StoreKit connects to the sandbox environment when you launch your application from Xcode, from your test device (iOS), or from the Finder (OS X). It connects to a production environment for applications that were downloaded from the App Store. You must not use your test user account to sign into the production environment. This will result in your test user account becoming invalid. Invalid test accounts cannot be used to test In-App Purchase again.


-You may have an unfinished transaction. As such, you need to call finishTransaction: on the associated transaction to end the loop to resolve your issue. See TN2387 In-App Purchase Best Practices > Add a transaction queue observer at application launch and Finish the transaction for more information on how to prevent this issue.


-You are calling SKReceiptRefreshRequest or restoreCompletedTransactions, which is prompting you to enter your username and password. If calling restoreCompletedTransactions, see When should I use SKPaymentQueue’ s restoreCompletedTransactions method? for more information. If calling SKReceiptRefreshRequest, that would be the expected behavior.

The problem doesnt seem to be related to us calling anything, as the login popup appears right away at app start, and we are deferring any receipt checking until 20 seconds after launch (to avoid a popup of login as app is launching). I put some alerts in our code to see where we are calling various store kit APIs and this doesnt seem to happen at app start. So it is tending toward unfinished transactions it seems, or something unfinished.


We had tried the trick of forcefully finishing all transactions by putting in a button for it. That didnt seem to work. Problem still occurs.


There seems to be another posting related to unfinished transactions lingering: https://forums.developer.apple.com/thread/72099


Is there like a "verbose" mode we can switch on for store kit to see what it is trying to do when it pops this login?

We are flying blind at this point. Too much guesswork involved.


We are going to try to disable store kit entirely to see if we can get rid of this popup.


also, itunes connect is having troubles today, you might want to throw some paper airplanes in the direction of those guys... 🙂

https://twitter.com/search?q=%23itunesconnect

possible solution found: when removing the StoreKit library from the build, it showed all the places (undefined symbols) where StoreKit was being called, and we found it was also being called from Google Mobile Ads SDK (in addition to our own code)


apparently in-app purchases are possible from Google Ads, and they were calling:

SKReceiptRefreshRequest and a bunch of other APIs in StoreKit


when we took out Google Mobile Ads SDK the login pop at startup problem seemed to go away


we will test more w/ this configuration

I am currently running into the same issue.


But my main problem is that it is happening to a Test-User who was testing something else. He accedentaly tapped the In-App-Purchase while being logged in with his real iTunes Account... And now ... no matter how often he correctly types in his password, the popover will show again and again....

I really don't want to tell the user to reset his phone... so is there any other solution?
Can the iTunes Team cancel his order? I'd really like to give the user an easy solution to the problem as he really helped us getting the last update out.

Also.. I don't know where he lives, so I have no access to his phone to help...

Any help is more than appreciated!


Cheers,

Georg

> ....Test-User who was testing something else. He accedentaly tapped the In-App-Purchase while being logged in with his real iTunes Account... And now ... no matter how often he correctly types in his password

There are two environments here; production and sandbox. If the user was "testing" something then he was running TestFlight and Testflight operates in the sandbox. (Testflight secretly creates a new test user with the user's 'real iTunes Account' username and password.) That could have generated an unfinished sandbox transaction and the 'pop-ups' would be coming from the sandbox and referring to that app. To clear that he needs to 'type in his password' in the sandbox environment by running the app out of Testflight (so it operates in the sandbox) and clear that transaction.

Alternatively, the transaction could be screwed up and 'appear' to be in the production environment. In which case he would need to run a real version of the app and log into his real account and clear the transaction. But in this case, even that mighht not work.