iOS 17.5.1 — IAP — Freeze

I have new behavior after updating to the iOS 17.5.1 and Unity 2022.3.30/31.

I made a sandbox USA purchase for AR Masker subscription on iOS in Dev Mode, then after several minutes, I clicked the “restore” button just to test — the App was frozen.

The next openings of app, the app is frozen at start, the phone is heated, and the app becomes normal after several minutes.

Unity console shows nothing because the connection to the phone is reset when making a purchase.

Xcode shows nothing without throwing of error because of this: Unity Issue Tracker - Logs don’t show up in Xcode when using WebCamTexture Class


Next I deleted the app and install it again - no freezes are here.
Next I clicked “restore”, and freeze is here with the same behavior. But it was frozen twice: after restoring and a little bit later.

Next opening of app, the behavior is the same.


The previous test of IAP was on March 12, with Editor Version: 2022.3.20f1 and “com.unity.purchasing”: “4.10.0” without freezing.

Today’s test was with Unity 2022.3.30/31 and “com.unity.purchasing”: “4.11.0”.

I have iOS 17.5.1 for now and can’t say you about iOS in March.


I use [SIS/Simple IAP Sytem asset (Unipay)] to operate with IAPs, and @Baroni1 - author of this asset - said next:
“I have heard of the freezing bug before when doing purchases in iOS 17.5 with Unity IAP. However, Simple IAP System does not contain any native code that could cause this.”

So @Yannick_D @bcamus can you fix that?

Non-Dev mode shows the same.

Following for updates while trying to update my iPhone in order to reproduce this.

1 Like

Thanks for flagging and providing the details, we appreciate it! The team is trying to reproduce.

1 Like

I was able to reproduce the freezing in the default Simple IAP System example scenes with iOS 17.5.1, XCode 15.4, Unity 2022.3.10f1 and Unity IAP 4.11.0.

My Apple sandbox account has several expired test subscriptions, 21 transactions in total. On the first restore transactions attempt, they get processed very quick in about 2 seconds. On the second and subsequent restore transaction attempts, XCode logs the message “UnityIAP: RestorePurchase” and hangs up to 40 seconds, while any button presses during that time are unresponsive, until the log continues with “Unity IAP: UpdatedTransactions” and “UnityIAP: PaymentQueueRestoreCompletedTransactionFinished” followed by all the DuplicateTransaction messages.

I also did the test with downgrading to Unity IAP 4.10.0 (same iOS, XCode and Unity versions) and the issue occurs there too, about 30 seconds delay on the second restore transactions call.

Please contact me if you need the exact XCode log.

1 Like

I tried to reproduce this on Unity 2022.3.18f1, but I had no issues. In my case the application was still responsive while waiting for the UpdatedTransactions.
Would you be able to provide us with the XCode log so we can see if there’s any difference with what we get?

I’ll be running some more tests including with the same editor version to see if that affects it.

1 Like

@bcamus @Yannick_D
Please note that the culprit here to reproduce this issue is having a handful of expired transactions. Like I wrote, I was able to reproduce the freezing behavior on a test account with ~20 expired subscription transactions. Therefore, to reproduce, you will have to buy a 3-min subscription at least 2 times and wait 1 hour in total for all of them to expire.

I re-tested on a new sandbox account with only 1 active product and the RestoreTransactions method completed instantly every time. So, the issue seems to not occur with only a handful of transactions.

In the XCode log there is nothing suspicious in both cases. It’s only that with a lot of transactions, the “UpdatedTransactions” event takes a lot longer to get processed. Hope this helps, even without posting a log.

1 Like

I was able to confirm that there’s a delay between the “RestorePurchase” and the “UpdatedTransactions” which only occurs after the first call. This also doesn’t seem to happen on previous iOS versions.
However, there’s been no freeze in my experience.

The “RestorePurchase” notifies Apple that we want the restored transactions. We get no response from this.
Apple then sends the restored transactions to the transaction observer and Unity IAP notifies you via the callback set in the RestoreTransactions when the response arrives.

