Available at Maven and IDE plugins are available for download.

Known issues

Release requires Xcode 11.4+, if running previous one following error is expected:

[ERROR] Undefined symbols for architecture arm64:
[ERROR]   "___darwin_check_fd_set_overflow", referenced from:

What’s changed

• support for iOS14 devices
• iOS13.6 bindings
• build system updated to work on recent JDK versions (was working only on JDK8)
• compiler: generic class arguments and @Block parameters pr419
• compiler: support for non-static @Bridge method in enums classes pr420
• compiler: support for @Block member in structs pr421
• fixed: compilation failed on @Bridge annotate covariant return synthetic method pr422
• Support for Struct.offsetOf in structs pr431
• workaround for missing objc classes(ObjCClassNotFoundException) pr442
• added: experimental and formal bitcode support, pr443
• fixed: error code -34018 when using Security API on simulator: pr447
• idea: fixed: annoying Android gradle faced #242
• idea: migrated to gradle build system
• idea: “no Xcode dialog” is not blocking anymore pr434
• idea: disabled generate separate IDEA module per source set pr449
• debugger: various crash fixes (more stable now)
• added: workaround to support static libraries that use swift pr474
• added: frameworkPath/extensionPath can be qualified (temporal support for xcframeworks) pr484
• fixed: OOM on class with huge number of fields pr485
• new icons for Idea plugin !

Other notes

Idea plugin now is a .zip file and Safari will unpack it (by default) which will make it not functional. It has to be downloaded as .zip file and installed using .zip file, not with .jar file inside zip/unpacked folder.

Happy coding! Please report any issue to tracker.

iOS 14

Bindings have been proposed as PR515.
All CocoaTouch APIs were processed based on Xcode12 BETA 6.
This update introduces changes to existing api and this might break existing code. Please open issue/communicate any problem.
Beside existing API update it introduces support for following new frameworks:

• UniformTypeIdentifiers
• Accessibility
• AppClip
• AppTrackingTransparency
• ClockKit
• MediaSetup
• MetalPerformanceShadersGraph
• MLCompute
• NearbyInteraction
• OSLog
• ScreenTime
• SensorKit
• WidgetKit
• DeveloperToolsSupport

AltPods were updated to v1.10.0-SNAPSHOTS to sync with recent releases. Part of list didn’t receive any API update hovewer bindings were re-generated against recent version of frameworks. Update list look as bellow:

Updated pods

• AppLovinSDK v6.13.4
• Firebase v6.30.0
• OneSignal v2.15.2

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.9.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.

issue 509 says that Collator api fails. Short investigations shows that the root case is missing files for collator/normalizer in icu.dat. Simple solution for user is to generate user files and use it as part of application. But icu data customizer is not available anymore online and python scripts for customization are not available for old v51.
icu.dat was built manualy and delivered as PR510. Steps how to do it described bellow.

Tutorial. Building icu.dat from sources

Subsurfer reported several issues related to JNI. Quick test exposed two issues:

Issue 1

JNI FindClass was not successful when was called from JNI_OnLoad (as result of System.loadLibrary for example) root case: top java class on the stack was java.lang.Runtime and its classLoader was NULL (corresponds to BootClassLoader). As result user class was looked in BC list and failed. fix: use systemClassLoader in case as top java class is BC class. issue is similar to robovm/robovm#352

Issue 2

If application uses a dynamic framework or library that exposes JNI_OnLoad it being called in context of application image. This happens as dyld loads all symbols from libraries referenced by LC_LOAD_DYLIB command. as result library JNI_OnLoad got called on early state while JNI is not initialized yet. This caused GPF due null pointer de-reference. fix: ignore JNI_OnLoad for application image

Fix was delivered as PR507.

AltPods were updated to v1.9.0-SNAPSHOTS to sync with recent releases. Part of list didn’t receive any API update hovewer bindings were re-generated against recent version of frameworks. Update list look as bellow:

New frameworks

• Flurry/Analytics v10.3.3
• Flurry/Ads v10.3.3
• Flurry/Config v10.3.3
• Flurry/Messaging v10.3.3
• Firebase/Messaging v4.6.0 (firebase v6.27.0)

Updated pods

• AppLovinSDK v6.13.1
• FacebookSDK v7.1.1
• Firebase v6.28.0
• OneSignal v2.14.3

Other changes

• FIRCrashlytics.registerDefaultJavaUncaughtExceptionHandler that acts similar to same method in NSException but convert stack traces to FIRExceptionModel (check post for details)

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.9.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.

This post continues tutorial for proper initialization of crash reporters t.
Option to track java exception was to use NSException.registerDefaultJavaUncaughtExceptionHandler(). It builds string presentation of exception creates NSException with this text as reason. At same time stack traces will be messed and will point to code where NSException is created.

FIRExceptionModel

Firebase Crashlytics provide special API FIRExceptionModel:

The Firebase Crashlytics Exception Model provides a way to report custom exceptions to Crashlytics that came from a runtime environment outside of the native platform Crashlytics is running in.

Exact case for RoboVM. To have it working its enough to setup Thread.setDefaultUncaughtExceptionHandler as bellow to convert exception stack traces into FIRExceptionModel elements:

