iPhone and iPad applications built with SwiftUI

Building applications that belong on the platform

Apple users have strong expectations, mostly unconscious. Navigation should work the way it works everywhere else. A swipe from the edge should go back. Lists should scroll with the right physics. The keyboard should not cover the field being typed into. Dynamic Type should be respected so somebody who has chosen larger text can read the application. Dark appearance should look designed rather than inverted.

We build with SwiftUI, which gives us modern layout behaviour, sensible support for dark appearance and accessibility sizing, and interfaces that adapt properly between iPhone and iPad. Where a specific requirement calls for it we drop into the underlying frameworks, but the default is the platform way of doing things because that is what users find familiar.

Layouts account for the range of devices genuinely in circulation, from compact iPhones to large iPads, including split view where it makes sense on tablet. We handle the details that break less careful applications, such as safe areas around notches and home indicators, rotation, state restoration after the system suspends an application, and correct behaviour when a device is set to a language that reads right to left.

Notifications, privacy and permissions

Push notifications on iOS require the user to grant permission, and the moment you ask matters enormously. Asking on first launch before anyone understands the value produces a refusal that is difficult to reverse. We design the sequence so the request arrives when the benefit is obvious, which meaningfully increases the proportion of users who accept.

Privacy is central to how Apple evaluates applications. Every permission an application requests must be justified with a clear explanation shown to the user, the App Store listing must declare exactly what data is collected and how it is used, and applications that allow account creation must also allow account deletion. We prepare all of that accurately rather than optimistically, because a declaration that does not match behaviour causes rejection and damages trust.

App Store review, handled calmly

Applications are rejected regularly for reasons unrelated to code quality, including unclear demonstration accounts, missing explanations, incomplete privacy declarations or a feature that appears to duplicate something the platform provides. Handling this well is a matter of preparation and tone rather than luck.

We provide reviewers with working test credentials and clear notes explaining what the application does and how to exercise the parts that are behind a login. When a question comes back, we answer it precisely rather than resubmitting and hoping. Launch schedules always include review time as a real period rather than an assumption.

One backend, consistent everywhere

The iOS application talks to the same REST API as the web system and the Android application, built with Django REST Framework. This is what keeps the platforms consistent as requirements evolve, because a business rule changes once rather than three times. It also means adding iOS to an existing web system is considerably cheaper than building from nothing, since the interface it needs already exists.