Native Mobile App Testing | Resync Bootcamp

1 The Hook — Why This Matters

A banking app passed QA on iPhone 14 in the test environment. It shipped. Within hours, users on iPhone XR (older screen dimensions) reported the login button was partially hidden. Android users on Samsung Galaxy A series (smaller, cheaper phones) complained the app crashed on startup. A tester used WiFi the entire time; a user on 3G in central Wellington waited 30 seconds for the app to become responsive. Users turned on location services and the app drained battery in two hours. No one had tested permissions dialogs.

Native app testing is unforgiving. You can't just resize a desktop browser and call it done. Real devices, real networks, real OS versions, real permissions, real battery constraints—all become part of your test surface. Miss any of these and your users will find the bugs first.

2 The Rule — The One-Sentence Version

Native app testing verifies that your app works not just on a single reference device, but across the combinations of device sizes, OS versions, network conditions, permissions, and real-world interruptions that your users will encounter.

It covers: device fragmentation (different screen sizes, OS versions, OEM customizations), network variance (4G vs 5G vs poor signal), operating system constraints (memory, battery, permissions), native features (camera, location, biometrics), interruptions (phone call during app use, network drop), and performance under real hardware limitations. Each adds a layer of complexity that web testing does not have.

3 The Analogy — Think Of It Like...

Analogy

Testing a car for all weather conditions, not just the dealer's showroom.

You could test a car in a climate-controlled garage. It works perfectly. But on the road, in rain, at 2am on a gravel track with a full load, at high altitude, with worn brake pads—failures emerge that the garage never saw. Native app testing is similar. The controlled device farm works fine. Real users on old phones, on 3G, with low battery, with location services on, with the app backgrounded and resumed—that's where the bugs are.

4 Real Devices vs Simulators

✅ Real Devices

Pros: Actual hardware behaviour, real network, real battery drain, real OS quirks, most faithful test
Cons: Expensive to maintain multiple devices, slow to swap between, hard to reproduce exact states, labour-intensive
Use when: Final acceptance testing, testing edge devices, performance/battery testing, permission flows

🔛 Simulators/Emulators

Pros: Free/cheap, fast, reproducible, easy to test multiple OS versions, fast to reset
Cons: Simulation misses real hardware quirks, network simulation is artificial, battery drain not accurate, touch feel is different
Use when: Rapid iteration during development, testing OS versions, testing crashes, regression testing

Best practice: Use emulators for rapid development and regression testing. Use real devices for final acceptance, performance testing, and edge cases. Use device farms (BrowserStack, Sauce Labs, AWS Device Farm) when you need a broad matrix of real devices without the cost of owning them.

iOS Simulator vs Xcode

The iOS Simulator runs on your Mac and mimics iPhone or iPad. Start it in Xcode, build your app to it, and test locally. It's fast but runs at native Mac performance, not iPhone performance. Bottlenecks you'd see on a real iPhone don't appear on the simulator.

Android Emulator vs Android Studio

The Android Emulator runs a full Android OS in a VM. It's slower than the iOS Simulator and can be finicky to set up. Hardware acceleration (KVM on Linux, Hypervisor on Windows) helps. Real devices are often faster to test on during development.

Device Farms

BrowserStack, Sauce Labs, and AWS Device Farm host real devices in the cloud. Upload your app, select devices and OS versions, and your app runs on real hardware somewhere else. You see a screen share and logs. Expensive but invaluable for testing 20+ device/OS combinations without owning them.

5 iOS-Specific Testing

Building and Deploying to iOS Devices

Development device: Connect an iPhone via USB, select it in Xcode, and build directly to the device. Your Apple ID is required to sign the app. The app runs for 7 days before expiring.

TestFlight: Apple's beta testing platform. Upload your app build, invite testers via email, they download and install via TestFlight app. Good for internal testing and external beta feedback. Builds expire after 30 days, so refresh often.

App Store: Final distribution. Apps are reviewed by Apple and may take 24-48 hours. Rejection is common for bugs, policy violations, or UX issues.

