Is Google eyeing Apple’s Swift language as a possible “first-class citizen” on Android?
It’s a good question, but here’s a better one: How hard would it be for Google to make Swift a viable choice on Android for developers and users? Plus, why would Google undertake such a lengthy and arduous move in the first place?
Here are four reasons why Swift on Android is a tough proposition, as well as the obstacles Google and its developer community would face in making it happen.
Contents
It would be difficult on Android’s part
Switching Android to Swift is nontrivial in the same way moving an extended family cross-country is nontrivial. First, Google would have to develop a Swift runtime for Android and deliver it side by side with the existing Java-powered runtime. Google has already done something along these lines — swapping the Dalvik VM for the faster ART runtime — but both were Java-based, so the job was a lot easier.
Even harder would be if Swift were to become the preferred language for Android. Moving to Swift would have to be done incrementally — first with both Swift and Java VMs side by side, then with Swift-only over time. That kind of transition takes years, especially in an ecosystem as well-trafficked and sprawling as Android’s.
Apple faces a similar issue, since it’s needed to keep Swift and Objective-C ecosystems in place side by side for two years now. That’s in a system where Apple controls everything. Imagine the complexities involved with Android, where the carriers, handset manufacturers, and Google are in a three-way tug-of-war.
Finally, this move would require the participation of Android developers — many of whom might not want to come along for the ride.
It would be difficult on the developers’ part
In addition to Google adding Swift to Android, developers would have to pick up on Swift.
Java was chosen for Android in big part to take advantage of the mass of existing Java development resources and programmer expertise. New and relatively untested, Swift doesn’t have the same momentum.
Swift is gaining traction at a healthy pace, though. Developers are clearly getting enthused (as well as IBM), and in April it even cracked the top 20 of the Tiobe languages index (currently at No. 15).
Still, getting developers to ditch a language they know and adopt an entirely new one is no small task — another reason why Swift and Java would have to co-exist in Android for years.
It would shift dependencies from Oracle to Apple
Right now, Android is planning to use OpenJDK rather than Oracle’s Java, if for no other reason than to put more distance between the two companies after Oracle’s ugly Android lawsuit. But there’s little question Oracle still controls the future direction of Java.
Swift, likewise, is Apple’s baby, although it’s been made into an open source project — which is expected to lead to major cross-platform adoption in the long run. Google adopting Swift as a long-term pivot makes sense if the plan is to reduce dependency on a platform and a runtime that’s fraught with proprietary concerns.
But again, there’s little question Swift’s direction is influenced chiefly by Apple. It isn’t likely Google wants to make itself dependent, even if only indirectly, on a key competitor — not even if the technology in question is open source. In theory, Google could fork Swift and take control of the fork, but it would be stuck with the maintenance and management overhead of an entire language.
Switching to Go would be more in line with Google’s thinking
If Google really wants to disassociate itself with third-party languages and runtimes, it wouldn’t ditch Java for Swift. It would make more sense to turn to the language, runtime, and toolchain built in-house: Go, also know as Golang.
Go can already be used for mobile development. Versions 1.5 and up of Golang provided support for both Android and iOS, and with the “app” package, devs can write all-Go apps for both platforms. That said, mobile support for Go is stillclassified as experimental.
If Google intended to make Go or Swift into a complement to Java on Android — let alone replace it — a lot more work would be in order. It’s a safe bet that Android will remain ensconced on Java for a long time to come.
[Source:- Javaworld]
