Hi, I'm the author. SourceDNA has built a platform for crawling the app stores & indexing app code. We provide app review, helping developers improve their code and security by finding apps that have out-of-date SDKs or use platform APIs incorrectly.
As a fun exercise, we looked into Google’s recent moves with Go 1.5 pre-release, which can compile apps for iOS and Android. They just published their first app (a calculator) on the app stores and we looked inside to see if there was anything too surprising. The apps are mostly Go, with a thin platform-specific UI and event layer but this does raise some questions about Google’s long-term mobile strategy.
Previous discussion about the app, including comments by one of the developers:
Let me know here if you have other questions. Is Google going after the cross-platform tools market? Is this the future of the Android SDK? Or is it just a curiosity?
It's not so much that the syntax was derived from Python (because it's not) as that the language was clearly informed by the authors' experience working commercially with Python, Java, and C projects.
I wrote my first Go program this weekend. The syntax felt like a cross between Python and C, notably doing away with parens in if statements and returning multiple values.
Thanks, looks great. BTW, the notes say no support for os/exec, but this library code is definitely present in both apps. It may not be usable though. :-)
I disagree that there should be libraries for GUI components. As soon as you try that, you end up compromising the UX with either non-native UI components, or lowest common denominator APIs that try to bridge iOS/Android. Write your models/controllers and other logic in Go, but keep your views native and use go's bind tool.
Sidenote: You can write OpenGL ES apps in Go (aka games). These typically don't use native UI controls so that's a great use case for go mobile.
How important is native UI to users? Is there any literature on the subject? I've always assumed it was important, but I keep seeing big name apps reinventing the UI and going the custom route.
In addition to providing the look and feel that users expect, native UIs are the most practical way to achieve accessibility for people with disabilities, e.g. blind people using screen readers like VoiceOver (iOS) and TalkBack (Android). You can implement the platform accessibility APIs for a non-native UI, but it's a lot of work; just ask the relevant developers of Chrome and Firefox.
Addendum: If your app uses a web view, it can be accessible, as long as you use standard semantic HTML elements and/or add the appropriate ARIA attributes and focus behavior for custom widgets. But in this comment, I was comparing a native UI to something completely custom.
I've seen this argument repeated ad nauseum over the past 15-20 years. I think it depends on what you want.
Yes to some having consistent elements of UI make some users feel very happy about using your software. Most probably won't be able to articulate why, they'll just feel a bit happier.
I don't think there's an absolute in this discussion though. The web has proven that people value having access to more capability more highly than how well every aspect of that capability works. You could view the lack of integration as a weakness of the web, but for me it reads as flexibility/empowerment for the developer. It's possible to view developer empowerment as a negative, but in the case of the web it's enabled it to tackle some interesting use cases that you might miss if you stick to the rules too zealously.
BTW, I think it's possible to build crappy UI natively too. It's a mindset thing. The web isn't native on any platform yet there are some web apps with great UI. There are also some non-native client apps (like Chrome) that I think (admitting my bias in Chrome's case) do a pretty good job.
Who are the big names you're referring to? Many of them highly customize the look of the controls (Spotify, AirBnb, MSFT) but they are still the native controls. The back stack, physics, etc are all native.
Yes, direct GL access with a thin app delegate is the most common way C++ game engines like Unreal Engine, Crytek, and Marmalade are packaged for iOS and Android. There's no reason you couldn't do that in Go too, except for the lack of other libraries like scripting, mesh, etc.
I'm not talking just a simple GUI abstraction wrapper, which has earned a deservedly bad reputation. The more full-fledged UI models have gotten much nicer, like in React Native or Xamarin.
Cool! I'm the developer of AnGoIde (the Go IDE that runs right on your Android device) and actually one of the future features was an option to generate APKs for custom CLI Go apps on Android; e.g., with a bootstrap GUI that just executes a Go binary. One challenge is supporting both ARM (different versions) and the x86 (gaining popularity) architectures, so I'm interested to see how the official tools will accommodate that going forward.
Go recently ported the toolchain to being self-hosted, so hopefully they can keep code-generation up to date as well. There's nothing special about the current Go mobile runtime so it should work on Android x86 as well.
Rooting for this stuff to keep moving forward, because as a Python(2) user, my Python3 migration is going to be to Go. It's just the ecosystem I'm waiting to catch up before I take the big plunge and port my relevant apps.
As a fun exercise, we looked into Google’s recent moves with Go 1.5 pre-release, which can compile apps for iOS and Android. They just published their first app (a calculator) on the app stores and we looked inside to see if there was anything too surprising. The apps are mostly Go, with a thin platform-specific UI and event layer but this does raise some questions about Google’s long-term mobile strategy.
Previous discussion about the app, including comments by one of the developers:
https://news.ycombinator.com/item?id=9875886
Let me know here if you have other questions. Is Google going after the cross-platform tools market? Is this the future of the Android SDK? Or is it just a curiosity?