How to Use Apple Swift to Make an Android App

Since WWDC (Apple’s Worldwide Developers Conference) and Apple’s announcement of Swift, I’ve become increasingly impressed with the new language. For iOS developers, it’s a no-brainer to use Swift instead of Objective-C. Writing code is easier and faster than ever with Swift, making you more productive. And being able to write code and test it more efficiently will ultimately save developers like us time and cost.

Can you use Apple Swift to create cross-platform apps?

The obvious benefits of Swift got me thinking: Could you use Swift to create an Android app? And, could you use Swift to write an app once for iOS and Android at the same time?

At ArcTouch, our clients regularly ask us to create both the iOS and Android version of their app. Where possible (and a good fit for the type of app), we like to use a unified code-base to bring cross-platform apps to market faster. We’ve had great success to date using Xamarin and HTML5, and if we can do the same with Swift, we’d have another great option for our customers.

After WWDC, we created a skunkworks team (led by two of our app developers, Diego Santiviago and Felipe Homma) to try building a simple app that works on both iOS and Android, written in Swift. And we succeeded with a proof-of-concept calculator app. Here’s how we did it.

Related Posts:

Java, not Swift, will be the universal language for cross-platform mobile app development

Picking an IDE to start

The first challenge was to determine which IDE (integrated development environment) to use. We didn’t want to build one from scratch. And we couldn’t plug Swift code directly into Android Studio. So we started with Xcode 6. We think the best approach for a future commercial solution is to build a compiler for Swift code that you’d plug into Xcode, and that compiler would translate Swift into ready-to-run Java byte-code and an Android Package (APK) ready to install.

For the sake of our proof of concept, we took a shortcut.

Compiling to Java Source Code from Swift

Our best course of action to get something working quickly was to take Swift code and compile it into Java source code — and then take it into the Android development environment to finish building it into an installable app. So we started in Xcode, where we wrote the Swift code. Then we tested it, including running it on an iPhone or in the iPhone Simulator, and ran a custom compiler that parsed the Swift code and output Java source code (adjusting any necessary syntax, and substituting appropriate Android calls for any iOS native ones). Then we moved it into Android Studio to finish the build process and produced the Android APK.

The downside of using this approach: You need both Xcode and Android Studio on your desktop, along with our tool chain to get from one to the other. But you still see a tremendous efficiency gain by being able to use the same base code — and you get the overall benefits of using Swift.

Developing a Single UI Layer

Another challenge in building our proof of concept was the need to have a UI abstraction or conversion layer, so you can see something on screen. In iOS, you can create the user interface by writing code that displays UI features, or you can use Interface Builder or Storyboards. With Android, it’s similar: You can write custom code or define the UI by using XML or a visual layout tool.

But how do you have a single UI that translates? Tools like Xamarin allow you to take business logic and carry it over across platforms, saving a lot time, but still require the development of two native UIs. (Side note: Xamarin recently introduced Xamarin.Forms, which allows developers to create their UI once. We like this approach for apps that provide the same experience regardless of platform.)

With many cross-platform apps, you would want to take advantage of UI features specific to Android and iOS — but for this this proof of concept, we wanted to develop the UI for Android within Swift. And with our calculator, we were able to do just that, using native iOS UI calls made in Swift, then translating them to corresponding Android UI calls. It all worked beautifully.

More exploration

We’re excited about the proof of concept and the problem our engineers solved, but there’s more work to be done if we’re going to use this type of compiler commercially. We’d love to know what you think: Would you want to write apps for Android, or for both iOS and Android at the same time, using Swift? Comment below or tweet us.