Is it possible to add a builder running the iOS emulator?

Per the porting policy, each port must have a builder with a designated maintainer. (We've run into issues in the past with regressions in otherwise-unsupported emulators, particularly QEMU user mode.)

Is it possible to add a builder running the iOS emulator?

I suppose a macOS builder could be repurposed to start a simulator and run ios/amd64 tests. I did CL 255257 to support running Go programs and tests on the simulator, but I don't have the inclination to set up and maintain a builder. Even if I did, it would likely not make it in time for the freeze.

Per the porting policy, each port must have a builder with a designated maintainer. (We've run into issues in the past with regressions in otherwise-unsupported emulators, particularly QEMU user mode.)

As Austin alluded to above, it's technically not a new port. Using GOOS=darwin GOARCH=amd64 -tags=ios happened to work on the iOS simulator and I have never seen bugs in that support for gomobile nor Gio projects. It seems the ios/arm64 and darwin/amd64 builders provided enough coverage.

My interest in this is solely to move the already existing simulator support to the new (in Go 1.16) GOOS=ios, and not leave it at the awkward GOOS=darwin -tags=ios configuration.

Right. Ideally we would have a builder for this, but I don't know that the porting policy really applies here because this is something we already kind of support. This proposal is really about keeping the thing we already kind of support consistent with other changes.

I guess part of what I'm saying is: if this is a configuration that we “already kind of support”, then we need a builder (regardless of whether it is GOOS=ios or GOOS=darwin -tags=ios) to ensure that that configuration doesn't regress.

(Note that I am distinguishing here between “a configuration that we support” and “a configuration that happens to work today”.)

For android, what we do is GOOS=android but "linux" is implied as a build tag.
Is the suggestion to do the same here? GOOS=ios but "darwin" is implied as a build tag?

@rsc GOOS=ios already implies "darwin", like GOOS=android implies "linux". This issue is about making it so that an iOS binary can be built for the iOS Simulator in AMD64 architecture using the GOOS=ios GOARCH=amd64 configuration, rather than what it was before (GOOS=darwin GOARCH=amd64 -tags=ios).

I posted a question in #38485 (comment) which is relevant (and probably would've been better to post in this issue instead).

The "GOOS=darwin GOARCH=amd64 -tags=ios" configuration was added in 2015, before there was as much attention paid to the porting policy as there is today. It was done with a single commit (see CL 12301) that resolved issue #11736.

I understand this proposal is to offer the same level of support for GOOS=ios GOARCH=amd64 as we did for GOOS=darwin GOARCH=amd64 -tags=ios.

Also CC @golang/release.

Sorry, I missed that amd64 is the important bit here, not ios. This is a clear yes.

Accepted.

Change https://golang.org/cl/263798 mentions this issue: all: add GOOS=ios GOARCH=amd64 target for the ios simulator

Change https://golang.org/cl/264738 mentions this issue: dashboard: skip ios-amd64 SlowBot alias

Change https://golang.org/cl/265197 mentions this issue: cmd/dist: use GOOS=ios for iOS simulator test

Change https://golang.org/cl/267718 mentions this issue: doc/go1.16: add release notes for darwin ports