Go: x/mobile: support Xcode 7

[crawshaw]

I have a change to the gomobile tool that appears to make .app bundles produced with Xcode 7. It needs a bit more testing.

The gist of it is that the DevelopmentTeam ID needs to be in the project file. Unfortunately this requires a bit of machinery to detect, and I fear on complex setups we will have to guess which is the correct ID. We probably already were taking the first team ID, so that's not a new problem.

[dmitshur]

It needs a bit more testing.

Is there any CL to review? I'd love to try something out, since I still can't build for iOS as is due to https://github.com/golang/go/issues/12028#issuecomment-141010040.

[dmitshur]

Note, I haven't plugged in a physical iOS device yet; I was gonna try the .app bundle on simulator first.

I've tried that now. Plugging in an iOS device did not help on its own, but when I tried running a sample iOS app on it, Xcode told me that my provisioning profiles were missing and it could try to fix it by resetting to default recommended settings. Letting it do that added a single provisioning profile. After that, I was able to deploy that sample iOS app to my iOS device.

However, gomobile still doesn't work after that change, but now it's a different error:

$ gomobile build -target=ios golang.org/x/mobile/example/basic
gomobile: xcrun xcodebuild -configuration Release -project /var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/gomobile-work-449284111/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 with a valid signing identity (i.e. certificate and private key pair) matching the bundle identifier “org.golang.todo.basic” were found.

** BUILD FAILED **


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

[dmitshur]

Just to see if I could get it to work, I modified gomobile to use "shurcooL.Test-1" as the bundle identifier (the same as what my sample iOS app used) when building iOS apps (see build_iosapp.go#L34), and that allowed it to work successfully.

[rakyll]

@shurcooL updated me yesterday that he may know how to generate a valid bundle identifier programatically.

@shurcooL, would like to open a CL?

[dmitshur]

It's more accurate to say I've learned more about why/how it works and what it would take to resolve the issue, but I don't know much about the specifics of generating certificates programmatically (without spending time researching this).

In the original post, @crawshaw said he had a change that appeared to work, but needed more testing. I'd be happy to help review if it were to be made into a CL (even if marked as "do not review" because it's not ready yet).

[gopherbot]

CL https://golang.org/cl/16634 mentions this issue.

[giskarda]

In the meantime do you think we can update the documentation to reflect that certificates are still necessary?

[gopherbot]

CL https://golang.org/cl/17146 mentions this issue.

[pawelkowalak]

As a workaround you can create a new, empty project in Xcode7 with the same namespace as your Go app, deploy it to your device and then you'll be able to set Trust level on the device. gomobile build -target ios and ios-deploy should work after that.

[AndreasHassing]

@viru: I get the following error:

Code Sign error: No matching provisioning profiles found: No provisioning profiles with a
valid signing identity (i.e. certificate and private key pair) matching the bundle identifier
“org.golang.todo.basic” were found.

In XCode I try to set the dummy-project's Bundle Identifier to be equal to the expected one (org.golang.todo.basic), and I get this:

(is that because someone on the app-market is already using that identifier? Edit: yup, that's why)

How do I set the gomobile build (or the basic go-project even) to use a different bundle identifier? Edit: see below.

---

Answer

I figured out how to fix it for my case (edit: and found out even later, that @shurcooL had already posted how to resolve this issue):

1. Edit golang.org/x/mobile/cmd/gomobile/build_iosapp.go:
   
   
   
   • Change BundleID's value from org.golang.todo. to domain.your_organization.package.
   
   
2. Run go install golang.org/x/mobile/cmd/gomobile to apply the change to the binaries.
3. Rebuild the gomobile app.
4. ...?!
5. Profit!

[joeblew99]

@egonelbre Thanks for picking this up.

[egonelbre]

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. But, there probably are restrictions how it can be used.
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. This potentially could allow directly deploying from XCode rather than the drag-and-drop approach.

Currently 3. seems the most promising and least likely to break in the future.

Any thoughts?

[eliasnaur]

I believe this issue is a duplicate of #20241, which is about the ability to configure the app id and signing parameters. I'm going to close this because 20241 is more specific.

@egonelbre it's been a while, but I believe the way forward on this issue is making gomobile build produce an artifact that the user then signs and uploads somehow (through Xcode). It's a nice goal to be able to run gomobile build and then have a final app ready to deploy, but I don't think it's realistic to expect gomobile be able to do that by itself, effectively copying Xcode. In particular, it is not scalable to larger projects where you want to customize permissions, icons and so on.

gomobile bind produces a .framework ready to be included in Xcode. Is there something similar for complete programs? Perhaps the unsigned .app folder structure?