A venue app from idea to App Store: the Pushka build
A venue app reaches the App Store once it covers one guest journey from arrival to bill, does things a website can't, has a staff side to receive requests, and passes Apple's review.
A venue app reaches the App Store once it covers one guest journey from arrival to bill, does things a website can't, has a staff side to receive requests, and passes Apple's review. Pushka, the guest app I built for a lounge in Dubai, went through the first three stages and was submitted to App Review on 27 October 2026, where it is waiting for Apple's decision at the time of writing.
Below is how that path works, which decisions shape the build, and what to prepare before you send anything to Apple.
Start with one venue and one guest journey
Pushka is the guest account for a single lounge in Dubai. It does not list other venues or act as a marketplace. That choice made every later decision easier: one floor plan, one menu, one cashback rule, one shift receiving requests.
Before you brief a developer, write the guest's evening as a list of moments. For Pushka it looked like this:
- The guest arrives for the first time and gets a card.
- Next time, they book a seat from home.
- On the way, they tell the shift they are coming.
- At the table, they browse the menu and ask for items.
- They watch the bill grow and see how much cashback will cover.
- They pay at the venue, and the visit lands in their history.
Each moment becomes a screen or a button. Anything that doesn't serve one of these moments waits for version two.
Decide what the app does that a website cannot
Apple's App Review Guidelines, section 4.2 (Minimum Functionality), say an app should go beyond a repackaged website. A menu and a "Book now" link inside an app shell is the classic rejection case. A website does that job well, and if your site is weak, fix it first. The Savage Media study of 537 Dubai venue sites found 147 of 409 fully analysed sites (35.9%) show the menu only as a PDF; my restaurant website checklist covers that side.
Here is how the tools split for a venue:
| Task | Website or QR menu | Guest app |
|---|---|---|
| Show the menu with prices | Yes | Yes, plus an offline copy and favourites |
| Book a table | Yes, through a booking widget | Yes, plus individual seats on the floor plan |
| Personal balance (cashback, deposit) | Needs a login portal | Built in, tied to the guest card |
| Live bill during the visit | Rarely | Yes |
| Notifications from the venue | Email or WhatsApp | Push |
| Tell the shift "I'm on my way" | No | One button |
If most of your rows sit in the left column, you need a better website. Pushka has something personal on every screen, which is what makes it an app.
Sign-in: let the venue create the card
The first sign-in in Pushka happens at the venue. A staff member shows a QR code, the guest scans it and lands in their own card. The venue creates the card, so a guest can't end up with a second, empty one.
After that, the guest signs back in with Apple, Telegram or a code sent to email. There is no password, and on a new phone the same card comes back.
Why this matters for a venue owner: duplicate profiles break loyalty. If a guest can register themselves from the App Store page, you get three cards for one person and cashback split across them. Tying the first entry to a physical visit keeps one guest, one card.
Two things to raise with your developer here. Apple's guideline 4.8 covers login services: if you offer third-party sign-in, Apple expects an equivalent privacy-focused option, and Sign in with Apple meets it. Guideline 5.1.1(v) requires that apps which let people create an account also let them delete it from inside the app. Put both in the scope from day one.
Booking by seat on the floor plan
The feature I consider the core of Pushka is booking on the floor plan. The guest sees the hall as it is, picks a table, and at the big table books individual seats. Confirmation comes as a notification, and cancelling takes one tap.
Hypothetical example: a group of three wants to sit at a long communal table on a Thursday night. With table-level booking, the venue either blocks the whole table for three people or turns them away. With seat-level booking, they take three seats and the rest stay open for other guests.
Questions to settle before design:
- Which tables are bookable, and which stay for walk-ins?
- How long does a booking hold a seat?
- Who confirms: the system automatically, or a person on shift?
- What does the guest see when a seat is taken?
The "On my way" button sits next to booking. The guest taps it, and the shift knows they are coming. It costs little to build and saves a phone call each time.
Order from the table and the live bill
In Pushka, an order from the table goes to the shift as a request. Nothing leaves the venue, and the app takes no payments. The menu covers kitchen, bar and tea, with photos, ingredients and prices in AED, and the guest can save favourites. A copy of the menu lives on the phone, so it opens without a connection.
The bill updates during the visit: what has been served, the running total, and how much cashback will cover. The guest chooses a payment method in the app, pays at the venue, and the cashier closes the bill.
Keeping payment at the till has two effects on the build. You skip card processing, refunds and payment disputes in the first version. And the in-app purchase rules in section 3.1 of the guidelines, which cover digital goods, stay out of the picture, because food and drinks served at the venue are physical goods consumed outside the app.
Cashback and deposit inside the guest card
Every closed bill in Pushka adds cashback. The guest sees the balance, the expiry date, and how much will be used on this visit. A deposit sits alongside it with a history of every movement. The visit history keeps past bills and the cashback earned on each.
The mechanics an owner has to decide, in writing, before development:
- Cashback rate, and whether it varies by category.
- Expiry period for unused cashback.
- Whether cashback can cover the full bill or only part of it.
- How a deposit is topped up and who can adjust it.
Developers can build any of these rules. What slows a project down is changing them after the screens exist.
The staff side receives what guests send
Every booking, "On my way" tap and table request has to reach someone on shift, or the guest app turns into a menu with extra steps. For this lounge I built a separate staff app, Pushka POS, which is in TestFlight. It sends push notifications and Live Activity cards on the Dynamic Island, and opens behind a Face ID lock screen.
How the two apps divide work, and what changes for the shift, is in my article on staff apps in venue operations.
Preparing for App Review
Pushka's guest app went to Apple on 27 October 2026. What Apple looks at in general is covered in what Apple checks in review. For a venue app specifically, prepare these:
- Reviewer access. If the first sign-in needs a QR code at the venue, the reviewer in another country can't scan it. Apple asks for a working demo account or demo mode in the review notes. Plan this path when you design sign-in.
- Review notes. Explain in plain words what happens at the venue: who shows the QR, what a "request" from the table means, where payment happens.
- Age rating. Pushka is rated 18+. Answer the age questionnaire honestly for what your venue serves.
- Screenshots in every language you list. Pushka has eight screenshots in English and eight in Russian: home, seat booking, cashback, menu item, table, onboarding, orders, tea grid.
- Account deletion reachable inside the app.
- Only shipped features. If a feature is behind a flag, keep it out of screenshots and the description.
What not to do
- Launching a marketplace first. Ten venues means ten menus, ten floor plans and ten sets of rules before anyone uses it. Start with one.
- Letting guests self-register from the store page when loyalty depends on one card per person.
- Building in-app payment in version one if the till already handles it. Show the bill and let the cashier close it.
- Using shop words like "checkout" or "buy" for a table request in the interface. In Pushka it is a request to the shift, and the wording sets what guests expect and how a reviewer reads the app.
- Shipping the guest app without a staff app or panel. Requests that land nowhere teach guests to stop pressing the button.
- Promoting regulated products in the store listing. UAE rules on tobacco and alcohol advertising apply to your App Store text and screenshots too; check with a lawyer before you publish. Show the venue, the table and the guest experience.
- Changing cashback rules mid-build. Fix them in writing first.
Budget and timeline questions for your developer
My apps start from AED 35,000 (Special offer), and the scope above is what moves the number up or down. For market ranges across freelancers and agencies, see the detailed cost figures in the Savage Media journal on app development cost in the UAE. The full project write-up is in the Pushka case, and the service itself is described on app development.
Ask any developer these before you sign:
- Who builds the staff side, and is it in this price?
- How will the App Review team sign in?
- Which features are version one, and which are written down for version two?
- Who owns the Apple developer account the app is published under?
- What happens if Apple rejects the build: who answers, and is the rework included?
Checklist
- Write the guest's visit as six to eight moments.
- Mark which moments need something personal to the guest; those justify an app.
- Decide how the first card is created and how guests sign back in.
- Draw the floor plan and mark bookable tables and seats.
- Fix cashback, expiry and deposit rules in a one-page document.
- Decide where payment happens; keep it at the till for version one if you can.
- Confirm who on shift receives bookings, "On my way" and table requests, and in which tool.
- Prepare a demo account and review notes that explain the in-venue steps.
- Produce screenshots for each listed language, showing only shipped features.
- Submit, and keep the developer available for Apple's questions in the days after.
Questions and answers
Does my venue need an app, or is a website with a QR menu enough?
If guests only read the menu and book a table, a fast website covers it. An app earns its place when it holds something personal to the guest, like a cashback balance, a deposit, a live bill or a reserved seat, and when your staff act on what the guest taps.
Can guests pay inside a venue app?
They can, but you don't have to build it. In Pushka the guest picks a payment method in the app, pays at the venue, and the cashier closes the bill. That keeps card processing out of the first version.
How long does Apple take to review a venue app?
Apple does not publish a fixed time, and it varies. Plan for at least one round of questions or a rejection, and keep a working demo account in the review notes so the reviewer can get past your sign-in.
What does a venue app cost in the UAE?
My apps start from AED 35,000 (Special offer). Market ranges for agencies and freelancers are collected in the Savage Media journal article on app development cost in the UAE.