6 ms·

I'm looking into potentially using Haxe as a way to share code between iOS and Android. Unfortunately, it doesn't seem like anybody has made a good, open source

I'm looking into potentially using Haxe as a way to share code between iOS and Android. Unfortunately, it doesn't seem like anybody has made a good, open source Objective-C/Swift target for it yet. (There is a Swift target here[0] but it hasn't been committed to since October 8 and doesn't seem production-ready by any means.) I would contribute one myself but I have no experience with OCaml, and don't currently have time to learn it. I like the idea of this approach way more than the one that projects like Xamarin take (build a common runtime on top of each platform) because you don't incur any runtime overhead, and debugging would (in theory) be much easier because you can just debug the native language instead of needing to understand the extra VM layer on top. As a bonus, with Haxe you can also target the web, which you can't do with Xamarin/RoboVM/RubyMotion/etc. Has anyone tried anything like this (not necessarily with Haxe) and had success with it? [0]: https://github.com/ralcr/swift-target https://github.com/ralcr/swift-target Edit: Wording and clarification, added bit about targeting web.

benologist 12y ago
I've been using haxe/openfl in production for 1.5 years and wouldn't really recommend it. Originally cross-platform code was a really good idea very few people had or executed well and haxe's warts were forgivable, today that's a capability many languages have without the hassle. I think the only unique value left in Haxe is outputting Flash.
- jdonaldson 12y ago
  what languages have a platform comparable to OpenFL?
  - benologist 12y ago
    I don't think there's a drop-in alternative to the Flash API other than OpenFL, but you can achieve the same outcomes in pretty much any language. If you're just looking for multi-platform stuff, that's almost a minimum requirement now: unity3d, unreal engine, xamarin, javascript etc.
    - jdonaldson 12y ago
      unity/unreal engine isn't really a fair comparison, you're either requiring a web view plugin (unity), or you're going with emscripten (unity/unreal). I couldn't find evidence of solid support for Xamarin there either. Haxe has the ability to integrate much more cleanly across all of these platforms imho.
  - WoodenChair 12y ago
    If you mean what languages have a near Flash equivalent API, then Dart has StageXL http://www.stagexl.org http://www.stagexl.org
    - jdonaldson 12y ago
      Hmm, hadn't heard of that one before.
