10 ms·

Matcha – A framework for building iOS and Android apps in Go

320 points by pritambarhate 9y ago

tobiaswk 9y ago
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.
- RubenSandwich 9y ago
  Exactly. I wonder if in the future we will more demand API stability of our host platforms so we aren't rewriting the same framework on every API change. I feel like I'm always building on sinking sand, that my programs have half-lives shorter then radioactive elements. Say what we want about Microsoft but they have always valued API stability.
  - MBCook 9y ago
    Apple’s frameworks are relatively stable. Maybe we shouldn’t be building frameworks on top of frameworks on top of other languages? Maybe officially supported tools/languages are often a good choice.
    - pjmlp 9y ago
      Experience taught me that it is always the best option for production code.
  - Fappy 9y ago
    I understand what you're getting at and agree with the sentiment. Knowing work on the .NET framework is going to be supported (see: not broken) for years to come is a big factor for deciding on a basket for your eggs. But aren't most radioactive elements notorious for having half-lives that are long with respect to the human lifespan? Just sayin'.
    - RubenSandwich 9y ago
      Yeah, the radioactive element comment is more statement on how our products are slowly decaying. But if I was to choose one with a half-life similar to the lifetime of the products I've worked on I'd go with the isotope: Sodium-22 with a half-life of 2.602 years. Edit: Going by https://en.wikipedia.org/wiki/List_of_radioactive_isotopes_by_half-life https://en.wikipedia.org/wiki/List_of_radioactive_isotopes_b..., it seems that most of the halflives fall in the 10^(n where n <= 6) seconds category which is smaller than a human lifetime.
- cgomezmendez 9y ago
  Yes, and there is not big company behind this one as far as I can see, Google's Flutter and Facebook's React Native will for sure have support from these companies cause they have projects written with their frameworks but this one, I'm hessitant.
  - equasar 9y ago
    Right now I'm vouching for Flutter, I tried their golden prototype "Hamilton — The Official App" on a slow android device and it runs pretty smooth. Not sure about iOS tho.
- pbreit 9y ago
  This sentiment seems to be in the tiny minority.
  - danpalmer 9y ago
    But it could be a major contributing factor to issues like the Javascript framework ecosystem changing every 6 months.
    - pbreit 9y ago
      That's my point.
- TeeWEE 9y ago
  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 9y ago
    @TeeWEE, Do you have any info on why Airbnb stopped using React Native? Would love a good read on why.
    - gpeal 9y ago
      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.
    - hysan 9y ago
      Also interested in hearing if they really stopped using React Native as a whole. Especially since their react-native-maps library is the defacto library for maps. It would be quite scary if they decided to stop using React Native. Right now, the only thing I'm currently aware of is that their navigation library (native-navigation [1]) is pretty much unmaintained and they are trying to plan out a transition to move it under react-community.[2] The only thing that hints at their slowing use of React Navigation is the mention of conversion to React Native's navigation getting a much lower priority to the point that the native-navigation library has essentially become unmaintained.[3] But when I initially read that, it didn't come off as Airbnb deciding to stop using React Native. [1] https://github.com/airbnb/native-navigation https://github.com/airbnb/native-navigation [2] https://github.com/airbnb/native-navigation/issues/145 https://github.com/airbnb/native-navigation/issues/145 [3] https://github.com/airbnb/native-navigation/issues/145#issuecomment-329384356 https://github.com/airbnb/native-navigation/issues/145#issue...
  - danpalmer 9y ago
