Skip to content

Conversation

@JZDesign
Copy link
Contributor

@JZDesign JZDesign commented Dec 3, 2025

Checklist

  • If applicable, unit tests
  • If applicable, create follow-up issues for purchases-ios and hybrids

Motivation

As we evolve the conditional visibility feature and add new conditions, our users will likely wind up in a spot where their paywalls don't render in an expected way. We need to provide an option to allow them to account for old SDKs and to control how their paywall renders if they use newer conditions that old SDKs are unaware of.

Description

Adds the ability for users to create a condition that will only show the component for a given app version

@JZDesign JZDesign changed the base branch from main to jzdesign/conditional-visibility-2 December 3, 2025 19:47
@RevenueCat-Danger-Bot
Copy link

1 Error
🚫 Label the PR using one of the change type labels. If you are not sure which label to use, choose pr:other.
Label Description
pr:feat A new feature. Use along with pr:breaking to force a major release.
pr:fix A bug fix. Use along with pr:force_minor to force a minor release.
pr:other Other changes. Catch-all for anything that doesn't fit the above categories. Releases that only contain this label will not be released. Use along with pr:force_patch, or pr:force_minor to force a patch or minor release.
pr:RevenueCatUI Use along any other tag to mark a PR that only contains RevenueCatUI changes
pr:next_release Preparing a new release
pr:dependencies Updating a dependency
pr:phc_dependencies Updating purchases-hybrid-common dependency
pr:changelog_ignore The PR will not be included in the changelog. This label doesn't determine the type of bump of the version and must be combined with pr:feat, pr:fix or pr:other.

Generated by 🚫 Danger

@JZDesign JZDesign marked this pull request as ready for review December 3, 2025 20:20
@JZDesign JZDesign requested a review from a team as a code owner December 3, 2025 20:20
Copy link
Contributor

@tonidero tonidero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good but I do think we need to fix the semver number parsing/comparison

* */
@Serializable
data class AppVersion(
@SerialName("operator") val operator: ComparisonOperatorType,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add in or not_in operators as well? Alternatively, we could add and and or... but maybe in/not_in would be enough.


/**
* Serializer that converts version strings like "3.2.0" to integers like 320 by keeping only digits.
* Also handles integer inputs directly for backward compatibility.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm does this work for comparison purposes? For example, 11.2.0 would get translated to 1120, and 2.11.0 would get translated to 2110, and it would say that the second is bigger than the first? I think we need proper semver parsing and comparison instead of parsing to an int.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Man… you're right. Thank you for the sanity check here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good to add some tests for this as well. Using parameterized tests we can cover a lot of cases easily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants