Remote Config Cache Invalidation API
New SDK methodinvalidateRemoteConfigsCache() forces the next remoteConfig / remoteConfigList call to fetch a fresh targeting evaluation instead of serving the in-memory cache — useful right after setting user properties your targeting depends on. Additionally, identify now drops the config cache even when the user id doesn’t change, so re-login flows always evaluate fresh.Available in iOS 6.14.0, Android 9.7.0, React Native 10.11.0, Flutter 11.10.0, Cordova 7.9.0, Capacitor 1.8.0, and Unity 9.9.0.See Invalidate the config cache for usage and When a device fetches a config for the full caching rules.Freeze Assignments for Remote Configs
Keep users on the Remote Config they already received — no matter how the targeting changes later. Turn on Freeze assignments in the configuration’s Targeting card, and every user who newly receives the config is pinned: later targeting-rule, rollout-percentage, or priority changes won’t re-seat them. When enabling, you can optionally pin everyone who has already received the config in one shot.Payload edits still apply to pinned users, and turning the switch off does not unfreeze anyone — detach users individually or archive/delete the configuration to release them.See Freezing assignments for the exact semantics.Rollout Percentage Is Now Enforced
The rollout percentage (segment_percent) of a Remote Config now actually gates delivery: a user is admitted when their stable per-config bucket falls below the percent. The decision is deterministic — a config edit never reshuffles who is inside the rollout, and raising the percent only adds users.One heads-up: drafts saved with a partial rollout come alive on activation. A draft configured at, say, 43% will gate 43% of matching users the moment you activate it — review the rollout field of your drafts before flipping them on.See How targeting and assignment works for the full evaluation model.Web Funnel
Sell your subscriptions on the web and unlock them in your app. Build a checkout funnel as a No-Code screen, hosted by Qonversion atscreens.qonversion.io, let users pay with Stripe in the browser (from ads, emails, or influencer links), and have them redeem the purchase inside your mobile app — Qonversion grants entitlements and tracks the revenue alongside your App Store and Google Play subscriptions.Available now in beta / early access, and you can validate the whole flow end to end with sandbox testing before going live.See the Web Funnel guide and Web Funnel redemption to get started.No-Code Builder & SDK Updates
Several No-Code improvements shipped with iOS SDK 6.13.0 and Android No-Codes SDK 1.10.0:- Custom purchase loader. Replace the SDK’s default purchase spinner with your own — a styled spinner or a Lottie animation — configured entirely in the No-Code Builder. See the Purchase Loader guide.
- Read a screen’s configured products and variables. Load a screen up front with
loadScreenand read the product IDs and screen variables configured in the Builder — each value keeping its native type — for analytics consistency and app-side logic. See Reading default variables. - Custom actions. Trigger a custom action from a No-Code screen and handle it in your app through a new delegate event. See Custom Actions.
- No-Codes in Kids Mode. No-Code screens are now available from the No-IDFA (Kids Mode) Qonversion SDK, starting with iOS SDK 6.12.1. See Kids Mode.
Paddle Integration
Qonversion now supports Paddle as a web payment provider, alongside the App Store, Google Play, and Stripe. Connect your Paddle account with an API key (Qonversion registers the webhook destination automatically), map your Paddle products, and link purchases to Qonversion users withcustom_data so entitlements are granted and revenue is tracked from Paddle webhooks.See the Paddle Integration guide and Paddle Credentials to get started.