- disconnected 9y ago
  The biggest problem with these frameworks is that they ignore the elephant in the room. We already have a widely adopted, widely compatible, highly developed and open framework for cross platform development: webpages. My confidence that Mr. J. Random Hacker - or even J. Random Company Inc. - can do better than this - and support it for over 2 decades - is close to 0.
  - yoz-y 9y ago
    If this framework focalizes on iOS and Android then it might be more useful than webpages in some cases. Native applications are still the way to go if you need to do computationally intensive tasks, UIs that are responsive (especially on Android), UIs that display real time data (especially on iOS) and anything that uses the cool features the phones have.
    - Zoon 9y ago
      Can you expand on why non-native iOS apps struggle with displaying real-time data, and why anroid’s struggle with responsiveness?
      - yoz-y 9y ago
        Sure. The current problem on iOS is that you can not replace the web-rendering engine, thus you have to send messages or call callbacks into the web engine api. You have no guarantees as to when they will be actually executed and you have to serialize your data. In my application I needed to display data incoming from a sensor. I can only access this data using the native functions and it comes at around 500Hz from 16 sensors. For comparison, in Electron, when you call a function defined in a module written in C++, you can get the answer in under 1 ms. When using something like Cordova, you have to serialize the data which can take a seriously long time and then you have to wait for the callback to execute. On Android I suppose it is quite possible to write a V8 native plugin and achieve this performance, but not on iOS where you are limited to included webkit. As for the Android responsiveness, the problem lies with the single threaded nature of JavaScript. CPUs on android phones _suck_ in single core performance. When I was looking for a good solution for multi platform development, I have found of a tech meeting that was supposed to present solutions taken by several different companies. It turned to be a huge complaint-fest about Android javascript performance and the only happy people were those using Xamarin (which is native). Edit: Note that I think that using web views for applications like banking or chat and so on is perfectly fine. My issue is with apps that eat a lot of incoming data and/or have to change what is displayed very often.
- jd20 9y ago
  Well, someone probably said the same about Go or React-Native when they first came out too. We have to start somewhere...
  - biokoda 9y ago
    > Well, someone probably said the same about Go or React-Native when they first came out too RN came from a giant company that uses it in its core product. Big difference.
    - zimpenfish 9y ago
      As did Go - Google is as equally giant as Facebook and uses Go in it core products. cf https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article (Agree with parent but not wanting Go to be left out of the "giant company" bucket.)
      - cweagans 9y ago
        That's not really a direct comparison. We're not talking about languages here - it's the framework. React Native is used and developed by Facebook, whereas Matcha is used and developed by no one notable (afaik).
      - nawgszy 9y ago
        You're comparing Go to RN. The comparison he's making is Matcha to RN. Matcha doesn't come from a giant company. The language it's in does, but that doesn't mean anything for framework momentum.
        deleted 9y ago
        [deleted]
      - muse900 9y ago
        We are discussing about the framework itself and not go as a language. The framework is a nice idea, and will definitely help into diversifying some of the mobile frontend stuff. On the other hand you can't compare RN to this framework. As the person you commented on, facebook has been using RN on its main products like instagram, so it has proven that the framework can be placed on production ready apps with a massive userbase.
- MBCook 9y ago
  I just saw a tweet this morning reminding React Native people about three20, the previous Facebook framework that they abandoned. At least React Native has been around for a while and has a good sized community. This is a neat little project but I would treat it like a toy unless you were willing to step up and take over maintence before usi it for a production app. (This wasn’t meant as a stab at React Native, it was meant as a warning about picking up frameworks that don’t have much history. RN is a few years old. I don’t think it will disappear next year).
  - bsaul 9y ago
    For those who don't know, Three20 really was two order of magnitude less involving if you decided to use it. It really was just a library of convenient classes that you could choose to use or not, or just part of it. RN is an entirely different beast...
    - k__ 9y ago
      Thanks, I never heard of Three20, but I use RN for 5 months now.
      - MBCook 9y ago
        When I saw the original tweet I hadn’t either and had to Google it.
- ship_it 9y ago
  Tldr: Keep it that way. I've started working on a side-project developing a mobile application when Fuse[1] got "traction". I remember the bashing on HN regarding the name (since well libfuse). I'm usually all sys/backend, but I've got into it. You start digging through their board and see a lot of examples, catch around stuff on their channel and so on. Kind of joy sometimes. The thing is, I've been planning to support both iOS and Android from the early start. So that was really a great choice, it looked promising. Or so was I thinking. After fine 7 months, my new shiny mobile app. was behind somehow manageable code and one developer - me. Stay still, I never worked on mobile before. So I went for market and hit few clients at an early stage. Good news everyone, we got this. As a co-founder with other two, designer and marketing manager, we went out as a `free` and rent the magical space. The hype was there and -. Clients started requesting features, which meant another success. The ideas presented were fine with us and I started working furiously on it. Pressure and all, inb4 start digging for more developers. Few remote devs and features are ready, users love them. Now it gets to more advanced features, UI, code starts to get abstract, and devs aren't sure if they web, script or compile. We somehow managed to stay on ball. After five such months, we ditched the Fuse and rewrote to native. Since devs where remote, they understood the cards. Some of them are still here. Now we are all happy, codebase is eh.. fine, stuff are supported, you know. The story speaks I think. These tools, at early stage, should be took as a grant of salt. I do however appreciate work given towards creating xp stuff. Some of these tools are great for prototyping. [1] https://www.fusetools.com/ https://www.fusetools.com/
