# Placements > Drop one line of code at every monetization moment, then decide what happens from the dashboard — no app release required. Source: https://superwall.com/features/placements --- Monetization # Placements Drop one line of code at every monetization moment, then decide what happens from the dashboard — no app release required. The hardest part of testing a paywall isn't the paywall — it's the wiring. Every time you want to show a different screen, gate a different feature, or try a different offer, someone has to touch the app, rebuild it, and wait on a review. Placements remove that loop entirely. You mark the moments in your app where monetization could happen, and from then on you decide what those moments do from the Superwall dashboard — without shipping a build. ## Mark the moment once, decide what happens later A **placement** is a named event you register at a point in your app — onboarding finishing, a workout starting, a premium button getting tapped. You add it with a single call to [register()](https://superwall.com/docs/ios/sdk-reference/register), and that's the last time engineering needs to be involved. From there, the placement becomes a remotely-configurable hook: it can trigger a paywall, gate a feature, or do nothing at all, and you change that decision from the dashboard. [ See the register() reference ](https://superwall.com/docs/ios/sdk-reference/register) Because the behavior lives server-side, the same line of code can show one paywall today and a completely different experiment tomorrow. You can even [add placements you don't use yet](https://superwall.com/docs/dashboard/dashboard-campaigns/campaigns-placements) and switch them on when you're ready — no redeploy, no waiting on the next release train. Don't be shy with placements Superwall's own guidance is to instrument generously: drop placements at every moment that _could_ become a monetization surface, leave them paused, and activate them when an experiment calls for it. The cost of an unused placement is essentially zero; the cost of a missing one is another app release. ## Gate features without hard-coding paywall logic Pass a feature closure to `register()` and the placement becomes an access gate. Whether that closure runs is decided by the paywall's gating mode, not by code branches in your app: * **Gated** — the feature runs only after the user subscribes or already has the entitlement. * **Non-gated** — the feature runs immediately, with the paywall shown as a soft prompt. The important part: you flip between gated and non-gated from the [dashboard](https://superwall.com/docs/dashboard/guides/tips-paywalls-feature-gating), so the same placement can hard-gate a feature in one experiment and softly nudge in the next — no new code, no new build. [ Learn about feature gating ](https://superwall.com/docs/dashboard/guides/tips-paywalls-feature-gating) ## Send context, target precisely Every placement can carry parameters — the source screen, a plan tier, a content category, anything you know at that moment. Those parameters flow into the dashboard, where you can filter [audiences](https://superwall.com/docs/dashboard/guides/tips-paywalls-based-on-placement) on them, personalize paywall copy with the values, and forward them to your analytics. One `caffeineLogged` placement with a `source` parameter can drive a different paywall for onboarding than it does for a deep-linked return visit. ## Standard and custom placements Custom placements are the app-specific events you name yourself. Alongside them, Superwall fires [standard placements](https://superwall.com/docs/dashboard/dashboard-campaigns/campaigns-standard-placements) automatically — app installs, session starts, failed transactions, survey responses — so you can build campaigns around lifecycle and recovery moments without instrumenting them yourself. Both types feed the same campaigns and audience rules. [ Browse standard placements ](https://superwall.com/docs/dashboard/dashboard-campaigns/campaigns-standard-placements) ## Built for experiments, not one-offs Because placements decouple "where" from "what," they're the foundation for running real experiments. A single paywall can serve many placements, and a single placement can route to different paywalls per audience. You can: * A/B test which paywall, offer, or onboarding flow a moment triggers — and read the results per placement. * Pause a placement to kill an experiment instantly, or resume it for a promotion, all without an app update. * Cache your most important campaign first with [priority placements](https://superwall.com/docs/dashboard/dashboard-campaigns/campaigns-placements-prioritized) so first-launch and onboarding paywalls appear with zero loading delay. ## Why teams reach for placements Growth and marketing teams consistently want the same thing: to test paywalls, offers, and onboarding fast, without queuing behind engineering or a release cycle. Placements are what make that possible. The engineering work is a one-time instrumentation pass; everything after that — what shows, to whom, when, and whether it gates — is a dashboard decision the growth team owns. ## Get started Add the SDK, register your first placement, and wire it into a campaign: * [Presenting paywalls & feature gating](https://superwall.com/docs/ios/quickstart/feature-gating) — register a placement and gate access. * [register() reference](https://superwall.com/docs/ios/sdk-reference/register) — parameters, feature closures, and presentation handlers. * [Placements in campaigns](https://superwall.com/docs/dashboard/dashboard-campaigns/campaigns-placements) — pairing placements with audiences and paywalls. * [Create a free Superwall account](https://superwall.com/sign-up) to start testing. ## More features | [ App-to-Web Checkout ](https://superwall.com/features/app-to-web-checkout) | Send U.S. iOS users from your paywall to a Stripe checkout in Safari, then link the purchase back to the app automatically — no IAP, no auth. | Monetization | | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | | [ Audience Targeting ](https://superwall.com/features/audience-targeting) | Decide exactly which users see which paywall — by user attributes, behavior, device, and subscription state — and change it without shipping a build. | Monetization | | [ Campaigns ](https://superwall.com/features/campaigns) | Decide which paywall every user sees, and A/B test new ones, from the dashboard — no app release required. | Monetization | Nothing matches. ## Book a demo Tell us a little about your app and we'll match you with the right person. * A personalized walkthrough of the paywall builder * Guidance on your monetization and pricing strategy * Custom implementation recommendations for your stack * A look at proven paywall templates * Revenue-optimization best practices ### Thanks — opening your calendar If a new tab didn't open, [click here to pick a time](#). Get started ## Build, test, and optimize your paywalls Join 10,000+ apps using Superwall to grow subscription revenue without shipping an app update. [Start for free](https://superwall.com/sign-up) No credit card required