Few cents about my commits

Kotlin coroutines: Dispatchers.Main context for RoboVM applications


Android has kotlinx-coroutines-android Dispatcher.Main that coroutine execution on main/ui thread.
It allows writing an effective suspend logic on main thread as described on the usage page:

fun setup(hello: Text, fab: Circle) {
    GlobalScope.launch(Dispatchers.Main) { // launch coroutine in the main thread
        for (i in 10 downTo 1) { // countdown from 10 to 1 
            hello.text = "Countdown $i ..." // update text
            delay(500) // wait half a second
        hello.text = "Done!"


To make Dispatchers.Main available to kotlinx following steps to be done:

AltPods: pods updated - 1.16.0-SNAPSHOT


AltPods were updated to v1.16.0-SNAPSHOT to sync with recent releases.

New pods

Updated pods

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.16.0-SNAPSHOTS version. Source code @github

Updates are not fully tested, please open issue if bug found.

Alt-pods binding -- useful script


Alt-pods binding process includes time-consuming preparation activities like download binaries/copy/update versions etc. An attempt to automate these was made and messy scripts/dumpdeps.kts was born.
It automates following flow:

  • gives instruction where to download framework to;
  • deletes header files in bro/ folder and copies new;
  • deletes java/ folder with existing bindings;
  • invokes bro-gen script to perform binding;
  • tries to fetch version information from where possible;
  • updates version information in pom.xml/readme files;
  • can process multiple frameworks in multi-thread mode;

Also its kotlin-script, and it can be debugged in Idea.


Idea plugin: support for 2020.1 EAP


Simple update that makes it working in Idea 2020.1 EAP. Deprecated API where removed and plugin has to be updated.
Also JetBrains has fixed the issue that was making development using Maven model complicated (hooray!).
(Maven model is nice as allows to have code hot-swap)

Changes proposed as PR670

fix #567: GlobalValueEnumeration crash


fix #561: wrong pointer to flexible array member



issue #561 ExtAudioFile.read() isn’t playing nice anymore. @yajirobe69 in comment described that possible root case it is a due field annotation was changed from @Array({1}) to @ByVal.
buffers field is a flexible array member of AudioBuffer struts. To work with this array required to get pointer to first struct (member itself) and then navigate in it by using methods of Struct class.

Root case

Root case of issue was introduced in e0b6db6. Accessing struct member is a struct kind and is annotated as @ByVal will cause following:

  • first element being accessed;
  • copied;
  • copy of it is returned

While it is normal to read struct by value, in flexible array member case it is wrong as:

  • pointer to first struct is required, not pointer to the COPY;
  • future operations with copy, e.g. setting elements (at index 1+) might cause memory corruption.

The fix

fix #557: Applying fixes to libcore


ClassCastException: ObjC protocol and its Java implementation



There is many API in CocoaTouch where argument is ObjC protocol type. In RoboVM protocols are mapped into interfaces. The problems begin when bro-bridge tries to marshall this protocol implementation into the native object:

UIToolbar toolbar = new UIToolbar();
toolbar.setDelegate(bar -> UIBarPosition.Any);


java.lang.ClassCastException: com.mycompany.myapp.Main$$Lambda$1 cannot be cast to org.robovm.objc.ObjCObject
	at org.robovm.objc.ObjCObject$Marshaler.protocolToNative(ObjCObject.java:388)
	at org.robovm.apple.uikit.UIToolbar.$m$setDelegate$(Native Method)
	at org.robovm.apple.uikit.UIToolbar.setDelegate(UIToolbar.java)
	at com.mycompany.myapp.Main.didFinishLaunching(Main.java:26)

Root case: protocol marshaller can handle only ObjCObject. Indeed, there is no way to marshal random Java class to ObjC native world.

The existing workaround:

AltPods: pods updated - 1.15.0-SNAPSHOT


AltPods were updated to v1.15.0-SNAPSHOT to sync with recent releases.

Updated pods

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.15.0-SNAPSHOTS version. Source code @github

Updates are not fully tested, please open issue if bug found.

NB: AltPods – are robopods kept at my personal standalone repo. This is done to prevent main robopods repo from turning into code graveyard. As these pods have low interest of community and low chances to be updated.

re-thinking a way SWIFT dependencies are resolved



First time issue was reported on gitter

libswiftCoreMIDI.dylib is not found in swift paths

Later it was communicated that workaround doesn’t work during submition to Apple: ERROR ITMS-90209: “Invalid Segment Alignment. The app binary at ‘SwiftSupport/iphoneos/libswiftCoreMIDI.dylib’ does not have proper segment alignment. Try rebuilding the app with the latest Xcode version.”


  • RoboVM can detect swift dependencies only in dynamic frameworks. For static libraries/frameworks workaround was introduced.
  • Today dynamic framworks might link again runtime swift libraries – these should not be copied to .app/Frameworks folder. These dependecies can be observed using otool -L command:
/usr/lib/swift/libswiftWebKit.dylib (compatibility version 1.0.0, current version 610.1.28, weak)
@rpath/libswiftAVFoundation.dylib (compatibility version 1.0.0, current version 1991.1.1, weak)  

there libswiftWebKit.dylib is from runtime location(and RoboVM can’t copy it) and libswiftAVFoundation.dylib to be bundled into application (have to be bundled).