Case study
A Pilates and rehabilitation group with nine locations was running bookings through a web portal most members opened on a phone anyway. We built a native iOS app that opens on their home studio and books a class in two taps.
Named only with client approval Figures marked are illustrative Reply within one business day
Good morning
Your account at a glance
Balance
12,480
OlDevs built a native iOS app in Swift and SwiftUI for a Pilates and rehabilitation studio group running nine locations in Washington State.The app opens on the member's home studio schedule, books a class or joins a waitlist in two taps, and delivers class reminders and waitlist offers as push notifications instead of email. Memberships, holds and saved payment methods sit in the same app, and a new API layer lets the existing web platform and the app read and write the same booking and membership records. The four month engagement reported a 31% reduction in Class no-shows, 3.4x Bookings made in the app and 9 Locations live at launch.
Key facts
The challenge
Booking ran through a web portal that most members opened on their phones anyway, and it listed all nine locations even when someone only ever attended one. Class reminders went out by email and were routinely missed, so spots held by no-shows sat empty while other members waited for them. Every membership hold, change and cancellation still came through the front desk by phone.
The portal listed the whole group's schedule, so a member who only ever attended one studio had to filter their way to it on every visit. The extra steps landed on a phone screen, where the portal was hardest to use in the first place.
Class reminders arrived in inboxes that members were not checking between appointments. Missed reminders turned into missed classes, and there was no channel fast enough to tell someone on a waitlist that a spot had just opened.
When a member did not show, the spot stayed held while other members sat on a waitlist for the same class. By the time anyone at the studio noticed, the class had started and the place could not be given to somebody who wanted it.
Holds, changes and cancellations all came in by phone, so staff spent their time on account admin during the hours when members were physically in the studio. Requests arriving after hours waited until someone could pick up the phone.
What we built
We built a native iOS app in Swift and SwiftUI that opens on the member's home studio schedule, books a class or joins a waitlist in two taps, and sends class reminders and waitlist offers as push notifications. Memberships, holds and saved payment methods sit in the same app, so a member can pause an account at midnight without phoning the front desk. The existing web platform stayed in place and gained a new API layer, so the site and the app read and write the same booking and membership records rather than drifting apart.
The app opens on the schedule for the location the member actually attends, with the other eight a switch away rather than a filter to work through. Booking a class or joining a waitlist takes two taps from that screen.
Class reminders and waitlist offers arrive as push notifications, so a spot released by a cancellation is offered to the next member while they can still act on it instead of sitting in an inbox unread.
Members place a hold, change a plan, cancel or update a saved payment method from the same app they book in, at any hour. Front desk staff keep a view of the cases that genuinely need a person to look at them.
Rather than replacing the web platform, we put an API layer in front of it so the site and the app write to the same booking and membership records. A change made on either side is immediately true on the other.
Process
Front desk and member research
We sat with front desk staff and listed every request that came in by phone, then followed a member through booking on the existing portal on their own phone to see where the steps piled up.
Mapping the existing platform
We read the current booking and membership data model and agreed what an API layer had to expose so the app and the website could share records without either one becoming a second source of truth.
Prototype on the two-tap path
The first working build did one thing: open on a home studio and book a class. We tested that path with members and staff before adding memberships, holds or payments to it.
Weekly demos through the build
Operations saw a working build every week, including the notification behaviour on a real device, so decisions about reminder timing and waitlist offers were made by watching them rather than reading a spec.
Launch across all nine locations
The web portal stayed live throughout, so nothing had to be migrated, and all nine locations went live on the same booking and membership records the site was already using.
Stack
iOS app
Shared API layer
Existing platform
Delivery
Quality and accessibility
−31%
Class no-shows
3.4x
Bookings made in the app
9
Locations live at launch
Outcomes
Push reminders reach members between appointments in a way email did not, and released spots are offered to the waitlist while there is still time to take them. The group reported a 31% reduction in Class no-shows.
Booking moved from a portal on a phone browser to an app that opens on the right schedule, which the group reported as 3.4x Bookings made in the app compared with the path it replaced.
Holds, changes and cancellations are self-serve, so staff are not working through phone admin while members are standing in front of them. Requests made after hours no longer wait for someone to pick up.
9 Locations went live on the same shared API, so a booking or membership change is the same fact whether it was made on the website or in the app, and the group is not reconciling two systems.
In their words
Members book their own classes and put their own memberships on hold now, so the front desk spends its time with the people actually in the room.
Studio operations manager, multi-location fitness and rehabilitation group
Fitness and rehabilitation
FAQ
No. The web platform stayed in place and gained an API layer, so the app and the site read and write the same booking and membership records. That kept the migration risk low, kept members who prefer the website working exactly as before, and meant the launch did not depend on moving historical data.
Push notifications, saved payment methods and the two-tap booking path all work better with native controls, and reminders are the part of this that changes attendance. A native Swift and SwiftUI app also gives you Dynamic Type and VoiceOver support properly rather than approximately.
Yes. We build Android in Kotlin and Jetpack Compose, and because this project already put a shared API layer in front of the booking and membership records, a second client is a smaller piece of work than the first. The contract the iOS app builds against is the same one Android would use.
We build to WCAG 2.2 AA, which for an iOS app means the interface works with Dynamic Type at large text sizes, is navigable with VoiceOver, and does not rely on colour alone to convey state. For a rehabilitation client that is a practical requirement, not a checkbox.
Four months, from the first look at the existing booking data model to nine locations live on the app. The order mattered more than the calendar: the shared API layer went in before the app was built on top of it, and operations saw a working build every week rather than a status report.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.