Build a Subscription App with Newly: A Practical Walkthrough

Use a small habit tracker as the example. The free experience lets someone create up to three habits, record today's completion and see a seven-day history. The proposed paid feature is an unlimited habit list and a longer history. Those are example product decisions, not a report of an app already built or released.

Decide whether the first version needs accounts or shared data. Ask the agent to explain the storage model before expanding the app. If you want access to follow a user between devices, plan identity and purchase restoration deliberately rather than assuming that a local flag will travel with the account.

Once the free flow works, ask the agent to add the subscription. Newly supports a Connect RevenueCat card and a Subscriptions setup flow. A project owner or admin connects the account and selects a RevenueCat project covered by the authorization.[6]

Use the app identity intended for the release. Check which Apple or Google app the products belong to and finish any required account agreements and configuration. If a connection is unavailable or an account lacks access, resolve that setup problem before treating the paywall as ready.

Choose an entitlement such as pro for the paid access. The entitlement describes what a customer can use; a store product describes the purchase. Map every intended monthly or annual product to the entitlement and verify the mapping before testing.[7]

Ask for the paywall to use the current store product information instead of a hardcoded price string. After a successful purchase or restore, the app should read the entitlement state and unlock the paid feature. A button that changes a local isPro value is a mock, not a complete purchase integration.[7][8]

Keep purchase handling and account identity consistent across devices. Define what should happen when a user signs out, signs in elsewhere or restores a prior purchase. Check the account model supported by the generated app before making promises about cross-device access.

A cloud preview is useful for layout and the free app flow. For purchase behavior, use the native build and test environment appropriate to the store and SDK. Follow RevenueCat's testing guidance and the store's account setup; a screenshot of a paywall does not establish that billing works.[9]

Record the expected result before each test and the observed result afterward. Keep the build version and test account type with the result, so a later fix can be checked against the same scenario. Use synthetic users and test purchases, and keep account details out of shared recordings.

Newly's entry subscription is $25/month with 100 credits. Agent work draws down credits according to the work performed. A prompt is not a fixed unit of cost. Cloud simulators and native builds do not consume those agent credits.[3][2]

Before an agent task, note the available balance and the scope of that task. After it finishes, record the usage shown by Newly and whether the acceptance criteria passed. Separate new-feature work from repair work, and account for any top-ups or other balance changes during the measurement.

Measure elapsed time with start and end timestamps. Separate agent work, native build processing, store processing and review waiting. Keep service subscriptions, app-store account costs and any RevenueCat charges outside the builder-credit total. Check each provider's current pricing for your usage.[10]

An owner or admin can download the source ZIP from Settings, Project, Download source. You can also use the Newly CLI or link a repository from Deploy for two-way GitHub sync. Record the branch and revision used for the tested build.[1][4]

Keep a service inventory with the source: RevenueCat project, store apps, product identifiers, entitlement mapping and any backend used by the app. Source export does not automatically transfer live data or account ownership. Have a developer verify configuration and dependencies in a clean environment before calling the handover complete.

Newly can build and upload an iOS version to App Store Connect and TestFlight. You complete the required listing, privacy and review submission steps. Android uses its own signing, Play Console setup and testing path, including any first-upload steps required for the project.[5][1]

Use the same product identifiers and app identity you tested. Check the subscription description, price presentation, restore action and reviewer access instructions against the actual app. Save the uploaded version and review outcome as separate records; a successful build is not the same milestone as a public release.