Apps that behave in the real world.

Before we discuss frameworks we ask where and when your app will be opened. On a platform at a station? In a warehouse with gloves on? Late at night by someone anxious about a bill? Those circumstances decide more about a good app than any technology choice: how large the touch targets must be, what has to work offline, how much text a screen can bear.

We turn those answers into a short set of principles for the product and test every later decision against them.

Native development (Swift for iOS, Kotlin for Android) gives the closest fit to each platform and the earliest access to new features, at the cost of two codebases. Cross-platform toolkits such as Flutter or React Native share most code between platforms, which usually reduces cost and keeps behaviour consistent, with occasional extra effort for platform-specific features.

Neither is universally better. We will recommend one for your situation and write down why, including what would make us change our minds.

• Support for dynamic text sizes, screen readers (VoiceOver and TalkBack) and reduced-motion settings.
• Graceful offline states and retry behaviour rather than blank screens.
• Crash reporting configured with privacy in mind, and agreed with you before launch.
• A documented build and release process, so updates are not dependent on one laptop.
• Sensible handling of permissions — asked for at the moment they make sense, with a clear reason.

Apple and Google change their requirements every year, and phones change with them. An app that is not maintained will eventually be removed from sale or stop working on new devices. Our ongoing support covers those annual updates, and our publishing service handles the submissions.