Service — Mobile app design built native, iOS HIG, Android Material, no ported web.

The fastest way to ship a bad mobile app is to take a web layout, shrink it, and call it done. The fastest way to ship a frustrating one is to ignore the platform: build the same UI for iOS and Android, ignore HIG, ignore Material, ignore the system back gesture, ignore accessibility.

We design native, meaning iOS apps follow Apple's Human Interface Guidelines (HIG), Android apps follow Material Design 3, and both respect the platform behaviours users already know. Tab bars where Apple expects tab bars. Bottom sheets where Android expects bottom sheets. System back navigation that does what users have learned it does.

For products that need both platforms, we design them in parallel with shared logic but platform-specific UI. That's slightly more design work than building one cross-platform layout, and it's the difference between an app users tolerate and an app users prefer.

6-week sprint. Same three-phase shape as our other services:

Week 1 is structural. Mobile IA, navigation model, primary flows, platform decisions (iOS-first, parity Android, or both in parallel), permission and onboarding strategy. Real go/no-go boundary at end of Week 1.

Weeks 2–5 are execution. Native high-fidelity screens for every primary flow. Every state. Platform-specific where it matters, shared where it doesn't. Friday demo every week.

Week 6 is handoff. Engineering-ready Figma organised by platform. Component library. Motion specs. Decision log explaining every platform divergence.

For mobile apps that pair with a web product, sprints stack. A typical Pro engagement is two sprints (12 weeks) covering web + iOS + Android with a shared system.

• Karaz Health, native patient mobile app paired with a clinician web dashboard. Smart-scale integration, diabetes management, healthcare data handling. Saudi Arabia.
• FePay, fintech mobile app with biometric auth, KYC, and payments. Native iOS and Android.
• Haven, wellbeing mobile app with one Right Now card and no streak resets.

More on selected work. Some mobile engagements are under NDA, happy to walk through them on a call.

Designing native means honoring the platform conventions users have already learned. Where iOS and Android diverge structurally:

• Navigation. iOS uses tab bars and stack navigation. Android supports navigation drawers, bottom nav, and predictive back. We design with each platform's primary pattern, not against it.
• Sheets and modals. iOS sheets slide up; Android bottom sheets follow Material 3 conventions. Modal dismissal patterns differ.
• Typography and density. SF Pro on iOS, Roboto on Android, each with their own dynamic type scaling. Component padding shifts between platforms.
• System controls. iOS uses segmented controls and steppers; Android uses chips and tabs. Same logical pattern, different visual conventions.
• Empty and loading states. iOS conventions favor empty illustrations with short copy; Material 3 uses cards and dividers with longer descriptive text.

Designing one shared layout for both platforms is faster, and almost always produces an app that feels slightly off on at least one platform.

Native mobile design covers behaviours web apps don't have to think about:

• Biometric authentication. Face ID, Touch ID, Android Biometric. When to prompt, how to fall back to passcode, what to show when the user opts out. Designed as part of onboarding, not as a settings toggle.
• Haptic feedback. Subtle vibrations at moments of confirmation. Used sparingly, not on every tap, only at moments worth marking.
• Push notifications. When to ask for permission (rarely on first launch, almost never on the home screen). What categories of notifications, with user-controllable preferences.
• Offline-first logic. Mobile devices drop connectivity constantly. We design queued actions, sync conflict resolution, optimistic UI, and the moments when network returns mid-action.
• Deep links and app shortcuts. How the app handles being entered mid-flow (from notification, share sheet, or system link).
• Accessibility. Dynamic Type, VoiceOver, TalkBack, contrast ratios, gesture alternatives. Designed in from the start.

• Port-then-call-it-mobile. Web layouts shrunk to phone size. Tap targets too small, density too high, system conventions ignored.
• Platform-blind design. One Figma file used for both iOS and Android with no platform-specific variants. The app feels slightly off on at least one platform.
• Permission-overload onboarding. Ask for camera, location, notifications, contacts, all in the first 30 seconds. Most users deny everything; the app degrades from there.
• Online-only assumptions. Spinner on every connectivity drop. No queued actions. No graceful offline state. Users in elevators, subways, and bad-coverage areas get a broken app.
• Notification spam. No user-controllable preferences, no notification categories. Users disable notifications entirely, losing the genuinely useful ones with the noise.
• Accessibility as an afterthought. Dynamic Type breaks layouts; VoiceOver labels are missing; contrast fails. The 15% of users who need these can't use the app at all.