--- title: Designing for iOS and Android Simultaneously description: "Navigation patterns, sheet presentation, haptic APIs, and system fonts differ between platforms. Know which conventions to follow, which to unify, and which to ignore." canonical: https://nowah.xyz/blog/designing-for-ios-android-simultaneously lastModified: "2026-08-07T07:59:57.835Z" --- # Designing for iOS and Android Simultaneously Navigation patterns, sheet presentation, haptic APIs, and system fonts differ between platforms. Know which conventions to follow, which to unify, and which to ignore. One codebase. Two platform cultures. This is the fundamental tension of cross-platform mobile development, and it extends far beyond code into design. iOS users expect certain patterns: swipe from the left edge to go back, sheets that slide up from the bottom with a drag handle, a specific haptic vocabulary, SF Pro as the system font. Android users expect different patterns: a hardware or gesture back button, bottom sheets with different presentation behavior, a different vibration model, Roboto or Material Design typography. Building a travel app from a shared codebase means making decisions about where to respect these platform differences, where to unify them, and where to ignore them entirely. Get these decisions wrong and your app feels foreign on one or both platforms. Get them right and users on each platform feel at home without the design team maintaining two separate systems. ## Navigation: the deepest divergence ![Illustration for this section](https://pics.nowah.xyz/website-media/design-046-img-1.webp) Navigation is where iOS and Android diverge most fundamentally. On iOS, the back gesture is a swipe from the left edge of the screen. It is deeply ingrained in muscle memory. iOS users swipe back without thinking about it. On Android, the back action is a system-level button or gesture that lives outside the app. Android users press back, they do not swipe it. Our approach: support both patterns plus an explicit back button. iOS users can swipe from the left edge. Android users can use the system back gesture. Both see an explicit back arrow in the header as a fallback. This triple-redundancy means no user has to learn a new navigation pattern, regardless of platform. The explicit back button is important because not all users are fluent in gesture navigation, even on their own platform. New smartphone users, older users, and users switching between platforms all benefit from a visible, tappable back affordance. ## Sheet presentation: platform-native with unified content When the user taps Select on a flight card, a review modal appears. On iOS, this uses the native sheet presentation: a card that slides up from the bottom with rounded corners and a drag handle, with the content behind it dimming and scaling down slightly. On Android, a bottom sheet slides up with its own material-style presentation. The content inside the sheet is identical on both platforms. The same [traveler information](/blog/traveler-information-forms-chat-first) form, the same fare breakdown, the same cancellation policy display. What differs is the container: the sheet behavior follows each platform's conventions because users have strong muscle-memory expectations about how sheets work. The [payment sheet](/blog/payment-sheet-native-vs-custom) is another platform divergence point. It uses each platform's native payment presentation, which includes biometric authentication flows that differ between face recognition, fingerprint readers, and platform-specific authentication patterns. We do not try to unify these because the native payment flow is where users feel most secure, and security perception is critical during a money transaction. ## Haptic APIs: nuanced versus limited ![Supporting diagram](https://pics.nowah.xyz/website-media/design-046-img-2.webp) [Haptic feedback](/blog/haptic-feedback-travel-when-vibrate) capabilities vary significantly between platforms. Sophisticated haptic engines offer multiple feedback types: impact with adjustable weight, selection feedback, notification patterns with success/warning/error variants, and custom patterns. Some Android devices have basic vibration motors that support on and off. We design for the sophisticated case and degrade gracefully. On devices with rich haptic support, the user gets nuanced feedback: a light selection tap when choosing a flight card, a distinct error pattern when something fails, a satisfying burst on booking confirmation. On devices with basic motors, we reduce to two haptic events: confirmation and error. Everything else is silent. We never attempt to simulate nuanced haptics on basic hardware. A crude buzz trying to feel like a gentle tap is worse than no haptic at all. Better to skip the feedback entirely than to deliver it at a quality level that undermines the experience. ## System fonts: when to use platform defaults Typography is a subtler platform divergence. iOS renders in SF Pro. Android defaults vary by manufacturer but typically use Roboto or a vendor-customized font. These fonts have different metrics, different character widths, and different visual weights at the same nominal size. Our approach is to use each platform's default system font for body text and UI labels. This means an iOS user sees familiar letterforms and an Android user sees familiar letterforms. The app feels native to each platform at the typographic level. We use consistent font weights and sizes across platforms (specified in our design token system) but allow the actual typeface to differ. A 16-point medium-weight heading in SF Pro and a 16-point medium-weight heading in Roboto look slightly different, but both feel correct on their respective platforms. ## Notifications: grouped versus channeled Notification design is another area where platform conventions diverge. iOS groups notifications by app with expandable stacks. Android uses notification channels that let users control permissions per category. For a travel app, this matters because we send different types of notifications: booking confirmations, flight status updates, check-in reminders, price alerts. On Android, each of these maps to a notification channel that the user can independently enable or disable. On iOS, the grouping is automatic but the per-category control lives in the app's settings. Our design accommodates both models. The app's notification settings screen mirrors the granularity that the platform supports, so users on either platform can tune their [notification preferences](/blog/notification-preferences-done-right) to the level of specificity their system allows. ## Where to unify, where to diverge The decision framework is straightforward. Unify everything that is about your product's identity: colors, card layouts, information hierarchy, the AI's personality, the booking flow sequence. These should feel identical across platforms because they are your product, not the platform's. Diverge on everything that is about the platform's identity: navigation gestures, sheet presentation, haptic patterns, system fonts, notification models. These should feel native to each platform because users have deep expectations about how their phone works. When in doubt, follow the platform convention. Users spend far more time in other apps than in yours, and their expectations are shaped by those other apps. A travel app that feels like a natural citizen of the user's phone earns trust faster than one that feels imported from a different platform. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).