If I raise my minimum iOS version, can people on older iPhones still download the app?

Apple does not document the user-facing answer, and it is worth knowing that before you promise anyone anything. What Apple does document is the control you hold. App Store Connect Help, read on 16 October 2026, says to open Apps, select the app, click Pricing and Availability in the sidebar, and at the bottom of the page under Last-Compatible Version Settings select the available version, with a note that only versions submitted to the App Store appear in that list. You deselect the versions that should not be available, click Done, then Save. The name of the setting tells you the App Store can serve a last compatible version. The page does not say who is offered one, on what condition, or what the default is. Treat the mechanism as real and the behaviour as unspecified. Either way, an app already installed on an older iPhone keeps working. It just stops receiving your updates.

Can I keep publishing an old build for old devices on Google Play?

Yes, and Google documents it as multiple APK support. You publish one APK with a lower android:minSdkVersion and another with a higher one, both with the same package name and signed with the same certificate key, each with a different version code. The rule that catches people out is the ordering: an APK that requires a higher API level must have a higher version code, otherwise a new phone can be served the old build. Google adds two caveats on the same page, last updated 21 July 2025. If you publish to Google Play you should build and upload an Android App Bundle instead, and multiple APKs are mainly useful when you are not publishing to Play, because you build, sign and manage every one of them yourself.

Should I just support the oldest phone I can?

The useful question is not how old, it is who. A low floor costs you the APIs you cannot call, the devices you cannot test on, and a crash report from hardware you do not own. A high floor costs you reach you can count. The workable answer is to take the floor your toolchain and your libraries already force on you, check it against what your own users actually carry, and then move it deliberately rather than by accident at the end of a release. Both stores let an existing install keep running, so raising the floor is a decision about who gets your future updates, not about taking anything away.

Articles · GuidesUpdated October 2026

Supporting older phones is two numbers, and only one of them is yours to pick.

Q: What does minSdkVersion actually do?

Two different things, documented in two different places. The Android uses-sdk reference, last updated 18 September 2026, says the Android system prevents the user from installing the application if the system's API level is lower than the value specified in this attribute, and tells you to always declare it. That is the device refusing the install. Separately, Google Play uses the same attributes to filter your app from devices that do not meet its platform version requirements. That is the store hiding the listing. Leave the attribute out and the system assumes a default value of 1, so Play shows the app to everything. Google's own worked example for that case ends with the app crashing at runtime.

Q: Do existing users lose the app when I raise minSdkVersion?

No, and Google is specific about it in one sentence. The Google Play filters page, last updated 21 July 2025, says all filtering restrictions are associated with an application's version and can change between versions, and gives the example that if a user has installed your application and you publish an update that makes the app invisible to the user, the user will not see that an update is available. Nothing is uninstalled. The copy they have freezes at the last version they received and stops getting your fixes, including the security ones. Note the one thing Google does say happens: the filtering is strong enough that Play hides the app from search and from category browsing even if the person opens a link pointing straight at your app's ID.

Q: Is minSdkVersion the same as the target API level Google keeps emailing me about?

No, and confusing them is expensive. minSdkVersion is the oldest Android you support. The target API level is the newest Android you have declared your app is built against, and Play enforces it on a published schedule. Play Console Help, read on 16 October 2026, says new apps and app updates must target Android 16, API level 36, or higher to be submitted to Google Play since 31 August 2026, with an extension available to 1 November 2026, and that existing apps must target Android 15, API level 35, or higher to remain available to new users. It also says users who have previously installed the app from Google Play will not be impacted, and will still be able to discover, re-install and use the app on any Android OS version that your app supports. That reassurance is about the target level. Do not read it as a promise about your minimum.

Q: What raises my minimum version without me choosing to?

