we don't have a radar or something we can link to here right?

this'd break again in the future if we add another type of error but don't add it here before PurchasesErrorConvertible, right?

are there any cases that aren't covered by BackendError + NetworkError? if not maybe we can skip the PurchasesErrorConvertible line, so that if we add a new error type in the future it gets handled as default without crashing on iOS 12

we don't have a radar or something we can link to here right?

Whatever it is, it's already fixed in future iOS versions, so they're not gonna bother. I also tried updating to the latest iOS 12.x to see if the fix is there, but 12.4 is the latest simulator we have available.

are there any cases that aren't covered by BackendError + NetworkError?

In practice right now, no. But there are other types that conform to PurchasesErrorConvertible, just wouldn't be used in the code paths this is called now. But we can't guarantee that for the future unfortunately.

so that if we add a new error type in the future it gets handled as default without crashing on iOS 12

That would break the behavior in later iOS versions though. It's unfortunate we even need this in the first place, but we do because throws is not typed, and we're using it more and more with async throws instead of typed Results in completion-block APIs. Using this is what ensures that we don't end up throwing a StoreKitError instead of our own ErrorCode.

If we miss a type here, we would send "unknown error" instead, even though it's not really unknown.

But maybe that is the best approach for iOS 12. Let me change this to a runtime check so at least we avoid the crash! Stand by.

Updated.