When calling the RestoreTransactions, is it possible that you are awaiting a result from the callback which is causing the freeze?

1 Like

Following on from @Yannick_D , I’ve found it better practice never to trust that these APIs will respond in a timely fashion, or even at all. Make sure your code handles every response with that in mind - asynchronously.

1 Like

Just tested with Unity IAP 4.12.0.
I have 5-min auto-renewal sandbox period.

There are still freezes when:

  • restoring purchases (1-min freeze, 4-min freeze).
  • sandbox environment loads new data about the next auto-renewal.

Moreover, I have the new behavior when restoration for the 2nd time:

<i>iPhone XS Max  "000080:0"</i> IAPManager reports: Restore failed. An unknown error occurred
SIS.IAPManager:OnTransactionsRestored(Boolean, String)
UnityEngine.Purchasing.Extension.UnityUtil:Update()

For the 3rd clicking on restoration, I have a freeze until the new auto-renewal happens and showed on In-App Purchases Made Secure - IAPGUARD… (second by second), then several seconds without freeze and new long freeze is here until the next auto-renewal with 280 same messages by 5:

<i>iPhone XS Max  "000080:0"</i> NullReferenceException: Object reference not set to an instance of an object.
  at SIS.ReceiptValidatorServer+<RequestPurchaseRoutine>d__24.MoveNext () [0x00000] in <00000000000000000000000000000000>:0
  at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00000] in <00000000000000000000000000000000>:0

<i>iPhone XS Max  "000080:0"</i> onPurchaseFailedEvent(productId:com.website.hiddenID message:smile:uplicate transaction occurred storeSpecificErrorCode: )
UnityEngine.Purchasing.PurchasingManager:OnPurchaseFailed(PurchaseFailureDescription)
UnityEngine.Purchasing.Extension.UnityUtil:Update()

<i>iPhone XS Max  "000080:0"</i> IAPManager reports: PurchaseFailed. Error: DuplicateTransaction
SIS.IAPManager:OnPurchaseFailed(Product, PurchaseFailureDescription)
UnityEngine.Purchasing.PurchasingManager:OnPurchaseFailed(PurchaseFailureDescription)
UnityEngine.Purchasing.Extension.UnityUtil:Update()

<i>iPhone XS Max  "000080:0"</i> IAP LISTENER:HandleFailedPurchase
SIS.IAPListener:HandleFailedPurchase(String)
SIS.IAPManager:OnPurchaseFailed(Product, PurchaseFailureDescription)
UnityEngine.Purchasing.PurchasingManager:OnPurchaseFailed(PurchaseFailureDescription)
UnityEngine.Purchasing.Extension.UnityUtil:Update()

Would you be able to provide the code you use to call the RestoreTransactions and your callback?

For the Restore failed, this can happen if you request another restore transaction while the first one is in progress.

1 Like

I believe that this part of the code must be provided by the Author of Plugin ([Simple IAP System / UniPay]) @Baroni1 , he is included in this thread.

Anyway, the source code is written in C# and available on Asset Store. I believe that I can’t share it for public.

I submitted bug report IN-79305 for this performance issue, most of the times taking 60 seconds or more for the restore to update transactions. This is without any external assets like Simple IAP System. The bug report uses the RestoreTransactions sample scene that is shipped with Unity IAP.

2 Likes

I’ve checked your bug report and while we confirm this is happening on iOS 17.5 and macOS 14.5, this doesn’t seem caused by Unity IAP.

The way our logs are set, the RestorePurchase happens when you press the restore button (this sends the request to Apple). As soon as Apple replies with the transactions to the transaction observer, we send the UpdatedTransactions before doing anything else. Anything that happens between that is on Apple’s side and we have no control on it.

Have you been able to reproduce this in production or is this a sandbox only issue?

1 Like

It looks like it’s been fixed somehow over the time.