eta VS ghc-for-ios

Or just go full on functional. There are several JVM based Haskell languages, e.g. Eta and Frege.

Facebook says that Flow is not a language, but just a type checker. Meanwhile TypeLead says Eta is a language. Both stances are purely arbitrary, and to me they're dialects of ECMAScript and Haskell respectively. In this sense, the difference between exogenous and "integrated" is purely one of terminology, and one on which people do not agree on.

I've heard of Eta (Haskell on JVM). It's supposed to work with Android. https://eta-lang.org

I'll try to improve on my speculative and admittedly uneducated guess: https://www.codenameone.com/ (JVM on iOS) + https://eta-lang.org/ (Haskell on the JVM)

Find a proper binding / way to run Haskell within Java / the JVM - it looks like there are some options, e.g. https://github.com/typelead/eta

What I know so far: 1. Compiling to iOS is "reasonably straightforward", see this repo for Intel-based Mac setup, on M1 mac it "should be" easier, as the code is natively executable and GHC binary is available for M1 CPUs from 8.10.7 (I think), so you don't even need to compile it. 2. Compiling to Android (you didn't ask for it, but still) was only done for GHC 8.4 as far as I know - see this post - not sure if it's possible to do with a newer version, but it took me 30min to downgrade our codebase to 8.4.4, so the difference seems not critical, if not. 3. Template Haskell cross-compilation is, at best, an extra challenge - see this post, for example: https://www.tweag.io/blog/2020-11-25-asterius-th/ . In your code you can probably avoid using it, but some libraries might use it - not sure yet how critical it is.. 4. FFI for C/C++ import/export is relatively straightforward, but writing Storable instances to marshall/unmarshall Haskell types to/from C structs with the existing tooling is quite annoying with lots of boilerplate - definitely some place for improvement here. 5. Connecting Haskell code to SQLite - it "should be" doable, as there is the same C api on all platforms. 6. Connecting Haskell code to network - most people would need http(s), we need tcp/tls, so in theory it should be doable to fork the libraries and replace c-bindings to keep the interface (and possibly to compile conditionally), but at best - it's non-trivial, at worst - can be impossible to keep Haskell APIs and would require replacing the libraries and changing the application code...