Swift-X tool to cross compile Swift and Objective-C(++) code to Android

Digia also recently changed the license to LGPL3, which has some implications in embedded platforms, like mobiles.

Personally, I am the opinion when one gets money from others work, it should pay back in some form.

Most well-known approaches to cross-platform mobile app development have left me dissatisfied. The root problem is the required bridging overhead between the cross-platform code and the platform's native runtime (the ObjC runtime on iOS; Dalvik/ART on Android). Using C/C++ for the cross-platform code is the lowest overhead approach on iOS, but it's suboptimal on Android.

So why does this matter in practice? A few reasons:

Multiple coexisting memory management systems: In general, my understanding is that a garbage collector behaves best when all memory, or very near all of it, is under the collector's control. My fuzzy intuition is that the least optimal situation is two coexisting garbage collectors, e.g. Xamarin.Android or a JavaScript engine other than Rhino on Android. But mixing a garbage collector with reference counting or manual memory management, such as with native code on Android or RoboVM or Xamarin.iOS, also seems to be suboptimal. If a significant amount of memory is allocated outside the scope of the GC, then the GC doesn't have as much information with which to intelligently decide when and how much to collect. Also, in hybrid systems like the ones being discussed here, objects under the GC's control sometimes have to be pinned so they can be accessed by the outside code; this interferes with copying or compacting collectors.

More information:

http://developer.android.com/training/articles/perf-tips.htm... (see the section "Use Native Methods Carefully")

http://developer.xamarin.com/guides/android/advanced_topics/...

http://developer.xamarin.com/guides/cross-platform/applicati...

http://www.virtualdub.org/blog/pivot/entry.php?id=360

Basically, having two coexisting memory management systems is messy. I'd rather avoid it.

Bridging adds overhead: Consider the cost of copying strings between the cross-platform component and the native string implementation, or mapping an array of cross-platform objects to a native array of wrappers so the objects can be used from UI code. There's always some overhead for marshaling. Maybe it's not much in practice, and I'm just being anal. But just knowing that it's there bothers me. The best way to keep software fast is simply to minimize the amount of pointless crap it has to do. So it seems best to minimize indirection and overhead by having just one implementation of strings, collections, etc.

Heavy use of external functions obstructs whole-program optimization: The Android performance tips document referenced above mentions this in the context of JNI methods and JIT compilation. I imagine the same applies to ART's AOT compilation, since the native methods are still opaque to the compiler, unlike the Dex bytecode. And for combinations such as Xamarin.Android or a JS engine other than Rhino on Android, there are two JIT compilers working suboptimally, because neither of them can see into the other's world.

Hybrid setups thwart obfuscation on Android: It's common for Android developers to use ProGuard (or its commercial big brother DexGuard) to shrink, obfuscate, and optimize their apps. Having a significant non-Java component in the app seriously limits the effectiveness of this practice.

Hybrid setups limit the usefulness of debuggers: If you're mixing Java and native code on Android, or using Xamarin, RoboVM, or a JavaScript engine, can you get a single useful stack trace across the platform-specific and cross-platform components when something goes wrong, as it inevitably will?

So are we doomed to rewrite the same common logic in Objective-C for iOS, Java for Android, JavaScript for client-side web apps, and (C#|JavaScript|C++) for Windows Phone, if we want that code to integrate well with the host platform? Luckily, no.

RubyMotion has the right idea, I think, and there's apparently an Android version on the way, but nothing for Windows Phone/WinRT or client-side web apps.

Another option is to write common code in Java, then use J2ObjC for iOS, IKVM.NET for Windows and Windows Phone, and GWT for the Web. Some teams within Google are doing this (minus the part about IKVM.net on Windows, AFAIK), including the team that developed J2ObjC. This approach certainly doesn't have the polish of a commercial product like RubyMotion or the Xamarin tools. But on the other hand, all the tools are free, so this should appeal to cash-strapped indie developers. One thing I don't like about J2ObjC is that the JRE emulation library has a larger footprint than I'd like. On a more aesthetic level, I don't like the fact that this approach takes Java, which is designed to be a platform unto itself, and tries to make it work on other host platforms.

And then there's RemObjects Elements (http://www.remobjects.com/elements/), a compiler toolchain with two language front-ends and three platform back-ends. On the language side, we have a choice of C# or Oxygene (a language based on Object Pascal). Either of these languages can be compiled to .NET bytecode, JVM bytecode (and from there to Dalvik bytecode for Android), or native code for the Objective-C runtime. (Note that the C# language front-end only provides the language; it doesn't attempt to bring the .NET class library to the other platforms.) Each platform back-end uses the target platform's preferred memory management system. That means GC for .NET and Java, and automatic reference counting for the Objective-C runtime. There's a cross-platform standard library called Sugar for things like collections, date/time manipulation, making HTTP requests, and XML, but emphatically not UI. Sugar has a very small footprint; in fact, many Sugar classes and methods are mapped to their platform-provided counterparts at compile time. Like the Xamarin suite, RemObjects C# and Oxygene are commercial products, but the pricing is very reasonable. I'm looking forward to trying this toolchain on a real project, probably using the C# front-end.

I know this has been a long comment; it covers a topic I've been thinking about a lot for more than a year. I know a lot of developers will just accept the added complexity and inefficiency I've described, for the sake of getting things done, i.e. accepting complexity and runtime inefficiency in exchange for developer efficiency. But then, added complexity translates to developer inefficiency at some point, especially when something goes wrong. And inflicting runtime inefficiency feels wrong when the machines in question aren't ours. That is, the trade-off between programmer time and machine time is different for client-side apps than for server-side apps. Luckily, it appears we can have the best of all worlds, especially with the RemObjects products, at least if we're willing and able to pay for excellent tools and accept that some of those tools will be closed-source.

(I guess readers will have to trust that this whole comment isn't actually a marketing piece for RemObjects. I just discovered the RemObjects products last night, and they don't seem to be well known, so I'm excited about them.)

This tool appears to fix the problem with the NDK make tool not recognizing .m files. I worked around this once by naming them with the .c extension and using compiler flags to set the language to Objective-C. Another time, I think I hacked the makefiles, but that was extremely painful.

Of course, there's apportable (http://www.apportable.com/open_source), their low-level stuff (runtime, Foundation) is open-source.