Swift API vs ObjectiveC API


Is there a particular reason that the MOE libraries target the ObjectiveC iOS API instead of the Swift API?

The Swift one is more modern and has more Java-like naming after all.


the reason is mostly historical: when we started working on MOE (or more precisely, its predecessor “Migeran for iOS”), Swift did not exist yet. Nor did the attributes that were added by Apple to the Objective-C header files to support the Swift -> ObjC bridge.

Our goal with Nat/J and the generator was to work with any ObjC code thrown at it.

That said, we are thinking about creating a new version of the bindings that will follow the Swift naming conventions. This will require changes to the binding generator to support the new ObjC attributes + change the code generator to generate more “Swifty” bindings + changes in the Nat/J runtime to support e.g. Swift like constructors.

Best Regards,


Hi Gergely,

That would definitely be nice. Similarly, do you think any effort would be put into generating the bindings in Kotlin in addition to Java? The main benefit for that would be making use of named arguments, which would definitely cut down on the length of method names.


1 Like

This will definitely be a must have!
Since I released a very popular app on the iTunes App store which has been built with Multi-OS-Engine, I’m afraid of not being able to make any updates in the future when framework by framework will steadily switch to swift.

There have already been some frameworks dropping the support for objective-c, since swift became so popular. Where does your team need help so far? It seems like your a bit overstrained with the changes which have to be made for such a big change.

Best regards!


good to hear that! Any plan when this will kick start?


Hi Gergely,
are there any news on that? I got an app in the appstore and I am really afraid of not being able to update it anymore because swift becomes more and more a must have. There are no new libraries supporting objective-c and many are dropping support already.

1 Like

It is a big problem indeed, but you still have two options:
1- the Swift library annotates its classes and functions with @objc -> you can embed the lib in an ObjectiveC project, it will generate a .h file with the appropriate signatures. Then you import this file in your nbc file.
2- the Swift library is not compatible with ObjectiveC -> you can write yourself a Swift “facade” with functions that will do what you need, and you annotate these functions with @objc so you can generate the .h file I’m talking about in solution 1.
Cumbersome but I had it working with Auth0 for example. Not the solution we would like though, but I suppose MOE is a dead project now.