deleted 9y ago
[deleted]
alfonsodev 9y ago
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.
- jd20 9y ago
  Looking at the examples for calling ObjC from Go, it looks like you still need a native piece of code to register the ObjC function being called and act as a shim (so same as RN I think). Looking at it from another perspective, there's a practical difficulty to being able to dynamically invoke any ObjC function from Go: the ObjC compiler would still need to know what libraries to link, and header files to include.
- overcyn 9y ago
  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 9y ago
    good point and that applies for both Objective-c and Swift?
tabeth 9y ago
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.
- abhas9 9y ago
  Any reference link/source?
- yoz-y 9y ago
  For me one of the showstopper for webapps on iOS was that there is no immediate, synchronous way to communicate data between the native part and the visualisation part. Since the only way is to communicate via messages which are painfully slow.
- MBCook 9y ago
  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.
mmjaa 9y ago
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 ..
lcfcjs2 9y ago
Oh god how awful. Objective-C was bad enough.
jd20 9y ago
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...
- megawatthours 9y ago
  >And don't even get me started on the async keyword Please do! Genuinely curious what you don't like about it.
  - NightMKoder 9y ago
    If you’re coming from Go especially, my money would be in a similar vein to http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... . That is, why be explicit about async when implicit style code is much easier to read. That said, the answer in this case is simply backwards compatibility - JS already had a concurrency model before async/await came around. You can also make a explicit is better than implicit argument; it’s mostly personal preference/ideology though. That said, Python has been in a fun land of “rewrite the world” because the async model they chose (async/await) was not backwards compatible to any existing libraries. So now in Python which library you use for e.g. http varies with which concurrency model you use in the rest of your app.
thedonkeycometh 9y ago
LOLd at todo list example gif
KirinDave 9y ago
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 9y ago
  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_ 9y ago
    So don't use JavaScript. That's a terrible idea anyway. Use Swift/Kotlin.
    - Un1corn 9y ago
      So I should just write my application twice? That's not really a solution.
      - virtualwhys 9y ago
        > So I should just write my application twice? No, write it thrice (need mobile web version as well).
        s73ver_ 9y ago
        If you're doing an app, why would you do mobile web?
        KirinDave 9y ago
        Any sufficiently advanced mobile app will redo at least its onboarding flow in the web. Capturing acquisition funnel details over an app download flow is either impossible if you're ethical or shady as hell even if you're not. This inevitably leads to a copy of your settings and account management page ion the web. At that point, why NOT get people into a decent experience as fast as possible?
overcyn 9y ago
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 9y ago
  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 9y ago
    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.
- dcu 9y ago
  how does it compare with gomobile?
  - overcyn 9y ago
    Repasting my comment from below, but Matcha is actually based on top of gomobile, albeit with a bunch changes to fit the needs of this framework. 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.
- therealmarv 9y ago
  I really like using go for writing e.g. the logic part of an Android/iOS/Desktop app. Would not it make more sense architecture wise to write UI real native and do the interfaces really well to the logic binary go parts? Are there good examples/libs for this approach?
codesternews 9y ago
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 9y ago
  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.
cweagans 9y ago
What's the difference between this and https://github.com/golang/mobile https://github.com/golang/mobile?
- overcyn 9y ago
  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 9y ago
    Ah, I see. That makes sense. Thanks for the info!
anindha 9y ago
Why did you choose Go over Swift? What would be great is to mix native views dynamic views.
- overcyn 9y ago
  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.
