View our current server-side Swift resources and read the deprecation announcement for Swift Sandbox and Package Catalog.


Recently, we released the IBM Swift Sandbox, a tool that allows anyone to write and run Swift code from their browser. One of the unique things about this tool is that all code submitted is running on Ubuntu, something that’s only possible now that Swift is open source. As the author of all of the initial samples in the sandbox, I’d like to give my perspective of using Swift in Linux.

One of the things I noticed right away was how much it felt exactly the same. Every language feature is in place and works just as you would expect. Most of the time it is not even noticeable that it is running on Linux except for the target name returned.

But that’s not too interesting; let’s talk about what’s different. Running on a GNU/Linux system as opposed to BSD/OS X, means that accessing lower level OS functions is done in a different matter. In many of the samples, we import Glibc, which is the the GNU C Library. While this is very similar to the Darwin module, there are some differences. The server.swift example highlights some of these differences as it is written to work both on OS X and Ubuntu.

 #if !os(Linux)
 // On OS X, FD_SETSIZE is 1024
 let FD_SETSIZE = Int32(1024) 

While there shouldn’t be anything possible in one library that’s not in the other, moving forward there will need to be considerations taken as to which system you want your code to run on.

While it is certainly possible to use C libraries in Swift, it is not always a seamless translation. One of the major design goals in Swift is avoiding the manual allocation of memory, and thus, in turn, avoiding having unmanaged pointers. However C programming uses both those things often, making some function calls a bit cumbersome.

 var size = sizeof (sockaddr_in)
 // Accept request and assign socket
 withUnsafeMutablePointers(&clientname,&size) { up1, up2 in
 var new = accept (s,

While it is certainly doable, it is a step back from the usually eloquent solutions that are done in Swift. There’s also the manner of how structures are translated. In Swift there are no fixed-length arrays, so when fd_set was imported, the fd_bits array was translated to a fixed-length tuple instead. This makes for some ugly setting and checking of the now huge fd_bits tuple, as seen in the fdSet functions.

switch intOffset {
 case 0: set.fds_bits.0 = set.fds_bits.0 | mask
 case 1: set.fds_bits.1 = set.fds_bits.1 | mask
 case 2: set.fds_bits.2 = set.fds_bits.2 | mask
 case 30: set.fds_bits.30 = set.fds_bits.30 | mask
 case 31: set.fds_bits.31 = set.fds_bits.31 | mask
 default: break

However, this isn’t really a critique of using the language itself. As support increases, there will be an explosion of libraries written that will take care of all this cumbersome work for you. I really enjoyed working on these new types of programs in Swift and I am excited to see more to follow. Stay tuned for more as we track and build a new world with Swift on the server.

Daniel Firsht, Swift Engineering at the IBM Mobile Innovation Lab

Join The Discussion

Your email address will not be published. Required fields are marked *