Native-feeling interaction
Touch-friendly controls, considered gestures and clear feedback.
Mobile Applications
Made for everyday moments
Build mobile apps for a connected world.
High-quality applications for iOS, Android and cross-platform experiences.
Consumer AppsBusiness AppsE-commerce AppsCustom Mobile Apps
Start a conversation 
Why it matters
A small screen. A complete experience.
Great mobile products fit the way people actually live and work, with clear interactions, considerate details and performance that feels immediate.
Cross-platform thinking
Consistent product logic with platform-aware details.
Performance that feels fast
Responsive states and lightweight screens.
Ready for real life
Accessible layouts and support for changing screen sizes.
Ways we can help
Designed around the work.
Start with the outcome. Then shape the right experience, tools and technical foundation around it.
Discuss a project
Everyday consumer tools
Focused everyday tasks with fast entry, useful reminders, personalisation and simple recovery after interruptions.
Business and team apps
On-the-go tools for field work, approvals, checklists, reporting and secure access to the information teams need.
Shopping and payment journeys
Browse, compare, save, pay and track orders with careful input design and clear feedback at every step.
Purpose-built mobile products
Specialised app flows that use device features only when they make the core job materially easier.
What sits beneath the surface
Built for life in motion.
Mobile apps need to work in short sessions, on small screens, across changing network conditions and alongside platform conventions. Every tap, permission request and interruption needs to feel deliberate.
A focused mobile journey
Prioritise the main tasks people need while moving. Reduce setup friction, keep navigation predictable, and help users resume a task after a call, a notification or an app restart.
Platform-aware interaction
Respect iOS and Android conventions for navigation, status bars, gestures, text scaling, keyboards, safe areas, accessibility services and system feedback—even when sharing a cross-platform codebase.
Local state and connectivity
Decide what should remain available offline, how changes sync, how conflicts are resolved, and what the user sees when a request is pending or a network disappears.
Notifications and background work
Use notifications for meaningful, timely information—not noise. Plan opt-in permission timing, deep links, background refresh and battery-conscious scheduling.
Privacy and device capabilities
Handle camera, microphone, location, files, biometrics and contacts only when the feature genuinely needs them. Explain permission value and provide graceful alternatives when access is declined.
Release and ongoing care
Account for platform versions, device sizes, crash diagnostics, app-store metadata, signing, review requirements, staged releases and a safe way to fix urgent issues.
A considered process
How we shape, build and release a mobile application.
The process keeps the main user journey central while validating device realities early enough to influence architecture and design.
Understand the mobile moment
Identify who uses the app, where and when they use it, how long tasks take, what interruptions occur and which outcomes matter most.
Output: mobile brief, priority journeys and usage context.Set platform and device scope
Agree iOS/Android targets, minimum OS versions, device classes, native or cross-platform strategy, required hardware features and release constraints.
Output: platform matrix and technical decision record.Map navigation and recovery
Design onboarding, identity, primary navigation, deep links, interrupted sessions, error recovery, empty states and the route back into unfinished work.
Output: user flows and screen inventory.Prototype touch-first interactions
Test reach, target size, gestures, keyboards, screen-reader labels, text scaling, forms, loading behaviour and permission requests on small screens.
Output: validated mobile interaction prototype.Build app and local state
Implement presentation, domain logic, persistence, secure credential handling, networking, app lifecycle behaviour and clear separation of concerns.
Output: functioning app foundation.Integrate devices and services
Connect APIs, notifications, deep links, camera or other agreed capabilities; define offline queues, sync rules and conflict resolution.
Output: complete main journeys with device integrations.Validate on real conditions
Test real devices, OS versions, low connectivity, permission denial, interruptions, background/foreground transitions, accessibility and crash recovery.
Output: device test matrix, fixes and release candidate.Publish and maintain
Prepare signing and store materials, roll out carefully, monitor stability, respond to feedback and plan compatibility and security updates.
Output: release checklist, ownership plan and improvement backlog.Engineering and quality
The realities beyond the screen.
Mobile architecture must balance responsiveness, platform integration, data safety and the practical work of maintaining releases.
App architecture
Clear separation between presentation, domain rules and data services to make features testable and maintainable.
Device and OS support
Platform-compatible navigation, lifecycle management, safe areas, keyboards, permissions and version-specific behaviours.
Offline-first decisions
Local cache and persistence only where useful, visible sync states, conflict handling and safe retry behaviour.
API and identity
Secure transport, token refresh, session expiry, robust validation and predictable handling of server failures.
Accessibility and quality
Screen-reader labels, scalable text, touch targets, focus order, contrast, crash-free behaviour and test coverage.
Release readiness
Signing and secrets, store listings, privacy disclosures, staged rollouts, version compatibility and a plan for updates.
A deeper look at the discipline
A mobile app is a personal product used amid movement, interruption and changing conditions.
A mobile experience must work on a small screen, with touch, during short sessions and when the network or application lifecycle changes unexpectedly. The platform is part of the product: permissions, deep links, notifications, safe areas, battery usage and accessibility all shape whether the app feels reliable.
01 / Real-world context
Design around short sessions and interruptions
We map the most common tasks and remove steps that are hard to complete on the move. Onboarding should explain value before requesting sensitive permissions; a call or system interruption should not erase progress; and a returning user should understand where they left off. Navigation needs to be consistent, with clear loading, confirmation and error feedback.
02 / Platform choices
Choose native, cross-platform or hybrid deliberately
The technology approach depends on required device capabilities, visual expectations, performance, release cadence, existing skills and long-term ownership. Sharing code can improve consistency but does not remove platform-specific work. We plan for safe areas, keyboard behaviour, OS lifecycle, accessibility services, signing and the support window for each targeted platform.
03 / Offline and device capabilities
Make connectivity and permissions understandable
The product must distinguish between data saved locally and data synchronised successfully. Queued edits need retry and conflict rules. Camera, location, microphone, biometrics, files and contacts should be accessed only when the feature needs them, with useful explanations and a graceful alternative when permission is denied.
04 / Release and ongoing care
Treat the store release as an engineering milestone
Testing covers different screen sizes, OS versions, network states, lifecycle transitions, performance, crash recovery and real-device behaviour. Release work also includes signing, store listings, privacy disclosures, staged rollout, crash diagnostics and a plan to respond to user feedback and platform changes.
Definition of done
Mobile quality means more than passing a happy-path demo.
Testing has to represent the conditions in which people actually use their phones—not just a single new device on a fast connection.
Touch, text and accessibility
Controls are comfortably targetable, layouts survive text scaling, screen readers receive useful labels and focus order remains understandable.
Lifecycle resilience
The app handles calls, backgrounding, force-close, rotation where supported and restored sessions without corrupting work or losing important context.
Network and sync states
Offline, pending, failed and successfully synchronised states are visually distinct; retries are safe and conflicts have a clear resolution path.
Permission restraint
Sensitive capabilities are requested in context, explained in plain language and not treated as mandatory when the product can degrade gracefully.
Performance and battery
Startup, navigation, scrolling, media and background tasks are measured on representative hardware to avoid sluggishness and excessive power use.
Release integrity
Signing, privacy statements, store metadata, supported OS versions, crash reporting and staged rollout are checked before and after publication.
Capability map
Build for the conditions people actually use a phone in.
A mobile app has to work during short sessions, interruptions, network changes, one-handed use and differences between operating systems and devices.
Platform and navigation model
Choose native or cross-platform implementation based on capabilities, schedule, team and long-term support. Respect each platform’s navigation patterns, safe areas, keyboard behaviour and lifecycle.
Onboarding, identity and recovery
Make first use understandable and minimize unnecessary setup. Cover sign-in, recovery, session expiry, device changes and the return path when a user leaves mid-task.
Touch interaction and accessibility
Design target sizes, gestures, focus order, screen-reader labels, scalable text, contrast and clear feedback for loading, success, validation and failure.
Device features and permissions
Use camera, microphone, location, biometrics, files or contacts only when they support a real feature. Explain permissions when needed and offer a graceful path if access is refused.
Offline behaviour and synchronisation
Identify what can be viewed or edited without a connection, how queued actions retry and how conflicts are resolved. Show the difference between saved locally and safely synced.
Notifications, analytics and releases
Make notifications opt-in and useful, route deep links to the right screen and measure product health without collecting unnecessary personal data. Plan signing, store metadata, staged rollout and update support.
Scope and handover
The pieces needed for a usable mobile release.
Delivery must cover the product experience, device behaviour, platform requirements and the ongoing process of shipping safe updates.
Platform and device matrix
Supported OS versions, device classes, screen sizes, orientation, accessibility and the limits of each platform target.
Mobile journeys and prototype
Onboarding, main tasks, navigation, forms, permission timing, interruption handling and empty/error/sync states.
Application and data structure
State management, persistence, API layer, identity handling, secrets storage and separation of interface from domain rules.
Device and notification integration
Validated use of device APIs, deep links, notification preferences, background tasks and permission fallback behaviour.
QA and release package
Tests across representative devices, crash/error checks, performance profiling, signing, store assets and release notes.
Update and support plan
Version compatibility, phased deployment, telemetry, privacy disclosures, issue triage and a clear process for follow-up fixes.
Questions worth answering
A few practical questions.
Clear expectations make better projects. These answers describe the decisions usually worth making before work begins.
Discuss your requirementsShould we build native or cross-platform?
It depends on required device capabilities, performance, visual complexity, target platforms and maintenance strategy. The choice should follow product constraints rather than a one-size-fits-all rule.
What should work offline?
That depends on the job. Decide which data is cached, which actions can be queued, how conflicts are shown and when an action must wait for confirmation from a server.
How should notifications be used?
They should carry timely value, respect user preferences and lead to a relevant screen. Avoid requesting permission before users understand the benefit.
What does release readiness include?
Device/OS testing, accessibility, crash and performance checks, signing, privacy declarations, store review details and a plan for monitoring and updating released versions.
Selected directions
Different challenges.
Thoughtful solutions.
Examples of the kinds of experiences and systems that this discipline can make possible.
01 / Selected direction
Everyday companion
A focused experience designed for quick, repeat use.
02 / Selected direction
Mobile business workspace
Key workflows designed for teams on the move.
03 / Selected direction
An organised workday
A clearer way to plan and act across devices.
Have an idea?
Let’s make it
real.
Bring us the ambition, the problem or the rough sketch. We’ll work through the right next step together.
Connect with Black Hole