Thread.setDefaultUncaughtExceptionHandler((thread, ex) -> {
    FIRExceptionModel model = new FIRExceptionModel(ex.getClass().getName(), ex.getMessage() != null ? ex.getMessage() : "");
    NSMutableArray<FIRStackFrame> modelFrames = new NSMutableArray<>();
    StackTraceElement[] stackTraces = ex.getStackTrace();
    if (stackTraces != null) {
        for (StackTraceElement st : stackTraces) {
            String symbol = st.getClassName() + '.' + st.getMethodName();
            String fileName;
            int lineNo = st.getLineNumber();
            if (lineNo < 0)
                lineNo = 0;
            if (st.isNativeMethod()) {
                fileName = "Native Method";
            } else {
                fileName = st.getFileName();
                if (fileName == null)
                    fileName = "Unknown Source";
            }

            FIRStackFrame frame = new FIRStackFrame(symbol, fileName, lineNo);
            modelFrames.add(frame);
        }
    }
    model.setStackTrace(modelFrames);
    FIRCrashlytics.crashlytics().recordExceptionModel(model);

    // kill app
    throw new ThreadDeath();
});

Note

Crashes will be reported as non-fatal !

Bonus

To get debug output from Crashlytics in simulator its not enought to provide -FIRDebugEnabled. Adding -FIRLoggerForceSTDERR helps.

Short guide how to get framework binary to use with RoboVM if it is provided by the vendor.

Building using Carthage

Carthage is intended to be the simplest way to add frameworks to your Cocoa application

Most github hosted projects provide a way to build artifacts using Carthage. Follow quick start guide for installation. Process is following:

• create Cartfile and set its content up to project info, e.g.: github "Alamofire/Alamofire" ~> 4.7.2
• run carthage update to build.

Result – dynamic framework.

Getting from CocoaPods

CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects

CocoaPods project is highly intended to be used as part of Xcode project.
Often vendors provide instructions on how to include their artifacts into project dependencies using CocoaPods. Xcode project is required, follow step to create one and build the pod:

• create new iOS - Single View App project in XCode and exit it;
• create Podfile in same folder where ${projectname}.xcodeproj is located;
• fill it with references from vendor (PersonalizedAdConsent here as example):

  platform :ios, '9.0'
  target 'pods_tutorial' do
  use_frameworks!
  use_modular_headers!
  pod 'PersonalizedAdConsent'
  end   
  

• run pod install --repo-update to add dependencies to project;
• cd Pods
• build for simulator:

  xcodebuild -configuration Release -sdk iphonesimulator13.5 -scheme PersonalizedAdConsent build \
           CODE_SIGNING_REQUIRED=NO CODE_SIGNING_ALLOWED=NO \
           CONFIGURATION_BUILD_DIR=artifacts_sim/
  

• build for devices:

  xcodebuild -configuration Release -sdk iphoneos13.5 -scheme PersonalizedAdConsent build \
           CODE_SIGNING_REQUIRED=NO CODE_SIGNING_ALLOWED=NO \
           CONFIGURATION_BUILD_DIR=artifacts_device/
  

Few moments here:

• target 'pods_tutorial' do specifies the target as it is in your Xcode project;
• -scheme PersonalizedAdConsent specifies the scheme added by pods, to list all schemes in project use xcodebuild -list;
• -sdk iphoneos13.5 specifies SDK available in Xcode, use xcodebuild -showsdks to list all available;
• CONFIGURATION_BUILD_DIR=artifacts_sim/ specifies the directory, where to put binaries;
• use_frameworks! and use_modular_headers! command to build a dynamic framework, if removed it will result in static library.

Building out of sources

Clone/download Google Mobile Ads Consent SDK as an example:

• Navigate to folder where PersonalizedAdConsent.xcodeproj is located;
• use xcodebuild -list to get list of targets – here is PersonalizedAdConsent;
• build same way as in case of cocoapods, simulator:

  xcodebuild -configuration Release -sdk iphonesimulator13.5 -scheme PersonalizedAdConsent build \
           CODE_SIGNING_REQUIRED=NO CODE_SIGNING_ALLOWED=NO \
           CONFIGURATION_BUILD_DIR=artifacts_sim/
  

• build for devices:

  xcodebuild -configuration Release -sdk iphoneos13.5 -scheme PersonalizedAdConsent build \
           CODE_SIGNING_REQUIRED=NO CODE_SIGNING_ALLOWED=NO \
           CONFIGURATION_BUILD_DIR=artifacts_device/
  

Note: this way static library/framework will be build.

AltPods were updated to v1.8.0-SNAPSHOTS to sync with recent releases. Part of list didn’t receive any API update hovewer bindings were re-generated against recent version of frameworks. Update list look as bellow:

New frameworks

• Firebase/Authentication v6.27.0
• Firebase/RemoteConfig v6.27.0

Updated pods

• AppLovinSDK v6.12.8
• BranchMetrics v0.34.0
• FacebookSDK v7.0.1
• Firebase v6.27.0
• OneSignal v2.14.2

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.8.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.

Previous rework broke JNI. Rework added logic to start JVM automatically once framework is loaded to provide ObjectiveC classes from Java side available as soon as possible. A bad thing is that JVM structures required for JNI call were not exposed. A try to initialize(second) JVM with JNI_CreateJavaVM will fail.
Goal of the fix is to provide ability to have both JNI and ObjectiveC framework operational.

Disabling automatic JVM startup

This can be controlled with another key to robovm.xml. Instead, automatic JVM startup will be disabled if JNI_CreateJavaVM is present in the list of exported symbols:

<exportedSymbols>
    <symbol>JNI_CreateJavaVM</symbol>
</exportedSymbols>

Compiler will generate(only in case of Framework target) _bcFrameworkSkipJavaVMStartup symbol that will be recognized by native code and JVM start up will be skipped.

Interoperability

Once JVM is created it is a good idea(but subject for JNI code design) to ping back framework support code to pre-load all objective-c custom classes. In this case JNI based code should call following function:

void rvmInitializeFrameworkWithJVM(JavaVM* externalVm, JNIEnv *externalEnv);

Code

Code was delivered as PR497