MOE 1.4.0 with Xcode 9 support is available for testing

kisg · September 29, 2017, 6:41pm

Dear MOE Users,

we just uploaded the MOE 1.4.0 build. It is not tagged yet in the repository, and the samples are not yet updated, because we want to get some more testing before we encourage everyone to upgrade.

In this (pre)release:

Xcode 9 is required
Support for launching Xcode 9 simulators
Support for launching apps on iOS 11 devices
Generated bindings for iOS 11 APIs
Updated error reporting and fixed race condition in Maven plugin (many thanks to Dukescript for their pull request!)

How to test:

Clone the MOE samples repository

git clone https://github.com/multi-os-engine/moe-samples-java

Update the moe-gradle plugin version to 1.4.+
Run ../gradlew moeUpdateXcodeSettings from the ios module folder
Import the project into your favorite IDE
Launch / Debug as usual

The IDE plugins don’t have to be updated for this release.

Please share your experience (and of course any issues) with us.

Best Regards,
Gergely

keesvandieren · September 30, 2017, 7:40pm

We have tested Xcode 9 with one of our MOE customer apps.

We have a fluent upgrade experience, nothing unexpected!

Things tested:

Changed MOE version to 1.4.0 in build.gradle
Run ./gradlew moeUpdateXcodeSettings
Run ./gradlew clean && ./gradlew build
Open XCode project
Run on iPhone 5s simulator
Run on connected iPhone device.

Thanks for the new version!

kisg · September 30, 2017, 9:31pm

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 https://github.com/multi-os-engine/manifest -b moe-master
repo sync

Leejjon · October 4, 2017, 8:27am

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

Alan_Hamilton · October 4, 2017, 10:45am

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(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at org.moe.ios.device.launcher.Main.loadNativeLibraries(Main.java:51)
at org.moe.ios.device.launcher.Main.main(Main.java:94)

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 
/Users/auser/.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 
/Users/auser/.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)

Leejjon · October 4, 2017, 11:50pm

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:

wernimaster · October 11, 2017, 9:41pm

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

Noisyfox · October 12, 2017, 12:05am

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.

wernimaster · October 12, 2017, 8:12am

thank you for the reply!

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

kisg · October 12, 2017, 4:00pm

Dear David,

we are looking into this.

Best Regards,
Gergely

vighr · October 13, 2017, 8:01am

Hi!

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

Best Regards,
Roland

kisg · October 13, 2017, 1:29pm

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,
Gergely

wernimaster · October 15, 2017, 6:26pm

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

kisg · October 17, 2017, 10:18am

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,
Gergely

Noisyfox · October 17, 2017, 11:15pm

In our case, the interface AVCaptureMetadataOutputObjectsDelegate changed from

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

to

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

give us the same compile error after upgrade to 1.4.

nprugne · October 26, 2017, 10:52am

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:

/usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)” (see: https://brew.sh)

Then run:

brew install xz

dunemaster · November 17, 2017, 1:07pm

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?

dzungpv · November 24, 2017, 8:28am

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

MrPat · November 30, 2017, 10:02pm

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 “com.android.tools.build:gradle:3.0.1” (I use LibGDX). Everything going fine with that too. Good job MOE Team!

kisg · December 9, 2017, 11:28am

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,
Gergely