Extracted PurchasesType and PurchasesSwiftType

[NachoSoto]

This is needed to fix RevenueCat/purchases-hybrid-common#229

purchases-hybrid-common had a hacky implementation of MockPurchases that subclassed Purchases.
Because of that, it had 100+ lines of code to initialize the instance, which was never used because all (most) methods were overridden.

This allows a much better way of doing that, which also enables any SDK user to mock Purchases.

Another benefit of this is that we can see at a glance what the public API is.
Also, all docstrings are now extracted into the protocol, which makes the implementation file shorter. The docs get inherited by the type itself.

All our API testers pass with no changes, and I've also added the updated RevenueCat-Swift.h to verify that no public API changed.

[tonidero]

I'm assuming the documentation was only moved and didn't change? (I didn't read all the documentation).

My main concern as someone not familiar with swift is whether the change from a class to a protocol can in any way break user's implementations or tests... From looking at the changes in RevenueCat/purchases-hybrid-common#230, looks like we had to remove the override keyword in the tests, and the same might happen to users in their tests if they are trying to mock Purchases right? So I'm wondering if this would be considered a breaking change...

[NachoSoto]

Yeah the docs are just a copy.

As for the override, that's a good question. Because the class wasn't open, it meant that it was implicitly final outside the module , so users couldn't even subclass it.

That's why this does allow users to mock the type, but without the dangers of subclassing.

[tonidero]

Ahh ok sounds good! Then this LGTM!

[aboedo]

yeah the tests thing is more just fixing the terrible hack we used to have to do because we were doing inherit + replace instead of using a public interface for mocking in tests

[aboedo]

And we were also using a @testable import, which does a few things specifically for testing (like making stuff open instead of final).
So... this would affect folks who were using @testable import Purchases in their own implementations, I suppose. But no one using in production as far as I understand it

[NachoSoto]

So... this would affect folks who were using @testable import Purchases in their own implementations, I suppose. But no one using in production as far as I understand it

The class was already made final already so it could become Sendable. That's a requirement for it.