bedros 9y ago
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
paultopia 9y ago
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 9y ago
  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 9y ago
    thanks!
tkubacki 9y ago
How is that different to flutter.io (beside using GO) ?

320 points by pritambarhate 9y ago

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.

RubenSandwich 9y ago
Exactly. I wonder if in the future we will more demand API stability of our host platforms so we aren't rewriting the same framework on every API change. I feel like I'm always building on sinking sand, that my programs have half-lives shorter then radioactive elements. Say what we want about Microsoft but they have always valued API stability.
- MBCook 9y ago
  Apple’s frameworks are relatively stable. Maybe we shouldn’t be building frameworks on top of frameworks on top of other languages? Maybe officially supported tools/languages are often a good choice.
  - pjmlp 9y ago
    Experience taught me that it is always the best option for production code.
- Fappy 9y ago
  I understand what you're getting at and agree with the sentiment. Knowing work on the .NET framework is going to be supported (see: not broken) for years to come is a big factor for deciding on a basket for your eggs. But aren't most radioactive elements notorious for having half-lives that are long with respect to the human lifespan? Just sayin'.
  - RubenSandwich 9y ago
    Yeah, the radioactive element comment is more statement on how our products are slowly decaying. But if I was to choose one with a half-life similar to the lifetime of the products I've worked on I'd go with the isotope: Sodium-22 with a half-life of 2.602 years. Edit: Going by https://en.wikipedia.org/wiki/List_of_radioactive_isotopes_by_half-life https://en.wikipedia.org/wiki/List_of_radioactive_isotopes_b..., it seems that most of the halflives fall in the 10^(n where n <= 6) seconds category which is smaller than a human lifetime.
cgomezmendez 9y ago
Yes, and there is not big company behind this one as far as I can see, Google's Flutter and Facebook's React Native will for sure have support from these companies cause they have projects written with their frameworks but this one, I'm hessitant.
- equasar 9y ago
  Right now I'm vouching for Flutter, I tried their golden prototype "Hamilton — The Official App" on a slow android device and it runs pretty smooth. Not sure about iOS tho.
pbreit 9y ago
This sentiment seems to be in the tiny minority.
- danpalmer 9y ago
  But it could be a major contributing factor to issues like the Javascript framework ecosystem changing every 6 months.
  - pbreit 9y ago
    That's my point.
TeeWEE 9y ago
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 9y ago
  @TeeWEE, Do you have any info on why Airbnb stopped using React Native? Would love a good read on why.
  - gpeal 9y ago
    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.
  - hysan 9y ago
    Also interested in hearing if they really stopped using React Native as a whole. Especially since their react-native-maps library is the defacto library for maps. It would be quite scary if they decided to stop using React Native. Right now, the only thing I'm currently aware of is that their navigation library (native-navigation [1]) is pretty much unmaintained and they are trying to plan out a transition to move it under react-community.[2] The only thing that hints at their slowing use of React Navigation is the mention of conversion to React Native's navigation getting a much lower priority to the point that the native-navigation library has essentially become unmaintained.[3] But when I initially read that, it didn't come off as Airbnb deciding to stop using React Native. [1] https://github.com/airbnb/native-navigation https://github.com/airbnb/native-navigation [2] https://github.com/airbnb/native-navigation/issues/145 https://github.com/airbnb/native-navigation/issues/145 [3] https://github.com/airbnb/native-navigation/issues/145#issuecomment-329384356 https://github.com/airbnb/native-navigation/issues/145#issue...
