Setting up j2ObjC for Xcode

Background

j2ObjC is a transpiler written and maintained by Google.It compiles java code to equivalent ObjectiveC code to enable mobile developers share common code between their Android and iOS apps. Google already uses this project internally to power production apps like Inbox so we know it is ready for prime time usage.

Motivation

Code sharing

In any meaningful mobile app, there is a chunk of code which relates to the business domain and storing, retrieving and manipulating that data. All of this code is basically the same irrespective of what platform you are writing the app for. This is where we should take advantage of such a tool.

Quicker time to market

Sharing such code between your iOS and Android app will help you reduce development time and increase stability of code.

Leveraging the plethora of Java open-source libraries

There are tons of open source Java projects which can be used very effectively even in an Android application. Projects like Google’s Guava can be very useful in developing an Android application. Imagine if you could use all of those features in your iOS library without writing much code.

Better abstractions

Personally I feel that using this tool will also help you identify the parts of the code which is independent of the platform and hide the platform dependent code behind meaningful abstractions.

Getting started

Setup options

The main hurdle behind using such tools is that they tend not to integrate well with your regular workflows. But with j2ObjC, we have a multitude of options when it comes to integrating this tool with your day to day projects.The main ways in which you can use j2ObjC are

Using j2ObjC’s Gradle plugin.

Using j2ObjC with Xcode build rules.

Using j2ObjC with Xcode and External Build.

Using the JRE Emulation project with Xcode.

The Gradle plugin is still under development and keeps updating the structure and way things are to be setup. They are doing great work but since it is still unstable, in this post I will explain the one which I found to be most convenient and easy to setup, namely via `Xcode with Build rules`

Setting up XCode for j2ObjC

To setup Xcode for building your java source files, follow the below steps.

Determine $source-root for your code. The root directory is the directory that contains the top package of your source files. For example, if you have a Java package foo.bar in a directory called ~/myproject/src, that package’s Java files should be in ~/myproject/src/foo/bar/\*\*.java. That means ~/myproject/src is the root directory for your project.

Add the java source files to your Xcode project, typically by dragging them into the project and selecting the appropriate targets. Do not select `Copy Files`

Go to the `Build Rules` section and add a new section for processing Java source files. Select `Custom script` to run on each Java file.

Add all the platform independent, Java only code in this library and use as required from your Android project. Typical candidates to go into this library would be your business models, your DB interfaces and your util classes.

Add the `java` folder from your `src/main` to your Xcode project.

Modify the `Build Rule` custom script to point to the `src/main/java` folder of your java lib.

Start coding and profit!

Additional configurations

Naming conventions

By default the j2ObjC tools follows a naming convention where your package name in Java code translates to a camel-cased prefix for your class. For example, com.helpshift.common.storage.KeyValueStorage.java would become ComHelpshiftCommonStorageKeyValueStorage.h/m. If that is a convention you don’t like, or you want your names to be a bit more predictable, you can use the — prefix/ — prefixes option of the j2objc tool.

For example, to change the prefix for all classes in the com.helpshift.common.storage package, you would do

--prefix com.helpshift.common.storage=HSStorage

Or you could specify a list of such package name prefixes in a prefixes.properties file and specify the file as an argument to — prefixes

--prefixes path-to/prefixes.properties

Method renaming

The default naming convention followed when converting Java function signatures to ObjC functions is to append the type of the variable to the method name. For example, *

Similar to the `prefix` option, you can provide the `mapping` option to the j2objc tool. This option takes a method signature defined by the Java Virtual Machine Specification and its required translation.

I would highly recommend using the Annotations option since it is much more readable and works more reliably.

Inline native code

J2objc supports embedding native ObjC code within your java sources. All code which lies within `/*-[` and `]-*/` will be copied as is into the generated ObjC files. Since this code is commented from Java’s perspective, it will of course be ignored by the Java compiler.

For example, to write a method which calls out to the ObjC code directly you could do this

Conclusion

If you follow the above steps, you will definitely be able to get up and running with a Java and ObjC project with a lot common code. If you have any difficulties in setting things up, please leave a comment.

Next steps

I am trying to write a python script which will make all the settings changes in Xcode in one shot which will help reduce the time and effort to set things up.

I will also be publishing a simple project which demonstrate how a typical almost-real world application can look like.