When the iPad is the whole point
If you’re building a phone app that should also work on iPad, you don’t need this page — that’s one codebase and one project, and we say so on our iPhone page. This is for the other kind: the counter, the van, the warehouse, the clipboard being replaced. There the tablet isn’t a bonus screen size, it’s the device the work happens on.
Where iPad is the right device
Kiosk and self-service
Check-in, ordering, sign-up or survey terminals — locked to one app, mounted, and usable by someone who has never seen it before.
Point of sale
Counter and mobile till systems, with card readers, receipt printers and cash drawers connected over Bluetooth or the network.
Field work and inspection
Forms, photos, signatures and checklists captured on site — often with no usable connection, which makes offline the core requirement.
Clinical and care records
Structured capture at the bedside or chairside, where a phone screen is too small and a laptop is in the way.
Sales and showroom tools
Configurators, catalogues and quoting apps handed across a table — built for being looked at by two people at once.
Annotation and markup
Drawings, plans and documents marked up with Apple Pencil, where precision input is the entire reason for the device.
A stretched phone app is obvious
An iPad app that’s a phone layout scaled up reads as unfinished immediately, and on a tablet-first product that’s the whole impression.
- The screen wants two panes. A list beside a detail view, rather than a phone’s push-and-go-back. It’s a different navigation model, not a wider one.
- Multitasking is expected. Split View and Slide Over mean your app can be resized to a narrow column at any moment. It has to stay usable.
- Keyboard and trackpad get used. Many iPads live in keyboard cases. Tab order, shortcuts and pointer hover states stop being optional.
- Orientation isn’t decorative. A mounted kiosk is landscape forever; a handheld inspection app flips constantly. Decide, then build for it.
- Reach is different. Thumbs land at the sides of a tablet, not the bottom — so phone-style bottom bars end up in the least reachable place.
Deployment is half the project
Underestimated every time. For a tablet-first app, getting it onto devices and keeping it there is as much work as building it.
- Kiosk lockdown so the device runs one app and can’t be exited by a curious customer
- Mobile device management for installing, updating and wiping across a fleet you don’t physically hold
- Private distribution for internal apps that shouldn’t be publicly listed
- Offline-first data, with a sync that resolves conflicts when two devices edited the same record in a dead zone
- Hardware pairing for printers, scanners, readers and payment terminals — and what the app does when one disconnects mid-task
- Battery and charging reality for a device used all shift
We scope this up front rather than discovering it in week six, because it’s where these projects overrun.
Common questions
Are you charging us twice for iPhone and iPad?
No, and we’d say the same if you asked on the iPhone page. It’s one React Native codebase and one app. What this page covers is the extra work that exists when iPad is the primary device — tablet layouts, multitasking, kiosk lockdown, fleet deployment, offline sync, hardware. If you just want your phone app to look right on an iPad, that’s included in the build and not a separate line.
Will it run on Android tablets too?
Usually, from the same codebase — which is often worth having even if you start on iPad, because hardware choices change and Android tablets are frequently cheaper to deploy at scale. The layout work largely carries across; device testing doesn’t, so we scope that separately.
Does it work without a connection?
If we build it to. Offline-first is a deliberate architecture, not a setting — local storage, a sync queue, and a decided answer for what happens when two devices changed the same record. For field work it’s the most important requirement in the brief, so it belongs in the first conversation.
Can it talk to our existing system?
Yes, if it has an API or we build one. Tablet apps are usually a front end onto something you already run, and that integration is often the larger half — see software development.
Do we need to list it on the App Store?
Not for internal apps. There are private distribution routes that keep it off the public store entirely. If it is public, store presentation matters — see app store optimization.
Where will the iPads actually live?
Mounted on a counter, carried in a van, handed to a customer? That answer shapes the whole build — tell us that and what they need to do, and we’ll scope it.