iOS vs Android Differences

A food-delivery startup builds its app on iPhones. Every tester owns an iPhone, every demo runs on an iPhone. Launch day goes well, until the Android reviews arrive: “Pressing Back closes the whole app.” “I can’t get rid of the menu at the bottom.” “It asked for notifications and then said they were on, but nothing ever came.”

None of these bugs existed on iOS. They came from building one design and shipping it to two platforms that work differently. Your job as a tester is to know those differences well enough to spot them, so let’s learn them.

Why it matters

iOS and Android are not just “two skins” of the same thing. They have different navigation models, different UI components, different permission rules, different release processes, and very different device landscapes.

• Users notice. People expect apps to behave like the rest of their phone. An Android user presses Back dozens of times a day; if your app ignores it, the app feels broken.
• The code is often different. Even cross-platform apps (React Native, Flutter, Kotlin Multiplatform) use platform-specific code for navigation, permissions and notifications. A fix on one platform does not fix the other.
• Bugs hide on the platform nobody tests. Teams usually have a “home” platform. The other one gets less attention and collects bugs.

The big differences at a glance

Area	iOS	Android
Going back	Back chevron in the navigation bar + swipe from the left edge	System Back (edge swipe or ◁ button) on every screen, plus the arrow in the app bar
Main navigation	Tab bar at the bottom	Navigation bar (bottom), navigation rail or drawer on big screens
Menus of actions	Action sheet with a separate Cancel button	Bottom sheet or menu, dismissed by swipe, tap outside or Back
Confirmations	Centered alert, must tap a button	Material dialog, usually dismissible by Back or tapping outside
Quick messages	No built-in toast; banners or inline messages	Toasts and snackbars
Permissions	System prompt shown once; after that, only Settings	Can ask again; after two denials (Android 11+) the dialog stops appearing
Notifications	Always needs permission	Needs permission on Android 13+; users can mute channels
System font	SF Pro	Roboto in Material, but makers ship their own fonts
Beta testing	TestFlight	Play Console testing tracks, Firebase App Distribution
Devices	A few dozen iPhone and iPad models	Thousands of models from hundreds of makers

Explore: same screen, two platforms

Here’s the same order screen built properly for each platform. Switch platforms, pick a situation, and tap the numbered hotspots. Try the System Back and edge swipe controls too: they’re the single most important difference to test.

📱 Same screen, two platforms

Switch between iOS and Android, pick a situation, and tap the numbered hotspots to see what differs and what to test.

iOSAndroid

NavigationAlert vs dialogPermission promptAction sheet vs bottom sheet

9:41

Orders1Order #48212

Pizza Place · Arriving 19:40

1 × Margherita, large

2 × Garlic bread

Total€24.70

Contactless delivery

3

Cancel Order

HomeSearchOrdersAccount4

⟶ Swipe from left edge

1Going back2Title and system font3Switch4Tab bar vs navigation bar

Going back

iOS

A chevron with the previous screen’s title in the navigation bar, plus a swipe from the left edge of the screen. There is no system Back button.

Android

An arrow in the top app bar, plus the system Back: a swipe from the left or right edge (gesture navigation) or the ◁ button (3-button navigation). Android 14+ can show a predictive back preview of where you’ll land.

What to test

• Android: press system Back on every screen, including with the keyboard, a dialog or a sheet open.
• iOS: swipe back from the left edge on every pushed screen. Start a swipe, then cancel it halfway.
• Back never loses typed data without asking, and never exits the app from a deep screen.

Try the edge swipe while a prompt is open, then switch to Android and press System Back in the same spot.

Navigation: the biggest source of bugs

iOS: back chevron and edge swipe

On iOS, screens are stacked on top of each other. Each new screen slides in from the right and shows a back chevron (‹) with the previous screen’s title. Users can also swipe from the left edge to drag the screen away. There is no system-wide Back button.

What breaks:

• The swipe-back gesture is disabled, often by accident when developers customize the navigation bar or hide the back button. Users swipe and nothing happens.
• A swipe-back on a screen with unsaved changes discards the data without asking.
• A half-finished swipe (start swiping, then let go) leaves the screen in a weird state.

Android: system Back everywhere

