fix: align PurchasesConfiguration.Builder defaults with the inspector - #1018
Draft
vegaro wants to merge 4 commits into
Draft
fix: align PurchasesConfiguration.Builder defaults with the inspector#1018vegaro wants to merge 4 commits into
vegaro wants to merge 4 commits into
Conversation
Adds baseline tests exercising the harness end to end: Configure forwarding through the wrapper spy, configuration builder defaults, presented-offering-context resolution, and baseline JSON model parsing.
BuildUsesDocumentedDefaults asserted default(...) for StoreKitVersion, ShouldShowInAppMessagesAutomatically and EntitlementVerificationMode, which read as an endorsement of values that diverge from the inspector defaults on Purchases: the builder leaves these at their C# zero values, so the runtime-setup path gets StoreKit 1, in-app messages disabled and verification disabled. Assert the explicit current values and name each divergence, so the test guards today's behavior without claiming it is correct. Renamed to BuildUsesBuilderDefaults to match. Fixing the defaults is a runtime behavior change and is handled separately. Co-Authored-By: Claude <noreply@anthropic.com>
- Assert the serialized UseWorkflows flag alongside AutoSyncPurchases, and build DangerousSettings with differing values so the two keys can't be confused for each other. - Read the spy's only invocation instead of its last, matching what the Has.Count.EqualTo(1) guard already asserts. - Add a SUBSCRIPTION case for productCategory. The UNKNOWN fallback test alone would still pass if Enum.TryParse stopped matching anything. Co-Authored-By: Claude <noreply@anthropic.com>
The builder left three fields at their C# zero values, so apps configuring through runtime setup silently got StoreKit 1, store in-app messages disabled, and entitlement verification disabled -- while the inspector fields on Purchases default to StoreKitVersion.Default, in-app messages enabled, and Informational. Build() passes these straight to the native SDKs, so the divergence was user visible: - StoreKit 1 is pinned rather than letting RevenueCat pick, which makes the win-back offer APIs fail on iOS 18+ (they require StoreKit 2). Broken since #485 replaced UsesStoreKit2IfAvailable with the enum. - Store in-app messages are suppressed, so users with billing issues are never prompted to fix their payment method. The inspector tooltip has always documented the opposite. Broken since #338 added the setting. - Trusted entitlements stayed Disabled, so #748's change of the default to Informational only ever reached inspector users. Give the three fields explicit initializers matching the inspector, and assert the documented values in BuildUsesDocumentedDefaults. Co-Authored-By: Claude <noreply@anthropic.com>
vegaro
force-pushed
the
cesar/unity-builder-defaults
branch
from
July 28, 2026 09:18
4f1f683 to
f7f5321
Compare
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #1014, which is where these divergences surfaced. Follow-up to review comments from @rickvdl and Bugbot on that PR.
PurchasesConfiguration.Builderleft three of its fields at C# zero values, so apps that configure through runtime setup and don't call the setter got different behavior than apps configured through the inspector.Build()hands these toConfigure, which forwards them to the native SDKs verbatim, so the divergence reached users.Purchases.cs)StoreKitVersionStoreKitVersion.DefaultStoreKit1ShouldShowInAppMessagesAutomaticallytruefalseEntitlementVerificationModeInformationalDisabledEach looks like an oversight rather than a decision:
bool UsesStoreKit2IfAvailablewith theStoreKitVersionenum. Under the bool,falsecoherently meant "don't use SK2"; after the migration the zero value came to mean "always use StoreKit 1". The inspector field was updated to.Default, the builder field wasn't. Pinning SK1 makes the win-back offer APIs fail on iOS 18+, since those require StoreKit 2 — with no indication the app ever opted into SK1.= trueand one without an initializer. The inspector tooltip has always documented that "by default, those messages will be shown automatically". Runtime-setup apps got the opposite: billing-issue messages suppressed, and since the developer never chose to take over presentation, nothing callsShowInAppMessages()either. Users with a failed renewal are never prompted to fix their payment method.Change default TrustedEntitlements mode to Informational) touched one line in one file,Purchases.cs. That default has therefore only ever applied to inspector users.Behavior change
Only for apps using runtime setup that leave these unset — anyone calling the setters is unaffected, as is the whole inspector path.
Informationalreports verification results but still grants entitlements when verification fails, so no user loses access;VerificationResultmoves fromNOT_REQUESTEDtoVERIFIED/FAILED. StoreKit version moves from forced SK1 to RevenueCat's choice, which is the documented default. In-app messages start showing, which is what the docs already promise.Tests
BuildUsesDocumentedDefaultsin #1014 now asserts the documented values, and goes back to earning its name (that PR had to rename itBuildUsesBuilderDefaultsand annotate each divergence). Verified by running the Edit Mode suite locally against a rebuiltPurchases.unitypackage— 9/9 pass, and the same assertions pinned the old values on the parent commit, so both directions are covered.Follow-up worth checking
The hybrid SDKs share this builder shape via purchases-hybrid-common, so RN / Flutter / Capacitor / Cordova may have inherited the same drift. Not checked in this PR.