Does Swift Compile to Native Code

Does Swift compile to native code?

Yes, it compiles to machine language by way of LLVM Bitcode and, as @connor said, runs on top of the Objective-C runtime.

Where does SWIFT ABI come into picture?

There is a nice description of the role of ABI in ABI Stability Manifesto.

In summary, ABI is about the communication layer between compiled application modules during linking and runtime. For example the application and a compiled static library. Or the application and the standard library (Swift runtime).

ABI answers the questions like:

  • how is a function stored? how is the name stored? how are its parameters stored? How are default parameter values stored? how are attributes (e.g. availability) stored?, how are generics stored? Where do you find the machine instructions for a function?

  • how to put parameters on the calling stack before starting executing function machine instructions (that is, how to pass parameters and self to a function?). This is what the calling conventions is.

If you have two versions of a Swift compiler and each uses a different format, they cannot call each other because they don't know how to interpret the information in the files. That's why ABI stability is needed. It stabilizes the way code is stored. Note that machine instructions are the body of functions but all the other metadata has to be stored too.

Assembly has no role in ABI stability. Assembly is just another low level programming language which is not used in Swift.

Is Kotlin Multi-platform Mobile code different from compiled Swift code on iOS platform?

The main difference is that Kotlin code compiled for iOS brings along the Kotlin/Native runtime which establishes the Kotlin/Native memory model that aims for safe concurrency and immutability of global objects, and also provides its own garbage collector for Kotlin objects.

Otherwise, code compiled with Kotlin/Native indeed has two-way interoperability with Swift, as normally the Kotlin binary that you use on iOS is an Objective-C framework that you can import in one project with Swift.

How does Apple's Swift Playgrounds app for iPad execute code?

Neither of Apple's general-audience nor developer marketing materials don't say much more than that Swift Playgrounds is "real code". But it's possible to verify for yourself (or at least find some strong evidence for) that Swift Playgrounds does indeed run the full compiler toolchain and produce native arm64 code.

Tip: if you download an App Store app in iTunes on your Mac (or Windows box, too, I guess?), you can find the corresponding .ipa file in your local filesystem. Unless you're a beer person, IPAs are just zip archives containing the app bundle that gets installed onto an iOS device when you sync, so you can unzip them with your favorite utility (including the builtin Archive Utility in macOS, or the unzip command line tool) and poke around a bit at their inner workings.

If you do this with Swift Playgrounds, you'll find a nearly complete replica of the SDKs and toolchains found inside Xcode, including some files specific to linking binaries for the arm64 architecture. (You won't find any command line binaries for the compiler & related tools, but there's nothing new about running parts of the LLVM toolchain as libraries.) You can also find some evidence of arm64 as a compiler-host architecture in the Swift compiler's open source code.

So, yes — short of official confirmation from Apple, it looks like Swift Playgrounds compiles and runs native code on iOS devices. (If you think about it a bit, it doesn't make much sense to do it otherwise — running Swift code in some sort of interpreted/emulated environment would kill performance. And probably make Apple's stated goal of providing access to the entire iOS toolkit incredibly difficult.)

And no, third-party apps still can't do that. Since 2010 it's been possible for third party apps to use tools that provide embedded scripting environments — game engines use this to speed up game design & development, and other apps provide coding environments for Python and Lua, for example. But you can probably imagine that allowing third-party apps to compile and run native code could be a security nightmare...

Does Objective-C compile to native code or byte-code?

Objective-C is compiled to native code by either GCC or LLVM[*]. You can compile ObjC programs on Linux (the generic GCC will happily support ObjC, though it uses a different runtime library than either of the Apple ones). For a cross-platform API similar to Cocoa (i.e. derived from Cocoa) which will happily work on Linux and let you port some code between OS X and Linux, check out GNUstep: http://www.gnustep.org

[*]In fact, LLVM internally compiles the Objective-C to an internal bitcode representation, then to code for the target machine, so perhaps the answer is "both"…

Can swift code be used in Codename One native code instead of Objective-C

Yes and no. You can probably compile Swift code to a static library today (.a file) and just use that like any static lib where the Objective-C code just acts as a bridge.

Using Swift directly is problematic due to several factors:

  • Currently we are still using an older version of xcode when building, we made an attempt at migrating to the latest but had a setback. We'll migrate hopefully before 3.5 comes out, if not then shortly after.

    Swift requires a relatively new version of xcode so until we do that embedding Swift code will be problematic.

  • Swift assumes ARC. This is something we tried to integrate with the GC but at this time it doesn't really work well.

  • We need to generate Swift stubs as an option, this is problematic as say you have existing cn1lib or native interface that relies on Objective-C it might create a conflict.

But lets back track a bit. Swift is a huge advantage over Objective-C which is pretty old by now. But it doesn't have any major advantages for Codename One developers...

  • It isn't faster as Codename One translates to C which is faster than both Swift and Objective-C

  • It won't make the code much cleaner, if you have a lot of code in your native interfaces then you are doing something wrong. Most of your code is in Java anyway, you can debate the merits of Java vs. Swift but if you are using Codename One then you pretty much picked Java.

  • If you need to use an app written in Swift you can package it as a static library.

So there is really no real use case for Swift in Codename One at this time.

Is it possible to code in Swift and deploy to real life devices on Windows?

Right now Swift is only for MacOS, iOS and linux devices available. While there are unofficial ports for windows like this one: Swift for Windows and Robert mentioned. The best solution right now to have the latest version of swift and run it is to buy either a Mac or an iOS device or an ubuntu device.

Compiling Swift for Android

While compiling Swift code for Android and even creating an .apk file is still far away from being easy, it is technically possible. From the way you're asking this question though, I expect you to be more on the "user space" of programming languages rather than knowing enough compiler details to get it working in a reasonable time and maintaining it with all the fast-paced changes happening.

So the more realistic answer for you probably is, that it's currently not possible.

But a lot of work is currently going on in the Swift community to drive support for more platforms forward in many ways, both to make building Swift very easy on more platforms and also to provide frameworks for creating UIs and integrating with the system properly (as Swift is just a programming language and there's more to an app than just programming logic).

Here are a few links for further reading:

  1. "Getting Started with Swift on Android" from the Swift GitHub repository
  2. Blog posts from Realm (2017) and Readdle (2018) explaining what's needed for Android apps
  3. Most viewed threads for the Android tag on the official Swift Forums
  4. "On the road to Swift 6" post, explaining how Swift will expand in the near future
  5. A community-driven port of UIKit for Android (work in progress)
  6. Ports of SwiftUI (OpenSwiftUI, Tokamak) that don't support Android yet, but might do later

I hope this gives a good overview about the current state of Swift for Android.



Related Topics



Leave a reply



Submit