- RussianCow 12y ago
  I think the value of Haxe comes from being able to use one language across platforms, not anything specific to the language itself. Could you speak to the specific "warts" you found while using it? I'm genuinely curious.
  - benologist 12y ago
    My favorite is Array.sort. Since it's consistent with many other languages you won't get to the docs until your app is crashing. Instead of being fixed it's had a recommended alternative buried in the docs for I think years: The sort operation is not guaranteed to be stable, which means that the order of equal elements may not be retained. For a stable Array sorting algorithm, haxe.ds.ArraySort.sort() can be used instead. Every platform has its own gaps in the API. This is evident in this submission - after the author translated his JavaScript he then had to fix his haxe to work within the subset available to C#. OpenFL isn't a mature platform and their releases are rushed and buggy. If you download and install <older OpenFL> their setup process will install the newest version of dependencies and their incomplete documentation will leave you to figure out what versions are actually compatible. Gestures are a pain in the ass with immature and incomplete libraries. The one thing that makes it worth using - barely - is the decade and a half of ActionScript experience I also have.
    - RussianCow 12y ago
      I see. Are there a lot of these warts? To be fair, if all the inconsistencies are documented, that seems like a fairly minor inconvenience for the benefits you get. (I don't know how well-documented they actually are, so maybe the answer is "not".) Also, if I were to use Haxe for mobile development, it wouldn't be through OpenFL; I would use the native APIs of each system and just write a thin wrapper in Haxe that's common for all platforms. I just want to reuse code, not adopt a completely separate UI toolkit.
      - benologist 12y ago
        The success story mentions the dev had to learn OCaml to fix bugs in Haxe, other comments here by jdk and reallyRaoul refer to inconveniences too. Elsassph mentions some of the issues are specific to OpenFL not haxe, that's true both ways. I think you can reasonably expect to encounter issues. Do you expect to encounter any bugs at all - outside your own code - in Java, Objective C etc when you do your native UIs?
- elsassph 12y ago
  Let's be careful not to limit Haxe to OpenFL, which the linked article isn't even using. The article points out that Haxe is a great option for creating portable application logic while the game is using Unity for rendering. Other uses for Haxe are the JavaScript target which a number of companies are using extensively in the same way you would be using typescript/coffeescript.
jdonaldson 12y ago
There's been some more discussion and developments on this recently: https://groups.google.com/forum/#!topic/haxelang/KhrRlizYwX8 https://groups.google.com/forum/#!topic/haxelang/KhrRlizYwX8 I think the focus is going to be on generating objective c, rather than swift. Although, that's the entire extent of my understanding.
- RussianCow 12y ago
  Yeah, I agree that an Objective-C target makes more sense because it's more broadly useful (and Apple is still making backwards-incompatible changes to Swift). Thanks for the link!
yissachar 12y ago
Regarding targeting the web, you can't do this directly with RoboVM, but you can use GWT to do so. This means that you can target Android, iOS, and web with Java. You would have shared code that all platforms could use, and then build the UIs natively. This is pretty much the approach that Google use with Inbox, except they used j2objc instead of RoboVM.
- RussianCow 12y ago
  That's true, thanks for pointing that out. Java-based solutions can target the web "for free".
  - ousado 12y ago
    When you take development time into account, GWT doesn't come for free. Yes, it's possible to compile Java to JS via GWT, but the toolchain is prohibitively slow. In contrast, the Haxe compiler is extremely fast.
- sehugg 12y ago
  I've done this successfully with libGDX/RoboVM for my game Feldspar. (http://feldspargame.com http://feldspargame.com)

benologist 12y ago

I've been using haxe/openfl in production for 1.5 years and wouldn't really recommend it. Originally cross-platform code was a really good idea very few people had or executed well and haxe's warts were forgivable, today that's a capability many languages have without the hassle. I think the only unique value left in Haxe is outputting Flash.

jdonaldson 12y ago
what languages have a platform comparable to OpenFL?
- benologist 12y ago
  I don't think there's a drop-in alternative to the Flash API other than OpenFL, but you can achieve the same outcomes in pretty much any language. If you're just looking for multi-platform stuff, that's almost a minimum requirement now: unity3d, unreal engine, xamarin, javascript etc.
  - jdonaldson 12y ago
    unity/unreal engine isn't really a fair comparison, you're either requiring a web view plugin (unity), or you're going with emscripten (unity/unreal). I couldn't find evidence of solid support for Xamarin there either. Haxe has the ability to integrate much more cleanly across all of these platforms imho.
- WoodenChair 12y ago
  If you mean what languages have a near Flash equivalent API, then Dart has StageXL http://www.stagexl.org http://www.stagexl.org
  - jdonaldson 12y ago
    Hmm, hadn't heard of that one before.
RussianCow 12y ago
I think the value of Haxe comes from being able to use one language across platforms, not anything specific to the language itself. Could you speak to the specific "warts" you found while using it? I'm genuinely curious.
- benologist 12y ago
  My favorite is Array.sort. Since it's consistent with many other languages you won't get to the docs until your app is crashing. Instead of being fixed it's had a recommended alternative buried in the docs for I think years: The sort operation is not guaranteed to be stable, which means that the order of equal elements may not be retained. For a stable Array sorting algorithm, haxe.ds.ArraySort.sort() can be used instead. Every platform has its own gaps in the API. This is evident in this submission - after the author translated his JavaScript he then had to fix his haxe to work within the subset available to C#. OpenFL isn't a mature platform and their releases are rushed and buggy. If you download and install <older OpenFL> their setup process will install the newest version of dependencies and their incomplete documentation will leave you to figure out what versions are actually compatible. Gestures are a pain in the ass with immature and incomplete libraries. The one thing that makes it worth using - barely - is the decade and a half of ActionScript experience I also have.
  - RussianCow 12y ago
    I see. Are there a lot of these warts? To be fair, if all the inconsistencies are documented, that seems like a fairly minor inconvenience for the benefits you get. (I don't know how well-documented they actually are, so maybe the answer is "not".) Also, if I were to use Haxe for mobile development, it wouldn't be through OpenFL; I would use the native APIs of each system and just write a thin wrapper in Haxe that's common for all platforms. I just want to reuse code, not adopt a completely separate UI toolkit.
    - benologist 12y ago
      The success story mentions the dev had to learn OCaml to fix bugs in Haxe, other comments here by jdk and reallyRaoul refer to inconveniences too. Elsassph mentions some of the issues are specific to OpenFL not haxe, that's true both ways. I think you can reasonably expect to encounter issues. Do you expect to encounter any bugs at all - outside your own code - in Java, Objective C etc when you do your native UIs?
elsassph 12y ago
Let's be careful not to limit Haxe to OpenFL, which the linked article isn't even using. The article points out that Haxe is a great option for creating portable application logic while the game is using Unity for rendering. Other uses for Haxe are the JavaScript target which a number of companies are using extensively in the same way you would be using typescript/coffeescript.

jdonaldson 12y ago

There's been some more discussion and developments on this recently: https://groups.google.com/forum/#!topic/haxelang/KhrRlizYwX8 https://groups.google.com/forum/#!topic/haxelang/KhrRlizYwX8 I think the focus is going to be on generating objective c, rather than swift. Although, that's the entire extent of my understanding.

RussianCow 12y ago
Yeah, I agree that an Objective-C target makes more sense because it's more broadly useful (and Apple is still making backwards-incompatible changes to Swift). Thanks for the link!

yissachar 12y ago

Regarding targeting the web, you can't do this directly with RoboVM, but you can use GWT to do so. This means that you can target Android, iOS, and web with Java. You would have shared code that all platforms could use, and then build the UIs natively. This is pretty much the approach that Google use with Inbox, except they used j2objc instead of RoboVM.

RussianCow 12y ago
That's true, thanks for pointing that out. Java-based solutions can target the web "for free".
- ousado 12y ago
  When you take development time into account, GWT doesn't come for free. Yes, it's possible to compile Java to JS via GWT, but the toolchain is prohibitively slow. In contrast, the Haxe compiler is extremely fast.
sehugg 12y ago
I've done this successfully with libGDX/RoboVM for my game Feldspar. (http://feldspargame.com http://feldspargame.com)