Three things, and two of them are on a clock. The toolchain is the first: uploads to App Store Connect have had to come from Xcode 26 or later since 28 April 2026, and Xcode 26 and 27 cannot build for anything below iOS 15, so the policy floor of iOS 13 is unreachable in practice. The libraries are the second: every dependency carries its own minimum, and the build takes the highest one in the project, so a single SDK can lift your floor without a line of your own code changing. The third is a mistake rather than a deadline. Google tells you to avoid android:maxSdkVersion in general, because the reference warns it can result in your application being removed from users' devices after a system update to a higher API level.

Supporting older phones comes down to the iOS deployment target and the Android minSdkVersion. The deployment target is the oldest iOS your build will install on, and Apple has it floored at iOS 15 today because the Xcode you are required to upload from cannot go lower. minSdkVersion is the oldest Android API level the system will let the app install on, and Google sets no floor there at all. Raising either one does not delete the app from anybody's phone. It stops their updates, quietly, and on Android Google documents that they are never told. Every number and screen name below comes from Apple's and Google's own documentation, read on 16 October 2026.

What follows is how low each store lets you go, what happens to the phone that falls below the line, and the one place Apple has a mechanism it never explains. Then the rule people mix up with this one and pay for twice.

Start here

The short version

Two numbers decide it, and one is capped by your toolchain.

Supporting older phones is not a feature you add. It is two values in your own project. Apple's floor is not a free choice. Apple's upcoming requirements page says that since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, and a separate entry, dated since 9 September 2026, says iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later. The second number looks like the answer. It is not, because Xcode 26 and Xcode 27 cannot build below iOS 15. The policy says 13, the tool says 15, and 15 is the one you have to live with.

Google's floor is a free choice, which is the trap. You can set minSdkVersion low enough to serve a phone from a decade ago and Play will do it. What you cannot do is take the number back without consequences. Raising it later makes the app invisible to the devices you just dropped, and Google documents exactly one thing about what those people see, which is nothing. No update, no notice. Who you drop is a business call and belongs next to your other app monetisation decisions, not buried in a build setting.

How low can you set the minimum iOS version?

iOS 15, and the page that tells you is not the one you would expect. Apple's Xcode support page carries a table with two columns that matter. SDK is the version of the SDKs included in that Xcode. Deployment Target is, in Apple's own words, the OS range supported by that version of Xcode for uploading apps to App Store Connect. Read on 16 October 2026, Xcode 27 lists an iOS 27 SDK and a deployment target range of iOS 15 to 27. Xcode 26 through 26.6 list the same floor of 15. So does every Xcode 16 release, which tops out at iOS 18.

The pattern in that table is the useful part. The ceiling moves every September and the floor has not moved for three Xcode generations. The question worth asking each autumn is not whether you can still target an old iOS, it is whether Apple raised the floor when it raised the ceiling. So far it has not.

What makes that table binding rather than advisory is the upload rule. On its own, old Xcode can still build for old iOS. Apple removed that escape in April 2026, when uploads to App Store Connect started requiring Xcode 26 or later. Combine the two and the result is simple: the lowest iOS you can ship is the lowest your required Xcode will accept, whatever Apple's separate policy minimum of iOS 13 says. A deployment target of 12 is not something you argue about at review time. It is something the upload refuses.

The other thing that lifts your floor is code you did not write. Every library carries its own minimum and the build takes the highest one in the project, so one dependency can move your number without you touching a setting. Payment and authentication SDKs are the usual culprits, because they track platform security features. If you are adding payments, read that SDK's stated minimum before you promise anybody iOS 15.

Apple, Xcode minimum requirements and supported SDKs, read 16 October 2026

Before you change it

What moving the floor actually does

Tick what you are about to change. The left answer is what the store does. The right answer is what the person on the old phone sees.

Nothing ticked. Leaving both numbers alone is a real option, and it is the only one where nobody loses an update they were getting yesterday.

What happens to an iPhone that is below your floor?

The app they already have keeps working. Raising a deployment target is not a remote uninstall, and nothing reaches onto the device. What stops is the supply of updates, and that is the whole cost: the person stays on your last compatible build for as long as they keep the phone, with whatever bugs and whatever security holes that build shipped with.

