MOE 1.4.0 with Xcode 9 support is available for testing

Hi Kees,

thanks for the report.

In the meantime the source code for the new release was also pushed to Github on the moe-master branch.

You may get it, like this:

repo init -u -b moe-master
repo sync
1 Like

No problems running it on an iPhone SE from my mac mini from xcode. Will test remote build tomorrow.

It looks like libimobiledevice.dylib is linked against the wrong version of liblzma. It is linked against version 8.0.0, but a standard macOS install only has version 6.0.0. See the exception below from a clean macOS install. A workaround is to brew install xz, which has version 8.0.0 of liblzma.

Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/auser/.moe/moe-sdk-1.4.0/tools/macosx/x86_64/libimobiledevice.dylib: dlopen(/Users/auser/.moe/moe-sdk-1.4.0/tools/macosx/x86_64/libimobiledevice.dylib, 1): Library not loaded: /usr/local/opt/xz/lib/liblzma.5.dylib
 Referenced from: /Users/auser/.moe/moe-sdk-1.4.0/tools/macosx/x86_64/libimobiledevice.dylib
 Reason: Incompatible library version: libimobiledevice.dylib requires version 8.0.0 or later, but liblzma.5.dylib provides version 6.0.0
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(
at java.lang.ClassLoader.loadLibrary(
at java.lang.Runtime.load0(
at java.lang.System.load(

otool -L output for 1.4.0 (after brew install xz):

MacBook-Pro-4:mydir auser$ otool -L ~/.moe/moe-sdk-1.4.0/tools/macosx/x86_64/libimobiledevice.dylib 
	libimobiledevice.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/local/opt/xz/lib/liblzma.5.dylib (compatibility version 8.0.0, current version 8.2.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

otool -L output for 1.3.8:

MacBook-Pro-4:mydir auser$ otool -L ~/.moe/moe-sdk-1.3.8/tools/macosx/x86_64/libimobiledevice.dylib 
	libimobiledevice.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/liblzma.5.dylib (compatibility version 6.0.0, current version 6.3.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

Had some signing issues but figured them out.

I seem to have the same problem as Alan_Hamilton now when I try to run from Android Studio. Installing xz via brew solved it.

Here’s my update on testing remote build:

I am trying to migrate my existing moe 1.3 project to 1.4, but sadly, I had no luck so far.

after changing the moe version in the build.gradle to 1.4, none of my bindings get recognized anymore.
I get errors like this:

Error:(96, 38) Gradle: error: name clash: errorWithDomainCodeUserInfo(String,long,NSDictionary<?,?>) in GADRequestError and errorWithDomainCodeUserInfo(String,long,NSDictionary<String,?>) in NSError have the same erasure, yet neither hides the other
Error:(114, 31) Gradle: error: name clash: initWithDomainCodeUserInfo(String,long,NSDictionary<?,?>) in GADRequestError and initWithDomainCodeUserInfo(String,long,NSDictionary<String,?>) in NSError have the same erasure, yet neither overrides the other

Re - generating the bindings with the .nbc files does not work eighter, it throws an error too.
I also updated the xcode settings with the gradle command, but no luck here.

Did I miss some steps? Is it even possible to migrate a project from 1.3 to 1.4 right now?

Thanks for the new version and for the help!

Best regards,
David Wernhart

moe 1.4 changed the argument type for methods take generic parameters. Most of them become more specific instead of Foo<?> (NSDictionary instead of NSDictionary<?, ?> in your case). But in Java Foo and Foo<?> have same earsed type signature so you will get those errors.

1 Like

thank you for the reply!

but does that mean I have to rewrite my bindings manually or is there something else I can do?

Dear David,

we are looking into this.

Best Regards,


We updated moe-bindings to MOE 1.4.0 and regenerated all bindings:

Best Regards,

Hi @Noisyfox,

Could you please elaborate where do you see type-erased NSDictionary instances? We saw that due to the iOS 11 changes, some APIs are now generated differently (e.g. as NSDictionary<String, ?> instead of NSDictionary<?,?>).

Thank you for your help in advance.

Best Regards,

thank you for your help! I managed to get my project up and running with MOE 1.4 now, but I want to add some new bindings for firebase. I basically took the .nbc file from the moe-bindings github page, but when I want to create the bindings, I get the following error:

It would be really helpful for me to know how to fix this.

Thank you and best regards,
David Wernhart

Dear David,

despite this error output, the bindings should have been correctly generated (at least this is our experience).

We are working on removing this error, in the meantime, could you please check if the bindings are generated for you?

Best Regards,

In our case, the interface AVCaptureMetadataOutputObjectsDelegate changed from

public void captureOutputDidOutputMetadataObjectsFromConnection(
AVCaptureOutput captureOutput, NSArray<?> metadataObjects, AVCaptureConnection connection )


public void captureOutputDidOutputMetadataObjectsFromConnection(
AVCaptureOutput output, NSArray<? extends AVMetadataObject> metadataObjects, AVCaptureConnection connection )

give us the same compile error after upgrade to 1.4.

Thanks a lot! I just add the two commands needed to brew install xz to your post.

If you don’t have Homebrew installed on your machine run this:

Then run:

  • brew install xz

Dear colleagues,
have you finalized your plans on Android 8/OpenJDK support?
we’ll be very thankful if you already have date of planned release for A8
do you plan early access for MOE 2.0 for your enterprise customers?

Seem good so far, but the CPU using are very high. My project is an Libgdx game. I test with both real device and simulator on iOS 10.3 and iOS 11.1. it use more than 30% of CPU even with a blank project generate by Libgdx Setup app. It is both on real device and Simulator. My CPU is core i7 @2.66GhzX4

My iMac also has experienced CPU spikes while building iOS apps with 1.4.0. This did not happen with 1.3.10.

My iMac is brand new and has latest gen 3.6 GHz Intel Core i7 with 16 GB RAM and 512 SSD. I’m running Sierra (OSX 10.12.6). So far MOE 1.4.0 is the only thing that can make the internal fan kick on loud enough to notice it.

Activity Monitor shows a “java” process taking over 300% of CPU at times. I should mention that this doesn’t happen on every build, and it seems to happen more often when I’m using the iPhone X simulator.

Other than that everything has worked great for me. I’m using Android Studio 3.0.1 with MOE 1.4.0 and Xcode 9.1. Already built and published an app update to the App Store (adding iPhone X support) with this setup and everything seems to be going as usual.

Also recently upgraded Gradle to 4.1 and I’m using the classpath “” (I use LibGDX). Everything going fine with that too. Good job MOE Team!

Dear MrPat,

could you please elaborate a bit which java process seems to eat that much CPU? Does it happen during building or during running your app on the iPhone X Simulator?

Could you please try also MOE 1.4.1 and Xcode 9.2 just to make sure that you can still reproduce it with the latest tools?

Best Regards,

Well I haven’t done as much iOS development in the last few days. I updated to MOE 1.4.1 a few days ago but I’ve been mostly doing Android. I did do a few runs of my iOS apps today on the iPhone X simulator and my iPhone SE device and didn’t experience any problems.

If I remember correctly the runaway task just said “java” in the Activity Monitor, but I’m not certain of that. It always happened during the build and would go back to normal when the build finished.

Will let you know if it happens again but is looking good so far on 1.4.1. Thanks!

Idk if it’s a bit late, but i’ll try.
Everything works just fine, execpt for the run on connected iPhone device
Any hint?