Screen Sizes and Safe Areas

iPhones range from 375px (iPhone SE) to 430px (iPhone 16 Plus) wide. iPad is 768px+ in portrait. Worse: notches, Dynamic Island, home indicator—all carve into the usable space. Always test layout at the extremes: smallest iPhone (375px) and largest iPad. Verify no content is hidden behind the notch or home indicator.

iOS Version Differences

iOS 16, 17, 18—each has different behaviour. Test on at least the current and previous two versions. Features like biometric authentication, location permissions, or image picker vary significantly between versions. Major version upgrades often break apps with subtle API changes.

VoiceOver (Accessibility)

iOS has built-in screen reader VoiceOver. Enable it (Settings → Accessibility → VoiceOver), close your eyes, and navigate the app using VoiceOver gestures. Tap, swipe, two-finger swipe, z-shape gesture for keyboard—all differ from sight navigation. A fully sighted test misses accessibility bugs that 15% of users will hit.

6 Android-Specific Testing

Device Fragmentation

Android runs on Samsung, Google, OnePlus, Motorola, Nokia, budget Chinese manufacturers—each with different screen sizes (480px to 720px+), different OS versions (Android 10 to 15), and different OEM customizations. A feature working on Pixel 8 (reference Android) may fail on Samsung Galaxy A23 (budget phone). Test the phones your users actually use, not just the flagship.

Android Versions and Permissions

Android 12, 13, 14, 15 each changed permissions handling. Runtime permissions (Android 6+) require user consent via dialog. Scoped storage (Android 10+) restricts file access. Exact alarm permissions (Android 12+) restrict scheduling. Know which version you target and test permission flows on multiple versions.

Google Play Distribution

Internal testing → Closed testing (limited testers) → Open testing (wider beta) → Production release. Builds must be signed with a key, versioned correctly, and accompanied by release notes. APK vs App Bundle (AAB) for distribution; AAB is now required for Play Store.

Samsung and OEM Customizations

Samsung's OneUI, Xiaomi's MIUI, OnePlus's OxygenOS—each layer changes Android behaviour. Permission dialogs, gesture navigation, system fonts, status bar styling—all differ. A Pixel device behaves differently than a Samsung. If 30% of your users are on Samsung, test a Samsung device.

TalkBack (Accessibility)

Android's screen reader. Enable it (Settings → Accessibility → TalkBack), navigate with two-finger Z swipe (read from top), tap and hold then swipe (explore), two-finger tap (activate). Again, sighted testing misses this entirely.

7 Common Mobile-Specific Concerns

Network Interruption

Users are on 5G, 4G, 3G, WiFi, and often switching between them. They drive through tunnels. They lose signal. Test your app's behaviour when the network drops:

Is a request in flight? Does it timeout gracefully or hang forever?
Is the user mid-form? Can they continue, or is state lost?
Is a download paused? Can they resume, or start over?
Use iOS simulator's Network Link Conditioner or Android emulator's throttling to simulate slow/disconnected states.

Battery Drain

Continuous location polling, rapid API calls, video playback, Bluetooth—all drain battery. Users complain if your app kills their battery in 4 hours. Test with Location services on, BLE enabled, video streaming. Monitor battery consumption on real devices. Profile with Instruments (iOS) or Android Studio (Android).

Memory and CPU Constraints

A budget Android phone has 2GB RAM. An iPhone 11 has 4GB. Heaps of images, large data structures, memory leaks—these hit quickly on constrained devices. Test on low-memory devices. Use simulator memory constraints (simulate 2GB vs 8GB). Watch for crashes after heavy usage (e.g., scrolling a list of 1000 items).

Storage Constraints

Users fill their phones. 16GB storage with OS taking 10GB leaves 6GB. Your app downloading a 500MB video and caching images aggressively will fail. Check: what happens if disk is nearly full? Can the user still use the core app? Can they clear cache? Do cache files age and get deleted automatically?

OS Permission Prompts

