Minimum deployment target
The oldest OS version your app will install on. Raise it for newer APIs, raise it too far and older phones lose the app.
See it
What it is
One setting decides the oldest OS your app will install on: the deployment target in Xcode, minSdkVersion in Gradle. Anyone below that line either does not see your app in the store or gets told their device is not compatible. Raise it and you get to use newer APIs with no availability checks, drop compatibility shims, and shrink the matrix you have to test. Raise it too far and you have quietly deleted part of your audience.
The usual call on iOS is to support the current version and the one or two before it, since adoption is fast and the tail is thin. Android is a judgment call you should make with data, not vibes: Play Console shows the actual share of your users and of the device catalog per API level, and in some markets a level you assumed was dead is 8 percent of your installs. Decide with that number, then check the analytics again a year later.
The confusion that trips everyone: minSdkVersion is not targetSdkVersion and neither is compileSdkVersion. Minimum is the floor for installs; target declares which OS behaviors you have adapted to; compile is just which SDK you build against. Google Play enforces a rising target level every year for new updates, which is a separate obligation from your floor. And raising the floor mid-life does not push anyone off your app: existing users on older versions simply stop receiving updates, frozen on whatever they last installed.
Ask AI for it
Set and document the minimum OS support for my app. Set the iOS deployment target to the current major version minus one. For Android, here is my exported API level distribution from Play Console: [paste the table, or attach the CSV]. Pick the lowest minSdkVersion that still covers 98 percent of the users in that table, show the arithmetic, and name the users being cut. If I did not give you that table, do not guess a number: produce the audit and a decision template with the threshold left blank instead. Keep targetSdkVersion and compileSdkVersion at the newest level Play requires, and explain in comments that these are three different settings. Then audit the codebase for APIs newer than the floor and wrap them in availability checks with a working fallback path, and add a CI lint rule that fails if an unguarded newer API is introduced.