Swiftystorekit: Calling verifyReceipt triggers login popup

[gerchicov-bp]

Platform

• [x] iOS

In app purchase type

• [x] Auto-Renewable Subscription

Environment

• [x] Sandbox
• [x] Production

Version

0.10.1 has this issue and 0.9.0 had but allowed to avoid it.

Report

Issue summary

https://github.com/bizz84/SwiftyStoreKit/blob/c644adca3ad4866fc29e167dadfee89d8a0b52b2/CHANGELOG.md

This release simplifies the receipt verification flows by removing the refreshReceipt method from the public API. Now clients only need to call verifyReceipt and the receipt is refreshed internally if needed.

I call SwiftyStoreKit.verifyReceipt(...) and get an alert with login&password request. It means the app may spam with these alerts depending on how frequently I call this method in 0.10.1 and how frequently I call SwiftyStoreKit.refreshReceipt(...) in 0.9.0.
Maybe I don't understand you - when and how frequently do you advice to call it to stop spamming with these login alerts?

What did you expect to happen

Login alert appears when it is necessary only

What happened instead

The app spams with login alerts until you enter login and password.

[gerchicov-bp]

As I understand InAppReceiptVerificator contains method verifyReceipt method which forces refreshReceipt always when receipt not found and this causes login&password alert to be shown

[bizz84]

@gerchicov-bp I agree that this may not be ideal, however I believe that the Sign-in screen should not appear very often in practice.

For example, if the user has just downloaded your app from the App Store, they are most likely already signed in so the sign-in screen should not appear.

Unless I'm missing something, the sign in screen would happen with this sequence of events:

• User downloads app from App Store
• User signs out of his iTunes account
• User starts the app, and you call verifyReceipt immediately.

As soon as the user has successfully refreshed the receipt OR completed his first purchase, the receipt will be stored locally and only the verification step will take place.

Again, in most cases users would be signed in to iTunes when they use the app.

On a more fundamental level, if a user is signed out of iTunes, it seems reasonable that they need to sign to get the receipt and their purchase history, right?

[gerchicov-bp]

@bizz84 Yes, it seems you are right - the steps are aproximate the same.
Yes, maybe they need to sign to get the receipt. But in the same time - how often should I ask login&password. With my old code I also got a situation with sandbox when iOS starts to spam with login request alerts (even if the app is not launched).
You have also wrote the code - class InAppReceipt has method appStoreReceiptData but you maked it as private and so I should copy it to do the same thing.

[bizz84]

@gerchicov-bp Are you aware of SwiftyStoreKit.localReceiptData?

This will give you the receipt data, or nil if the receipt is missing.

You can use it as a check to prevent the undesired sign-in message.

One annoying thing about StoreKit is that once the sign in popup appears and the user cancels it, the device will randomly ask to sign in again even if the user is outside your app.

This even happened to me while I was driving and using a navigation app 😠

[bizz84]

There isn't a reliable way of refreshing/validating the receipt that doesn't require the user to be signed in.

Because a sign in may be required, I would prefer to put any actions that require to refresh the receipt behind a button that needs to be explicitly pressed by the user.

This may not be great UX, but at least it would prevent annoying popups at the wrong time.

[gerchicov-bp]

@bizz84 thanks I didn't know about SwiftyStoreKit.localReceiptData. It seems you should add some additional info - especially about what occurs when it is nil.

[fortmarek]

I do not know why, but whenever I call SwiftyStoreKit.verifyReceipt(...), the app ALWAYS asks me for my iTunes Store password - even if I am signed in. I even tried SwiftyStoreKit iOS example with no luck. I thought it was issue of my iPhone or my Apple ID but this happens even when I try it on other device with different Apple ID. Am I doing something wrong? Or does this happen because the app is not on the AppStore?

[funkenstrahlen]

Is this related to #307 ?

[RobertGummesson]

Were any conclusion drawn from this?

Like @fortmarek - I get this too despite being signed in. In my case, this app is available on the AppStore. It could still be a Sandbox related issue but at this point I can't be certain. Some reassurance would be nice.

[markz-nyc]

I have this issue too. Maybe it's a sandbox bug, even in the setting->iTunes account, if you login with sandbox tester user and log out, then if you want to login with another sandbox text user, it will constantly prompt sign in box.

[migueliOS]

Same here, I was expecting to have this stopped in Prod as someone mentioned but the issue is also in prod, it keeps on prompting the Sign in to iTunes Alert all the time. I guess it’s pretty annoying to the user.

[mickspecial]

I have this issue as well and caused my app update to be rejected from App Store

[Tybion]

This issue appeared in my app some time in the last 6 months, and I have now fixed it, thanks to ideas in this issue. Summary follows ..

I am using SwiftyStoreKit 0.14.2
Problem known to be fixed on dev iPhone 5s (iOS 10), customer iPhone 6 (iOS 12), customer iPhone 7 (iOS 12)

1. Changed force=true to force=false in verifyReceipt
2. Removed verifyReceipt from AppDelegate
3. Removed verifyReceipt that was called immediately after purchase

From some of the writings linked to in this issue, it seemed that this problem might be caused by calling verifyReceipt while a transaction was still being processed. I looked to see where a verifyReceipt was being called while there MIGHT be an incomplete transaction. I had excessive calls to verifyReceipt (via a general function) in my logic, so removed the calls that were surplus to requirements - keep it simple (KIS) - and the problem disappeared. I don't know if all 3 changes were necessary, but all changes were for the better anyway, so leaving as is.

I hope this helps somebody.