Am Samstag, den 26.09.2015, 05:48 -0700 schrieb Raoul Duke: > Exciting to hear! Thank you and your contributors for this work. I > know there are ways people can be parochial, but I have never been > able to fathom how the core OCaml team can ignore mobile so actively, > it seems. It is to sigh, oy veh. I wouldn't say it was "actively" ignored. It is a matter of resources, and - to some agree - also a matter of how important you think support for mobile is. And finally, the devices got first recently so powerful that it makes a lot of sense to target mobile/desktop/server in similar ways, in particular with the same dev languages. This is an important niche for OCaml because the choice of languages on mobile OS is somewhat restricted. > * Getting anything working as simply as possible would be a nice first > step, even if it isn't the most performant. I.e. bytecode. It seems > Apple has loosened up on that a bit over the years? And I wonder if > LLVM bytecode would be no problem with them now. As whitequark already said there is no need to back up to using bytecode. Both 32 and 64 bit ARM works (the latter is now required for Apple's appstore). There might be here and there uses for bytecode, though, e.g. if you need to compile code on the fly. > * FFI will be essential. It is one thing to have 2+2 working on > mobile, it is another to be able to get any real app work done. The FFI works in the normal way. You just need to ensure that you also cross-compile the wrapped library for the mobile device. If you compile C files with ocamlc/ocamlopt as driver it just works (and all tools basing on that work, e.g. ocamlbuild). If you invoke the C compiler directly you need to ensure to pass the right flags for cross-compiling (e.g. -arch arm64). I guess the biggest missing piece here is getting wrappers for the typical platform libraries. > * Ideally it has to integrate well with the platform toolchains, > including the preferred IDEs. E.g. if there's no good installer, if I > have to do a lot of work to build things, etc., then I'm way less > likely to even try to use it. I know that is work most people do not > like to do. I say that empirically. For the iOS support we are not yet that far. > * If you can find some commerical users and support, that could help > drive some of the above issues further faster (although of course the > vector along which they proceed is subjective). This is not as you think. The iOS port is actually driven by commercial users, which has two big advantages: developers have time, and there are plenty of testing opportunities. These users, however, don't have any problems with the FFI or need an IDE. This is just a matter of using development resources well. Let me just explain for what I need the iOS port. The company I'm working for developed a query compiler in OCaml for a new database system. This database backs a UI, and there is also a mobile version of it. Getting the compiler to mobile is fairly essential for the whole success of the product. Now, a compiler doesn't need much of the FFI as it only transforms some data (a query string into bytecode, an int array). External libs are not really needed. The UI is built with the platform tools (I think it is still in Objective C), and we deliver the query compiler simply as a normal library with a C header file to the UI team. I guess this is fairly typical of commercial users. There is some highly complex library written in OCaml providing some functionality you don't want to duplicate in lower-level languages like Swift (sorry,..., a matter of perspective). The UI is better to develop with the platform tools, though (and keep in mind that there is usually a separate UI team not knowing anything about OCaml). Gerd -- ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------