Thoughts on RoboVM vs MOE

1

SOME WORDS ABOUT ROBOVM

  • I think, the team around the MobiDevelop fork of RoboVM is quite active. (http://robovm.mobidevelop.com/)
  • Recently, a member of the team has published the before mentioned IDEA Plugin with Debugger support (https://gitter.im/MobiDevelop/robovm).
  • Regarding the limited coverage of iOS APIs, I cannot say much at the moment. You may be right.

Nevertheless, I think your idea of porting ART to iOS is great. I am confident, that you are optimizing the implementation further. Hopefully, you are adequately funded by Intel, so that the product can be continued. I have been a customer of RoboVM before Microsoft got involved. Have you thought about a licensing model with basic support as it was once offered by RoboVM?

Best wishes,
Daniel

1 Like
2

Hi Daniel,

thanks for sharing. The RoboVM debugger seems to be very new, it landed just a few days ago.

Intel is not funding MOE development anymore. They did a great job with releasing the code to open-source. Development has been completely funded by Migeran, since the open sourcing.

We are offering support packages to customers. It is a bit different from what RoboVM did, because back then a lot of features were only available in the paid version. Currently all of MOE is open-source.

Best Regards,
Gergely

3

One point through, as I’ve been a RoboVM customer as well :disappointed_relieved:
MOE 2.0 is going to support LLVM, which is a huge step forward, as you’ll be able to target devices being phones and tablets. I have an understanding of the effort involved to make this happen, which I bet is not on the MobiDevelop radar.
In my opinion, MOE has 2 areas to improve to make it the killer tool:

  • the size of the executable. It is based an ART, and carries over the VM, while RoboVM does not. This increases the final size.
  • Swift integration. RIP Objective-C, I never liked you. But nowadays developer prefer Swift, and thus a tighter integration, including Cocoapods automatic consumption, will be a big plus.
2 Likes
4

Cocoapods support is already there. I am using Charts one written in Swift in my app and Crashlytics written in ObjC.

5

But you have to go through the Obj-C headers, right?

6

Does it make a big difference? I don’t see it from the Java code point of view and binding configuration is similar. Here is Charts vs. Crashlytics:

{
  "output" : "src/main/java",
  "platform" : "iOS",
  "inline-function-binding-output" : "src/main/native",
  "bindings" : [ {
    "type" : "framework",
    "name" : "Crashlytics",
    "objcClassGenerationMode" : "Binding",
    "frameworkPath" : "xcode/Pods/Crashlytics/iOS/Crashlytics.framework",
    "packageBase" : "org.moe.binding",
    "importCode" : "#import <Crashlytics/Crashlytics.h>"
  }, {
    "type" : "framework",
    "name" : "Fabric",
    "objcClassGenerationMode" : "Binding",
    "frameworkPath" : "xcode/Pods/Fabric/iOS/Fabric.framework",
    "packageBase" : "org.moe.binding",
    "importCode" : "#import <Fabric/Fabric.h>"
  } ]
}

…

{
  "output" : "src/main/java",
  "platform" : "iOS",
  "bindings" : [ {
    "type" : "header",
    "name" : "Charts",
    "objcClassGenerationMode" : "Binding",
    "headerPath" : "build/moe/xcodebuild/Release-iphonesimulator/Charts.framework/Headers",
    "headerSearchPaths" : [],
    "userHeaderSearchPaths" : [],
    "frameworkSearchPaths" : [],
    "packageBase" : "com.github.danielgindi",
    "importCode" : "#import <UIKit/UIKit.h>\n#import \"Charts-Swift.h\""
  } ]
}
7

That’s right, it seems very similar in most cases. But there are some Swift constructs that do not translate directly to Objective-C. That’s the reason why Swift has the @objc notation, but you do not control where it is defined in a third party library.