“Adds iOS build support to gomobile command”(go-review.googlesource.com)
go-review.googlesource.com
“Adds iOS build support to gomobile command”
https://go-review.googlesource.com/#/c/11587/8
60 comments
I currently do this with Rust, as it can target both iOS [1] and Android [2], but you do have to build your own cross-compiler.
[1]: https://github.com/rust-lang/rust-wiki-backup/blob/master/Do...
[2]: https://github.com/rust-lang/rust-wiki-backup/blob/master/Do...
[1]: https://github.com/rust-lang/rust-wiki-backup/blob/master/Do...
[2]: https://github.com/rust-lang/rust-wiki-backup/blob/master/Do...
You can do that with C and C++ as well. It's the native platform framework interfacing problem that usually makes this not as amazing as it sounds
You can actually do that with a lot of languages now. C# with xamarin, java/clojure with robovm, java with j2objc, etc.
I was tempted with robovm, but found the 30s minimum build & run cycle for trivial code changes too slow for me.
And the performance is pretty good for these guys, they're all as fast as objective-c:
https://medium.com/@harrycheung/mobile-app-performance-redux...
At my last job we did the C++ cross platform layer, and it was very painful. C++ is slow to compile and can create bloated binaries. There can be something said for the freedom of having separate platform teams with just a server api.
I was tempted with robovm, but found the 30s minimum build & run cycle for trivial code changes too slow for me.
And the performance is pretty good for these guys, they're all as fast as objective-c:
https://medium.com/@harrycheung/mobile-app-performance-redux...
At my last job we did the C++ cross platform layer, and it was very painful. C++ is slow to compile and can create bloated binaries. There can be something said for the freedom of having separate platform teams with just a server api.
And we're doing the separate platform teams thing, and have to find, train, pay twice the number of developers that would be needed for a cross-platform solution. There is by no means a clear answer on which way is better...
We looked at doing cross-platform, but we would have to retrain a lot of iOS-only or Java-only developers so no luck.
We looked at doing cross-platform, but we would have to retrain a lot of iOS-only or Java-only developers so no luck.
I wouldn't say 'double' the engineers. In my last company's case, you still need to write the iOS and Android "UI" part, and waiting for the C++ engineers to finally make this relatively simple thing could take longer than it should. Sometimes it was just faster for the two UI engineers to implement it in the UI than it was for the two C++ engineers to make it themselves.
Then the UI engineers often had to create wrappers for the C++ objects (in the iOS Objective-C++ case at least), because ObjC objects only take NSString, while the C++ types only give C++ strings and other such glue things.
Then lazy engineers / deadlines would move business logic into the UI layer wrappers, because development speed wise it was much easier to work with there than to put inside the C++ layer.
Cross platform makes it's own work. But this was with a 'homegrown' C++ solution, so maybe something made by a third party like xamarin might be a very different experience.
Then the UI engineers often had to create wrappers for the C++ objects (in the iOS Objective-C++ case at least), because ObjC objects only take NSString, while the C++ types only give C++ strings and other such glue things.
Then lazy engineers / deadlines would move business logic into the UI layer wrappers, because development speed wise it was much easier to work with there than to put inside the C++ layer.
Cross platform makes it's own work. But this was with a 'homegrown' C++ solution, so maybe something made by a third party like xamarin might be a very different experience.
I play with Android and Windows Phone in my free time, but I also have experience with cross platform development.
One additional issue is that an abstraction layer also adds up in development time. Someone needs to write the platform specific glue, create abstractions that work across all platforms lifecycles, debug if errors happen in the middleware or device firmware...
So it is not always a clear win to not have focused device teams.
Each OS is very complex and no developer can know all of it.
One additional issue is that an abstraction layer also adds up in development time. Someone needs to write the platform specific glue, create abstractions that work across all platforms lifecycles, debug if errors happen in the middleware or device firmware...
So it is not always a clear win to not have focused device teams.
Each OS is very complex and no developer can know all of it.
"Twice" seems exaggerated; cross-platform applications come with their own set of challenges (often about device-specific issues), and you'll still need expertise on all your supported platforms. Saying developing for X native platforms is X times as hard/expensive is naive.
What's the point of your post? OP provided an anecdote, I provided another. You're criticizing something that was never said.
RoboVM has been working pretty hard recently to cut the compile times down. I haven't used it in a year, but I read a blog post where Nick said he cut the compile times down by a ton. Plus he added incremental compiling recently as well, which should resolve your issue. :D
This was from me playing with it a week ago in the new robovm studio. It's still 30s with no code changes after you have built once, most of it being the robovm build part.
Long compile times and bloated binaries do come with the platform for C++, but (with experience) you get pretty good at minimizing both of those with little effort. This also tends to lead to a fairly clean dialect of C++ (closer to C), and has higher performance code as well. It basically boils down to not really using templates.
That means no stl or boost, but (and this is not a popular opinion at all) this tends to lead to cleaner code, and more productive programmers.
My experience is that templates do allow for more code reuse than you can typically get in other languages, however they do so at a high complexity and maintenance cost -- not to mention binary bloat and long compile times.
That means no stl or boost, but (and this is not a popular opinion at all) this tends to lead to cleaner code, and more productive programmers.
My experience is that templates do allow for more code reuse than you can typically get in other languages, however they do so at a high complexity and maintenance cost -- not to mention binary bloat and long compile times.
I've learned long ago that you can't rely on 'good engineers' to keep up good practices over a large amount of people. Eventually the bad practices happen unless it's set as policy by the heads of the C++ platform, and enforced by scripts and management. It comes down to an education thing, since most C++ devs you hire will use boost & STL.
And de-templating, removing stl & boost from 300k+ line projects and debugging it all is something most orgs wont swallow.
And de-templating, removing stl & boost from 300k+ line projects and debugging it all is something most orgs wont swallow.
I use STL and Boost, it seldom goes over 8MB.
However stay away from Qt if you don't want over 30MB with almost no mobile support.
However stay away from Qt if you don't want over 30MB with almost no mobile support.
"makes this not as amazing as it sounds"
It's actually pretty amazing. C/C++ has lots and lots of well established, well tested, open source code in every possible domain. There's also a pretty large base of programmers familiar with the language. There's no dearth of tooling on any platform. And you can do pretty much anything you want to squeeze performance out of the mobile platform (think watches).
If you can write bulk of your business logic as a C/C++ library with clear API's to call into it, then you can simply compile it directly into the ObjC code on iOS and add a thin JNI wrapper on those API's on Android. It works beautifully. We do this for our mobile specific protocol code.
It's actually pretty amazing. C/C++ has lots and lots of well established, well tested, open source code in every possible domain. There's also a pretty large base of programmers familiar with the language. There's no dearth of tooling on any platform. And you can do pretty much anything you want to squeeze performance out of the mobile platform (think watches).
If you can write bulk of your business logic as a C/C++ library with clear API's to call into it, then you can simply compile it directly into the ObjC code on iOS and add a thin JNI wrapper on those API's on Android. It works beautifully. We do this for our mobile specific protocol code.
What is the build cycle time for your C++ code? Does it kill xcode's indexer? Does it get included into the iOS project?
It's about 50K lines of code all told (using simple find | wc -l ) all library code used (except for language and posix standard libraries) is included in the repo.
"What is the build cycle time for your C++ code?"
Depending on the machine, 10-20 seconds
"Does it kill xcode's indexer?"
Not at all.
"Does it get included into the iOS project?"
Yes it does. We have it as a git sub repo and a sub project in XCode. Both those things allow us great freedom in independent development, testing, release versioning etc. Of course there are also make files for independent build/test cycles on linux etc.
Another bonus of having it as a first class XCode project, clang Analyze tool does beautiful static analysis. What a godsend that is.
"What is the build cycle time for your C++ code?"
Depending on the machine, 10-20 seconds
"Does it kill xcode's indexer?"
Not at all.
"Does it get included into the iOS project?"
Yes it does. We have it as a git sub repo and a sub project in XCode. Both those things allow us great freedom in independent development, testing, release versioning etc. Of course there are also make files for independent build/test cycles on linux etc.
Another bonus of having it as a first class XCode project, clang Analyze tool does beautiful static analysis. What a godsend that is.
Yeah at my old job, the C++ part was more around 500'000 lines of code, and it took 15 minutes to compile full cycle. And it also killed xcode's indexer.
You guys have a far more manageable size.
You guys have a far more manageable size.
I do the same, but JNI is a big pain, specially given how Android team deals with those pesky NDK users.
Agreed. I guess the most amazing part is that you don't need C or C++.
Is it really that beneficial to do this? Your system API's are still in Java/Obj-C/Swift, so all you can really share is business logic.
Has anybody had any real benefit from doing this in the past? I know Facebook did it with moments, but the image processing code could at least be shared here.
Has anybody had any real benefit from doing this in the past? I know Facebook did it with moments, but the image processing code could at least be shared here.
Google does it with Inbox. They have Java business logic that they cross-compile to Javascript on the web, ObjC on iOS, and run as-is on Android. The respective UIs are done natively on the respective platforms. (Surprisingly, they do not use GWT for the web UI.)
I guess there is a lot of complex logic in there, the GWT chunk is a good megabyte or so, if I remember right. I think it's all syncing and conflict resolution stuff, but it's hard to tell for sure. (GWT code is optimized/compacted enough that I only have the string constants to go on.)
I guess there is a lot of complex logic in there, the GWT chunk is a good megabyte or so, if I remember right. I think it's all syncing and conflict resolution stuff, but it's hard to tell for sure. (GWT code is optimized/compacted enough that I only have the string constants to go on.)
It's possible to have significant amounts of business logic. Google is able to share 70% of it's code (written in Java) for the Google Inbox apps[0][1].
[0]: http://gmailblog.blogspot.ca/2014/11/going-under-hood-of-inb...
[1]: http://arstechnica.com/information-technology/2014/11/how-go...
[0]: http://gmailblog.blogspot.ca/2014/11/going-under-hood-of-inb...
[1]: http://arstechnica.com/information-technology/2014/11/how-go...
Depending on how you structure your application, "business logic" may include persistence, network code, and everything that's not UI.
If you're writing games, you aren't using those Java/Obj-C/Swift APIs; you're using the C API.
That's the use case they're targeting. They want Go to be a viable language for mobile games, not mobile apps.
That's the use case they're targeting. They want Go to be a viable language for mobile games, not mobile apps.
is that still correct after the Dalvik -> ART move ? I always thought a long term strategy around ART was to move away from the jvm dependency.
Just in time for all the Oracle lawsuits confirming that Java apis are patent encumbered.
Just in time for all the Oracle lawsuits confirming that Java apis are patent encumbered.
Nothing official but after all these efforts with ART and jack&Jill both of which are not tied to java, it seems likely that Google is at least experimenting with another language.
What else would Google use? Android dev is pretty reliant on the OO model.
Well, that's an open question...
IMO, moving to another language should be taken as an opportunity to fix the oversights of the Framework. Things like the atrocious Activity lifecycle or the backstack handling.
There are several contenders :
-Dart : Google controls this language and the Dart Team is openly experimenting with their own Android fralewirj. The results are extremely underwhelming so far though.
-Kotlin : A better Java. I doubt that it would solve Android legal troubles though.
-Rust : the language has so many interesting ideas. I don't know if its complexity is warranted in Android's context though.
-a new language inspired by Kotlin, Rust, Go, Swift,... . Why not ? It would need a serious value proposition in order to be interesting though.
-insert your pet language here : everyone seems to want to develop Android apps in their most familiar language ...
Again, the official word from the Android team is that Java is the language of the platform for the time being. I just hope that if they are indeed planning a switch to another language, it will be discussed in the open beforehand. Such a debate is not always constructive, but it could be very important in Android's context.
IMO, moving to another language should be taken as an opportunity to fix the oversights of the Framework. Things like the atrocious Activity lifecycle or the backstack handling.
There are several contenders :
-Dart : Google controls this language and the Dart Team is openly experimenting with their own Android fralewirj. The results are extremely underwhelming so far though.
-Kotlin : A better Java. I doubt that it would solve Android legal troubles though.
-Rust : the language has so many interesting ideas. I don't know if its complexity is warranted in Android's context though.
-a new language inspired by Kotlin, Rust, Go, Swift,... . Why not ? It would need a serious value proposition in order to be interesting though.
-insert your pet language here : everyone seems to want to develop Android apps in their most familiar language ...
Again, the official word from the Android team is that Java is the language of the platform for the time being. I just hope that if they are indeed planning a switch to another language, it will be discussed in the open beforehand. Such a debate is not always constructive, but it could be very important in Android's context.
ART still uses dalvik bytecode.
from my understanding, it uses dalvik bytecode (dex) as input format. but the resultant .oat files are binary/ELF [1]
[1] http://newandroidbook.com/files/Andevcon-ART.pdf
[1] http://newandroidbook.com/files/Andevcon-ART.pdf
And even 99% of the business logic these days is pushed server side.
I've worked on about 20 enterprise apps and they are nothing more than pretty API wrappers with some trivial functionality implemented on the phone.
I've worked on about 20 enterprise apps and they are nothing more than pretty API wrappers with some trivial functionality implemented on the phone.
Haven't tried this myself, but Swift compiles to Android:
http://elementscompiler.com/elements/silver/
http://elementscompiler.com/elements/silver/
it's a good replacement for C if you were using it in Android or Ios. But you can't write classic Android or Ios apps with Go.You can however use Opengl so potentially write games, but using Cocoa and co? zip. Go on android doesn't even support android's own NDK ...
Yeah, being able to compile and link a binary is pretty far from having a nice SDK :-)
It doesn't save you from JNI or Objective-C/Swift fun.
Regardless of what is going on with Oracle, the Android team sees the NDK as a nuisance and only offers NDK APIs suitable for games.
How does Go represent UIkit and similar APIs?
Regardless of what is going on with Oracle, the Android team sees the NDK as a nuisance and only offers NDK APIs suitable for games.
How does Go represent UIkit and similar APIs?
OT: Does Gerrit provide any extra features helping in code review, compared to Github? We use Github and it does fine.
Gerrit and GitHub provide two different paradigms. If you want a straightforward answer, then yes Gerrit provides a number of extra features, but it isn't a replacement for GitHub.
Yeah, it does -- I'll let somebody who knows it better fill you in, but it really is night and day if you're serious about reviewing code. If you'd like to try a more powerful code review system than GitHub's to see what you're missing, without spending lots of time setting up and learning Gerrit, I'd recommend giving https://reviewable.io a whirl. (Disclosure: I built it.)
So this make something similar as Cordova possible ? Running a local webserver with all logic, serving html5/css/js as GUI ?
Would still need bindings for accelerator and such (just as Cordova) but maybe its possible to use the ones Cordova already has ?
Which part of the application can be shared between iOS and Android apps that is most suitable to write in Go? Data layer, like communication protocol?
go has issues on IPv6 clients, so not communication.
Probably the business logic, which is what least needs to interact with the OS APIs.
Probably the business logic, which is what least needs to interact with the OS APIs.
What exactly does this enable?
Here's some good examples: https://medium.com/using-go-in-mobile-apps
Judging from the popping a dialog example, I think the main use case is reusing a Go library inside an iOS app, not any kind of standalone app development entirely with Go. At least, not without a lot of helper libraries which don't exist yet!
Judging from the popping a dialog example, I think the main use case is reusing a Go library inside an iOS app, not any kind of standalone app development entirely with Go. At least, not without a lot of helper libraries which don't exist yet!
Dear mods: please stop 'de-editorializing' headlines when the alternative won't make any sense. The new title for this link is nigh-unintelligible.
(the previous title was something like "Go 1.5 will add support for building iOS apps")
(the previous title was something like "Go 1.5 will add support for building iOS apps")
Take the sample bias out of your request and generalize it to all of HN, and what you're asking will no longer sound so trivial.
Submitters make up titles all the time that are (to use the sibling comment's words) "clear, descriptive", and wrong. Set aside the fact that HN's rules explicitly ask people not to do that. What would you have us do?
If you say "never change them", that would flood HN with false and manipulative titles forever. (Not that this one was false and manipulative—I wouldn't know. But I do know that that would be the consequence of never changing titles.) If you say "change the ones that are false and keep the ones that are true", you're asking us to be experts on everything.
The submitted title was "Go 1.5 will have iOS support". The submitted web page says nothing of the sort. What should we do? Being an expert on the Go project's internal progress—that is, being an expert on everything in the general case—is not an option. So we look for language in the article itself that is representative of what it says. That has two merits: (1) it preserves the neutral quality of HN's front page and (2) it's doable.
If you'd like to propose a change that doesn't demand superhuman powers of us and wouldn't destroy the character of HN, please do. But getting upset over a single suboptimal example doesn't seem serious to me. HN sees a thousand stories a day. Not every example is going to come out optimal no matter what we do.
Submitters make up titles all the time that are (to use the sibling comment's words) "clear, descriptive", and wrong. Set aside the fact that HN's rules explicitly ask people not to do that. What would you have us do?
If you say "never change them", that would flood HN with false and manipulative titles forever. (Not that this one was false and manipulative—I wouldn't know. But I do know that that would be the consequence of never changing titles.) If you say "change the ones that are false and keep the ones that are true", you're asking us to be experts on everything.
The submitted title was "Go 1.5 will have iOS support". The submitted web page says nothing of the sort. What should we do? Being an expert on the Go project's internal progress—that is, being an expert on everything in the general case—is not an option. So we look for language in the article itself that is representative of what it says. That has two merits: (1) it preserves the neutral quality of HN's front page and (2) it's doable.
If you'd like to propose a change that doesn't demand superhuman powers of us and wouldn't destroy the character of HN, please do. But getting upset over a single suboptimal example doesn't seem serious to me. HN sees a thousand stories a day. Not every example is going to come out optimal no matter what we do.
Hi Dan - fair point. To be pedantic, though, the title of this article should then be
Change Ibc23b6d3: cmd/gomobile: enable target=ios
builds | go-review.googlesource Code Review
Even pedantically, that's not true: the HN guidelines have never said you must always use the original title. Pedantry aside, the important thing above is language in the article itself that is representative of what it says. That's both why we changed the title and what we changed it to.
> allow both titles and descriptions on posts with URLs.
I appreciate the suggestion, but we're unlikely to do that. On HN, submitting a story conveys no special rights, and submitters do not get to frame the story for everybody else. Framing it for everybody else effectively means controlling the discussion. We want discussion to be driven by the article itself, not a single user's spin. If a submitter wishes to offer a description or say what they think is important about a story, they're welcome to do so by adding a comment to the thread on the same footing as everybody else.
> allow both titles and descriptions on posts with URLs.
I appreciate the suggestion, but we're unlikely to do that. On HN, submitting a story conveys no special rights, and submitters do not get to frame the story for everybody else. Framing it for everybody else effectively means controlling the discussion. We want discussion to be driven by the article itself, not a single user's spin. If a submitter wishes to offer a description or say what they think is important about a story, they're welcome to do so by adding a comment to the thread on the same footing as everybody else.
> Set aside the fact that HN's rules explicitly ask people not to do that.
Didn't know that. Why don't remind that on the "Post to YC" page?
Didn't know that. Why don't remind that on the "Post to YC" page?
Agreed. I'm all for cracking down on title bait, but this is just going too far. This submission had a clear, descriptive title, and now it completely lacks context.
I submitted this news few hours back with that title based on the tweet:
https://news.ycombinator.com/item?id=9812968
Edit: not exact same title, but similar.
https://news.ycombinator.com/item?id=9812968
Edit: not exact same title, but similar.
I don't think the fruit company will approve apps programmed other than objc or swift.
They have been for a long time now. Apps are commonly written in Java, Javascript, scripting in lua, python, etc. The only thing they don't allow is executable pages of memory, which the Go previously required due to it's runtime.
Apple has been accepting apps in all kinds of languages for years, including: Lua, C#, Racket, JS+native wrappers, Java, C, C++, Ruby, Python, etc.
Their current guidelines only prohibit dynamic code download (that is: installable plugins from outside the App Store):
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework.
Their current guidelines only prohibit dynamic code download (that is: installable plugins from outside the App Store):
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework.
Aren't they already approving apps written in C#? What's different about Go?
They've been doing that for ages already.
Please do at least a cursory bit of research before commenting about an area you're clearly not familiar with! It will save a lot of time, and prevent FUD like this from continuing to spread.
Please do at least a cursory bit of research before commenting about an area you're clearly not familiar with! It will save a lot of time, and prevent FUD like this from continuing to spread.
Well, I'm glad he asked, because I didn't know all these languages mentioned in the responses, were supported on iOS and the App Store.
* You can write part of your app in Go
* You can share that code across your Android and iOS apps?
Is that right? If so, seems like a solid use case for Go. Until Swift compiles to Android...