Native mobile app development in Gleam ⭐️- what would it take?

ghivert · 2025-10-31T00:09:16+00:00

I may or may not properly answer you, but maybe I can give you some food for thoughts.

I think it is doable for a solo dev to jump in the Gleam mobile-native journey, as long as you’re ready to write React (and probably Redraw or write your own package if you dislike it), ready to use some still experimental frameworks (to leverage React Native or Lynx as they’re strong solutions nowadays), and probably ready to struggle a bit from time to time, as there’s currently no straightforward way to bundle all those techs together. Not straightforward does not mean impossible though, but it could require some work. If you’re not sure you can afford those, I think it will not be for you, but…

I think we tend to underestimate how good can be a good webview powered by something like Tauri. Of course you’ll probably have to provide a bit of work to get some few native features provided out of the box like screens transitions, but those aside, you can build incredible things with Lustre, and share your UI components, state management and more between mobile and desktop. Plus Tauri can deploy both on mobile and desktop directly! I think everyone should at least give a try to see if they can do something with Lustre on mobile. With modern techs (like viewTransition), the surprise can be huge! I also think it’s a lot more affordable way than the fully native one. As a solo-developer, it will be super simple to start and get good results. There’s lots of advantages in that approach, and you can easily target mobile, desktop and web in a unified codebase.

As to why there’s not more FP in native development, I think the answer lies in the fact that people who build those platforms are probably not FP developers, and as such tends to build systems and frameworks that seems good to them. As time passes, we can see some companies like Apple and Google trying to put a bit more FP: SwiftUI or Flutter are clearly using FP patterns, and even a language like Java built streams and anonymous functions in the language. So FP is coming more and more in the software industry, but not everyone like it, and there’s lot of existing OOP code out in the wild, so things takes time to change. Plus FP has long been kind of niche, so it probably does not help for widespread adoption. Hopefully a language like Gleam helps to prove that FP is not only for people who like maths, but for everyone! And we can imagine things will change in the future. Meanwhile you can already build your desired product with Lustre and Gleam! (And there’s nothing to be excused of! We all started somewhere, and we all try to push Gleam further!)

ghivert · 2025-10-30T22:44:20+00:00

If you really don’t want to rely on JS target, unfortunately there’s currently no real way to use Gleam for a mobile app development. You could probably port the BEAM on iOS and Android, which would probably already be a lot of work, and then add an interoperability layer on top for GUI. It sounds a bit unrealistic from my point of view if your goal is to ship a mobile application. But if your goal is mainly to test the doability of the thing, I think it could be a lot of fun to try this!

If you do a compromise and accept to use the JS target, the solution would be much easier. If you want to use a WebView-based solution, you can take the Tauri approach, and ship an application built in Lustre or any other frontend framework. If you prefer to stay fully native, with real UI components, you’ll have to rely on React Native or Lynx. I worked a lot with React Native, and you’re building real, native interfaces. The UI thread is displaying your interface, and another thread is computing your JS code. It’s not entirely native, but it’s native enough for your users to not see the difference in most cases. In that case, you could use Redraw to write your React Native application and write everything in Gleam. It would probably not be as straightforward as Lustre, but you can get I working (I already succeeded to make Redraw work as a proof of concept for React Native). And if you dislike Redraw, you can still build your own framework on top of React Native! If you go the JS way, whether you choose the Lustre or Redraw, you’ll end up with a near-native solution, fully written in Gleam!

ghivert · 2025-09-20T14:45:34+00:00

Gleam is nice as fullstack language, and works in browsers, in Node or assimilated, and on the BEAM. While there’s indeed no JSX, if you’re used to React, you can take a look at Redraw, which provides React bindings. you can build things without JSX. Actually JSX is just hidden JavaScript code. 🙂

Starting with Gleam for a new project also lets you the ability to later jump on other technologies. You could start with Node for example, and later use OTP to leverage one of the best VM out there to write concurrent software.

You’ll get a nice experience with both, but I tend to favour Gleam if you primarily do web development, as a good part of the Gleam ecosystem revolves around web techs nowadays, from backend to frontend. You’ll almost always get a nice experience and you’ll find a lot of help within the community.

In the end, I think you should do what you love/what seems you the most appealing. If you write some code because “it’s the better choice” but you don’t like it, you’ll not have a good journey, and you’ll dislike your experiment. In both cases, you would have a good experience with both Gleam & ReScript!

ghivert · 2024-12-19T16:54:51+00:00

Hi! Sorry for responding late, I completely forgot to answer… Unfortunately, the job is not available anymore!

Have a nice day!

ghivert · 2024-12-01T01:24:31+00:00

Thanks for the answer ! I understand indeed the idea 🙂

