Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/mobile: support Xcode 7 #12660

Closed
crawshaw opened this issue Sep 17, 2015 · 13 comments
Closed

x/mobile: support Xcode 7 #12660

crawshaw opened this issue Sep 17, 2015 · 13 comments
Labels
FrozenDueToAge mobile Android, iOS, and x/mobile
Milestone

Comments

@crawshaw
Copy link
Member

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
Copy link
Contributor

dmitshur commented Oct 3, 2015

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 #12028 (comment).

@dmitshur
Copy link
Contributor

dmitshur commented Oct 4, 2015

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
Copy link
Contributor

dmitshur commented Oct 4, 2015

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
Copy link
Contributor

rakyll commented Oct 22, 2015

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

@shurcooL, would like to open a CL?

@dmitshur
Copy link
Contributor

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
Copy link

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

crawshaw added a commit that referenced this issue Nov 4, 2015
The existing go_darwin_arm_exec.go script does not work with Xcode 7,
not due to any significant changes, but just ordering and timing of
statements from lldb. Unfortunately the current design of
go_darwin_arm_exec.go makes it not obvious what gets stuck where, so
this moves from a moving buffer window to a complete buffer of the
lldb output.

The result is easier code to follow, and it works with Xcode 7.

Updates #12660.

Change-Id: I3b8b890b0bf4474119482e95d84e821a86d1eaed
Reviewed-on: https://go-review.googlesource.com/16634
Reviewed-by: Michael Matloob <matloob@golang.org>
@giskarda
Copy link

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

@gopherbot
Copy link

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

crawshaw added a commit that referenced this issue Nov 23, 2015
The existing go_darwin_arm_exec.go script does not work with Xcode 7,
not due to any significant changes, but just ordering and timing of
statements from lldb. Unfortunately the current design of
go_darwin_arm_exec.go makes it not obvious what gets stuck where, so
this moves from a moving buffer window to a complete buffer of the
lldb output.

The result is easier code to follow, and it works with Xcode 7.

Updates #12660.

Change-Id: I3b8b890b0bf4474119482e95d84e821a86d1eaed
Reviewed-on: https://go-review.googlesource.com/16634
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-on: https://go-review.googlesource.com/17146
@pawelkowalak
Copy link

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
Copy link

@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:
Image of stolen bundle identifier
(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
Copy link

joeblew99 commented Apr 15, 2017

@egonelbre Thanks for picking this up.

@egonelbre
Copy link
Contributor

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?

@gopherbot gopherbot added the mobile Android, iOS, and x/mobile label Jul 20, 2017
@eliasnaur
Copy link
Contributor

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?

@golang golang locked and limited conversation to collaborators Apr 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge mobile Android, iOS, and x/mobile
Projects
None yet
Development

No branches or pull requests

10 participants