Whether the App Store offers a new download of an older version to someone on an old iOS is a different question, and here Apple has a mechanism it does not explain. App Store Connect Help, read on 16 October 2026, documents the developer side of it. Open Apps, select your app, click Pricing and Availability in the sidebar, and at the bottom of the page, under Last-Compatible Version Settings, select the available version. A dialog titled Edit your last-compatible version for iOS apps lets you deselect the versions that should not be available. Click Done, then Save at the top right. Only versions submitted to the App Store appear in the list, and you need to be the Account Holder, an Admin or an App Manager to change it.

Read what that page is for and the gap is obvious. Apple frames the screen as a way to address legal or usability issues in a previous app version by removing that version from the App Store. The name of the setting tells you the App Store can serve a last compatible version to somebody. The page never says who gets offered one, under what condition, or what the default is. So the honest position is this: the mechanism exists, you control which of your submitted versions feed it, and the user-facing behaviour is undocumented. Build a support plan on it and you are guessing.

The opposite mistake costs more. Set the floor lower than your code really supports, ship a call into an API the old phone does not have, and you own a crash on hardware you cannot borrow. On iOS the compiler is on your side here, because Swift refuses a call that needs a newer OS than your deployment target unless you guard it. The holes are the ones the compiler cannot see, in native dependencies and at runtime, which turns this into a different job: debugging a crash you cannot reproduce.

Apple, Xcode minimum requirements and supported SDKs, read 16 October 2026

What does minSdkVersion actually do on Google Play?

Two separate things, enforced by two different parties, and Google documents them in two different places. The Android uses-sdk reference, last updated 18 September 2026, covers the device: the Android system prevents the user from installing the application if the system's API level is lower than the value specified in this attribute. That is the phone saying no, with no store involved. The same page then says Google Play uses the uses-sdk attributes declared in your app manifest to filter your app from devices that do not meet its platform version requirements. That is the store saying no earlier, so the install never gets attempted.

Filtering is stronger than the word suggests. Google's filters page, last updated 21 July 2025, says Play hides your application from search results and from category browsing, even if a user specifically requests the app by clicking a deep link that points directly to the app's ID within Google Play. So the support reply that usually works, send them the store link, does not work here. There is nothing at the other end of the link for them.

Leaving the attribute out is worse than setting it too high, and Google walks through why. If you do not declare minSdkVersion the system assumes a default value of 1. Google's own example takes an app that uses API level 3 features with no declared minimum, puts it in front of a device on API level 2, and ends like this: Play shows the app to the user, allows the user to download it, and the app crashes at runtime. That is the reason the reference tells you to always declare the attribute. A refused install is a bad review. A crash on launch is a one star review.

Play Console adds a layer on top that overrides all of this. Its help on compatible devices, read on 16 October 2026, puts it plainly: manifest declarations define what devices your app supports and they operate at the individual device level, with setting minSdk to Android 9 given as the example that makes only devices on Android 9 and above eligible. Exclusions you set in the Play Console override the supported devices your manifest declares, and excluded devices cannot see or install your app on Google Play. If your app is missing from a device whose Android version should qualify, check the exclusions before you check the manifest.

Android Developers, filters on Google Play, last updated 21 July 2025, read 16 October 2026

Do the people who already installed it keep the app?

Yes, on both stores. Google says it once, in a sentence worth reading twice. All filtering restrictions are associated with an application's version and can change between versions, and the example it gives is that if a user has installed your application and you publish an update that makes the app invisible to the user, the user will not see that an update is available. Notice what that does not say. It does not say the app is removed, disabled or hidden on the device. It says the update goes quiet. The install survives and freezes.

That silence is the part to plan for. Those users will not know they have stopped receiving fixes, will not see a message explaining it, and will keep sending you bug reports against a build you stopped shipping. Nothing in either store's documentation offers you a way to tell them. If you care, the message has to come from inside your own app, before you raise the floor, in a build they can still receive.

