Navigating OS Compatibility: Tackling Testing Challenges

OS compatibility testing means checking that your app works on every iOS and Android version, and every kind of device, that you promise to support. The practical approach is to set clear minimum OS versions, build a small device matrix based on what your users actually run, test each build on real devices across that matrix, and pay extra attention whenever a new OS version ships. This guide explains each step and the challenges that come with it.

Why OS compatibility is hard

• Android fragmentation: many manufacturers, screen sizes, chipsets and customised versions of Android, with users spread across several major versions.
• Fast iOS adoption: iPhone users tend to update quickly, so a new iOS release can expose a problem in a large share of your users within weeks.
• Behaviour changes between versions: each OS release can change permissions, background limits, privacy rules and UI defaults. For example, Android 13 made notification permission a runtime prompt, and iOS 14 introduced App Tracking Transparency.
• Store requirements: Google Play requires new apps and updates to target a recent Android API level, and Apple sets a minimum Xcode and SDK version for submissions. Check the current requirements in the Play Console help and Apple's developer news.

Step 1: Set your minimum versions

Decide which OS versions you support, and write it down.

• iOS: the deployment target in Xcode sets the oldest iOS version the app can install on. Many teams support the current and previous one or two major versions.
• Android: minSdk sets the oldest Android version, and targetSdk tells the system which version's behaviour your app is designed for.

Base the choice on your own analytics if you have them. Supporting very old versions costs testing time on every release.

Step 2: Build a device matrix

You cannot test on every device, so choose a representative set:

Slot	iOS example	Android example
Newest OS, recent flagship	Recent iPhone on the latest iOS	Recent Pixel or Samsung on the latest Android
Oldest supported OS	Oldest iPhone your deployment target allows	A device on your minSdk version
Small screen	iPhone SE class device	Compact budget phone
Large screen or tablet	Pro Max class iPhone or an iPad	Large phone or tablet
Low memory or slow device	Older iPhone	Entry level Android phone

Add your users' most common devices if you know them. Simulators and emulators are useful for quick checks across many versions, but always confirm on real hardware before release.

Step 3: Know what to check on each version

• Install, first launch and upgrade from the previous app version
• Permission prompts: camera, location, notifications, photos, and what happens when they are denied
• Background behaviour: push notifications, background refresh, long running tasks
• Layout: notches and Dynamic Island, edge to edge display on Android, large text sizes, dark mode
• Networking: TLS and certificate handling, offline mode, slow connections
• Third party SDKs: make sure their versions support the newest OS

Step 4: Test every build on real devices

Compatibility bugs often appear in the build after the one you tested. The fix is to make it easy to put every build on every device in the matrix.

This is the part AppForShare handles. Upload an Android .apk or an iOS .ipa (signed Ad Hoc, Development or Enterprise) and you get an install link and QR code. Each tester, or each device on the test shelf, installs over the air in a minute.

• Free: 150 MB per file, 7 day links, password protection, QR codes and the UDID finder for registering iPhones.
• Pro: CI uploads so every build gets a link automatically (CI docs), release notes, and install analytics showing which device models, OS versions and countries installed each build. That tells you whether your matrix was actually covered.
• Team: invited testers, emails on new builds and a "who installed" view.

AppForShare is a distribution tool, not a test platform. It does not run automated tests, provide remote devices, test APIs or scan for security issues. For automated tests across many devices, look at device cloud services such as Firebase Test Lab, AWS Device Farm or BrowserStack, and check their current pricing pages.

Step 5: Prepare for new OS releases

• Install the public or developer betas of the next iOS and Android versions on a spare device each summer.
• Read the behaviour changes lists that Apple and Google publish for each release.
• Run your full compatibility checklist on the beta, then again on the final release.
• Update your targetSdk and Xcode version before store deadlines, not after.

Common challenges and fixes

Challenge	Fix
A bug only appears on one manufacturer's phones	Add that brand to the matrix and ask affected users for model and OS version
Testers are on different builds	Give each build its own link and release notes; install fresh for each round
Not enough physical devices	Ask testers to install on their own phones, or use a device cloud for automated runs
A new OS release breaks a feature	Test on betas early and keep an update ready for release day

For troubleshooting specific failures, see how to troubleshoot Android apps and how to troubleshoot iOS apps.

Frequently asked questions

What is OS compatibility testing?

It is checking that an app installs and works correctly on every iOS and Android version and device type you support, including the oldest supported version and the newest release.

How many devices do I need for compatibility testing?

A small matrix usually covers most problems: the newest and oldest supported OS versions, a small and a large screen, and a slow or low memory device, for each platform. Add your users' most common devices if you know them.

Does AppForShare run compatibility tests?

No. AppForShare shares builds through install links so your testers can install each build on real devices quickly. It does not run automated tests or provide remote devices.

How can I see which OS versions installed my build?

On AppForShare Pro and Team, install analytics show the device models, OS versions and countries of the devices that installed each build.