Read iOS/macOS minimum versions from the framework, where possible.

[freakboy3742]

One of the files included in a BeeWare iOS/macOS support package is the VERSIONS file. This describes the version of Python that has been packaged, and some other metadata, including the minimum supported iOS version.

While this file exists for historical reasons, it (a) isn't in an inherently parseable format, and (b) likely won't be included in an official Python release of an iOS or macOS XCframework distribution.

However, the only piece of metadata that is important for runtime purposes is the minimum OS version - and that is available in the Framework metadata.

This PR modifies the iOS and macOS backends to read the minimum OS version from the XCframework, rather than from the VERSIONS file. This will allow for the VERSIONS file to be removed in later support packages.

A fallback to VERSION files is retained for older support packages that weren't distributed as XCframeworks.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

This sets the min iOS version to 12.0, so why does the command below say --platform=ios_13_0? If this is being intentionally overridden by something, then the comment should explain that, both here and in the other tests updated by this PR.

[freakboy3742]

So - this test is correct - but it points out an edge case that we could handle better.

The definition you've flagged is defining the minimum version allowed by the support package. The app can then define its own minimum version, which is 13.0 by default.

In this test, the fact that the support package can support a version less than 13.0 is fine; but the app specifying a minimum version of 13.0 means that definition takes priority.

The next test in the file (test_min_os_version) verifies that you can customise the minimum OS version to something other than 13.0. The test after that (test_incompatible_min_os_version) verifies that if you specify an app minimum version that is less that your support version, an error is raised.

The edge case is if the app doesn't specify a minimum OS version. The current logic falls back to 13.0 unconditionally - but it would make more sense for the default to be the value in the support package. At the moment, it's a moot point, because the minimum supported version is always 13.0 - but that could (and inevitably will) change in future.

The same edge case exists for macOS. I'll modify the logic to make better use of the available defaults.

[mhsmith]

Why do we need to handle the case where the support package doesn't specify a minimum OS version either in the XCframework or the VERSIONS file? Do such support packages exist, and if so, how could they be used by the current version of Briefcase?

[freakboy3742]

iOS frameworks have always included the minimum version, so this case should probably raise an error rather than fall back to a default. I'll add a change to that effect.

The current macOS support package doesn't specify a minimum version in the framework definition. I'm not sure why - I'm fairly certain it's an oversight on the part of CPython - but it means we'll need to support a default fallback. A fallback of 11.0 makes sense for all extant Python versions (as that's the ARM64 introduction point).

As for VERSIONS files - we didn't originally include the minimum OS version in the VERSION file. IIRC, we added it at about the same time that we added the new --platform based pip installer, because that provided for installing wheels that had a different minimum version identifier. If anything, we could/should be dropping support for the legacy VERSIONS format; but until we do, we might as well retain the fallback.