Live data from Hacker News

Using Go for Mobile Apps

davidsobsessions.com

11–20 of 27 posts

Re: Using Go for Mobile Apps

#11

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 pac…

Go mobile definitely supports building libraries. It will package up an xcframework for iOS and something else for Android (I forget details). It doesn't need to be the whole app. You get nice(ish) language bindings.

That said, a pure c framework is probably a cleaner way to go.

Re: Using Go for Mobile Apps

#12
The author uses Flutter for UI, Golang binary for the app backend, and uses channels passing serialized protobuf messages between them. Since adding a new API call requires changes in multiple places, they ended up defining a "god message" which has a oneof with all possible options:

  message CarrotAPI {
    oneof api {
      Function1API function1 = 10;
      Function2API function2 = 11;
    }
  }
  
  message Function1API {
        message Request {}
        message Response {}
        
        Request request = 1;
        Response response = 2;
  }
and then dispatch the call using switch to check the value of the api field.

This is... not really a good API design. I wonder if the problem of "multiple places to be edited" can be solved in an easier way by making a custom protoc plugin [1] which will take care of generating all the boilerplate for both Dart and Golang. This is how support for new languages and use cases is normally added to protoc.

[1]: https://protobuf.dev/reference/other/

Re: Using Go for Mobile Apps

#13
Go is my favorite language of all time, but it is my favorite language because of its inherent simplicity for a modernish language...and all the setups required to try to use it as mobile app development platform that I've seen are the opposite of simplicity.

When it comes to mobile app development I'll stick to Kotlin Multiplatform with Compose Multiplatform. I love Kotlin less than I love Go, but its still pretty good and its much simpler to write 99% of the app in Kotlin and Compose and just have a very small amount of platform-specific stuff in expect/actual functions than it is to deal with layers and layers of shims pulling together various technologies that were not designed to work together.

Re: Using Go for Mobile Apps

#14

Go is my favorite language of all time, but it is my favorite language because of its inherent simplicity for a modernish language...and all the setups required to try to use it as mobile app development platform that I've seen are the opposite of simplicity. When it comes to mobile app development I'll stick to Kotlin Multiplatform with Compose Multiplatform. I love Kotlin less than I love Go, but its still pretty g…

KMP is brilliant and arguably the best way to write a cross platform app that has Android as a target.

But what you can do with it on non-JVM platforms is a bit lacking. There are few libraries and the stdlib is rather minimal.

If you're just making some http calls and instantiating models it's pretty good though!

Shame it's part of the Grade hellscape though ;)

Re: Using Go for Mobile Apps

#15
post #12

The author uses Flutter for UI, Golang binary for the app backend, and uses channels passing serialized protobuf messages between them. Since adding a new API call requires changes in multiple places, they ended up defining a "god message" which has a oneof with all possible options: message CarrotAPI { oneof api { Function1API function1 = 10; Function2API function2 = 11; } } message Function1API { message Request {}…

I don’t get it. Why not just use dart for the app backend? I understand not using it on the server because it’s not mature there.

Re: Using Go for Mobile Apps

#16

Go is my favorite language of all time, but it is my favorite language because of its inherent simplicity for a modernish language...and all the setups required to try to use it as mobile app development platform that I've seen are the opposite of simplicity. When it comes to mobile app development I'll stick to Kotlin Multiplatform with Compose Multiplatform. I love Kotlin less than I love Go, but its still pretty g…

Kotlin is great on the server too.

Re: Using Go for Mobile Apps

#18
post #15
post #12

The author uses Flutter for UI, Golang binary for the app backend, and uses channels passing serialized protobuf messages between them. Since adding a new API call requires changes in multiple places, they ended up defining a "god message" which has a oneof with all possible options: message CarrotAPI { oneof api { Function1API function1 = 10; Function2API function2 = 11; } } message Function1API { message Request {}…

I don’t get it. Why not just use dart for the app backend? I understand not using it on the server because it’s not mature there.

I don't know! The author chose to use Golang, maybe it's for code reuse or just because they like Golang more. I did not question their choice, only commented on the implementation detail.

Re: Using Go for Mobile Apps

#19

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 pac…

I use the same language everywhere, but Swift (:

Re: Using Go for Mobile Apps

#20
post #17

I can highly recommend Rust for this. The same Rust engine powering web app (WASM + React), iOS (SwiftUI), Android (Kotlin Compose) and desktop (Tauri). https://github.com/koofr/vault

Honestly nowadays Swift seems a better fit IMHO, though it is probably a matter of taste.
Post reply on HN