A membership freeze is a rule in your own billing, and for a gym it has to be.
To pause a membership you stop the next charge, suspend access, and set a date it all comes back. For anything a person uses in a physical place, a gym, a studio, a salon, a clinic, that is work you do in your own billing, because App Store Review Guideline 3.1.3(e) requires you to take those payments outside in-app purchase in the first place. No store is in the loop, so no store can hold the membership for you. The upside is that nobody caps how long a freeze lasts or what it costs. The downside is that nothing is built.
There is one case where the store does own it: a membership that is purely digital and sold through store billing. There the two platforms disagree completely. Google Play has a documented pause, one week to three months, that the subscriber chooses themselves. Apple documents no pause at all. Everything below comes from Apple's and Google's own current documentation, read on 14 October 2026, and from how a freeze behaves in a booking diary once it exists.
Start hereThe short version
Two different problems wear the same word.
The first problem is a hold on a real world service. Somebody is travelling for six weeks, or injured, or between seasons, and they would rather suspend than cancel. That hold lives in your billing and your access rules, and it is the one every small operator actually asks about. Nothing in either store's documentation limits it, because neither store took the money.
The second problem is a pause on a store subscription, which is a different mechanism with hard edges. Google built one and documents it precisely: who starts it, when it starts, how long it can run, what the server tells you while it runs. Apple did not build one. Mixing the two up is how you end up promising a freeze feature on iOS that the platform has no way to deliver.
Does a membership freeze go through the app stores at all?
For a gym, a studio or any booked service, no. Guideline 3.1.3(e), Goods and Services Outside of the App, is the one that settles it. It says that where your app lets people buy physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, naming Apple Pay and ordinary credit card entry as examples. Access to a room, a class or an hour of somebody's time is consumed outside the app. Guideline 3.1.1 is the other side of the same line: in-app purchase is what you use to unlock features or content inside the app.
Read those two together and the freeze question answers itself. The money never passed through the store, so the store has no record to suspend. Your freeze is a row in your own database and a rule in your own billing account. That is better than it sounds. A store pause is one shape, take it or leave it. Your own hold can be a week or a season, free or paid, staff initiated or self service, and it can keep a member's class history and booking preferences exactly where they were.
It is worth being blunt about the trade. Taking payment outside in-app purchase means you also own the card details flow, the failed payment retries, the receipts and the refunds. People reach for in-app purchase partly to avoid all of that, then discover the guideline will not let them. If you are weighing the cost of one route against the other, the arithmetic behind Apple's commission is the honest comparison, not a guess about which one is simpler.
One more thing before the mechanics. A freeze is not a standalone feature. It only makes sense next to a schedule, a member record and a payment, which is why it shows up late in most projects, usually the first week a real customer goes on holiday. If you are still working out the shape of the thing, the rest of a booking app for business has to exist before a hold on it means anything.
Apple, App Review Guidelines, 3.1.1 and 3.1.3(e), read 14 October 2026
Work out who owns the hold
Who can actually freeze this membership
Pick how the money reaches you. That single answer decides whether a freeze is a feature you build, a feature the store already has, or a feature nobody has.
Access to a gym, a studio or an in person service
Can it be frozen: Yes, and it has to be yours. Guideline 3.1.3(e) keeps this payment out of in-app purchase in the first place.
Who controls it: You do, and Apple requires it.
How long it can last: Your own rules again, because no store is in the loop.
Read from Apple's and Google's own documentation on 14 October 2026. Google notes its pause lengths are subject to change.
What does Apple document about pausing a subscription?
Nothing, and that is the useful answer rather than a gap in the research. Checked on 14 October 2026, Apple publishes no pause for an auto renewable subscription. Its own support page on managing subscriptions lists what a person can do, and the list is cancel, cancel a trial before it renews, change the linked Apple Account by contacting support, ask the family member whose account is on the receipt to cancel theirs, or contact the carrier that bills them. Pause is not on it.
The server side agrees. The App Store Server API reports a subscription status with five possible values: the subscription is active, expired, in a billing retry period, in a Billing Grace Period, or revoked. There is no paused value, so even if you wanted to read a hold off Apple's records there is nothing to read. StoreKit's renewal states on the device line up with the same five.
Billing Grace Period gets mistaken for a pause often enough to be worth separating out. It is a recovery window for a renewal that failed because of a payment issue, not a hold a member asks for. You turn it on per app in App Store Connect and pick 3, 16 or 28 days, applied across every subscription product in that app, and for a weekly subscription the real window is 6 days even if you selected a longer one. Apple is explicit that without it, the subscriber's days of paid service pause until it can collect payment. That sentence is the only place the word pause appears, and it describes an accounting effect, not a feature.
So if your membership really is digital and really is sold through in-app purchase on iOS, there are two honest options. Let people cancel and resubscribe later, and build your retention story around keeping their data intact so coming back costs them nothing. Or look again at whether what you sell is a service consumed outside the app, in which case the guideline above moves the whole payment, and the freeze with it, into billing you control.
How long can a Google Play subscriber pause for?
One week to three months, and the exact choices depend on the recurring period. Google's documented lengths are one, two, three or four weeks for a weekly subscription, and one, two or three months for monthly, three month, six month and annual ones. Google adds that those lengths are subject to change at any time, so treat them as current rather than permanent. Pause is enabled by default on all subscriptions, and you disable it in Play Console if you do not want it.
The timing is the part worth copying. A pause takes effect only after the current billing period ends, so a subscriber who pauses on day three of a month keeps access for the rest of that month and the hold starts at the next renewal. While it runs they have no access and pay no renewal price. At the end of it the subscription resumes and Google attempts the charge. If that succeeds the subscription is active again. If it fails on a payment issue the subscriber goes into account hold, which is the same unhappy path as any other failed renewal. They can also resume manually at any point during the pause, and the billing date then moves to the day they resumed.
Two limits catch people. Prepaid plans cannot pause, which Google states plainly in the subscription resource it returns. And pausing or resuming a subscription that has add-ons is documented as not supported at this time. Neither of those is a bug to work around. They are shapes of plan where you need a different answer ready for the member who asks.
On the server there are two notifications, not one, and they mean different things. A pause schedule change fires when the subscriber asks for the pause, while the subscription is still active and they still have access. The pause itself fires later, when access actually stops, and the state becomes the paused one. The trap is in the client: Google documents that a paused subscription is not returned by the purchase query unless you include suspended subscriptions in the query parameters. Miss it and your app shows a paused member the sign up screen. If you have already wired up calendar sync, the same thought applies to their diary: a pause has to clear what is already booked inside it.
Google, Play Billing, subscription lifecycle and paused subscriptions, read 14 October 2026
What should your own freeze rules actually say?
Six decisions, and you want all six written down before any of it reaches a screen. Who can start a freeze, the member or your staff. The shortest and longest hold you will accept. How many holds somebody gets in a year. What a hold costs, if anything. When it starts. And what happens to the sessions already in the diary. Skipping the last two is what turns a small kindness into an argument at the front desk.
Google's shape is a reasonable template even when no store is involved, because it was designed by people who watched it go wrong at scale. A floor of one week stops the hold being used as a way to skip a single session. A ceiling of three months stops a frozen member sitting in your records forever looking like revenue. Taking effect at the end of the paid period means you never owe a credit for days already bought. Letting somebody resume early, with the billing date moving to the day they came back, keeps the arithmetic honest in both directions.
In your own billing the vocabulary matters more than it looks, because the two obvious operations are not the same operation. Stripe's subscription documentation separates pausing a subscription, which suspends service delivery and invoice generation and moves the subscription into a paused status, from pausing payment collection, which keeps the subscriber's access alive and only stops collecting money. A gym freeze is almost always the first one. A goodwill gesture to somebody mid dispute is almost always the second. Pick on purpose, and have your app listen for the pause and resume events so access follows billing instead of drifting away from it.
Then the diary. A frozen member with a class booked on Thursday is an empty seat you could have sold and a no show nobody will charge for. Freezing has to release every booking inside the frozen window, tell the member it did, and free the capacity back to everyone else. This is also where a hold differs most from a cancellation: you are keeping the relationship, the history and the preferences, so the resume should drop them back into the same timetable they left. The rest of the member record for a gym membership app is what makes that resume feel like nothing happened.
Google, Play Billing, pause lengths by recurring period, read 14 October 2026
Three ways to stop charging somebody, and what each one controls
| The question | A freeze in your own billing | Google Play pause | Apple in-app purchase |
|---|---|---|---|
| Who starts the hold | Either of you, usually staff on request | The subscriber, in the Play subscriptions centre | No |
| When the hold begins | Whenever you choose, including immediately | Only after the current billing period ends | No |
| Longest documented hold | No documented limit, it is your policy | Three months, or four weeks on a weekly plan | No |
| Keeps access while held | Your choice, both behaviours are available | No, access stops and no renewal is charged | No |
| Ending it early | Yes | Yes | No |
| Allowed for a gym or studio membership | Yes | Only if what you sell is digital, not the room | No |
Where this lands if a builder generated your app
A freeze is three small pieces of ordinary software: a state on the member record, a rule that stops the next invoice, and a sweep that releases bookings inside the frozen window. None of it is exotic, and all of it is specific to your policy, which is why no tool can hand it to you finished. What a builder can do is get the member record, the schedule and the payment integration standing so the freeze has something to act on.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, with two way GitHub sync so the code is somewhere you can read it. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and builds a standalone Android APK. It is $25 a month and there is no free tier. Because the project is an ordinary codebase, a freeze rule you write by hand on top of generated screens is just a change to a file, not a feature request to a closed platform.
One limit to plan around on iOS. Newly does not submit to the App Store for you, because Guideline 4.2.6 says apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content. You press submit, which also means you are the one answering review questions about how memberships are sold. Having the answer ready, that memberships are a service consumed outside the app and billed outside in-app purchase under 3.1.3(e), is worth more at that moment than any amount of polish on the freeze screen.
Questions people ask about freezing a membership
Yes, but who can do it depends entirely on who takes the money. If you charge a card on file yourself, a freeze is a rule you write and a state you store, with no store involvement and no documented limit. If the membership is a digital subscription sold through Google Play billing, Google has a built-in pause the subscriber chooses themselves, lasting one week to three months depending on the recurring period. If it is sold through Apple in-app purchase, there is no pause at all: Apple documents cancel and resubscribe instead.
Write the six rules, then build the screen
Decide who can freeze, for how long, how often, at what price, from when, and what happens to the bookings. Those six answers are the whole feature. The app around them is a description away.
Start building