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.

Sign up for GitHub

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

Jump to bottom

x/mobile/cmd/gomobile: add iOS build support #11043

Closed
rakyll opened this issue Jun 3, 2015 · 11 comments
Closed

x/mobile/cmd/gomobile: add iOS build support #11043

rakyll opened this issue Jun 3, 2015 · 11 comments
Labels
FrozenDueToAge
Milestone
Unreleased

Comments

@rakyll
Copy link
Contributor

rakyll commented Jun 3, 2015

This is the tracking bug for the gomobile’s iOS build support.

There are two obvious strategies we can follow to build an *.app file from a Go package.

The first alternative is what misc/ios/go_darwin_arm_exec.go has been doing.

  • Require user to set GOIOS_DEV_ID, GOIOS_APP_ID, and GOIOS_TEAM_ID manually.
  • Target darwin/arm (and darwin/arm64 in the future) and build a binary.
  • Generate Info.plist, Entitlements.plist and ResourceRules.plist.
  • Compile the asset catalog and generate asset catalog plist file. (TBD)
  • codesign the the application directory.
  • Output the app file and optionally generate an IPA for ad-hoc distribution.

Or a simpler alternative is to create a minimal Xcode project.

  • Create the minimal Xcode project. (TBD, CLI tools like xcodeproj is able to create projects, it must be doable.)
  • Target darwin/arm and build a binary.
  • Shell out to xcodebuild to build and app. (It will fail if there are no default signing authorities.)
  • Optionally we can output the generated xcode project to allow users to open it in Xcode.

Any feedback or opinions about which way to follow?

cc/ @crawshaw @hyangah @minux
@rakyll rakyll self-assigned this Jun 3, 2015
@rakyll
Copy link
Contributor Author

rakyll commented Jun 3, 2015

I may move the discussion to golang-dev@ if any extensive discussion is required.

@rakyll rakyll added the Started label Jun 3, 2015
@crawshaw
Copy link
Member

crawshaw commented Jun 3, 2015

If the latter approach works, creating an Xcode project and building it with xcodebuild, I would prefer that as it offers users more flexibility. However I'm not sure how it will be compatible with our linking process. For gomobile bind this strategy will definitely work, because we provide .a files and expect the entry point to be a main function in a .m/.c file, which xcode understands how to link.

Perhaps it is possible to replace the binary compile command with an xcode project setting?

One alternative would be to forgo real binary building and build with -buildmode=c-archive and let xcode do the linking (with a tiny .c file containing a main function). It would be odd, building libraries and passing them to xcode because there's no other way to get at its app building machinery, but if there's no other way it would probably work.

Minor notes:

  • darwin/arm64 binaries are required by the app store, so we should build both. The tool to build universal binaries is called lipo.
  • the build should copy assets to xcode resources.
  • a slash page image is required to get the iPhone 5S/6 to use its full resolution. according to the UI guideline this splash page is not a "company icon"-style splash page but an image of the first page. For game-like apps, I suspect that's a simple black page.

@ianlancetaylor ianlancetaylor added this to the Unreleased milestone Jun 3, 2015
@rakyll
Copy link
Contributor Author

rakyll commented Jun 3, 2015

However I'm not sure how it will be compatible with our linking process.

I was able to skip the compile/link step just by removing the main.c, adding a static binary to the project and setting the CFBundleExecutable. I will investigate if it is achievable with lipo files.

I suspect that's a simple black page.

We may look for a, let's say, splash.png in the assets directory and fall back to a default image (which is likely to be a black image). According to the guidelines, a black screen is not a bad idea.

@rakyll
Copy link
Contributor Author

rakyll commented Jun 4, 2015

The idea worked with fat binaries! I pushed a minimal Xcode project to https://github.com/rakyll/go-xcode and am suggesting to follow this path. Being able to work with Xcode is great for the developer experience. I am seamlessly pushing the debug builds to the test device, can export the app as an ad-hoc distribution or publish the app to the App Store.

@rakyll
Copy link
Contributor Author

rakyll commented Jun 4, 2015

Blocked by #11075.

rakyll added a commit to golang/mobile that referenced this issue Jun 18, 2015
@rakyll
mobile/cmd/gomobile: add the assets to the iOS Release build
2813ddb 
Updates golang/go#11043.

Change-Id: Ied1a2a4842dc0078dc34da1266c11eec9acba114
Reviewed-on: https://go-review.googlesource.com/11263
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
@rakyll
Copy link
Contributor Author

rakyll commented Jun 20, 2015

Blocked by #11311.

@rakyll
Copy link
Contributor Author

rakyll commented Jun 23, 2015

Blocked by #11339.

@gopherbot
Copy link

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

rakyll added a commit to golang/mobile that referenced this issue Jun 24, 2015
@rakyll
cmd/gomobile: build *.app files if target=ios
597df59 
This CL will be followed by another change to remove the
misc/ios/clangwrapper.sh dependency.

Updates golang/go#11043.

Fixes golang/go#11339.

Change-Id: I82466f8d845945935ab82d3d0b75f5af9e1ef3ec
Reviewed-on: https://go-review.googlesource.com/11345
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
@rakyll
Copy link
Contributor Author

rakyll commented Jun 24, 2015

Blocked by #11342.

@rakyll
Copy link
Contributor Author

rakyll commented Jun 24, 2015

Blocked by #11337.

@gopherbot
Copy link

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

@golang golang locked and limited conversation to collaborators Jun 28, 2016
imWildCat pushed a commit to imWildCat/go-mobile that referenced this issue Apr 10, 2021
@rakyll
cmd/gomobile: enable target=ios builds
040bd65 
This CL adds iOS build support to gomobile command.

  $ gomobile build golang.org/x/mobile/example/basic

gomobile builds an .app file that is signed with the development
provisioning entities.

You may deploy .app files to your test device or convert them to IPA
to publish on App Store or share them as an AdHoc distribution.

target=ios flag requires a Darwin host machine.

Fixes golang/go#11043.

Change-Id: Ibc23b6d355f10b09940b20c813eb73d0f4313851
Reviewed-on: https://go-review.googlesource.com/11587
Reviewed-by: David Crawshaw <crawshaw@golang.org>
imWildCat pushed a commit to imWildCat/go-mobile that referenced this issue Apr 11, 2021
@rakyll
cmd/gomobile: enable target=ios builds
51a4d9b 
This CL adds iOS build support to gomobile command.

  $ gomobile build golang.org/x/mobile/example/basic

gomobile builds an .app file that is signed with the development
provisioning entities.

You may deploy .app files to your test device or convert them to IPA
to publish on App Store or share them as an AdHoc distribution.

target=ios flag requires a Darwin host machine.

Fixes golang/go#11043.

Change-Id: Ibc23b6d355f10b09940b20c813eb73d0f4313851
Reviewed-on: https://go-review.googlesource.com/11587
Reviewed-by: David Crawshaw <crawshaw@golang.org>
@rsc rsc unassigned rakyll Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@rakyll @crawshaw @ianlancetaylor @gopherbot