go version:
1.7
go env:

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/zeta/workspace/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/7v/mfkwfd0s2gv68b087kpx3dpc0000gn/T/go-build664342466=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

building: https://github.com/golang/mobile/tree/master/example/basic

gomobile build -target=ios

gomobile: xcrun xcodebuild -configuration Release -project /var/folders/7v/mfkwfd0s2gv68b087kpx3dpc0000gn/T/gomobile-work-901146193/main.xcodeproj failed: exit status 65
=== BUILD TARGET main OF PROJECT main WITH CONFIGURATION Release ===

Check dependencies
Code Sign error: No matching provisioning profiles found: No provisioning profiles matching an applicable signing identity were found.

** BUILD FAILED **


The following build commands failed:
    Check dependencies
(1 failure)

Xcode : 7.3
MacOS:10.11

i never worked it out..

I can build other things for IOS, just not with gomobile

This is a duplicate of #12660, check there for workarounds.

hey @vIRu
Thats does sound exactly like what i experience too. Thanks for letting me know.

The problem is that its not really fixed. The fix is to hardcode a namespace into the gomobile tool and then recompile. Thats really a temp hack..

@eliasnaur
Could someone on the gomobile team think about fixing this obvious tooling bug ?
What might be best is a command line flag for compiling for ios ? This would then get ride of the hardcoded constant in the common code as shown at the #12660

I agree that it seems like an obvious tooling bug, but unfortunately iOS provisioning and signing is not obvious to me. I'll gladly review any CL that attempts a fix.

@shurcooL did you ever get past this ??

No, I haven't built for mobile recently. My latest status was #12660 (comment).

in summary, for now I guess i will also just have to maintain my own fork and hack it too.

@shurcooL
thanks for update.

@eliasnaur
i doubt i have the skills to fix this. IOS signed etc is also newish to me.

I'm looking into fixing this.

I think the first solution should be to allow specifying the BundleID (and Android package ID) manually and direct people to create an application in XCode with the specified identifier. This would make gomobile easier to use now, with little effort. PS: Currently when I tried to use an existing profile then xcodebuild also required to specify DEVELOPMENT_TEAM (that can be detected from the provisioning profile).

Then as a next step there are few ideas:

1. Try to figure out how to create provisioning profile automatically (command-line tools or write the code). Unfortunately, I haven't yet found a nice way to do it. We can create BundleID with this https://play.golang.org/p/ZiOkpaU3HP... but this could still be problematic when you want to build application that is already registered and you don't have the signing key.
2. Use wildcard AppID for multiple apps (https://developer.apple.com/library/content/qa/qa1713/_index.html) -- this would avoid the need to create manually multiple profiles. There probably are restrictions when doing it in this way.
3. Combine XCode and gomobile. When selecting a new project there are templates "Empty" and "External-Build-System"... maybe we can use XCode to trigger "gomobile" with the correct parameters. Or create a custom template for gomobile.

Any thoughts?

PS: it seems that #12660 is pretty much the same issue? Should the discussion be moved there and this closed as a duplicate?

@egonelbre Thanks for picking this up.
yes #12660 is the same. i will close this, so it can be worked on at #12660