Android has a system Back that works in every app: a swipe in from the left or right edge in gesture navigation, or the ◁ button in 3-button navigation. Your app must handle it on every screen and every state:

Newer Android versions add predictive back: when the user starts the back gesture, apps that support it show a preview of where they’ll land (the previous screen or the home screen), and the user can cancel by sliding back. Since Android 15 these previews appear for apps that opted in; for apps that target Android 16 they’re on by default. Test that the preview matches where you really end up.

For swipes, long presses and other touch input, see Gestures.

Tabs vs bottom navigation

Both platforms put the main sections at the bottom, but they behave differently:

• iOS tab bar: tapping the active tab again usually scrolls to the top or returns to that tab’s first screen. Each tab keeps its own history. In iOS 26, Apple’s Liquid Glass design makes the tab bar float over the content, and apps can let it shrink as you scroll.
• Android navigation bar: the active destination gets a pill-shaped indicator. Pressing Back from another tab normally returns to the start tab before leaving the app.

UI conventions that differ

Component	iOS	Android (Material 3)	What to look for
Alert / dialog	Centered, buttons side by side or stacked; destructive in red	Rounded dialog, left-aligned text, text buttons bottom-right	Back / tap outside counts as Cancel on Android, never as “Confirm”
Menu of actions	Action sheet with a Cancel button	Modal bottom sheet with a drag handle	No iOS action sheet in an Android app
Switch	Green pill (toggle switchToggle switchAn on/off control that applies a setting immediately, like Wi-Fi or Dark mode.Open in glossary →)	Material switch, theme color, optional check icon	State announced by the screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary →
Date & time picker	Compact field, inline calendar or scrolling wheels	Calendar dialog with a typing mode; clock-dial time picker	The native picker for each platform, correct first day of week
Share	iOS share sheet	Android Sharesheet	The system sheet opens with the right content
Short feedback	Banner or inline message (no native toast)	ToastToastA short, temporary message that appears briefly and disappears on its own, like 'Message sent'.Open in glossary → or snackbar	Message isn’t hidden behind the keyboard or nav bar
Font	SF Pro, scales with Dynamic TypeDynamic TypeThe phone setting that lets users make text bigger or smaller across apps.Open in glossary →	Roboto or the maker’s font, scales with Font size (up to 200% on Android 14+)	No clipped text at the largest size on either
Haptics	Precise, consistent Taptic Engine	Vibration quality varies a lot between devices	Haptics feel right and can be turned off

Permissions: same idea, different rules

Both platforms ask the user before an app can use the camera, location, microphone, photos, contacts or notifications. These are app permissionsApp permissionsThe user's approval for an app to use things like the camera, location, contacts or notifications.Open in glossary → (see the App permissions feature lesson), and the rules differ in ways that create real bugs.

iOSAndroid

• The system prompt appears only once per permission. If the user taps Don’t Allow, the app can never show it again. The only way back is the Settings app.
• Location offers Allow Once, Allow While Using App and Don’t Allow, plus a Precise on/off switch.
• Photos can be shared as limited access (only selected photos).
• The text under the title is the app’s own purpose string. Apple requires it, and App Review rejects vague ones.
• Good apps show their own explanation screen before triggering the one-shot system prompt.

• Permissions have been asked at runtime since Android 6. The app can ask again after a denial.
• Since Android 11, if the user denies the same permission twice, Android stops showing the dialog (it behaves like “Don’t ask again”). The app must then send the user to Settings.
• Location, camera and microphone offer Only this time (Android 11+). The permission is revoked soon after the user leaves the app.
• Location offers Precise or Approximate (Android 12+). Photos can be shared partially (“Select photos”, Android 14+).
• Android may auto-reset permissions of apps that haven’t been used for a few months.

What to test on both: every answer (allow, one-time, deny), revoking the permission in Settings while the app is in the background, and the “permanently denied” state, where the app must explain how to turn it back on instead of failing silently.

Notifications

Push notificationsPush notificationA message an app sends to the device that appears even when the app is closed.Open in glossary → look similar on both platforms, but the setup differs:

