@bradfitz for their Tailscale app, @steeve for their Zenly app.

Whatever we decide, I'd like to discuss someone else taking over the Corellium builders.

Also CC @changkun, @hajimehoshi.

Thanks for the ping @eliasnaur.

Generally speaking, supporting N-2 versions is the standard way. That would put it at iOS 12 as of today.
We're building for iOS 11 without issues at the moment.

Thanks for the CC @dmitshur.

I think documenting the official support of the latest two iOS versions is sufficient (does not constraint on it may actually support older OSes). Although iOS releases a new major version every year, a development beta is released 3-4 months before the public release. This means, with the existing Go's release cycle (every 6 months), support the latest two iOSes already past 5 versions of Go releases. If we document the official support's latest three iOS versions, it seems too long (6-7 Go versions)and may tie the Go development process up.

According to a public source on the marked share of iOS versions, iOS 13.7 only shares less than 1% today.

Furthermore, it seems Apple may be much more aggressive to ensure its developers upgrade their apps up-to-date. The majority of their users are more willing to upgrade their systems. Supporting older versions may be beneficial for users who do not upgrade their OS, but this may cause trouble for developers that apps may very difficult to find an appropriate device or environment for testing purposes.

One important thing to note is that updating to the latest iOS SDK isn't a simple operation for most. So including iOS betas for Go releases seems dangerous IMHO.
Lots of things change during the beta period, and most apps don't update until a few months after release. For instance, for iOS 14 we could not bump the SDK until 14.2 was released due to bugs in Apple APIs.

On the other hand, Apple requires apps to use the latest SDK usually around April/May of the year following an iOS release (~September). That said, most iOS will use the #available keyword to guard against calling unsupported APIs; something that's not available to us.

So unless there's a blocking reason (in which case I'd hope we'd discuss it), sticking to N-2 at the time of the Go release seems a simpler option.

Also adding that Go 1.17 compiles for iOS 11 without issue (from my perspective of course).

Regarding the bumping of ios-version-min, as far as I recently learned from @andydotxyz that fyne as a GUI framework that is still needed to support iOS 10 devices. Hence his insights could also be useful.

Thanks @changkun, it is important to be clear on the distinction between the min iOS and the target iOS. Yes Apple is aggressive in moving people's target iOS version up (to be able to access latest features) but they are less pushy about the minimum version (as long as you guard against crashes as @steeve shows).

It is true that the statistics for upgrading iOS is very high - however, if I understand correctly, this is for consumer devices connecting to the standard store. It does not cover MDM or business-managed devices who can be slower and use enterprise-certificates and side-loading through internal distribution which supports much older devices and may not wish the same upgrade cycle. So it's worth considering do we want to match what Apple wants to push, or what is in use in the wider community.

Can we compare to Android? How many versions back do we support there? I know it's not the same, but their numbers seem more "real world".
From the Fyne point of view we try not to increase the minimum version until required for some reason. You build the latest Fyne onto iOS 32bit devices (using Go 1.14 or earlier of course) because I see that there are millions of devices out there that we really should not be condemning to the scrap heap ;)

From the discussion in #49616, it appears that the minimum supported version for platform certificate verification (#46287) is iOS 12.

Issue #49616 is a release blocker for 1.18, and the approach used to resolve it depends on a decision here. (CC @rolandshoemaker.)

there are millions of devices out there that we really should not be condemning to the scrap heap

A new major iOS release comes out each year. There are many old devices that don't update or cannot update to the latest, but because Go aims to enable building secure applications, security and workload constraints mean support must be dropped at some point (and, in specific situations where absence of latest security fixes is not relevant, older Go toolchains can be used as a best effort workaround).

Can we compare to Android?

As far as I can tell, it's not well defined what support levels for Android we're looking and able to achieve. I filed #49654 for determining that.

Based on discussion above and the relevant constraints, it seems to me using N-3 may be an optimal compromise, at least as a starting point with the Go 1.18 release until there's more evidence to adjust this strategy further. Go 1.18 will be out in early 2022, at which point iOS 15 would be latest, meaning Go 1.18 should not try to support iOS 11 and older, if this approach is used. Thoughts?

I generally agree, although I think the choice has more dimensions than "N-K" can capture. For example, it depends on what iOS versions run on what devices. Currently, supporting iOS 11 has zero extra benefit over supporting iOS 12. To support the 2012 iPhone 5 we'd have to support iOS 10. The next model, the 2013 iPhone 5S, supports iOS 12. Apple itself is still releasing iOS 12 versions, but not iOS 11 versions. https://en.wikipedia.org/wiki/IOS_version_history

As long as the Apple policy runs on similar rails, I think supporting whatever Apple is still supporting is the right choice. It's vague, but since the Apple release schedule is not formalized, I think our policy should leave room for interpretation as well.

In fact, we haven't supported 32-bit iOS since Go 1.14 (#34751) which means we don't support any device that can't run iOS 12.

Setting the minimum version to iOS 12 in Go 1.18 should be a no-op in terms of device support (and I am way way way less sympathetic to users who can update their OS but don't).

Change https://golang.org/cl/366914 mentions this issue: doc/go1.18: document that iOS 12 or newer is required

Change https://golang.org/cl/366934 mentions this issue: env/corellium: bump minimum ios version

Change https://golang.org/cl/368615 mentions this issue: misc/ios: bump min version

CL 366914 documents that iOS 12 is required. It seems that the issue is resolved.

Are we still waiting for documentation in https://golang.org/wiki/MinimumRequirements and https://golang.org/wiki/Mobile? Can we close this?

Updated https://github.com/golang/go/wiki/MinimumRequirements mentioning iOS 12 or later.

Thanks all for resolving this!