| ▲ | Using Go for Mobile Apps(davidsobsessions.com) | |||||||||||||
| 25 points by theHocineSaad 6 hours ago | 8 comments | ||||||||||||||
| ▲ | dizhn 2 hours ago | parent | next [-] | |||||||||||||
I don't get why with all the plumbing the author already set up, Go had to be part of the mobile app at all. Could have been a clean flutter/dart UI with a Go backend. (All of these they already have but somehow they have to deal with passing binary data between Go mobile and dart?) | ||||||||||||||
| ||||||||||||||
| ▲ | iamcalledrob 2 hours ago | parent | prev | next [-] | |||||||||||||
I've built and shipped some native-UI cross-platform apps to millions of devices, powered by a Go shared library. It works. It's fantastic to use the same language on client and server, and the end-to-end testing story is really strong. However, in my opinion, "Go Mobile" is a bit of a red herring if you just want a cross-platform shared library. I wouldn't recommend starting there. It's optimised for writing and packaging an entire app in Go. Incremental builds don't work well (or at all), and cobbled-together "build system" is more to debug. It's also oriented around iOS and Android, which isn't great if you eventually want a native desktop app too. The generated bindings are okay, but the author's approach of using Protobuf (or some kind of wire format + simple API) means you don't really need them. I found that it's more straightforward to just compile Go code into a library that can be called from C -- and thus can be called from anywhere. Call into it natively from Swift, and via JNI on Android and desktop JVM. With the right toolchain, you can cross-compile pretty easily too. The biggest issue is that on Android you often want to talk to the OS, but the OS only speaks JVM. https://github.com/timob/jnigi "solves" this, although you will hate your life manually constructing JVM calls that you can't easily test. | ||||||||||||||
| ||||||||||||||
| ▲ | nasretdinov 2 hours ago | parent | prev | next [-] | |||||||||||||
Given that even on Linux DNS resolution in Go can be quite... interesting without CGO being enabled, honestly it's hardly surprising that on iOS it would also be quite challenging. I imagine that one more interesting thing to consider is that on iOS you can't fork() or spawn sub-processes, so your Go mobile app is indeed running simultaneously as a Go binary and the UI, and there probably can exist countless interactions between the two being unaware of each other that might cause issues | ||||||||||||||
| ||||||||||||||
| ▲ | kqr 2 hours ago | parent | prev [-] | |||||||||||||
Vaguely related realisation I had a couple of years ago: if you don't need a complicated mobile app, but just something simple for your own use, you can write and run Perl scripts in Termux and there you go – an app, without learning any Android at all! | ||||||||||||||