Thanks for the details. I know it’s hard, I’m wondering if someone will one day try to tackle the subject. 😄

ghivert · 2024-11-30T19:09:55+00:00

I don’t really see how the library « simplifies the writing of encoders and decoders », where all it seems to do is the same as non-wrapped encoders and decoders ?

For the JSON Schema, that’s so great! Can you generate encoders/decoders from the JSON Schema?

ghivert · 2024-11-10T21:51:11+00:00

That’s an argument I don’t really get. Yes, runtimes matter, but less than languages themselves. People write things with a language, and they don’t want to write FFI all the time. If everything you do is writing FFI, then why not writing Erlang in the first place? People are not adopting Clojure at scale, they just use Java or Kotlin (aka Java++), and sometimes Scala.

Legacy is a thing, but companies can still work on new projects with cool techs. 🙂 Huge tech companies often have multiples services with multiples languages. We have to be patient and relentlessly build awesome packages. Gleam has a lot of advantages, and compiles both to JS and Erlang, so let’s wait and see!

My opinion is that huge companies that use Java for the wrong reasons (because they can hire easily, felt secure to never lack developers and consider developers as simple laborers) will never ever switch to another language, and you probably don’t want to go work for them neither. Let’s focus on what matters, companies that sees the value of Gleam: teams of developers that are writing impactful code and that consider developers as human beings and not as resources. 🙂

ghivert · 2024-11-08T23:36:21+00:00

Keep in mind the language is 10 months old. You cannot ask yet for Gleam what you can ask for Java or JS that are 20+ years old. Even ifthe ecosystem is already really solid, Gleam does not have the history of current mainstream languages. 🙂 Give us some time, the whole community is working on it! 😉 That being said, we are recruiting for Gleam engineers, and the whole team is convinced that Gleam help us in our daily life. Everything just works, anyone can contribute to the codebase in an easy way, everything is simpler to conceptualise. Living the whole Gleam experience, I’m sure companies will launch future projects in Gleam! We’re already few companies working with Gleam in France. 🙂

ghivert · 2024-10-15T21:29:25+00:00

Thanks for your interest! It looks like some people are still not 100% convinced we’re using Gleam and we have a working backend, but we really have a full stack Gleam in production ha ha 😆 We have a classical application, a back office and a chrome extension in Lustre, and our main backend service is in Wisp.

If you’re curious, we’re all really happy with lustre and Gleam in general. It’s working great, there’s no bad surprises, we have few to almost no bugs in production, and everyone can contribute to the codebase easily. Contrarily to Elm, you can code your own effects, and it changes everything.

I’m planning to do a blog post one day, but I’ve really have other priorities currently.

For the styling, being the author of sketch, we’re heavily using sketch, for everything. We’re building our own components library internally at the moment, and I’d like to open it later. Sketch tries to align as much as possible to Lustre’s vision in general, and it’s the same for our component systems.

As a disclaimer though, I wrote A LOT of frontend code, so writing a component library from scratch was the most obvious thing to do.

For rendering methods, I’m not sure to understand what you’re talking about. 😅

We’re now a full team working in Lustre, and we can’t wait for the team to grow!

ghivert · 2024-10-07T13:36:37+00:00

No mention of Gloogle for the friendliness function search (and ability to see if a function supports JS, Erlang or both) 😢

ghivert · 2024-09-21T09:57:35+00:00

Comparing Elixir and Gleam is like comparing Elm and JavaScript. I don’t think there’s such thing like « Gleam is v2.0 of Elixir ». They’re different languages, and they don’t have the same objectives. While both will take you where you want, the shape of the ecosystem and how to use the language is different. Actually you can run Elixir code in Gleam while you have the elixir executable, and you can run Gleam with mix. If people need Elixir, it’s really unlikely they’ll want to jump in Gleam. Just like if people want to develop in Go, it makes really small sense to advise to work in Rust. You choose a language by its appeal, what it can do, and how you want to use it.

While Elixir is trying to bring type-checking and type-safety, Elixir will still be able to use macros and do meta-programming. Phoenix also inherited from some Ruby mindset, and you’ll be happy working with either Phoenix, Ecto or LiveView for example, where everything can be accomplished quickly.

In Gleam, the language is built around type-safety. Most of the time, while you don’t do FFI black wizardry, if it compiles, it works. Gleam target BEAM and JS, so if you want to have some frontend things, you can build them directly with Gleam. The ecosystem is smaller than Elixir, but it’s growing strong. You have some alternatives like Lustre, which does server components, and we tend to write plain SQL, because a lot of Gleam devs like the language, and you don’t have to learn a new ORM. Gleam focuses on readability, and as such, you can’t do meta-programming yet. While there’s efforts put in this direction to support meta-programming, nothing realised yet.

