Fork me on GitHub
#graalvm
<
2021-06-14
>
phronmophobic18:06:06

A simple todo app written in clojure, compiled with native image, and running on my iPhone. Not sure it's a good idea, but I'm having fun simple_smile.

🆒 15
😮 9
borkdude18:06:19

Is the GUI also written in Clojure, or do you still use the shared lib approach?

phronmophobic18:06:34

All of the app logic is pure clojure (exact https://github.com/phronmophobic/membrane/blob/master/src/membrane/example/todo.cljc#L109as the desktop/web version). There's a shared library for drawing using skia. It's probably possible to skip including a shared library by drawing everything using CoreGraphics

phronmophobic18:06:08

It would also be possible to take the React Native approach by using interop to control native widgets.

phronmophobic18:06:57

I still build the image as a shared library, but that's because the app setup is so much easier to write in objective-c and then call into the shared library than it would be to do everything in clojure with ffi.

raspasov18:06:05

Wow. That’s neat. Do you see any fundamental limitations at this point?

raspasov18:06:46

So this is a real native app, like from Xcode or built from the terminal? What does the process of creating a binary from Clojure code look like? (I have no practical experience with graalvm at the moment)

phronmophobic18:06:24

It's a real native app built with a combination of commands in terminal and xcode. The current process is pretty clunky: 1. Compile java classes for shared library interfaces 2. Build an uber jar 3. run native-image on the uber jar to produce a shared library 4. Build and run from Xcode It would be possible to package all these together, but I'm not sure what that should look like. There are still many limitations, but none of them seem insurmountable if someone was motivated: • Build process is clunky (see above) • Foreign function interface to iOS APIs unimplemented (can be automatically generated from https://developer.apple.com/tutorials/data/documentation/technologies.json?language=objc api) • Long build times • Repl integration lacking. the babashka remote repl does compile and run. There's still some work to integrate it into a comfortable workflow • The current setup only builds for device. It should be possible to build for simulator, but I haven't tried it yet. Building for the simulator might not be strictly necessary, but it might be useful.

kokada19:06:14

Does it starts fast :thinking_face: ?

phronmophobic19:06:55

Seems fast to me, but I have no metrics and the todo app I have is pretty dinky.

phronmophobic19:06:20

It would be interesting to compare with a similar app using cljs+react native

phronmophobic20:06:22

does anyone have xcode experience that wants to try it out?

raspasov04:06:50

I have some. Been doing RN since 2016 or so. Also been doing a bit more Swift/Obj-C native dev in combination with RN last couple of weeks.

raspasov04:06:30

What can I do to help/participate?

phronmophobic17:06:19

@U050KSS8M. It would be great to double check that the https://github.com/phronmophobic/mobiletest 1) works , 2) is easy to follow. I've done mobile development, but mostly objective-c/c++ for games. It would great to get your take on what kind of GUI API you think would make sense (clj bindings for SwiftUI?, UIKit, something else?). I'd also like to know what you think of React Native generally. One interesting strategy would be to create bindings to the https://github.com/facebook/react-native/tree/master/ReactCommon of React Native. Maybe it's worth creating a new slack channel to discuss?

raspasov00:06:05

Sure! Make a channel and I’ll join.

borkdude05:06:23

Where is this channel?

borkdude05:06:16

There is also #cljsrn

phronmophobic05:06:36

whoops, #graalvm-mobile is the channel. join us!