Nuxie vs RevenueCat: when to use them together

You can evaluate Nuxie while keeping RevenueCat. Nuxie's public iOS purchase documentation describes a RevenueCat delegate integration. That makes coexistence a concrete option to investigate, not a promise that every app can switch on an integration without engineering work. Replacing billing should be a separate decision with its own acceptance criteria.

This guide is written by Nuxie and reviews public documentation checked on October 6, 2026. It includes an original ownership worksheet and trial plan. It is not an independent vendor ranking, a tested migration report, or a claim that one product improves conversion more than another.

These paths are evaluation choices, not maturity stages. Adding another platform creates an ongoing integration and support responsibility. A successful trial may conclude that keeping your current system is the right decision.

RevenueCat's product and pricing page includes paywalls, web-to-app funnels and A/B/n testing. Its Offerings documentation explains how to change the products shown to customers remotely. Check those capabilities against your brief before assuming that adding a second product is necessary.

For access decisions, RevenueCat documents CustomerInfo and entitlements. If those already govern your app's premium features, list every place they are read before proposing a different authority. A paywall can look correct while the rest of the app still grants or denies access incorrectly.

Nuxie's iOS purchase guide documents an example RevenueCat purchase delegate and an explicit observer mode when another SDK owns transaction finishing. Installing a delegate does not automatically select that mode. The guide also separates checkout integration from switching feature-access checks through a Connector.

Use that documentation for your exact SDK version and product configuration. Start with the existing provider's access checks while you validate checkout. Treat any later access migration as a separate release decision. The cited integration is iOS-specific; it does not establish equivalent behavior for every platform in your app.

This article has not run that integration against a production app. Before buying or migrating, ask the engineer doing the trial to demonstrate purchase, restore and access behavior in your own environment. A source-code example is useful evidence of an integration path, but it is not evidence that your identifiers, products and lifecycle rules are configured correctly.

Use one row per responsibility, not one row per vendor. Record the current owner, the proposed owner, the evidence that will prove the handoff works, and the person responsible for investigating failures. The following is a trial template rather than a description of an automatic Nuxie setup.

Select one app, one platform and one placement. Keep other acquisition and pricing changes out of the initial integration trial so failures have fewer possible causes. Use designated test accounts and store test environments. Do not use a paying audience to discover whether restores work.

For every case, write the expected outcome before testing. Save the actual outcome, relevant SDK versions and remaining uncertainty. Do not collapse an incomplete test into a green overall result. If the trial fails, fix the integration or retain the current setup before testing growth hypotheses.

• New purchase: confirm displayed terms match checkout, the expected account receives access, and a relaunch preserves it.
• Cancellation and pending approval: confirm the app does not treat either as a completed paid conversion. Show a useful next step rather than an unexplained success screen.
• Restore: test an account with purchases, one without purchases, and a failed restore. Confirm the interface distinguishes those outcomes.
• Lifecycle change: test expiration and refund/revocation using the provider's supported test workflow. Record how long each authoritative system takes to reflect the change.
• Identity change: purchase, log out and switch accounts. Check that the intended transfer or retention policy is followed and another account is not accidentally granted access.
• Interruption and rollback: interrupt the app or network during checkout, then restart. Confirm recovery, reporting and the return to the previous Experience.

RevenueCat's public pricing page states a free threshold of $2,500 in monthly tracked revenue, followed by 1% of tracked revenue, and describes separate Growth Tools options. Nuxie's pricing page separates creation plans from a revenue fee: the fee is waived through $10,000 in monthly attributed revenue, then applies at 1% of the full adjusted net amount. Verify the current terms for your account before making a cost decision.

Tracked revenue and attributed revenue are different inputs. Put each provider's actual billable amount, creation usage, contract terms and expected engineering effort into your comparison. If you keep both products, include both bills. Do not subtract two percentages with different denominators and call the result a saving.

First measure whether the team can produce, review, publish and roll back the intended Experience. Record the time spent and unresolved integration work. Then define a customer outcome, such as completed onboarding or a verified paid conversion, and design a separate experiment.

The paywall test calculator can help estimate the sample needed for a two-variant conversion test. Read the test methodology guide before treating the estimate as a schedule. Passing integration tests does not prove conversion lift, and an attractive screen is not an experiment result.

Keep RevenueCat alone if it meets the brief. Evaluate Nuxie alongside it if the Experience creation workflow is the gap. Investigate replacement only when you can name the requirement, demonstrate the new system and own the migration. The useful output is a clear responsibility map and a tested decision, not a longer list of vendors.