A membership management app is an admin tool with a member app attached.
Most of the work in a membership management app is not the part members see. A member opens it a few times a year: to check they are paid up, to look someone up, to show a code at a door. The committee is in it every week, adding people, correcting a name, working out who lapsed in March and who is about to. Two audiences with opposite needs share one list, and that is what makes membership and fitness apps harder to get right than they look.
This page covers who is allowed to change a record, where membership dues can be collected, what it takes to prove membership at a door, and what has to be true for the list to survive the next change of committee.
See what each role can doThe short version
One list, several sets of rights, and a handover every year.
A membership record is shared by people who should not have the same powers over it. A member ought to fix their own phone number and read a limited view of everyone else. A membership secretary adds, merges and corrects anybody. A treasurer needs to see who has paid without being able to rewrite the roll. Homemade systems usually offer two settings, read only or everything, and then leak somebody's arrears into a shared spreadsheet.
The second fact is turnover. Clubs and associations change officers, often every year, so the app has to hand over cleanly: no personal account holding the only copy, no file that left with the last secretary. Design for the handover and most of the other decisions get simpler.
Write the permission table before you design a screen
Start by listing every action the app allows, then say which role may do it. Add a member. Edit somebody else's details. See a phone number. See what someone paid. Mark dues received. Change a category. Export the list. Delete a person. Four roles cover most organisations: member, committee, membership secretary and treasurer. A membership app for clubs that skips this step ends up with one admin password that everyone knows.
Two rules save the most trouble later. First, a member may edit their own record and nothing else. Second, anything that touches money or status is done by a named role and leaves a trace: who did it, when, and what the value was before. Once dues are involved somebody will eventually ask why a record says what it says, and a shrug is not an answer.
Field level visibility matters more than people expect, because a directory is personal data that members did not necessarily agree to publish. Let each person choose per field: show my email, show my phone, list me by name only, hide me. That is a small amount of work at the start and an argument you never have afterwards. A body where the point is members finding each other, like an alumni engagement app, stands or falls on getting that consent right, and half the people searching for a member directory app want only this: a searchable list with the right things hidden.
Try it
Who is allowed to change what
Pick a role. These two lists are the permission table, and writing it down comes before designing a single screen.
Member can
- Edit their own contact details
- Search the directory
- Show their own code at the door
Member cannot
- See what anyone else paid
- Edit another record
- Export the list
Where the dues arrive decides what the app may do
A subscription membership app has to answer one question before it picks a payment route: where is the thing being bought actually used? The app stores draw their line there. Apple's guidelines say that if you unlock features or functionality within your app, including subscriptions and access to premium content, you must use in-app purchase, and that apps may not use their own mechanisms to unlock content or functionality. Licence keys and QR codes are named in that list, so the obvious workaround is closed off in writing.
The other half of the rule points the opposite way. Section 3.1.3(e) says that if your app enables people to purchase physical goods or services that will be consumed outside the app, you must use purchase methods other than in-app purchase, such as Apple Pay or traditional credit card entry. Dues that buy entry to a building, a court, a class or a clubhouse are that case. A gym membership app is the clearest version of it: what the member bought gets used in a physical room.
So read your own membership against that line before you choose anything. Access to premises and events sits outside in-app purchase. A membership whose entire value is a members only feed inside the app sits inside it. Many organisations are a mix, and the common answer is to collect dues on your own website and let the app read the resulting status, which keeps the purchase out of the app altogether. Read the current wording of both sections against your own case before you commit to a payment route.
Apple App Store Review Guidelines, sections 3.1.1 and 3.1.3(e)
Proving membership at the door
Sooner or later somebody stands at a door and has to be let in. There are four ways that happens: a name on a printed list, a plastic card, a code on the member's phone, or a credential issued by the building's own access system. Only one of those is cheap to build and entirely under your control, which is the code on the phone.
The mechanics are ordinary. The member's screen shows a QR code carrying an identifier, and a phone at the door reads it and checks it against the member list. Expo's camera module, which is what a React Native app uses for this, lists qr among the barcode types it reads on both iOS and Android, through a barcode scanner setting and one callback. Newly writes React Native and Expo projects, so that path is open to a build, and the camera permission has to be declared in the project config, with a purpose string for iOS, or review sends the app back.
The door reader is the part to be plain about: we did not verify it. A reader opens for credentials its own access control system issued, in its own format, so unless your access vendor exposes an API or accepts an identifier you generate, an app cannot make that door open. Treat staff phone scanning as the thing you can build, and treat anything involving turnstiles as a conversation with the vendor first.
Two details decide whether the code is any good. Make it expire, because a static code that identifies a member forever is one screenshot away from being shared, so encode a short lived token and accept it for a minute or two. And decide what happens with no signal, because door frames are where mobile data dies: a scanner that must reach a server fails at the worst moment, so keep the current member list on the scanning device and reconcile afterwards.
Expo SDK, Camera: barcode scanner settings and supported types
The list has to outlive the committee
The usual failure of club administration is not a missing feature, it is three lists. Membership on a spreadsheet, dues in a payment dashboard, contact details in a mailing tool. Nothing reconciles, so every question needs a person to cross check three places, and the answer depends on who you ask. The value of one app is that one of those becomes the record and the others read from it.
That makes export a first class feature rather than an afterthought. An organisation that cannot get a clean file of its own members out of its own system is captive to it. Test the export before the first renewal round, not during it, because the moment you need it is the moment something has already gone wrong.
Handover is the same problem in slow motion. Records belong to the organisation, not to whoever set the account up, which in practice means more than one administrator, no single personal login, and a written note of where the list is kept and who can reach it. A committee that turns over every year will otherwise learn this the expensive way, usually in the week the renewal notices should have gone out.
What each way of running a membership gives you
| Approach | One list everyone trusts | Members edit their own details | Dues collected | Proof at the door |
|---|---|---|---|---|
| Spreadsheet plus an email list | one copy per officer | No | matched by hand | No |
| Payment dashboard on its own | payers only | card details only | Yes | No |
| Membership platform, priced per member | Yes | Yes | Yes | their card or pass format |
| Plugin on your own website | Yes | Yes | Yes | No |
| A membership app you build | Yes | the fields you allow | processor you pick | a code your own scanner reads |
Building one around how your organisation actually works
Membership platforms are built for the median organisation and priced per member per month, so the fit is usually about eighty percent. The missing part is always specific: a family membership that is one payment and four people, a life member who never renews, a waiting list that becomes a category on the first of January, a rule that a lapsed member keeps directory access for a year, a discount only the treasurer may apply.
Newly is an AI app builder. You describe the app you want, including the categories and the rules that go with them, and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month, there is no free plan, and iOS distribution needs your own Apple Developer account. It does not process card payments, so dues go through a processor you choose.
One decision comes before any screen, and that is where the member list lives. Membership data is small and slow moving, but several people write to it and it has to be right, which points at a hosted database rather than anything kept on a phone.
Questions people ask about membership management apps
It keeps one record per member and one truth about their standing: who they are, which category they are in, when the term started, when it ends, and whether they are in good standing today. Everything else is a view over that: the directory, the renewal list, the arrears list, the check in at the door. The admin side is the bigger half of the build.
Describe how your membership actually works
Write down your categories, your grace period, who is allowed to change a record, and what happens at the door, then build the app around those rules.
Start building