A membership app tracks a state, not a card.
Nearly everyone who plans a membership app starts by drawing the card. The card is the least interesting part of it. A membership is a state: it starts on a date, it runs for a term, it renews or it lapses, and the only question anyone asks on a given morning is whether this person is in good standing right now. If the card really is the product, that is a membership card app, and it is a much smaller build.
This page covers what the membership record has to hold, what each way of proving membership at a door actually costs to build, why renewals fail in a way nobody chose, and why the member directory turns out to be the screen people open.
See how the status resolvesThe short version
Model the term and the lapse, and the screens follow.
A membership record is a term with a status attached: who, which tier, when it started, when it ends, and what happened at the end. Almost every feature anyone asks for later is a query over that. Who renews this month. Who lapsed in March and came back in May. Who is allowed through the door tonight.
The usual mistake is storing a boolean called active and updating it by hand. Status is derived from dates and from what the payment did, and once it is derived, nobody has to remember to flip it.
Lapsed and cancelled are not the same thing
Start with the fields, because the rest of the app is a view of them. A member has an identity, a tier, a term with a start and an end date, a renewal date that is not always the same as the end date, and a joined date that never changes even when the term does. Keep the joined date separate. It is what people mean when they say they have been a member for eleven years, and it has to survive a gap.
Then there is status, and this is where homemade systems go wrong. Active, lapsed, cancelled and suspended are four states with four different follow-ups. A lapse is a payment that did not happen, usually for a boring reason like a reissued card, and the member frequently does not know. A cancellation is a decision somebody made on purpose. A suspension is your decision, not theirs. Collapsing all three into not active means you email a person who already told you to stop, which is the fastest way to turn a quiet exit into a complaint.
So status should be computed, not typed. Given a term end date, a grace period and whatever the last payment did, the state is a small function you write once and call everywhere. The alternative is a column somebody updates on a Tuesday, and a year later nobody can tell you what it meant.
A grace period is a policy, and it belongs in the data
Most memberships keep working for a while after a payment fails, because the alternative is locking out a good customer over an expired card. That window is a number your organisation chose, so store it as a number rather than burying it in whatever the door check happens to do. When somebody asks why a lapsed member got in on the fourteenth, you want to be able to point at a field and a date.
Try it
What the status should say this morning
Status is a function of two dates and one event, which is why it should be computed rather than typed into a column by hand.
In grace
Let them through the door
5 days of grace left. Almost always an expired card rather than a decision, so let them in, chase the payment, and say which of the two it is.
What it costs to prove membership at a door
There are four ways a person proves they are a member, and they differ enormously in what they cost to build. Somebody looks them up by name. They show a plastic card with a number on it. They show a barcode in your app, which a scanner or a second phone reads. Or they show a pass in Apple Wallet.
The barcode is the cheap one and it is usually the right answer. The app draws a code from the member identifier, something at the door reads it, and the check runs against your own record, so a revoked membership stops working the same day. It needs no certificates and no relationship with Apple beyond shipping the app you were shipping anyway.
A Wallet pass is a different order of work. A pass is a signed bundle: a pass.json, a manifest listing SHA1 hashes of every file in it, a detached PKCS#7 signature and the images, zipped into a .pkpass file. Signing one requires a Pass Type ID certificate obtained through an Apple Developer account. Once it exists it can be emailed, downloaded from a web link or opened from a QR code, which is genuinely convenient for the member.
We checked the current Newly documentation for this and it does not mention Apple Wallet, PassKit or .pkpass anywhere. The integrations listed for v2 apps are Newly Backend, push notifications through OneSignal and purchases through RevenueCat, with other services handled by asking the agent to add them. So treat a Wallet pass as something to confirm against the docs as they stand on the day you build, not as a checkbox, and know that the certificate and the signing step are yours either way. If you want most of the effect now with none of that, draw the code inside the app.
It is worth separating all of this from a punch card scheme, where the card is the entire product and nothing expires. That is a loyalty card app, and it has no term, no renewal and no lapse to model.
Renewals fail quietly, which is the whole problem
A renewal is not an event you schedule, it is a payment that either happens or does not. Cards expire, banks decline, somebody moves account and forgets. None of that produces a person who meant to leave, and all of it produces a lapsed record unless something chases it.
Chasing failed payments has a name, dunning, and it is mostly a schedule: retry the charge, tell the member, retry again, then stop. The part people get wrong is the stopping. An unbounded retry loop against a dead card irritates a bank and a person at the same time. Decide in advance how many attempts and how many messages, write it down, and have the app do exactly that and nothing more.
Where you take the money is a separate decision with a rule attached to it. The App Store Review Guidelines state at 3.1.3(e) that if your app enables people to purchase 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, such as Apple Pay or traditional credit card entry. A gym membership, a club subscription and a society fee are all consumed outside the app. Read the current guideline against your own case before you commit to a path, because that boundary matters far more than the plumbing on either side of it.
Newly does not process card payments whichever path you pick. Taking money means integrating a payment provider under your own account, and the membership record then becomes a mirror of what that provider says happened rather than a source of truth about money.
The member directory is the feature people actually use
Ask a committee what the app is for and they will say renewals. Watch what happens after launch and the screen people open is the list of other members. That pattern is consistent enough across clubs, associations, alumni bodies and trade groups to plan around from the start.
A directory is also the part with real consequences if you get it wrong, because it publishes people to each other. Decide per field whether a member can hide it, default to hidden for anything a person would not put on a name badge, and let every member see exactly what others see of them. Consent given once at signup is not consent to appear in a searchable list.
The strongest version of this is a body where the connection outlives the subscription, which is why an alumni app is mostly a directory with a membership attached rather than the other way round. If that is your situation, build the directory first and the renewal machinery second.
Search matters more than layout here. People look for a name they half remember, a company, a year, a chapter. If search only matches the beginning of a surname, the directory is decorative, and the members will go back to asking each other.
What each way of proving membership costs you
| Option | Nothing for you to sign | Works with no signal at the door | Stops working the day you revoke it | What reads it |
|---|---|---|---|---|
| Name on a printed list | Yes | Yes | No | a person |
| Plastic card with a number | Yes | Yes | No | a person |
| Barcode drawn in your app | Yes | if the code is cached | Yes | a scanner or a second phone |
| Apple Wallet pass | No | Yes | the pass has to be updated | a pass reader or a scanner |
| Staff look the member up live | Yes | No | Yes | a person with the record open |
Building one around your own rules
Membership platforms are built for the median club and priced per member per month. They are good at renewals and rigid about everything else: a household tier that is one membership and four people, a year that starts in September, a committee that votes on applications, a lapsed member who keeps directory access for a season. None of those are exotic. They are just yours, and they are the reason the spreadsheet never quite died.
Newly is an AI app builder. You describe the app you want, including how your terms and tiers actually work, and it builds and ships a real mobile app you own. Plans start at $25 a month, there is no free plan, and iOS builds ship through App Store Connect. It is not a membership platform and it does not process card payments, so a payment provider under your own account is part of the plan from the first day.
The piece to settle before anything else is members signing in, because every question on this page reduces to knowing which record belongs to the person holding the phone.
Questions people ask about membership apps
It tracks who is a member, on what terms, and whether they are in good standing today. The record holds a tier, a start and an end date, a renewal date and a status, and every screen is a view over that. A card or a barcode is only one way of proving the state at a door, not the thing itself.
Describe how your membership actually works
Write down your terms, your grace period and what happens on the day a payment fails, then build the app around those rather than around a card.
Start building