A staff rota app is judged on the swap, not on the schedule.
A staff rota app does two jobs: it publishes a schedule your team can read on their own phones, and it moves a shift from one person to another without a group chat. The schedule is a week of work. The swap is where these apps get abandoned, because a swap is not a message, it is a set of rules about who is allowed to work when. This page is about the second job. It covers the three states a swap needs, the checks the app has to run before it accepts one, and the part nobody expects: an app only your own staff will ever use does not have to sit in the public App Store at all.
Every distribution rule and figure below comes from Apple's and Google's own documentation, read on 14 October 2026. The rota mechanics come from how these apps are actually used, which is on a phone, one handed, at the end of a shift.
Start hereThe short version
Publish the rota, then make one button safe the claim button.
A rota has two states and your app needs both. A draft only managers can see, and a published version everyone works from. Staff get one screen showing their own shifts and a second showing the team. Every change after publishing gets a line in a log, because the first argument you will have is about whether a shift was moved.
The swap then runs offered, claimed, approved. Before the app accepts a claim it has to answer the questions a manager answers in their head: does this person hold the role, are they already working, does this break a rest gap, does it cross an hours cap, is there still minimum cover on the shift. On distribution, there is more room than people think. Apple documents unlisted App Store distribution and custom app distribution to named organisations, and Google Play lets you restrict an app to organisations you name. None of those put your rota in front of the public.
What does a staff rota app need on day one?
Four things, and the list is shorter than most people start with. A shift, which is a start time, an end time, a place and a role. A rota, which is a set of shifts over a date range, in exactly one of two states. A person, who holds roles and has a contract or an availability pattern. And a change log. That is the whole model, and you can describe it in a paragraph before anyone opens a design tool.
The draft and published split is the single most valuable thing in the list, and it is the one people leave out. Managers build next week by moving things around and changing their mind. If staff can see that work in progress, they plan their lives around a shift that was never real, and you spend Tuesday on the phone. One flag on the rota solves it. Nothing is visible to staff until a manager publishes, and publishing is a deliberate act with a notification attached.
Then two screens, in this order of importance. My shifts, which is a list of the next few things this one person is working, with the date, the time, the place and who else is on. That is the screen that gets opened, usually in a corridor, and it should answer the question in under a second without scrolling. The team rota, a grid of everyone across a week, is the manager's screen. It is harder to build, it is used far less, and building it first is the most common way these projects stall.
Leave three things out of the first version. Clocking in, which is a different product with hardware questions attached. Payroll, which brings rates and deductions and a reporting obligation you do not want on week one. And labour cost forecasting, which sounds useful and gets opened twice. If your business also takes bookings from customers, the rota is the staff facing half of the same calendar, and a booking app builder is the right place to start if you are building both sides. Build one side at a time even then. A rota that is trusted is worth more than two halves that are nearly done.
How should a shift swap actually work?
In three states: offered, claimed, approved. A shift the owner cannot work gets offered. Somebody eligible claims it. A manager approves, and only then does the rota change. Teams ask for the middle state to be removed, because it feels like friction. Remove it and you eventually get two people who have never closed up alone on a Saturday night, having traded a shift between themselves at eleven in the morning. The approval is the feature, not the delay.
The second thing worth knowing is that most swaps are not swaps. In practice the overwhelming majority are giveaways: one person cannot work Thursday and wants anyone to take it. A true one for one trade of two named shifts is rarer, harder to model, and harder to explain in a screen. Build the giveaway first. Let someone offer a shift, let the eligible people see it as an open shift, let one of them claim it. The trade can arrive later as a second kind of offer that happens to carry a shift back.
Who sees an open shift matters more than it looks. Broadcast every offer to the whole team and people turn notifications off inside a fortnight, which quietly breaks the app. Filter the offer to the people who could actually take it, by role and by whether they are already working, and send one notification rather than one per offer. A daily digest of open shifts plus an instant alert for anything inside two days covers most businesses better than alerting on everything.
Then give every offer a deadline. An offer with no claim by a cutoff goes back to the manager as a problem to solve, rather than sitting open until the morning of the shift. The same cutoff logic closes self serve swapping some hours before a shift starts, because a same day absence is not a swap and should not travel through the swap screen. Below is the list of checks the claim button has to pass. Tick the rules that are true in your business and you have the specification for that one button.
Check yours
What your swap screen has to check
Tick the rules your business actually runs on. Each one is a test the app has to pass before it accepts a claim, not a note in a handbook.
Nothing ticked. A rota with no rules can let anyone take anything, which is one screen and a weekend of work. Almost nobody runs that way, so tick what is true before you write the swap flow.
Does a staff only app have to be on the public App Store?
No. Apple documents three routes that are not a public listing, and all three were current when this was read on 14 October 2026. The first is unlisted app distribution. The app is on the App Store, but Apple states that unlisted apps do not appear in any App Store categories, recommendations, charts, search results or other listings, and are discoverable only with a direct link. Apple names employee resources as an example of a good candidate, alongside partner sales tools and research studies. It is the closest thing to what a shop or a clinic actually wants: a normal install, a normal update, and nothing in front of the public.
Two things about unlisted distribution are worth reading before you plan around it. It still goes through App Review. Apple declines unlisted requests if the app has not been submitted to App Review or if it is in a beta or prerelease state, so the app has to be finished. And the link is the only gate. Apple says in the same documentation that unlisted apps are available to anyone who has access to the link, and suggests implementing a mechanism within your app to prevent unauthorised use. A rota app needs sign in anyway, so that suggestion costs nothing. The request is two steps: a note in the Review Notes section of your submission, then Apple's separate unlisted app request form.
The second route is custom app distribution on Apple Business, the program Apple used to call Apple Business Manager. Apple describes a custom app as one you have created for a specific organisation, including a proprietary app for your organisation's internal use, and says you keep the code and your intellectual property. You set it in App Store Connect under Pricing and Availability, in App Distribution Methods, by selecting Private and entering an Organization ID. Only the organisations you name can see it, and they hand it out through mobile device management or redemption codes. The third route is the Apple Developer Enterprise Program, which is 299 USD per membership year and needs 100 or more employees. Apple is explicit that it is only for cases not adequately addressed by public apps, custom apps, Ad Hoc distribution or TestFlight, so for one site it is the wrong door.
Google Play has a direct equivalent and it is less fuss. In Play Console you open Test and release, then Setup, then Advanced settings, then the Managed Google Play tab, and add organisations under Organizations. Each one is identified by its Organization ID, which that organisation finds in its own managed Google Play admin settings. Google states the app will then be private and available only to those organisations, and that you can enter up to 1000 organisations per app. It needs a Google Play developer account, and registration can take up to 48 hours to process, so start it before you need it. For the account fees on both stores and what else lands on the bill, we have a page on what it costs to publish an app.
Apple, unlisted app distribution, read 14 October 2026
Google Play Console Help, publish private apps, read 14 October 2026
How do you get the app onto your team's phones?
Start with the testing tracks, because they cost nothing and they are the fastest way to find out whether the swap flow survives real staff. On iOS that is TestFlight, where Apple lets you designate up to 100 members of your development team holding the Account Holder, Admin, App Manager, Developer or Marketing role, each testing on up to 30 devices. On Android it is the internal testing track, where Google says an internal test can have up to 100 testers per app, and notes that internal tests might not be subject to standard Play policy or security reviews. Both numbers were checked on 14 October 2026.
Testing tracks are the right place for a two week trial with the supervisors and the wrong place for a tool your team depends on. The iOS side is the reason. Every internal tester has to be a user on your App Store Connect account with one of those roles, which is a lot of administration for a kitchen and gives people access you may not want them to have. Google's internal track is friendlier, because testers are just email addresses on a list, but a testing track is still a testing track and staff will notice it behaves like one.
For the permanent home, pick by who owns the phones. If your team use their own phones and you run no device management, unlisted App Store distribution plus a public Play listing or a private Play app is the simplest thing that works: you send a link, they install, updates arrive the usual way. Apple lists employee owned devices that are not eligible for management as a distribution target for unlisted apps, which is exactly the situation most small businesses are in. If you do run device management across company phones, custom app distribution on Apple Business and a private Play app are tidier, because the app appears in a catalogue the organisation controls rather than behind a link anyone can forward.
One rule applies whichever route you take, and it is the one that surprises people who used a builder. Apple's App Review Guideline 4.2.6, read on 14 October 2026, says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. The business whose rota it is has to hold the developer account and press submit. A tool can write the project and upload the build. It cannot be the one that submits on your behalf.
Apple, unlisted app distribution, read 14 October 2026
Google Play Console Help, publish private apps, read 14 October 2026
Four ways to hand a staff app to staff
| Route | Who can install it | Shows in store search | What it needs |
|---|---|---|---|
| Public listing, either store | Anyone | Yes | A developer account and a normal submission |
| Unlisted on the App Store | Anyone who has the link | No | Submit to App Review, note it in Review Notes, then send Apple the unlisted app request |
| Custom app on Apple Business | Only the organisations you name by ID | No | App Store Connect, Pricing and Availability, App Distribution Methods, Private |
| Private app on Google Play | Only the organisations you name by ID, up to 1000 per app | No | Play Console, Advanced settings, the Managed Google Play tab |
| TestFlight or Play internal testing | Up to 100 testers per app on each store | No | An email list, and on iOS an App Store Connect role for every tester |
Routes and limits from Apple's and Google's own documentation, read 14 October 2026. The Apple Developer Enterprise Program is a fifth route and is left out on purpose: at 299 USD a year and 100 or more employees, it is not the answer for a single site.
A rota app sells nothing, until you sell it to someone else
Worth saying plainly, because it saves a week of reading. A rota app your own staff use takes no money from anybody. There is no purchase, so there is no in app purchase question, no paywall, and none of the store commission arguments apply to you. The app is free, your staff are the only users, and the stores have nothing to take a cut of.
That changes if you decide the thing you built is worth selling to other businesses like yours, which happens more often than you would think. Then Apple's rules on how you charge start to matter. Guideline 3.1.3(c), read on 14 October 2026, covers enterprise services: if your app is only sold directly by you to organisations or groups for their employees or students, you may allow enterprise users to access previously purchased content or subscriptions, and Apple adds that consumer, single user or family sales must use in app purchase. Selling seats to a shop is one thing. Selling a subscription to a sole trader through the app is another.
So if that is where you are heading, read about adding payments before you design a pricing page, and decide which payment layer to use early, because moving subscriptions between layers after you have paying customers is genuinely painful. For the first version, for your own team, skip all of it.
Where this lands if a builder generates the app
A rota app is a good fit for describing rather than hand building, because the hard part is rules rather than interface. 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, runs it on cloud simulators while it builds, uploads iOS builds to TestFlight, publishes to Google Play internal testing, and can build a standalone Android package. It keeps two way GitHub sync, so the project is yours to hand to a contractor later rather than a configuration locked inside a tool. It is $25 a month and there is no free tier.
Describe the rules, not the screens. Write down the shift states, the three swap states, and every check from the list above as a sentence: nobody on two shifts at once, twelve hours between a close and an open, minimum two people on a Saturday evening, a manager approves anything over thirty eight hours in a week. Rules written that way turn into conditions on one button. Screens described without them turn into an app that lets anyone take anything.
Two honest limits. Newly does not submit to the App Store for you, because Apple requires the owner of the content to submit, and nothing about that changes for an internal app. And no builder fills in the unlisted app request or adds an Organization ID to your Play Console for you. Those are a form and two text fields, they take an afternoon, and they are the difference between a rota app your staff can install and a build sitting in a testing track.
Questions people ask about staff rota apps
Two things. It publishes a schedule your team can read on their own phones, and it moves a shift from one person to another without a group chat. Everything else is optional. The schedule needs a draft state only managers see and a published state everyone sees, a screen that shows one person just their own shifts, and a record of who changed what. The swap is the part that gets used every week, so it is the part worth building properly.
Write the rules down, then build the button
Start with the two rota states, the three swap states, and your own cover rules in plain sentences. That is the whole specification, and it fits on one side of paper before anybody writes a line of code.
Start building