Eventually, we could merge this option with usesStoreKit2IfAvailable outright.

We send the receipt base64-encoded, while the JWS token is sent as it is. I don't particularly like the placement of this piece of code, ideally we would be doing the encoding on the call site, but changing that broke a lot of receipt tests that were expecting unencoded receipts. Open to suggestions on how to handle this better.

We need at least one JWS token in the backend in order to sign the offer, plus we get to fail early if user has not made any purchase.

Since this is just a "dangerous" setting, even though technically it's a public API, I think we can get away with making this not a minor (so not using feat).

Wondering what you have in mind for this: is this just for us to test, or do we expect others to be able to use this?
I'm asking because we could make this internal only.

Just for us but we need to be able to use it in PurchaseTester so internal would not work I think

I would not put this in DangerousSettings then, let's move it to InternalDangerousSettingsType

It's weird that we're converting it from string to data and now back to string. Let's change the parameter in these 2 operations to String to avoid that.

I would not put this in DangerousSettings then, let's move it to InternalDangerousSettingsType

Let's move this to a method. I'm thinking maybe AppleReceipt+Serialization.swift:

extension AppleReceipt {
  static func serialized(receiptData: Data, forJWS: Bool) -> String {
    if forJWS {
      return String(data: receiptData, encoding: .utf8) ?? ""
    } else {
      return receiptData.asFetchToken
    }
  }
}

Another idea:

struct EncodedAppleReceipt {
  let data: Data
}

extension EncodedAppleReceipt {
  func serialized(forJWS: Bool) -> String {
    if forJWS {
      return String(data: self.data, encoding: .utf8) ?? ""
    } else {
      return self.data.asFetchToken
    }
  }
}

From our conversation:

#if DEBUG
@testable import RevenueCat
#else
import RevenueCat
#endif

#if DEBUG
.with(dangerousSettings: .init(internalSettings: DangerousSettings.Internal(useJWT: useStoreKit2)))
#endif

I'd change to async for consistency with the rest, and use the completion block outside.

Let's test to make sure this works with no transactions.

Just use first (without closure). Also, you can use keypath in the compactMap and StoreTransaction.init in the map.

This is an AsyncStream not a regular collection.
The separate map and compact map are fine, separate modification helps with clarity.

Reminder to change this 😇

Did you mean to change this?

👍🏻
Let's add tests for this too.

The good thing is that our current integration tests will cover this as well, but I'd cover it in PurchasesOrchestratorTests too.

Can you move this to StoreKitStrings?

Should we fail if syncPurchases is called when user has no transactions?

I would match the existing logic, so no:

let hasTransactions = self.transactionsManager.customerHasTransactions(receiptData: receiptData)
let cachedCustomerInfo = self.customerInfoManager.cachedCustomerInfo(appUserID: currentAppUserID)

if !hasTransactions, let customerInfo = cachedCustomerInfo, customerInfo.originalPurchaseDate != nil {
    if let completion = completion {
        self.operationDispatcher.dispatchOnMainThread {
            completion(.success(customerInfo))
        }
    }

    return
}

That way we don't need a new ErrorCode.

The scenario here is: if a user has no previous transactions, we cannot fetch any token, and hence we cannot post it to /receipt because it would return a 400 error. Instead, I fetch customer info and return it.

Maybe move this file to StoreKitAbstractions?

Even though it's internal, a docstring might help devs in the future:

Nit: our style guide requires lines at the beginning and the end of every type, extension, etc.

This becomes EncodedAppleReceipt.ReceiptType which is a bit redundant, I'd change this to just

Maybe rename these to post(receipt: EncodedAppleReceipt) now that it's not a Data?

Should we verify the result too?

This is needed :P

Awesome 👍🏻

Formatting here is weird, maybe move all the parameters to their own line?

Nit: maybe create an extension in this file to simplify this:

private extension EncodedAppleReceipt {
  init(receiptString: String) {
    self.init(type: .receipt, data: receiptString.asData)
  }
}

This new definition is great 👍🏻

But now the extra type is unnecessary, how about defining it like this:

enum EncodedAppleReceipt: Equatable {

  case jws(String)
  case receipt(Data)

}

Then you don't even need the redundant constructors.

This is duplicated below, can you extract it?

let transaction = StoreTransaction(
  sk2Transaction: verifiedTransaction,
    jwsRepresentation: transactionResult.jwsRepresentation
)

if fromTransactionUpdate, let delegate = self.delegate {...}

return transaction

👍🏻

This isn't used anywhere, make it fileprivate?

Let's make sure we write tests with this on before we use it. This is fine for now 👍🏻

This can be simplified:

This isn't needed

Hmm this was using receiptData.hashString to prevent this cache key from being a huge string.
I'd recommend doing this instead now;

private extension EncodedAppleReceipt {

  var hash: String {
    switch self {
      case let .jws(content): return content.asData.hashString
      case let .receipt(data): return data.hashString
    }
  }

}

Added as internal extension 👍

This is only relevant in the context of creating a hash for operations, so I'd make it private put it there.

⚠️ Uh oh, this is a breaking change. Did you mean to change this?

I just realized that this has no tests either in TransactionPosterTests.

This can be simplified as: