We are seeing frequent crashes from within the CocoaAsyncSocket library on iOS 15.1 So far iOS 15.1 is the only os version affected even though the 15.1 population is small relative to 15.0 and 14.x. This leads us to think that this is likely an issue with iOS? This is possibly a race condition because the crash does not occur every time this code is exercised, however we haven't been able to diagnose with the Thread Sanitizer because the Thread Sanitizer is only available on the simulator, and iOS 15.1 is not yet available for the simulator. Any ideas? Crash Report

Description: Using the Network framework, SDDP discovery will fail while 3rd party apps are running in the background The 3rd party apps in question are (presumably) using the CocoaAsyncSocket library to perform SSDP discoveries on WiFi. How to reproduce Test Setup: For the 3rd party app, you can use https://apps.apple.com/us/app/web-video-cast-browser-to-tv/id1400866497 The simplistic test app referenced below can be installed from: https://github.com/tifroz/SSDPTest You must have the multicast entitlement (https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_networking_multicast) Test steps: On the test device, install a 3rd party app that uses the CocoaAsyncSocket library to performs SSDPdiscovery. Restart the test device to clear any existing 3rd party apps/processes Run this test app on the device, the status should be ready Kill the test app Start the 3rd party app that uses the CocoaAsyncSocket library, then send it to the background (without killing it) after a few seconds Start the test app, this time the status should be (failed, address already in use) Optionally, kill the test app + the 3rd party app, then start the test app again (status should be ready) Question: Is there a workaround?

Context/intro: We are running into a situation where a subset of our users are complaining that they need to frequently restore their purchases because the app seems to forget some non-consumable purchases. Our app uses the local receipt as the source of truth, however it restores transactions via restoreCompletedTransactions() so a restored transaction will fire the same app-specific logic that would get fired after a purchase. One theory we have is that the restored transactions do not automatically make their way into the receipt, so these transactions are not persisted. If that's true, refreshing the receipt (via SKReceiptRefreshRequest), along with restoreCompletedTransactions() would make sure the receipt is updated as well whenever the user decides to restore. My question: do transaction restored via restoreCompletedTransactions() make their way into the receipt file?