When compiling with Xcode 16, we started throwing a bunch of new warnings. Here's a list and explanation of each:
- The most common one was needing to explicitly restate the @unchecked Sendable conformance from a parent class.
- There were a couple switches where a new entry was added in tvOS but only for iOS 18, and needed to add it to make it exhaustive.
- There we a couple of places where we were adding a protocol conformance to a class from a different module e.g. extension DispatchTimeInterval: Comparable. This is considered unsafe now because the owners of the module could add the conformance later. Solved by removing the conformance which wasn't being used widely in the codebase, only in tests.
- Finally there was a class where we were capturing SKRequest and SKProductsRequest instances in a sendable block, but only to either log something, or use them as dictionary key, so I just made the classes Sendable (with the new @retroactice attribute because they belong to a different module)
## Changes:
- `DeviceCache` support for caching `ProductsEntitlementsResponse` as
well as "last updated" date
- Added `JSONEncoder.encode` helper matching `JSONDecoder.decode`
version, with an optional `logErrors` parameter
- `OfferingsManager. updateProductsEntitlementsCacheIfStale`
- `Purchases.updateAllCaches` also updates this new cache
- Added `OfferingsManager` / `DeviceCache` / `Purchases` tests
- Integration test for fetching mapping
This prevents users from keeping an outdated active entitlement forever.
One could start a free trial then block all further requests from the
backend in order to keep that active.
When this check fails, a new warning log is generated:
> WARN: ⚠️ Entitlement is no longer active (expired 2023-02-12 18:15:11
+0000) and it's outside grace period window (last updated 2023-02-12
18:13:31 +0000)
Fixes#2116.
Depends on #2134, #2144, #2145.
We've known that, especially for sandbox accounts with lots of
purchases, the SDK can get flooded with a lot of transactions to process
at once.
I've been making some improvements for this (like #2115).
Another consequence of this behavior, is that we can end up failing due
to `StoreKit` throttling us (see #2116):
> 2022-12-03 12:31:58.670892+0100 app[673:61074]
<SKReceiptRefreshRequest: 0x283edc860>: Finished refreshing receipt with
error: Error Domain=ASDErrorDomain Code=603 "Request throttled"
UserInfo={NSLocalizedFailureReason=Unified receipt is valid and current,
NSLocalizedDescription=Request throttled, AMSServerErrorCode=0}
This change avoids that by skipping the refresh if less than 2 seconds
have elapsed. I chose 2 to make this a low-ish risk change, with a huge
benefit for multiple semi-concurrent requests coming from a big
transaction queue.
Mark Villacampa