cordova-ios 8.0.0: Support minimum iOS 15

[GitToTheHub]

Hi,

I would raise the minimum iOS version for cordova-ios 8.0.0 from version 13.0 to version 15.0.

Here are the reasons:

Why minimum iOS 15?

Still 10 years of device support

We still support devices released in 2015. The minimum iPhone would be iPhone 6s released on September 2015, or iPhone SE - 1. generation - released in 2016. For iPadOS, this would be iPad Air 2 (2014), or iPad 5. Generation (2017).

iOS 13 is upgradable to iOS 15

Every device (iPhone/iPad) which supports iOS/iPad OS 13, also supports iOS/iPad OS 15 (see https://iosref.com/ios). There is no device with max iOS/iPad OS 13 or 14.

iOS 13/14 get no security updates

iOS 13 stopped receiving security updates on September 2020 and iOS 14 on October 2021 because Apple won’t backport such fixes since the devices could get the security updates by updating to iOS 15 instead. The current version of iOS 15 is 15.8.5, which was released on September 15, 2025.

No Simulators available for older OSs

In the recent XCode 26 version you can minimum install an iOS 15 simulator. The minimum XCode version since April 24, 2025 supported by Apple for uploading new apps is XCode 16 using an SDK for iOS 18. This XCode also supports minimum an iOS 15 simulator. According ChatGPT, you can't test an App with it on a iOS 13 device.

Remove code for older OSs

We can remove Code for older OSs and must not support them any more.

What do you think?

Regards,

Manuel

[dpogue]

We could look at bumping the minimum iOS version to 15 in Cordova iOS 9, but I'm generally not a fan of bumping it unless we're actually requiring APIs that aren't available in the previously supported version. Xcode might not let you run old simulators, but you can still build and deploy to older devices.

The only reason that I begrudgingly bumped the minimum to iOS 13 for Cordova iOS 8 was because the changes to the WKURLScheme handling weren't feasible on older versions, and we were getting flooded with (incorrect) bug reports about an Xcode warning.

There are a few reasons I feel this way:

1. From an API perspective, dropping support for the sake of dropping support kinda sucks. It's one thing to say "we have to update the minimum version because that allows us to use these new APIs to support these new features", it's another to break compatibility with no gain to the end user.

2. It's a bit of an ethical decision in a world of planned obsolescence, climate change, and rampant e-waste to make choices around which devices you're willing to support.

3. There are lots of people and lots of companies who are not in positions to upgrade devices on a regular basis and who need software that can still support older devices. As an example, I know a company that has a Cordova app deployed to customers with hundreds of old iPads on an internal network that don't support anything newer than iOS 14. The customer isn't in a position to replace all these older (but perfectly functional) devices, and Cordova dropping support would put that company in a difficult position where they'd be forced to stay on old unsupported Cordova versions.

If there's a good technical reason or new API that justifies bumping the minimum version, put an argument together. But I don't find "We get to remove some if statements" and "Apple doesn't care about old versions" to be particularly compelling.

[GitToTheHub]

Good point also 🙂 I added your things to the discussion on the top.

[dpa99c]

Another justification is alignment with major industry players: e.g. Google increased the minimum deployment target from iOS 13 to 15 in its major Firebase iOS SDK v12 release in July 2025.

[GitToTheHub]

Google Maps SDK for iOS goes also one step further and supports minimum iOS 16 with version 10.0.0 from 19. May 2025

[breautek]

It's a bit of an ethical decision in a world of planned obsolescence, climate change, and rampant e-waste to make choices around which devices you're willing to support.

Oddly enough, I am in support of this virtually in every other context I can think of. Dpogue really provoked some thought on this because I've always been the person to bump minimum requirements usually by looking at some metrics including but not limited to:

• market share usage
• Debug and Testability/Support of underlying tools
• Software or technical requirements requiring newer features
• Security concerns

And I feel like we have hit some of these checkpoints. E.g. on XCode 26 afaik you can't install any simulator older than iOS 15. Even if I go into my simulators and add a new one for an older device like 1st gen iPhone SE, the oldest runtime I can download is iOS 15.0. Which makes testing or supporting anything older a bit difficult.

But I admit this is viewing the problem from an app development lens, not from framework development lens.

Diving deeper...

Debug and Testability/Support of underlying tools

In order to properly test older iOS platforms, one would need to either have physical devices, or they will need to have an older XCode version available, potentially requiring an older MacOS version depending on how far back you actually need to go. So that you can get access to the older iOS simulator runtimes.

Security concerns

Honestly, while security concerns are present in general usage of an out-dated OS, I don't think this applies directly to the Cordova framework, unless if the security issue involves linking with a particular SDK version.

Software or technical requirements requiring newer features

Sometimes supporting older platforms requires holding off migrating off of deprecated features as the replacement has a higher minimum version. So either we are stuck with using deprecated APIs that is no longer recommended, or we create two pathways via runtime version checks and/or compiler macros. I think this needs an evaluation on a case-by-case basis, but there is definitely a balance required in my opinion.

So I feel like supporting iOS 11 in 2025, going on 2026 is definitely a bit much. There is a lot of features I think we can look into integrating if we bump it up to at least iOS 13. I'm not sure if there is anything that requires iOS 15 so I think I'm +0 for that.

Bias disclaimer:

In my own apps, I use Google Maps, which I typically keep at a modern version. Their latest major has a minimum iOS of 16, which they treat has "frozen", which means while they support iOS 16, they will not address any issues for iOS 16 in normal circumstances. So as a result, my own apps are iOS 16+.

[breautek]

Just another thought... we could always look at "soft" supporting older/legacy platform versions.

Soft support as in it worked, or used to work but the versions is not actively tested against and any issues arising in those versions are likely not to be prioritized. Which is effectively how we are operate already today. It's just not documented as such.

[erisu]

I believe the deployment target for Cordova-iOS 8.0 should remain at iOS 13.0.

As @dpogue suggested, we can consider increasing the minimum deployment target again in Cordova-iOS 9.0.

The previous major release, Cordova-iOS 7.x, targeted iOS 11.0, and jumping directly to iOS 15.0 feels too aggressive. Such a change would drop support for four major iOS versions in one step, which is a significant gap. Incrementally increasing the minimum version is a more practical approach. IMO

We also need to consider that some apps are distributed in-house to older devices that may be locked to a specific iOS version. While it's difficult to determine how many businesses use Cordova to build in-house apps or what OS versions those devices run, our goal should be to support as many reasonable scenarios as possible.

If our decision is based solely on API usage, then iOS 13.0 remains the most appropriate minimum target for this release. Even though certain APIs under the WKWebView umbrella may require a higher target, we do not currently use those specific APIs. Basing our deployment target on the APIs that Cordova actually implements is the most logical and sustainable strategy.

This perspective applies specifically to Cordova's iOS core framework.
The application itself can set its own deployment target, independent of the framework. The framework's minimum simply defines the lowest iOS version the app can target.

If a developer chooses to use third-party libraries—such as Google Firebase or Google Maps—that require a higher iOS version, it is their responsibility to increase their app's deployment target accordingly. Alternatively, they can remove those libraries if they need to support older devices.

Regarding market share, I believe our general goal has been to support at least 98% of active devices. However, since Apple does not publicly share detailed distribution data, we make the best decision we can based on available information.

We shouldn't bump our minimum deployment target just to align with a third-party library that isn't part of our core dependencies. Third-party libraries don't set their deployment target based on other unrelated libraries. They typically determine it based on the APIs they use directly or their own dependency tree.

They might raise their minimum version for practical testing and tooling reasons, for example, if they no longer have access to testing devices or development environments compatible with older versions of Xcode. But that is based on choice... For instance, GitHub Actions only provides the last three macOS images, and not all Xcode versions can be installed on those runners. Even the oldest supported Xcode version doesn't include support for iOS 13.0 anymore (I recall). But this is where the concept of "soft support", as @breautek suggested, could come into play.

One additional thing I wanted to point out is that some of Apple's own frameworks still set the deployment target as 11.0.