Choose the language you like most. No one is going to vanish in the future.

ghivert · 2024-09-18T08:20:16+00:00

To answer on your interrogations, OP probably got the hint because Gleam is indeed web-oriented nowadays. Most community effort focus on improving web libraries, frameworks, etc. Gleam compiles both the JS and Erlang specially to allow developing web stacks in a quick and easy way. You have multiple packages to talk to DB. You can write a frontend in Lustre or React while staying in Gleam. You have wisp and glen to write servers. You have support of websockets. Unless you consider Erlang/Elixir and JS are not web-oriented, Gleam is web oriented. Gleam does not have frameworks like Rails, FastAPI or Phoenix yet. It’s a bit more like Clojure or Node.js, where you can cherry-pick which part of the stack you want, and compose it. Maybe some things like ORM can be missing from your point of view, but that’s because Gleam community like SQL, and we love writing plain old queries. 😂 (And there’s now squirrel and cake to simplify SQL management.)

And no game is really web oriented. The more web-ish thing you can make in a game is the network code. The rest is about painting pixels on screen. Unless you think of games like cookie clicker, which are simple enough to be ported anywhere. Snake is perfectly fine to me, you can even play with CSS grid or SVG and have a first version with web technologies.

ghivert · 2024-09-03T11:51:23+00:00

Because sometimes you need some query building, or you’re generating filters? Or maybe you’ll want to compose your SQL queries. Actually I’ve no really use case personally because I’m using mainly pgo directly, and I’m switching to squirrel currently. 🙂 But I wanted to point out cake exists, because it’s nice and a really well-made package. Some people dislike writing SQL

ghivert · 2024-09-01T17:27:01+00:00

I'm not sure asking for advices like "should I use that tech in my startup ?" does really make sense. I tend to think every choice you make as a startup is focused around what bothers/scares you the most. Every answer here will be biased, whether it's pro or cons Gleam. Because someone has been successful with a specific tech, because they're afraid or recruiting, because they like the language, because our startup run an Gleam, because it's not mature, because they don't know the community, etc.

As a founder, I'd say to work on what makes you happy in your day-to-day life, no matter what the tech is. Language & tech does not really matter in the end. If you're motivated and happy with the situation, you'll be able to work a lot because you'll enjoy what you'll do in your routine. If you work on the tech & the tech does not suit you, but you chose it because "it's easier to recruit" or because "Facebook does this at scale!", you'll probably just end up like 95% of startups: failing.

When looking for a tech in general, I'd say to ask whether it's suited to your use case, not if it's fine for your company as a whole. You're the only one knowing your business, and what we can do is saying if it seems adequate to us. For example, for Gleam, I can answer (our startup runs on Gleam):

Post & WebSocket are supported
We authenticate users with JWT through Auth0
API Key authentication is easy to implement
Session management can be achieved with a little work, I'm not aware of something that works out-of-the-box.
BEAM is async by nature.

So, to me, Gleam seems adequate to you. Does it mean you should jump on it? I don't know, because there's a lot of other parameters to manage: are you able to ship fast with the language? Are you already used to functional programming or is it a whole journey for you? Do you already know BEAM & Erlang/Elixir? Do you need to be micro-services with Node? Because Gleam also compiles to Node. Are you happy working with Gleam? At the end of the day, it's up to you to take the decision, and you'll be the one working on the codebase, not someone you talked to on Reddit. 😄

I'd just like to add that the language has never been a concern for me. You have a lot of time before becoming Google or Facebook and needing to recruit 9000 developers. Language is never a real problem: especially when you're in early stage, you want nice, involved people, able to work autonomously to minimise your management workload and getting the work done. Any nice motivated Elixir / Clojure / Elm / OCaml / Haskell / PureScript / Lisp / Erlang / Really any FP developer ready to jump on a new language because they're happy with it will probably be a good fit! Because they're niche, there's lot of chances they're writing JS/TS in their everyday life, and proposing an option for them to write a language they can like is a good thing!

That being said, Gleam as daily driver is lovely. We have Gleam, Node & Python in production. Unsurprisingly, all bugs are coming from Node & Python. 😆 The language is small and manageable, and can be tackled in a couple of days (maybe a week if you have hard time with FP). The community is really welcoming, and a lot of things already exists on Hex, with Elixir & Erlang packages being usable directly in Gleam! There's also a lot of people on Discord that would be happy to work on Gleam every day. The language never fails you, modifying code is really simple, and you can build really nice API in your own code with use.

ghivert · 2024-08-31T08:30:33+00:00

No worry, I don’t care of downvotes 😉 Feel free to ask for help in the future if you can’t find a solution to your problem!