Location, camera, microphone, photos, contacts, calendar—each requires user permission on iOS and Android. First request shows a dialog. User can deny, allow, or allow once. Test all paths:

User denies permission: Does the app handle gracefully with a helpful message, or crash?
User allowed but then revokes in Settings: Does the app handle the error when it next tries to access?
User allows "allow once" (iOS 14+): Does the app re-request next time, or assume ongoing access?

Background/Foreground Transitions

User is in your app, receives a phone call, hangs up, returns to your app. Or user switches to another app and back. State should be preserved, network requests should resume correctly, UI should refresh if data changed. Test app backgrounding (pause video, pause network requests, save state) and resumption (resume state, refresh if stale).

Rotation and Safe Areas

User rotates device mid-task. State must be preserved, layout must reflow without crashing, keyboard (if open) must dismiss. Also: notches, home indicators, keyboard height—all consume safe area. Test rotation frequently. Test on devices with notches/dynamic island.

8 Testing Native Features

Camera and Photos

Test: Can user open camera? Can they take photo? Are photos saved to phone? Can they select from photo library? Does permission prompt work? On iOS, can they use both back and front cameras? On Android, does image rotation persist correctly (portrait photo doesn't rotate to landscape)?

Location Services

Test: Permission prompt shown correctly. If denied, app offers retry. If allowed, location is acquired. Test background location (if applicable). Simulator: set mock location via settings. Real device: go outside or drive around. Verify accuracy (GPS vs WiFi geolocation). Test when location is off, location permission is denied, location is stale (old GPS fix).

Biometric Authentication (Face ID, Touch ID, Fingerprint)

Test: Does the app call the biometric API correctly? Simulator: use the biometric mockery (Xcode → Simulate Face ID / Touch ID success/failure). Real device: test with your actual fingerprint / face. Test when biometric is enrolled, when it's not, when it fails. Test fallback to password if biometric fails.

File System Access

Test: App reads/writes files. Where? Documents, Caches, Temp? On iOS, files outside Documents are not backed up to iCloud. On Android, scoped storage (Android 10+) restricts where you can write. Test download files, document creation, cache clearing, offline file access.

Push Notifications

Test: Register device token. Send notification from backend. Does it arrive? Does it appear in notification center even when app is closed? Tapping notification—does it open the app and deliver the deep link payload? Test notification permissions (iOS 12+ requires user consent). Test when notification is rejected by user.

Deep Linking

Test: App handles custom URL schemes (myapp://order/123). Clicking a link from email or browser should open the app and navigate to the order. Test when app is installed vs not installed. Test invalid deep links (should fail gracefully, not crash).

9 Worked Examples

Example 1: Testing a Location-Based Feature

Scenario: A delivery app needs to locate the user and show nearby restaurants.

On simulator, set mock location iOS Simulator: Features → Location → Select a city. Android Emulator: Extended controls → Location → Set coordinates. Verify app shows restaurants for that location.
Test permission denial Settings → Location → Off (or deny for the app). Relaunch app. Verify permission prompt shows. User taps "Don't Allow." Verify app offers a retry button and doesn't crash.
Test permission acceptance User taps "Allow While Using App." Verify location is acquired. Verify restaurants are shown.
Test on real device Go outside or drive to different location. Verify restaurants change as you move. Check accuracy (should be roughly correct, within a few hundred meters).
Test background location (if applicable) If the app requests background location: stop the app, drive, relaunch app. Verify location is updated to current position, not stale.
Test battery impact Run app with location on for 30 minutes. Measure battery drain. Compare to baseline. Is it reasonable?

Example 2: Testing Network Interruption During Payment

Scenario: User is checking out, network drops.

Start checkout flow Fill form, enter payment details, tap submit.
Interrupt network Airplane mode on (iOS/Android Control Center), or network throttle to offline in simulator.
Verify graceful handling Request should timeout (not hang indefinitely). Error message should be shown: "Network error. Please check your connection and try again." Button to retry should be visible. Form should not be cleared.
Restore network Airplane mode off. Tap retry. Verify payment completes and order is not duplicated.
Test mid-request interruption Slower networks: use throttling. Interrupt while request is in flight. Verify timeout and recovery work.

Example 3: Permission Handling Workflow

Scenario: App needs photo library access.

Scenario	Expected	Verify
First time, tap "Pick photo"	Permission prompt shown	Prompt text is clear; user can tap Allow/Don't Allow
User taps "Don't Allow"	Permission denied, helpful message shown ("Enable photos in Settings")	App does not crash, user can retry
User manually enables in Settings, returns to app	App recognizes permission is now granted	"Pick photo" now works without re-prompting
iOS 14+ limited photo library access	App shows only allowed photos; option to "Select More Photos"	Does not assume full access; handles gracefully

10 Common Mistakes

🚫 Testing Only on High-End Devices (Flagship Phones)

I used to think: If it works on iPhone 16 and Pixel 8, it works for everyone.
Actually: 40% of users are on budget phones (iPhone SE, Samsung Galaxy A series, Motorola Moto G). These have slower processors, less RAM, older OS versions. A feature that works on flagship may crash on budget phones. Test the phones your users actually use, not just the expensive ones.

🚫 Ignoring Background/Foreground Transitions

I used to think: If the app works when it's open, it's fine.
Actually: Users background apps constantly. Call comes in, they switch to another app, they lock the phone. Returning to your app, state must be preserved, network requests must resume. A video that doesn't pause on background will be jarring. An API that doesn't resume on foreground will be slow. Always test backgrounding and resumption.

🚫 Not Testing Permissions or Assuming They Work

I used to think: Permissions are OS-handled; my app doesn't need to test them.
Actually: Permissions are critical failure points. Users deny camera access, deny location, revoke permissions in Settings. Your app must handle denial gracefully without crashing. Permission prompts must be clear. Test all paths: first request, denial, revocation, subsequent request.

🚫 Testing Only with Perfect Network (WiFi in Office)

I used to think: If it works on WiFi, it works on 4G.
Actually: 3G is slower, less reliable, and still used. Users on 3G in rural areas experience 5+ second latencies. Test with throttling (Fast 3G, Slow 3G) in simulator. Better: test on a real 3G connection. A feature that works in 200ms on WiFi may timeout on 3G.

🚫 Not Rotating Device During Testing

I used to think: Portrait is the main orientation; landscape is rare.
Actually: Users rotate constantly. If layout doesn't reflow or state is lost on rotation, users feel your app is broken. Rotate frequently during testing. If orientation should be locked, explicitly test that and document it.

11 Self-Check

Click each question to reveal the answer. If you get all three, you can test native apps independently.

Q1. You test on iPhone simulator and everything works. You test on real iPhone and it crashes. Why?

Simulator runs at Mac performance; real device has different hardware. Memory is more constrained. Network is real. Simulator sometimes masks issues. Real devices expose them. Also: simulator may not have all OS features enabled; features work in simulator but fail on real device. Always test on real devices for final acceptance.

Q2. You're testing a location feature. What three things should you verify beyond "location is shown"?

First: permission prompt works and app handles denial. Second: accuracy is reasonable (GPS on real device, not just simulator mock location). Third: background location (if applicable) works and doesn't drain battery excessively. Bonus: test when location is off, when permission is denied, when user revokes permission in Settings.

Q3. Why should you test network interruption if your app is mainly used on WiFi?

Because not all users are on WiFi. Rural areas have 3G. Users are on trains with spotty signal. Network drops happen everywhere. If your app can't handle a temporary network loss without hanging or crashing, it's a usability failure. Test by toggling airplane mode, using network throttling, or testing on real 3G/4G.

Q4. You're testing a form on iPhone SE (375px) and it fits perfectly. It breaks on a smaller display. What device should you have tested first?

The smallest device your app supports. Always. iPhone SE is already the smallest current iPhone, but for older support, iPhone 6/7 (375px) is also common. Test at the extremes of your supported range before testing in the middle. If you only test "normal" sizes, you'll miss edge cases.