Google is far more explicit about existing installs for a different rule, which is exactly why people get confused. Play Console Help on target API level requirements, read on 16 October 2026, says new apps and app updates must target Android 16, API level 36, or higher to be submitted to Google Play since 31 August 2026, with an extension available to 1 November 2026, and that existing apps must target Android 15, API level 35, or higher to remain available to new users. Then it gives the reassurance everybody quotes: users who have previously installed the app from Google Play will not be impacted, and will still be able to discover, re-install and use the app on any Android OS version that your app supports. That covers the target level. It is not a statement about your minimum, and Google has not published an equivalent one.

If you genuinely need to keep old devices served, Google documents one route: multiple APKs. Publish one with a lower android:minSdkVersion and one with a higher one, same package name, same signing certificate, a different version code on each. The rule that bites is the ordering, because an APK that requires a higher API level must have a higher version code, and get that backwards and new phones receive the old build. Google is lukewarm about the whole approach: if you publish to Google Play you should build and upload an Android App Bundle instead, and multiple APKs are mainly for publishing outside Play, since you build, sign and manage each one yourself. Weigh that work against the alternative honestly. Two build lines is a permanent tax on every release.

Android Developers, filters on Google Play, last updated 21 July 2025, read 16 October 2026

The same floor, enforced with different amounts of honesty

The question	iOS, deployment target	Android, minSdkVersion	Same answer on both
Where you set the number	Deployment target, in the Xcode project or the app config	minSdkVersion, in the manifest or build.gradle	No
The lowest you can pick today	iOS 15, the floor in Xcode 26 and Xcode 27	No floor at all, Google leaves the number to you	No
A phone below it can install your current build	No	No	Yes
An install made before you raised it keeps working	Yes	Yes	Yes
Those people are told an update exists	Not documented either way	Documented, and the answer is no	No
You can keep an older build available to them	Last-Compatible Version Settings	Two APKs, same key, higher minimum needs the higher version code	No
A separate rule pushes the number up anyway	Uploads need Xcode 26 or later	Updates need target API level 36	Yes

Where this lands if a builder generated your app

Both numbers live in the project, so the only thing that matters is whether you can open the project. Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync, so the code is on your machine as well as in the browser. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month, paid, with no free tier.

In an Expo project these are ordinary config values rather than something a builder hides from you. Expo's app configuration documentation, read on 16 October 2026, documents ios.deploymentTarget and describes it as setting the iOS deployment target, the minimum iOS version, taking a value like 26 or 18.6. The Android minimum is not in the app config at all. Expo puts it in the expo-build-properties plugin as android.minSdkVersion, which overrides the default minSdkVersion in build.gradle, alongside compileSdkVersion and targetSdkVersion. So moving your floor is a one line change in a file you can read, which is the practical argument for owning the generated project rather than renting a preview of it.

The honest limit sits at the store door. Newly does not submit to the App Store on your behalf, because Apple requires the owner of the app's content to submit it. That makes the SDK requirement yours. If the project is still on an old toolchain when you go to upload, App Store Connect refuses the build, and since this is an upload rule rather than a reviewer's judgement it never appears in rejection rates. Keeping the toolchain current is maintenance, not a one off task, and it is the most common way a floor rises without anybody deciding to raise it.

Questions people ask about supporting older phones

iOS 15. Apple's Xcode support page, read on 16 October 2026, lists Xcode 27 with an iOS 27 SDK and a Deployment Targets range of iOS 15 to 27, and its own legend defines Deployment Target as the OS range supported by that version of Xcode for uploading apps to App Store Connect. Every Xcode 26 release shows the same floor of 15, and so does Xcode 16. Apple's upcoming requirements page states two separate rules: since 9 September 2026, iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later, and since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26. The policy says 13 and the required toolchain cannot go below 15, so 15 is the number that binds.

Pick the floor on purpose, then write it down

Put both numbers in the same place as your release notes, with the date and the reason. The next person to ask why the app will not install on somebody's old phone deserves an answer better than a search through build settings.

Start building