What makes a good mobile app?
A good mobile app does a few things well for someone who is not sitting at a desk. Designing one is deciding how it behaves: what it opens on, what happens when a call interrupts it, what it shows when the internet is unavailable. Underneath that sits a build decision with two answers: native, a separate build for iPhone and for Android, or cross-platform, one build serving both stores. A website you can fix this afternoon. An app has to go back through a store.
What makes mobile design different from web design?
Mostly, that a phone gets interrupted. A browser tab sits there until someone closes it. An app gets a call, a notification, a train arriving, or a pocket. That is the normal case rather than the edge case, so every flow has to survive being left halfway and picked up later. A form that loses what was typed, a checkout that restarts at step one, an upload that dies on a lock screen: none of those is a bug. Each is what happens when a flow was designed without the proper considerations.
Then there is what the connection costs. For a South African audience that is not a rounding error, and our user research identifies the price of mobile data as a real design constraint. So images earn their kilobytes, recent content is cached so there is something to show when the signal drops, and the offline state is designed rather than left to default. There is a test you can run on any app you already have. Turn on aeroplane mode, open it, and see whether it explains itself or just breaks.
Should it be built once or twice?
Twice means native: one build for iPhone, another for Android. Each can use everything the phone offers on the day the phone offers it, and each behaves like the other apps on that device because it is made from the same parts.
Once means cross-platform: a single build that goes to both stores. It costs less and it reaches both audiences at the same time, but it gives up some of that native feel. How much depends on whether the design follows each platform's own conventions or averages them.
Most apps could go either way, and this is rarely the first thing to settle. What decides it in practice is how much the app leans on the phone itself, how quickly you need to be in both stores, and who will maintain it after launch. We design so the decision can stay open as long as possible, and when it is made, the design carries across rather than starting again.
What decides the build
- What the app needs
- Gesture-led interaction, where how it moves is the point
- The build
- Native
- What that buys
- The most room to make movement feel right
- What the app needs
- Camera, background tasks, offline sync, anything deep in the phone
- The build
- Native
- What that buys
- Direct access, on the day the platform ships it rather than whenever the shared tooling catches up
- What the app needs
- Both stores, on one budget and one timeline
- The build
- Cross-platform
- What that buys
- One codebase and one team instead of two
- What the app needs
- Browsing, booking, accounts, messages: patterns people already know
- The build
- Cross-platform
- What that buys
- Those patterns translate cleanly, so what you save goes into the design rather than into a second build
| What the app needs | The build | What that buys |
|---|---|---|
| Gesture-led interaction, where how it moves is the point | Native | The most room to make movement feel right |
| Camera, background tasks, offline sync, anything deep in the phone | Native | Direct access, on the day the platform ships it rather than whenever the shared tooling catches up |
| Both stores, on one budget and one timeline | Cross-platform | One codebase and one team instead of two |
| Browsing, booking, accounts, messages: patterns people already know | Cross-platform | Those patterns translate cleanly, so what you save goes into the design rather than into a second build |
Where we stand on Mobile Apps
- 01Websites get closed. Apps get interrupted, and a flow that cannot be left halfway will be abandoned there.
- 02An app that follows the conventions of the phone it runs on needs no explaining. One that ignores them teaches every user something they did not ask to learn.
- 03For a South African audience the price of mobile data is a design constraint. Every megabyte you do not send is money you are not spending on your users' behalf.
- 04Offline is a state, not an error. A well-made app holds what it last knew and picks up where it stopped.
- 05Native or cross-platform is a build decision, and rarely the first one. Settle what the app does before you settle what it is written in.
- 06An app is never finished at launch, because the next OS release can break it. Deciding who fixes that belongs at the start of a project. We do it for clients who don't have an in-house team, and hand over to those who do.
Work featuring Mobile Apps
What’s included in Mobile Apps?
- iOS & Android app design
- Interfaces designed to each platform's own navigation, type, iconography and gesture.
- Cross-platform design
- One design system serving both stores, with platform-specific variations where convention demands them.
- Mobile-first flows
- Primary actions in reach, steps that survive a pocketed phone, progress that is never lost.
- Onboarding & activation
- The first session designed as its own problem: what a new user must understand, do and be shown before the app is worth keeping.
- App accessibility
- Dynamic type, contrast, screen-reader semantics and touch-target sizing, designed in from the first screen.
- Data-light design
- Assets that earn their weight, caching that holds recent content, and offline states designed rather than defaulted.
Final questions
How much does app design cost?
Three things move the number: how many flows and roles the app carries, whether it ships to one platform or both, and how far the prototype goes before code starts. We quote per project, not per hour. Working from South Africa also means our rates land well under what European and US studios charge for the same craft. Tell us what the app must do and we will scope it.How long does it take to design an app?
A focused first version (research, flows, visual design and a tested prototype) typically runs six to ten weeks. Apps with many kinds of user, or interactions nobody has seen before, take longer, and design usually continues alongside development as screens meet the real thing. The fastest projects are the ones that settle the riskiest flows in a prototype before visual polish begins.Do you actually need an app, or would a website do?
Often a website is the better answer, and we will say so before you spend anything. An app earns its place when people come back to it often, when it has to work with no signal, or when it needs to keep doing something while it is closed. If what you are building is content, a booking, or a form somebody fills in once, a mobile website reaches everyone immediately, costs less, and needs no install. The question worth asking is whether anyone will open it a second time. An app nobody reopens is a website with an install step in front of it.What is the difference between app design and app development?
App design decides what the product is and how it behaves: research, flows, interfaces, prototypes and the visual system. App development makes it real: engineering the design into native or cross-platform code, integrating services, and shipping to the stores. They are different crafts that work best close together. At Hominum one engagement can carry an app from first research through design into a built, launched product, and on into the updates that follow it.What happens after the app launches?
It needs an owner. Phones get a new operating system version every year, and an app that worked on the last one can break on the next without anyone touching it. Some of our clients have in-house development teams and take that on themselves. For those who do not, we submit the app to the stores and run a maintenance plan covering the updates, including the ones an OS release forces. The length of that plan is set per project rather than sold as a standard package.