• iOS always needs the user’s permission before showing alerts. The prompt appears once. Users can also choose how notifications appear (banners, lock screen, summary) and turn on Focus modes.
• Android 13 and newer require the POST_NOTIFICATIONS runtime permission, so notifications are off for a new install until the user allows them. On Android 12 and older, notifications are allowed by default.
• Android notification channels (Android 8+) group notifications by type, like “Order updates” and “Promotions”. Users can mute one channel and keep the others.

Test that the app’s own notification toggle matches the real system permission (more in Push notifications). A switch that says “On” while the OS blocks notifications is one of the most common bugs in this area.

Keyboards and autofill

• Android has many keyboards: Gboard, Samsung Keyboard, SwiftKey and others. Each one handles autocorrect, suggestions and emoji differently. Test with at least two.
• iOS number pads have no Return key. If the app doesn’t add a Done button or tap-outside handling, the user can’t close the keyboard and can’t reach the button below it.
• The keyboard covers content. Check that the focused field and the main button stay visible on short screens.
• Autofill: iOS offers Password AutoFill and one-time codes from SMS above the keyboard; Android’s Autofill framework works with Google Password Manager and other password managersPassword managerA tool that stores credentials and fills them into login forms, like Apple Passwords, Google Password Manager or 1Password.Open in glossary →. Fields must be marked correctly (username, new password, one-time code), or autofill won’t appear.

Distribution, review and beta testing

How a buildBuildA specific compiled version of the app or website that is ready to be installed or tested.Open in glossary → reaches users is different too, and testers are often in charge of the beta builds (more in Beta distribution).

	App Store (iOS)	Google Play (Android)
Beta testing	TestFlightTestFlightApple's service for distributing beta builds of iOS apps to testers before App Store release.Open in glossary →: internal testers from your team, external testers after a quick Beta App Review; builds expire after 90 days	Testing tracks: internal (up to 100 testers, available within minutes), closed and open
Other options	Firebase App DistributionFirebase App DistributionGoogle's service for sending pre-release Android (and iOS) builds to testers.Open in glossary → for ad-hoc builds	Firebase App Distribution, or sharing APKs directly (sideloading)
Review	Every version is reviewed by Apple; most are reviewed within a day	Automated plus manual checks; usually hours, sometimes several days
Gradual release	Phased release over 7 days for automatic updates	Staged rollout to a percentage of users, can be halted
Rollback	No rollback: you must ship a new version	No rollback either, but you can halt a staged rollout

OS updates and hardware variety

• iOS users update fast. Most iPhones move to the newest major iOS within a few months, so teams can drop old versions sooner. Apple also supports devices for many years, so a 6-year-old iPhone may still run the newest iOS.
• Android is spread across many versions. Updates depend on the phone maker and carrier, so at any time your users run five or more different Android versions. See Device fragmentation for how to deal with this.
• Hardware varies a lot more on Android: screen sizes, cameras, chips, RAM, foldables and makers’ own skins (Samsung One UI, Xiaomi HyperOS). Every OS versionOS versionWhich version of iOS, Android or another operating system a device runs.Open in glossary → and skin can change how permissions, notifications or background work behave.

What to test

Group your platform checks like this:

• Navigation: system Back in every state (Android), edge swipe on every pushed screen (iOS), tabs keep their state, deep links land on the right screen with a sensible back path.
• Platform UI: native pickers, sheets and dialogs on each platform; dialogs dismiss correctly; text fits with large fonts.
• Permissions: allow, one-time, deny, permanently deny, revoke in Settings, then return to the app.
• Notifications: first-time prompt, denied state, the app’s toggle vs the real system setting, Android channels, tapping a notification opens the right screen.
• Keyboard and autofill: keyboard can always be dismissed, fields stay visible, password and one-time-code autofill appear.
• Lifecycle: backgrounding, interruptionsInterruptionAnything that takes the user away from the app mid-task: a call, an alarm, a notification, low battery.Open in glossary → like calls, and the OS killing the app. Both platforms do this, but differently.
• Release: install the TestFlight / internal-track build, and test upgradingUpgrade testingChecking that updating from an older app version keeps the user's data and settings working.Open in glossary → from the version in the store.

Common bugs