- danpalmer 9y ago
disconnected 9y ago
The biggest problem with these frameworks is that they ignore the elephant in the room. We already have a widely adopted, widely compatible, highly developed and open framework for cross platform development: webpages. My confidence that Mr. J. Random Hacker - or even J. Random Company Inc. - can do better than this - and support it for over 2 decades - is close to 0.
- yoz-y 9y ago
  If this framework focalizes on iOS and Android then it might be more useful than webpages in some cases. Native applications are still the way to go if you need to do computationally intensive tasks, UIs that are responsive (especially on Android), UIs that display real time data (especially on iOS) and anything that uses the cool features the phones have.
  - Zoon 9y ago
    Can you expand on why non-native iOS apps struggle with displaying real-time data, and why anroid’s struggle with responsiveness?
    - yoz-y 9y ago
      Sure. The current problem on iOS is that you can not replace the web-rendering engine, thus you have to send messages or call callbacks into the web engine api. You have no guarantees as to when they will be actually executed and you have to serialize your data. In my application I needed to display data incoming from a sensor. I can only access this data using the native functions and it comes at around 500Hz from 16 sensors. For comparison, in Electron, when you call a function defined in a module written in C++, you can get the answer in under 1 ms. When using something like Cordova, you have to serialize the data which can take a seriously long time and then you have to wait for the callback to execute. On Android I suppose it is quite possible to write a V8 native plugin and achieve this performance, but not on iOS where you are limited to included webkit. As for the Android responsiveness, the problem lies with the single threaded nature of JavaScript. CPUs on android phones _suck_ in single core performance. When I was looking for a good solution for multi platform development, I have found of a tech meeting that was supposed to present solutions taken by several different companies. It turned to be a huge complaint-fest about Android javascript performance and the only happy people were those using Xamarin (which is native). Edit: Note that I think that using web views for applications like banking or chat and so on is perfectly fine. My issue is with apps that eat a lot of incoming data and/or have to change what is displayed very often.
jd20 9y ago
Well, someone probably said the same about Go or React-Native when they first came out too. We have to start somewhere...
- biokoda 9y ago
  > Well, someone probably said the same about Go or React-Native when they first came out too RN came from a giant company that uses it in its core product. Big difference.
  - zimpenfish 9y ago
    As did Go - Google is as equally giant as Facebook and uses Go in it core products. cf https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article (Agree with parent but not wanting Go to be left out of the "giant company" bucket.)
    - cweagans 9y ago
      That's not really a direct comparison. We're not talking about languages here - it's the framework. React Native is used and developed by Facebook, whereas Matcha is used and developed by no one notable (afaik).
    - nawgszy 9y ago
      You're comparing Go to RN. The comparison he's making is Matcha to RN. Matcha doesn't come from a giant company. The language it's in does, but that doesn't mean anything for framework momentum.
      - deleted 9y ago
        [deleted]
    - muse900 9y ago
      We are discussing about the framework itself and not go as a language. The framework is a nice idea, and will definitely help into diversifying some of the mobile frontend stuff. On the other hand you can't compare RN to this framework. As the person you commented on, facebook has been using RN on its main products like instagram, so it has proven that the framework can be placed on production ready apps with a massive userbase.
MBCook 9y ago
I just saw a tweet this morning reminding React Native people about three20, the previous Facebook framework that they abandoned. At least React Native has been around for a while and has a good sized community. This is a neat little project but I would treat it like a toy unless you were willing to step up and take over maintence before usi it for a production app. (This wasn’t meant as a stab at React Native, it was meant as a warning about picking up frameworks that don’t have much history. RN is a few years old. I don’t think it will disappear next year).
- bsaul 9y ago
  For those who don't know, Three20 really was two order of magnitude less involving if you decided to use it. It really was just a library of convenient classes that you could choose to use or not, or just part of it. RN is an entirely different beast...
  - k__ 9y ago
    Thanks, I never heard of Three20, but I use RN for 5 months now.
    - MBCook 9y ago
      When I saw the original tweet I hadn’t either and had to Google it.
ship_it 9y ago
Tldr: Keep it that way. I've started working on a side-project developing a mobile application when Fuse[1] got "traction". I remember the bashing on HN regarding the name (since well libfuse). I'm usually all sys/backend, but I've got into it. You start digging through their board and see a lot of examples, catch around stuff on their channel and so on. Kind of joy sometimes. The thing is, I've been planning to support both iOS and Android from the early start. So that was really a great choice, it looked promising. Or so was I thinking. After fine 7 months, my new shiny mobile app. was behind somehow manageable code and one developer - me. Stay still, I never worked on mobile before. So I went for market and hit few clients at an early stage. Good news everyone, we got this. As a co-founder with other two, designer and marketing manager, we went out as a `free` and rent the magical space. The hype was there and -. Clients started requesting features, which meant another success. The ideas presented were fine with us and I started working furiously on it. Pressure and all, inb4 start digging for more developers. Few remote devs and features are ready, users love them. Now it gets to more advanced features, UI, code starts to get abstract, and devs aren't sure if they web, script or compile. We somehow managed to stay on ball. After five such months, we ditched the Fuse and rewrote to native. Since devs where remote, they understood the cards. Some of them are still here. Now we are all happy, codebase is eh.. fine, stuff are supported, you know. The story speaks I think. These tools, at early stage, should be took as a grant of salt. I do however appreciate work given towards creating xp stuff. Some of these tools are great for prototyping. [1] https://www.fusetools.com/ https://www.fusetools.com/

