What comes to mind when you hear the words “cross-platform project”?  Do you get shivers up your spine? Remember those long nights trying to get all the platforms to follow the same business logic? Cross-platform projects can have up to 70% of code that gets duplicated for each platform. Don’t you wish there was a way to reduce this redundancy?

There is. It’s called J2ObjC.

J2ObjC allows developers to write all of the business logic and data model handling in Java (Android) and then convert it to ObjC (iOS). J2ObjC also forces the developers to think differently and follow MVC pattern more closely.

The Advantages of J2ObjC

What’s easier: maintaining multiple separate code bases by multiple different teams that provide the same functionality? Or having one team maintaining one code base and then simply converting it to a platform specific language? Obviously, the second option is significantly easier. J2ObjC give you this ability, and the benefits go beyond time saved.

Fewer Errors and Less Redundancy

Writing the functionality in Java and converting it to ObjC removes the redundancy of duplicating the business logic and model handling for each platform. It also reduces the number of human errors that enter the code per platform. If the app is not functioning as expected or the business logic changes, there is no need to look in multiple places to resolve it – all you have to do is modify the Java code and convert it to ObjC again and the changes are applied on all platforms.

MVC

All iOS developers know and use MVC pattern to some extent. By using J2ObjC you can truly enforce the usage of MVC. If the business logic and model handling is written in Java without using platform specific code and converted to ObjC, you can create a blackbox that the platform specific view controllers don’t know much about. This blackbox is identical on all platforms and exposes the same functions to the platform specific view controllers.

Therefore, a true separation of the Model, the View, and the Controller can be achieved. Each platform is not allowed to write their own business logic or model handling unless it is platform specific, which is very rare for most cross-platform apps. The blackbox should handle all the business logic, models, error handling, and navigation. It can achieve this by providing interfaces for different platforms to implement.

The Shortcomings of J2ObjC

As with most things that are designed to make a developer’s life easier, J2ObjC is not 100% perfect. The initial setup takes a lot of time, patience, and trial and error, and you can expect a few snags in the process.

Running the J2ObjC Build Script

One of the biggest challenges is getting xcode to run the J2ObjC build script without conflicting with other dependencies like cocoa pods. In order to get all of the class paths to be recognized when converted to ObjC, you have to search through the issues logged in github to find the cause.

Using the Generated Code

Another major issue is actually using the generated code. The code generated by J2ObjC uses custom classes that match the functionality available in Java. This can take some adjustment for iOS developers because they are used to working with native objects like NSArray or NSDictionary.

Consequently, the iOS developers must either learn how to use the custom object instead of the native objects, or figure out how to convert the custom objects to native objects. Converting the custom objects to native objects is not well documented, and it can take a lot of time to find a good solution.

Understanding the New Workflow

Many iOS developers may find the workflow confusing and restrictive, because they are no longer required to write the business logic, model handling, error handling, or navigation. The only thing the iOS developers need to do is provide the views, view controllers, and platform specific interface implementations and call the functions exposed to them. This allows developers on each platform to focus on UI rather than logic.

Although J2ObjC has a few issues with it, it is appropriate for most cross-platform projects. It is an ideal solution if you don’t want to duplicate the business logic and model handling. It’s also a good way to enforce the MVC pattern. The issues with getting started, integrating the generated code, and understanding the new workflow may seem like deterrents, but if you are willing to overcome them you can improve your cross-platform development process, make fewer errors, and fix errors more quickly.