
Matcha – A framework for building iOS and Android apps in Go - pritambarhate
https://github.com/gomatcha/matcha
======
jd20
I think it's really great to see a project like this coming out, as someone
who loves writing Go on the server side, but has been grinding my teeth
through learning JS to be able to do client-side work. That said, I would love
to hear more about how a compiled Go app will handle three of what I see as
being RN's biggest advantages:

1) Ability to quickly see changes in the simulator as you're modifying code
(one of the main reasons I went with RN over ObjC/Swift, is I can just Cmd+R
and boom, my changes are live in a second).

2) Pushing new updates remotely, without having to resubmit your app. Would Go
being statically compiled, mean we can't ship bits of executable code for
minor updates / bug fixes as we see fit?

3) Debugging is really nice on RN, because you get to leverage awesome JS
debugging environments like Chrome DevTools. While I've not yet had a need for
a fancy debugger with Go, I could see that as a big sticking point for teams
trying to choose.

Nonetheless, really applaud this effort so far, and look forward to seeing
more. Go's concept of goroutines seems much better suited to UI event
handling, then stringing together a ton of promises and callbacks. And don't
even get me started on the async keyword...

~~~
ASinclair
RN = ReactNative? Gentle Tech Writing reminder that it helps to spell out
initialisms the first time you use them.

~~~
jd20
You're totally right, I'd go back and fix that if I could. Funny how a few
months learning a new framework can make you forget how normal people talk :)

------
overcyn
I'm the author of this framework. I think Matcha has a really cool approach to
building UIs. Everything is built on top of interfaces, so its very easy to
reuse and customize components and layouts. Its not quite production ready but
I can any answer any questions.

~~~
codesternews
Thanks overcyn great framework. How you are bridging between iOS and Android.
Can you provide simple example code that make me understand how you make
things working and internal details.

It will help me to understand better. Any future plans to write blog.

~~~
overcyn
The bridging happens through Cgo and JNI. bridge/matchaforeign.h contains the
functions that Go implements that can be called by ObjC/Java and
bridge/matchago.h are the functions that Java/Objc implements that can be
called by Go. Everything else is built on top of that.

------
tobiaswk
The thing with frameworks like this is that the time invested could be lost if
the framework looses traction. I am very hesitant to use a framework like this
for anything serious and business-oriented.

~~~
TeeWEE
Thats true, however in the long term, we need a react like framework that
solves cross platform development. React Native has lots of problems with
navigation, the AirBnB team even stopped using it seriously.

I guess Kotlin and Kotlin Native (which runs on ios) could be a good started
for building a KotlinReactNative, which allows creating an UI in a DSL based
syntax that works on multiple platforms.

~~~
pdnell
@TeeWEE,

Do you have any info on why Airbnb stopped using React Native? Would love a
good read on why.

~~~
gpeal
We have definitely not stopped using React Native! Not sure where you got that
impression. We continue to heavily invest in it as well as native platforms
and make a case by case decision for all new products.

------
mmjaa
Cool! This might make it a _lot_ easier to get IPFS going on Mobile platforms
.. there is already a shim for getting IPFS built and running alongside a
native iOS app but it'll be much more interesting to do the whole thing in
Golang ..

------
KirinDave
Why would you want to do this? At what point would this be a better decision
than using a Swift/Kotlin environment?

Why would we voluntarily choose an inferior 3rd party tool when superior first
party tool exists?

~~~
srameshc
I would love to use this at some point. I would also contribute towards the
development of this framework. I love Go and I don't want to switch to
JavaScript when I want to write a iOS/Android application. Everything has to
begin somewhere. This is probably a first step to something fine.

~~~
s73ver_
So don't use JavaScript. That's a terrible idea anyway. Use Swift/Kotlin.

~~~
Un1corn
So I should just write my application twice? That's not really a solution.

~~~
KirinDave
If it didn't work with React Native and the much richer Javascript/Typescript
world, what makes you think that Go will magically make it better?

I get that you like Go, logically (although emotionally, I can only feel
confusion from such an idea). But no one has even remotely offered an idea
what advantages Go brings to this table other than "I like it!"

