A good app earns its place on the home screen by doing one thing noticeably better than the browser. It is there when the phone is locked, and when the signal is gone. We build iOS and Android apps from one codebase that feel native on each platform, work offline and ship on a predictable cadence.

Much of an app's value now sits outside its own screens: a notification at the right moment, a widget, an order's progress on the lock screen. Our guide Beyond the app icon covers what each of these can and cannot do.

Most app projects are one of three kinds.

Most of what people see of an app happens outside it. The four surfaces below are where an app earns attention without being opened. Each has its own rules on both platforms, and we design for those rules.

A notification is the app speaking when it is closed, so it has to be worth the interruption. Both platforms make people opt in: iOS asks the first time an app requests permission, and since Android 13 notifications are off until the person allows them. We ask when it makes sense, after the first order and not at first launch, which is what Apple recommends.

Then we keep the promise: one notification per event, sent when it happens, that opens the right screen. Marketing messages need explicit consent on the App Store, and the app gets a settings screen where people can change their mind.

A widget puts one piece of the app on the home screen or the lock screen: the next booking, the usual order, today's numbers. It is for glancing. Apple is clear that widgets are not small apps and do not update in real time: a widget that is viewed often typically gets 40 to 70 refreshes a day. A widget can carry a button or a toggle, so one tap can reorder or check in without opening the app.

Android widgets follow the same idea with their own sizes and refresh limits. We design each size deliberately and choose the one action that deserves the space.

A Live Activity shows something that is happening now: an order being prepared, a ride arriving, a workout. On iPhone it appears on the Lock Screen and, on models that have one, in the Dynamic Island. It also shows on a paired Apple Watch, in CarPlay and on the Mac. It can run for up to eight hours and stays on the Lock Screen for up to four more.

Android's equivalent is Live Updates, introduced with Android 16, for ongoing activities the person started, such as navigation, a call or a delivery. Neither platform allows ads or promotions there. We use them for tasks with a clear start and end, update them from the server, and end them the moment the task is done.

Notifications from your phone app already reach a paired watch. A watch app goes further: people act from the wrist in a few seconds, showing a pickup code, confirming a dose or starting a session. Apple's guidance notes that people use a watch app's notifications, complications and widgets more than the app itself, so we design those first.

An Apple Watch app can run without the phone app, and Google recommends the same for Wear OS. We build watch apps natively, in Swift and Kotlin, alongside the shared codebase.

Typing on a phone is slow and speaking is not. We add voice where it removes steps: say the order, dictate the note, ask for the booking. The app shows that it is listening, turns speech into text and then into an action the person confirms before anything happens.

Recent versions of iOS and Android can recognise speech on the device, which keeps the audio on the phone. Where a request needs more understanding, an AI model interprets it and the app asks before it acts. Our AI agents service builds the part behind the microphone.

Connections drop in lifts, in basements and on the road. The app stores what people need on the device, lets them carry on, queues their changes and syncs when the connection returns, settling conflicts by rules we agree with you.

Both iOS and Android decide when an app may work in the background. We design sync around what the system allows and never promise a fixed schedule.

Prototype early, lay solid foundations, then ship features weekly into testers' hands. Releases go out in stages: to a small share of users first, then to everyone once the crash-free rate holds.

Apps for both stores, the services behind them and a release pipeline your team can run. You own the code, the developer accounts and the data.

React Native and Expo with TypeScript for the shared code, and native code in Swift and Kotlin where the product needs it: widgets, Live Activities and watch apps. Behind the apps sit a typed API layer, push notifications through Apple's and Google's services, payments, analytics and crash reporting. Fixes to the shared code can go out over the air between store releases; native changes go through review.

Answers to the questions we hear most often about app projects.