deleted 9y ago

[deleted]

alfonsodev 9y ago

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.

jd20 9y ago
Looking at the examples for calling ObjC from Go, it looks like you still need a native piece of code to register the ObjC function being called and act as a shim (so same as RN I think). Looking at it from another perspective, there's a practical difficulty to being able to dynamically invoke any ObjC function from Go: the ObjC compiler would still need to know what libraries to link, and header files to include.
overcyn 9y ago
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 9y ago
  good point and that applies for both Objective-c and Swift?

tabeth 9y ago

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.

abhas9 9y ago
Any reference link/source?
yoz-y 9y ago
For me one of the showstopper for webapps on iOS was that there is no immediate, synchronous way to communicate data between the native part and the visualisation part. Since the only way is to communicate via messages which are painfully slow.
MBCook 9y ago
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.

mmjaa 9y ago

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 ..

lcfcjs2 9y ago

Oh god how awful. Objective-C was bad enough.

jd20 9y ago

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...

megawatthours 9y ago
>And don't even get me started on the async keyword Please do! Genuinely curious what you don't like about it.
- NightMKoder 9y ago
  If you’re coming from Go especially, my money would be in a similar vein to http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... . That is, why be explicit about async when implicit style code is much easier to read. That said, the answer in this case is simply backwards compatibility - JS already had a concurrency model before async/await came around. You can also make a explicit is better than implicit argument; it’s mostly personal preference/ideology though. That said, Python has been in a fun land of “rewrite the world” because the async model they chose (async/await) was not backwards compatible to any existing libraries. So now in Python which library you use for e.g. http varies with which concurrency model you use in the rest of your app.

thedonkeycometh 9y ago

LOLd at todo list example gif

KirinDave 9y ago

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 9y ago
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_ 9y ago
  So don't use JavaScript. That's a terrible idea anyway. Use Swift/Kotlin.
  - Un1corn 9y ago
    So I should just write my application twice? That's not really a solution.
    - virtualwhys 9y ago
      > So I should just write my application twice? No, write it thrice (need mobile web version as well).
      - s73ver_ 9y ago
        If you're doing an app, why would you do mobile web?
        KirinDave 9y ago
        Any sufficiently advanced mobile app will redo at least its onboarding flow in the web. Capturing acquisition funnel details over an app download flow is either impossible if you're ethical or shady as hell even if you're not. This inevitably leads to a copy of your settings and account management page ion the web. At that point, why NOT get people into a decent experience as fast as possible?

overcyn 9y ago

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 9y ago
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 9y ago
  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.
dcu 9y ago
how does it compare with gomobile?
- overcyn 9y ago
  Repasting my comment from below, but Matcha is actually based on top of gomobile, albeit with a bunch changes to fit the needs of this framework. 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.
therealmarv 9y ago
I really like using go for writing e.g. the logic part of an Android/iOS/Desktop app. Would not it make more sense architecture wise to write UI real native and do the interfaces really well to the logic binary go parts? Are there good examples/libs for this approach?

codesternews 9y ago

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 9y ago
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.

cweagans 9y ago

What's the difference between this and https://github.com/golang/mobile https://github.com/golang/mobile?

overcyn 9y ago
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 9y ago
  Ah, I see. That makes sense. Thanks for the info!

anindha 9y ago

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

overcyn 9y ago
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.

bedros 9y ago

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

paultopia 9y ago

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 9y ago
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 9y ago
  thanks!

tkubacki 9y ago

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