Which is cool, but I loathe it. So unless there are compelling things in this
framework (hence my question) this seems like a great way to use worse tooling
and an awkwardly shoehorned language to fail to accomplish exactly what other
frameworks have failed to do.

~~~
zghst
There's nothing wrong with exploration and improving language interop across
platforms.

~~~
KirinDave
This isn't really answering the question though, is it?

On the basis of language, Go is a regressive and under-performant pile that
people seem to love largely because of its nostalgia factor.

What about this framework helps to offset how awful Go is?

------
codesternews
I amazed by seeing this type of frameworks and code written by a single
person. How can one person write this type of framework. I want to learn this.
Anyone please provide suggestion how to make myself better like this.

How much time and dedication he devoted in this is really amazing.

~~~
overcyn
Thank you, I appreciate that! I was just lucky to have saved enough money to
take some time off and work on something I find interesting and think has a
lot of potential.

------
alfonsodev
From the Conceptual Overview [1]

> The gomatcha.io/bridge package handles the interface between Objective-C and
> Go. Go values become MatchaGoValue in Objective-C, and Objective-C values
> become *bridge.Value in Go. Methods and functions can then be called on
> these objects using reflection.

Does this mean that you can call any of the Objective-c frameworks from Go
lang side? if so, and if working well that would be a huge improvement
compared with react-native.

~~~
overcyn
The reflection is limited to calling methods on objects. So it would be
difficult to directly interface with Apple frameworks. You couldn't build
closures or respond to delegate callbacks for example.

~~~
alfonsodev
good point and that applies for both Objective-c and Swift?

------
paultopia
I’m curious about something. Asking as someone who doesn’t make a living
slinging code, and who is kind of terrified of mobile development because of
all the UI stuff (xcode makes me want to cry), in case any pro mobile devs
want to answer: is the UI part the real pain point here?

It seems to me like it must be, rather than the cross-platform thing, because
what people are producing seems heavily weighted toward “here are UI
components you can use” (or even in the react native case “here’s an entirely
different way of doing UI, yanked straight from webland”). Whereas if it were
just a matter of sharing a codebase across platforms, it seems like it would
be easier to work on a compiler-side, e.g. by extending clojure, scala, etc.
to compile to swift.

But maybe that’s just my bias because I look at any ui code from anything and
my eyeballs start to bleed.

~~~
overcyn
UI is the difficult part in my opinion. iOS and Android take different
approaches to building apps so even if you had a language that perfectly
compiled to both Swift and Java, the code to build your views would end up
diverging significantly without some sort of component library.

~~~
paultopia
thanks!

------
cweagans
What's the difference between this and
[https://github.com/golang/mobile](https://github.com/golang/mobile)?

~~~
overcyn
This is actually based on top of gomobile. Gomobile provides language bindings
and Matcha adds a usable component library on top of that. It serializes Go
data structures into protobuf, passes it through to iOS/Android and creates
the necessary views. Matcha also does all the layout, event handling etc.

~~~
cweagans
Ah, I see. That makes sense. Thanks for the info!

------
tabeth
Wasn't there a proposal to expose native functionality in browsers on iOS and
Android? If that were to be finished it could make things like this and react
native less necessary.

~~~
MBCook
Why would Apple ever implement that? They’ve made their point of view on
preferring native development (and being very cautious about what’s exposed to
the browser) very clear.

------
bedros
can someone explains how this is different from ReactNative, Phonegap, etc.

I've never done production mobile app, just played with examples on iOS and
Android, wondering if this is a good framework to play with and eventually use
for production mobile apps

------
anindha
Why did you choose Go over Swift? What would be great is to mix native views
dynamic views.

~~~
overcyn
You can definitely mix native and dynamic views. Theres an interface for
registering custom views with the framework. It doesn't need to take over your
entire app either. Matcha gives you a view controller, which displays the Go
stuff, but that can be presented however you like.

------
tkubacki
How is that different to flutter.io (beside using GO) ?

