Device compatibility decides which phones and tablets can install your app. Exclusions remove devices that cannot run the app well. A careful exclusion protects users from a broken experience. A careless exclusion blocks users who could have run the app fine.
Exclusions should follow evidence rather than assumptions about a device. Test the app on the device class before excluding it. A device that struggles with one feature may still run the core app well. Excluding the whole device for one feature punishes users unnecessarily.
Think of compatibility as a spectrum rather than as a simple yes or no. Some devices run the full app. Some run the core app without an advanced feature. Some cannot run the app at all. Exclusions should target only the last group whenever possible.
Understand Compatibility Signals
Compatibility signals include screen size and processor type and system version and hardware features. The store combines manifest declarations with console settings to build the device list. Each signal narrows the audience in a different way. Understand each signal before you change it.
Check the device catalog in the console to see which devices are included and excluded. A catalog view shows the effect of a change before it reaches users. Review the catalog after every manifest change. A small manifest edit can exclude thousands of devices unexpectedly.
Use Manifest Declarations Carefully
Manifest declarations state hard requirements such as a camera or a sensor. A device without a required feature cannot install the app. Declare only features that the core app truly needs. An optional feature declared as required will exclude devices that could run the core app.
Mark optional features as not required in the manifest. Handle their absence in code with a graceful fallback. A camera feature can hide when no camera exists. A core task should never depend on an optional feature. Manifest honesty keeps the audience as wide as possible.
Set System Version Limits Thoughtfully
Minimum system version excludes older devices from installing the app. Set the minimum to the oldest version that your code and libraries truly support. Raising the minimum without a technical reason abandons users who depend on older phones.
Test the app on the minimum version before raising or lowering it. A library update can raise the effective minimum silently. Check library requirements after every major update. A silent minimum change can surprise users who update and then cannot install.
Exclude By Device Model Sparingly
Model exclusions target specific devices that fail despite meeting general requirements. Use them for devices with a proven fault such as a broken driver or a faulty sensor. Document the fault and the test that proved it. An undocumented model exclusion looks arbitrary to reviewers and to users.
Review model exclusions regularly because manufacturers fix faults with system updates. A device excluded for a fault in one system version may work fine after an update. Remove exclusions that no longer have evidence. Stale exclusions shrink your audience for no benefit.
Handle Screen And Density Differences
Screen size and density affect layout more than any other signal. Test layouts on small phones and on large tablets and on foldable devices. A layout that breaks on a small screen is a compatibility fault rather than a reason for exclusion. Fix the layout first when possible.
Exclude a screen class only when the app cannot function on that size even after layout work. A phone app that requires a tablet screen should state that requirement clearly. Most apps should support phones and tablets with adaptive layouts. Adaptive design beats exclusion for most cases.
Test Before Excluding
Build a test plan for any device class that you consider excluding. Test core tasks and performance and stability on that class. Record results with device details and system versions. Evidence based exclusion is defensible. Assumption based exclusion is not.
Use cloud device testing when you cannot buy a specific model. Cloud testing covers many models at a lower cost than purchase. Focus cloud tests on the models that your analytics show as common. A common model deserves more testing than a rare model.
Communicate Exclusions Clearly
Tell users why a device is excluded when they ask. A clear explanation about a hardware requirement feels fair. A vague statement about compatibility feels like neglect. Support answers should name the requirement and suggest alternatives where they exist.
Update the listing when an exclusion changes the audience materially. A listing that promises support for all devices while excluding many will mislead visitors. Honest listing language about supported devices builds trust even when some users cannot install.
Monitor Exclusion Impact
Track how many users each exclusion affects. The console device catalog can show counts for excluded groups. A large excluded group deserves a second look at whether a fix is possible. A small group with a severe fault justifies exclusion more easily.
Review exclusion impact monthly alongside crash data. A device group with high crashes may need exclusion or may need a fix. Choose the response based on whether a fix is feasible. Exclusion is a last resort when a fix is not possible in reasonable time.
Support Older Devices Gracefully
Older devices often belong to users who cannot upgrade easily. Support them as long as core features run acceptably. Optimize performance for low memory and for slow processors. Small optimizations can keep an older device viable for another year.
Use feature flags to disable heavy features on older devices while keeping core tasks. A heavy animation or a large model can stay off on low end hardware. Core tasks should remain fast and stable. Graceful degradation respects users who cannot buy new hardware.
Handle Processor And ABI Exclusions
Processor architecture exclusions affect which native libraries ship to a device. Most apps should support the common architectures for phones. Excluding an architecture should follow a technical reason such as a native library that cannot build for it.
Test native code on each architecture that you support. A native fault on one architecture can look like a device exclusion problem. Fix the native code when possible rather than excluding the architecture. Architecture support widens the audience with little extra effort in most cases.
Review Exclusions After Updates
Every major app update can change compatibility needs. A new feature may add a hardware requirement. A removed feature may remove a requirement. Review manifest and console settings after each major update. An outdated requirement can exclude devices unnecessarily.
Add a compatibility review to the release checklist for major versions. Check the device catalog before submission. Confirm that the included and excluded lists match your intent. A catalog check takes minutes and prevents a release that reaches the wrong audience.
Avoid Over Exclusion
Over exclusion happens when developers exclude devices out of caution rather than evidence. A cautious exclusion list can halve the potential audience. Each exclusion should have a test result behind it. A list built on fear will cost installs every day.
Challenge each exclusion during review with a simple question. What test proves that this device cannot run the app. If no test exists then test the device before excluding it. Evidence based lists stay smaller and fairer than fear based lists.
Plan Compatibility For New Features
Plan compatibility when designing a new feature rather than after building it. Ask which devices lack the required hardware. Design a fallback for those devices at design time. A fallback planned early costs far less than a fallback added after launch.
Document compatibility decisions for each feature in the project notes. Note which devices are supported and which are excluded and why. Future developers can then maintain the feature without rediscovering the same constraints. Documentation turns compatibility into shared knowledge.
Learn From Compatibility Data
Study crash and performance data by device group over time. Groups with persistent problems may need engineering attention or exclusion. Groups that improve after an optimization show that investment in compatibility pays off. Data should guide the next compatibility decision.
Share compatibility findings with the product team regularly. Product decisions about features should consider device impact. A feature that only works on flagship devices serves a narrow audience. A feature designed for broad devices serves the whole user base better.
Keep Exclusions Fair And Current
Audit the full exclusion list at least twice a year. Remove exclusions without current evidence. Update exclusions when new test data arrives. A fair list changes over time as devices and software improve. A frozen list becomes unfair as the world moves on.
End each audit with a short summary for the team. List added and removed exclusions with reasons. A summary keeps everyone aligned on who can install the app. Alignment prevents support answers that contradict the actual device list.
- Declare only features that the core app truly needs
- Test a device class before excluding it
- Review the device catalog after every manifest change
- Remove model exclusions when system updates fix the fault
- Support older devices with graceful degradation
- Audit the full exclusion list twice a year
Testing Foldables And Tablets
Foldable devices change screen size during use when the user folds or unfolds the device. Test layout transitions during a fold change rather than only at fixed sizes. A layout that breaks during transition feels worse than a layout that starts imperfectly. Transition testing is essential for foldable compatibility.
Test tablet layouts with the same rigor as phone layouts. A tablet user expects a layout that uses the larger screen well. A stretched phone layout on a tablet looks unfinished. Adaptive layouts that rearrange content for tablets convert tablet visitors into loyal users.
Documenting Compatibility Decisions
Write down each compatibility decision with the device group and the evidence behind it. Note the test date and the system version and the observed fault. A decision record lets future developers understand why a device is excluded. Without a record the same device may be tested repeatedly without a conclusion.
Share compatibility decisions with support staff so their answers match the device list. A support answer that contradicts the catalog confuses users. A shared record keeps product and support aligned. Alignment between catalog and support is a quiet sign of a well run app.
For reference the snippet below shows how an optional hardware feature is declared so it does not exclude devices.
// Manifest feature example
For more context read app store screenshots and video previews for conversions and access permissions policies for accessibility storage and SMS. You may also find appealing unjust app suspensions or account bans helpful for your next release.
The steps above follow the approach described in the official developer documentation for this platform. That guidance explains the same sequence in general terms. This article adapts those ideas into a practical workflow for independent developers and small teams.
