I finally managed to get this to run on IOS as well,
android and wear OS already worked last week,
so good enough for a propper anouncement:
13 Likes
I haven’t delved deeply into it yet but this looks really promising. I’ve been waiting for something like this for at least 5 years. Thank you for making it a reality.
1 Like
Very nice - Haskell iOS support has always been lacking, and being able to deploy apps to iOS without any hassle would be a killer feature for Haskell.
2 Likes
It looks like this is mostly vibe-coded with Claude Opus 4.6, is that correct?
4 Likes
True..doesn’t look natty :/
well using xcode has fair bit of hassle. but not much you can do about that, apple /makes/ you use xcode, I tried automating it completly and failed. But flutter can’t automate this either so I’m okay with that. The nix build will make a working library for you and if you use a script like this you get a working project prrrrrrrrr/setup-ios.sh at master · jappeace/prrrrrrrrr · GitHub
Then all you have to do is resetup signing and it just works. The script could be made a bit better by retaining the signing settings, which makes you run it and then you just press play.
UI is shared between ios and android although they do look a bit different.
I suppose with platform detection you could fixup the styling.
How does this compare to other solutions for Haksell app development, for example obelisk?
1 Like
Definitely vibe coded.
I’m not going to write it off just for that but it’s healthy to be skeptical of it. OP wasn’t hiding it, which I appreciate.
Depends.
I don’t know if OP has any credibility in that domain and whether this whole thing just works by accident (or at all).
It also happens that vibe coded projects are discarded/abandoned quickly, because maintaining something long term and being engaged in a project is something entirely different than a weekend claude session.
Additionally, mobile apps are end-user facing and there’s lots of concerns wrt privacy and security. And we know those properties don’t magically appear out of thin air and that vibe coded projects are often more vulnerable.
That means to me that someone announcing a vibe coded mobile app framework has more convincing to do than is visible here. Otherwise I’m not sure how seriously I can take this.
2 Likes
Reflex uses webviews.
This dissalows access to integrations such as bleutooth and also is just slower.
1 Like
Why is AI-generated Haskell inherently bad?
That’s not what I said.
But I’ve explained the state of affairs from my point of view here: How to filter out vibe-coded dependencies - #36 by hasufell
1 Like
This project has a better security story then http-client-tls because it binds to the native android/ios libraries for http, compared to that http-client-tls stack which is kinda crazy (although kazu does their best).
This project is mostly bindings and the transpile setup, not a lot of logic outside of the widgets and animations.
1 Like
How did you develop it?
Do you understand the code? Did you review it?
1 Like
You’re right but you’re also super preachy about it, dedicating entire minutes of your time and whole paragraphs just to warn others.
Can we all just agree that OP’s project has a higher burden of proof than a non vibe coded one and call it a day?
3 Likes
that’s the issue core issue though. There aren’t any real alternatives for native haskell on mobile if you want to control the UI layer (or have access to say, bleutooth).
I’d happily use a human written one, but there are none, so I made this.
This project wins by default because the competition is just non-existent (unless you count webviews, which aren’t very nice)
4 Likes
There are alternatives (albeit still in the works) that use native UI view libraries (not just web views) and allow access to device APIs.
No LLMs were used to make miso-lynx, you also commented on that issue here it seems…
4 Likes
Yeah I did reply to that. I assumed it’d be a webview approach seing the javascript stuff, clearly I was wrong, it appears to be more like flutter, nice 
To be clear, I want a /working/ approach for device / integration access on mobile in haskell, I don’t care who makes it. For example access to the camera or bleutooth.
miso-lynx doesn’t appear to do this right now and is a fair bit away from doing that.
I told it to make a full comparison here:
NB: This is a cookbook on how to use agents better: A Practical Guide to Agentic Software Development — Jappie Software B.V.
I’m linking this because miso-lynx has a lot of infrastructure work ahead (dual-thread architecture, native modules, FFI bindings) — the kind of repetitive cross-platform plumbing that agentic workflows are genuinely good at. It could help get device API support landed faster.
1 Like
Interesting, cool write up. In my opinion it is kind of comparing apples and oranges. I’m writing JS bindings to an already mature set of native C++ libraries deployed in the TikTok app, I’m not attempting to write the native libraries themselves. I believe that is a monumental effort that requires corporate backing, hence ByteDance.
I understand the compile-to-JS approach (as opposed to native compilation) might seem pathological, but since the project is half TypeScript (and a mini-React implementation) we’re following the React native path to target mobile phones. This is the path the virtual DOM ecosystem chose. LynxJS has now made that path available to all web frameworks, which is great.
Thanks for the agentic workflow link, will check it out. The recent VFrag (React fragment) additions did use Claude Sonnet 4.6 to test all the new edge cases introduced. It surprisingly did a good job, after some prodding.
This “repetitive cross-platform plumbing” (LLM speak?) is anything but, I can assure you. It entails re-architecting React internals, splitting event delegation, diffing / patching to execute in separate interpreters, using WebWorkers to communicate. There isn’t much prior art to go off of besides ReactLynx (preact) itself, and we’re not exactly identical to that. So we’re one of the few attempting this, now with VueLynx. Regarding “native modules, FFI bindings”, these are things we will soon get for free through the module system and ecosystem via sparkling.
7 Likes