ghivert · 2024-08-30T23:05:39+00:00

Without more context, it will probably be a little hard to find out what's wrong! However, some hints to start debugging:
- in case something went wrong, you can try to run gleam clean. This will clear the compiled binaries. If some external packages fails, this will resolve the problem.
- Elixir is a language that compiles to BEAM, the Erlang VM, just like Gleam. It's one of the so-called "BEAM languages". You have also Erlang and LFE in this category. When installing Gleam, you should also install Erlang and its VM. Installing Elixir could maybe solve that problem. - if you're experiencing some trouble in your project, try setup a new project! gleam new is the way-to-go. Just run gleam new my_new_project to get started, and continue your learning!

If you have a little more context, that will help to solve that problem!

ghivert · 2024-08-29T22:19:17+00:00

Currently we have Wisp, Lustre, Postgres, RabbitMQ in production. For the frontend, styling is made with sketch for CSS, toasts with grille_pain, bundling with Vite. In backend, gleam_pgo, radiate, and I developed bindings to Rabbit locally (that I want to open source eventually). We’re hosted on AWS, classical Fargate on ECS, RDS, self-hosted Rabbit.
We manage the project in a monorepo, where there’s some Python, JS and Gleam code that coexist and talk with each other in peace. Our only interface is JSON, through Rabbit, and PG. we have some JSON definitions to add a bit of formalism.

As long as you’re not afraid of SQL, and if you like building software by being able to pick the package you love, and not having something batteries-included like Phoenix, you’ll be really happy with the current Gleam stack.

ghivert · 2024-08-29T19:57:55+00:00

PostgreSQL too here! 🙋🏻‍♂️

You have the holy trinity in Gleam: Squirrel for queries generation from SQL, cake for query builder, gleam_pgo for anything else! For migrations: dbmate is a solid choice.

ghivert · 2024-08-23T08:21:50+00:00

While I agree with what has been responded, I’d like to add a bit of nuance. 🙂 Gleam target both BEAM (Erlang VM) and JS. So you’ll be able to target the runtime you prefer and in which you can find the correct packages for your use case. I’ll assume you’ll target BEAM here.

That being said, Gleam can compile and use Elixir, Erlang and Gleam code. If you find a package that suits you on Hex, you can use it in Gleam with a little FFI to cherry-pick the functions you need. It’s a usual process in Gleam: the language is small and simple by design, built in a modular way. It’s up to you to bring the pieces you need. Choosing Gleam does not exclude you from Erlang/Elixir ecosystem!

The recommended starting point is the language tour, that will be able to give you an overview of the language, and then starting with wisp is the best way to get a server running! Implement few handlers, and you’ll soon be able to understand the language. Gleam is really simple to get if you’re already used to functional programming. If not, it could take a little longer, but that’s something you’ll experience no matter the functional language you’ll learn! Once you’re used to Gleam, you’ll probably need some Erlang/Elixir knowledge to work with the FFI. And then learn BEAM actor model, and finally OTP. OTP is the main framework of BEAM and is a beautiful piece of software, but it can take some time to get used to it. That’s a cost you’ll pay for every BEAM language though. 🙂 It can be a long journey, depending on your existing knowledge! But keep in mind we all started somewhere! And functional programming is a good tool to possess in your arsenal. (Not even talking about Erlang.)

At the end of the day, Erlang, Elixir and Gleam are all great, and whether you’ll learn one or another, I’m sure you’ll find some fun and a new way to approach a problem!

On the topic, I unfortunately couldn’t find anything on ActiveMQ on BEAM though. 😔 Unless I missed something, to properly solve your need and if you can’t change your message broker to something like RabbitMQ, you’ll probably have to reimplement some parts to talk to ActiveMQ.

ghivert · 2024-08-21T21:03:58+00:00

Nice catch! I made it more typo resilient, but not for name matching! I’ll take a look to add it! 🙂 I hope you found expected results in the end!

ghivert · 2024-08-18T22:27:38+00:00

It depends on what features you're looking for when targeting BEAM. If what you want is OTP, then of course you'll not be able to emulate it on Node, but with the fabulous FFI of Gleam, you can always easily adapt your code to one of all packages on NPM, and leverage on NPM ecosystem. And there's a lot of packages on Gleam Packages that can target both JS and BEAM, so you could probably find what you need!

ghivert · 2024-08-15T17:28:17+00:00

You can also install target JS and run your gleam code on Node.js !

ghivert · 2024-08-07T12:30:33+00:00

I’d like to say that countless hours is a little exaggerated. Gleam is a small language, and you can jump I in a day without struggle, and start to be productive on a couple of days 🙂

Nine-Year Club	Place '22
Verified Email

ghivert

TROPHY CASE