#	Bug	What you see	Typical severity
1	System Back not handled	Android Back closes the app from a deep screen, or does nothing in a dialog	High
2	Swipe-back disabled	iOS edge swipe does nothing on some screens	Medium
3	Wrong platform component	iOS action sheet or wheel picker inside an Android app	Low–Medium
4	Permission state out of sync	App toggle shows “On” but the OS denied the permission	High
5	Permanently denied = dead end	Feature silently fails; no explanation or link to Settings	High
6	Missing Android 13 notification permission	No notifications ever arrive on new Android phones	High
7	Keyboard can’t be dismissed	iOS number pad covers the Pay button	High
8	Dismissing a dialog confirms it	Back or tap outside triggers the destructive action	Critical
9	Text clipped at large font sizes	Labels cut off with Dynamic Type or Android Font size at max	Medium
10	Beta build differs from store build	Bug only appears in the TestFlight or Play build, not in debug	Medium–High

Find the bug

This food-delivery app ships to both platforms, and it has six bugs. Some only appear on Android, some only on iOS. Switch between the two devices, and explore:

• Open the order, then use System Back (Android) or the edge swipe (iOS).
• Open the ⋮ / ⋯ menu, the delivery time and the “Cancel order” dialog, and try to close each one in every way you can.
• Turn on Order updates and answer the notification prompt both ways (use Restart app to start over).

🐞 Bug hunt: FoodNow order screen

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

9:41

Orders

Order #4821Pizza Place · Arriving 19:30

Order #4790 · Sushi Bar · Delivered yesterday

Device

Restart app

Pixel · AndroidiPhone · iOS

◁ System Back

Gesture navigation: Back = swipe in from the screen edge.

1. 1

   Hint: On Android, open the order and press System Back.

   Android: system Back closes the app from the order screen

   Instead of returning to the Orders list, the app closes and you land on the home screen. Only the on-screen chevron works. The chevron itself is copied from iOS (‹ Orders); Android uses an arrow. Expected: system Back goes to the previous screen.

   Reveal answer✓ I found this
2. 2

   Hint: On Android, tap Delivery time.

   Android: iOS wheel picker for delivery time

   The Android build shows the iOS-style scrolling wheel with Cancel/Done in iOS blue. Expected: a Material picker (for example a list of time slots or the Material time picker) that fits the rest of the Android UI.

   Reveal answer✓ I found this
3. 3

   Hint: On Android, open the ⋮ menu and tap the dimmed area above it.

   Android: action sheet instead of a bottom sheet, and tapping outside does nothing

   The menu is an iOS action sheet with a separate Cancel button and no drag handle. Tapping the scrim does not close it. Expected: a Material bottom sheet that closes when you tap outside, swipe it down or press Back.

   Reveal answer✓ I found this
4. 4

   Hint: On Android, open the Cancel order dialog and press System Back.

   Android: the "Cancel this order?" dialog ignores system Back

   Nothing happens; the user is stuck until they tap a button. Expected: Back dismisses the dialog and keeps the order, exactly like Keep order. (Tapping outside correctly dismisses it, which makes the inconsistency easy to miss.)

   Reveal answer✓ I found this
5. 5

   Hint: On iOS, open the order and swipe from the left edge.

   iOS: swipe back from the left edge does nothing

   The interactive back gesture is disabled on the order screen, so users must reach for the chevron at the top. Expected: an edge swipe pops back to the Orders list, like everywhere else in iOS.

   Reveal answer✓ I found this
6. 6

   Hint: On iOS, turn on Order updates and tap Don’t Allow.

   iOS: notifications switch shows On after "Don’t Allow"

   The switch turns On even though iOS will never deliver notifications, and the app never mentions Settings. Because iOS shows the system prompt only once, the user has no idea why updates never arrive. Expected: the switch stays off and the app explains how to enable notifications in Settings (Android handles this correctly).

   Reveal answer✓ I found this

Tools and how-to

iOSAndroid

• Xcode Simulator: test layouts, permissions and navigation on many iPhone and iPad models. The edge swipe works with a mouse drag from the left edge. It’s a simulatorSimulatorSoftware that imitates a device's behavior on your computer, like Apple's iOS Simulator.Open in glossary →, so camera, some sensors and real performance need a real deviceReal deviceA physical phone or tablet used for testing, as opposed to an emulator or simulator.Open in glossary →.
• Reset permissions: on a device, delete and reinstall the app, or use Settings › General › Transfer or Reset iPhone › Reset › Reset Location & Privacy. On the simulator: xcrun simctl privacy booted reset all <bundle-id>.
• Test push on the simulator: drag an .apns payload file onto the simulator window, or run xcrun simctl push booted <bundle-id> payload.apns.
• TestFlight: install the TestFlight app, accept the invite, and always note the build number you tested.
• Large text: Settings › Accessibility › Display & Text Size › Larger Text.

• Android Studio Emulator: create devices with different Android versions. Switch between gesture and 3-button navigation in Settings › System › Navigation mode (the exact path varies by phone maker).
• Revoke a permission with adbadbAndroid Debug Bridge: a command-line tool for installing apps, reading logs and controlling Android devices.Open in glossary →: adb shell pm revoke <package> android.permission.POST_NOTIFICATIONS, or use Settings › Apps › your app › Permissions.
• Read crash logs: adb logcat shows logcatLogcatAndroid's system log, read with adb logcat, where apps write errors and crash details.Open in glossary → output; filter by your app’s package name.
• Notification channels: long-press a notification, or open Settings › Apps › your app › Notifications to mute single channels.
• Internal testing: join via the opt-in link from Play Console, then install from the Play Store. Note the version code.
• Font size: Settings › Display › Display size and text (called Font size on some phones).

Example test cases

Checklist

iOS vs Android checklist

0 of 13 checked

Copy

• Android: system Back works on every screen, with the keyboard, dialogs, sheets and menus open
• Android: Back from the start screen leaves the app; from other tabs it returns to the start tab
• iOS: edge swipe goes back on every pushed screen, and a canceled swipe leaves no glitches
• Unsaved changes are never lost by Back or a swipe without a confirmation
• Each platform uses its own pickers, sheets, dialogs and share sheet
• Dismissing a dialog (Back, tap outside) never confirms a destructive action
• Every permission answer works: allow, one-time, deny and permanently deny
• App toggles match the real OS permission (notifications, location) after changes in Settings
• Android 13+: notification permission is requested at a sensible moment; channels are named clearly
• The keyboard can always be dismissed and never hides the focused field or main button
• Password and one-time-code autofill appear on both platforms
• Text fits at the largest Dynamic Type / Font size setting on both platforms
• The TestFlight / internal-testing build is tested, with the build number noted in reports

Check your understanding

Quick quiz

0/5 answered · 0 correct

1. 1.An Android app shows a "‹ Back" chevron at the top. What is the MOST important thing to test?

   AThat the chevron is blueBThat system Back (gesture or button) also goes back correctlyCThat the chevron is 44×44 ptDThat the title is centered

2. 2.A user on iOS tapped "Don’t Allow" for notifications. What can the app do?

   AShow the system prompt again next launchBNothing, notifications are impossible foreverCExplain the benefit and send the user to the Settings appDTurn notifications on silently

3. 3.Notifications never arrive on a new Android 15 phone but work on an Android 12 phone. What is the likely cause?

   AAndroid 15 does not support notificationsBThe app never requests the POST_NOTIFICATIONS permission required since Android 13CThe phone is in dark modeDThe notification channel is too long

4. 4.On Android, a "Delete account?" dialog is open and the user presses Back. What should happen?

   AThe account is deletedBNothingCThe dialog closes and nothing is deletedDThe app closes

5. 5.Which is TRUE about releases?

   AYou can roll back an App Store release instantlyBGoogle Play lets you halt a staged rollout, but neither store has an instant undoCTestFlight builds never expireDAndroid apps are never reviewed

Key takeaways

• iOS and Android differ in navigation, UI components, permissions, notifications, releases and devices. Always test both, and always say which one you tested.
• The number one cross-platform bug: Android system Back not handled. On iOS, check that the edge swipe works.
• Each platform should use its own dialogs, sheets, pickers and share sheet. iOS patterns in an Android app (or vice versa) are valid findings.
• iOS shows each permission prompt once; Android stops asking after two denials. Test the denied path and make sure the app’s toggles match the real OS setting.
• Android 13+ needs the notification permission; Android channels let users mute types of notifications.
• Releases can’t be undone instantly, so test the TestFlight / internal-testing build before it goes out.