Last Thursday JP Simard gave the first talk of the Swift Language User Group (#SLUG) in Palo Alto. He started with a short intro recapping what is publicly known about Swift, then detailed what he has learned about Swift internals so far, such as introspection, Xcode tooling (including dynamic Swift header generation), followed by a healthy round of Q&A.

---

Swift recap (00:00)

Swift was created by Chris Lattner and has been in development for four years. There are a few cautions to using Swift currently. What’s been released is an incomplete version of the language paired with a buggy compiler, IDE, and OS. Furthermore, the subject matter isn’t fully understood yet.

New Features in Swift (04:56)

Type safety & inference (07:10)

Swift has stricter type safety than Objective-C, so the compiler will stop you as soon as possible. Type inference in Swift allows for fewer explicit types, less verbosity and more space in your code (i.e. more descriptive method names). See slides for example code.

Closures (10:41)

Closures are very similar to Objective-C blocks. They use the same block-based APIs from Apple frameworks. They are less verbose and almost interchangeable with functions. See slides for example code.

Tuples (11:36)

Tuples allow you to group variables together, including variables of different types. This allows you to track multiple variables that make more sense grouped together (i.e. HTTP status code number and its message).

Super-enums (12:20)

Enums have lots of more functionality that before. You can include functions within the enums instead of writing multiple methods outside of them as in Objective-C.

Functional programming (13:10)

With functional programming, you have operations that can be performed on a collection of items (such as map, filter, and reduce). Through nicer syntax this allows for better readability and streamlined code. There are also some performance considerations. Sample code on the accompanying slide provides examples of functional programming, as well as type inference, closure syntax, and generics. Playgrounds (like workspaces for Xcode 6) are good for providing snippets of code for examples, as opposed to creating lots of files for one demonstration app.

Generics (15:09)

Generics allow for “type agnostic methods”. For example, you can specify that an array will contain a certain type or that your comparison method that will take in any type but still keep the one type.

Asterisks? (15:49)

Swift no longer uses asterisks to refer to pointers, although it does have types passed reference and types passed by values. You can also interact with APIs from C.

DEMO #1 (18:10)

Swift in practice: The first demo shows how to build a straightforward app that stores usernames and hashes passwords. In Swift, you can create a user class, which is all that is necessary for a compilable Swift project. You can also add properties without specifying types, as an example of type inference. This app also interacted with C API, includes overwritten custom getters and setters, and imported values.

Swift Internals (25:36)

So how it does it work when compiled in an app? Swift objects are valid Objective-C objects but without methods or properties! They have ivars and functions to edit them – getters and setters. Swift methods are listed in a vtable under the class definition, and Swift properties are ivars with Swift methods. Furthermore, ivars have no type encoding, so when you try to find their type, the only thing returned is null.

DEMO #2: Dynamic introspection in Swift (28:13)

To introspect Swift objects, you can use reflect, which produces a mirror for any value. Mirror is a protocol that returns a value that, if stored, would be very difficult to access later. Calling count on the mirror provides the number of logical children of the class, or the number of its properties. You can then call subscript on it to access that property or call some other methods. This demo provides examples of these methods with different types, including optionals.

Swift Tooling (Xcode, Clang, etc.) (33:11)

Clang actually knows nothing about Swift. Instead, there is a Swift compiler that talks to Clang through XPC. There are a series of tools that sit before Clang and take care of Swift compilation and interaction, including syntax highlighting. This provides better architecture. Some useful links to look at include llvm.org and clang.llvm.org.

DEMO #3: Reverse-engineering the Swift tooling (35:46)

In this demo, we found header files and its enforced foundation. There are documentation comments along with the properties and so Xcode calls something like the Swift IDE test to generate the equivalent Swift header. You can use Objective-C classes, objects, and frameworks and call them using a Swift-like syntax that’s automatically generated from the Objective-C headers. You can find the tool to generate the Swift header without using Xcode, which is useful if you want to do anything that will interact between Swift and Objective-C. An equivalent way of using the init method uses the same tools and processes as Xcode to generate the same thing. This demo also shows Jazzy, an ObjC/Swift documentation tool built by Realm to produce Swift headers.

Resources (Apple & elsewhere) (42:16)

• Official Swift website
• Swift Programming Language Book
• WWDC Videos & Code
• Xcode 6
• Jay Freeman’s AltConf talk: Debugging your (Swift) apps with Cycript
• ObjC/Swift doc generator Jazzy
• Evan Swick: Inside Swift
• #Swift on StackOverflow

Q&A with the help of the crowd (43:49)

Q: Were there anonymous functions being passed as arguments?
JP: Anonymous functions are basically just closures, one example of which was the sort function that takes in both the object to sort and an anonymous function to sort it by.

Q: Are generics compiled into the type or is it a run time mechanism?
JP: It occurs during runtime.

Q: Will there be automated tools to convert existing Xcode or an Objective-C program into Swift?
JP: I don’t think it’s necessarily a very pressing matter. I think it will be very difficult for anyone outside of Apple to build a tool like that mostly because you would need access to the entire Swift compiling stack. I would venture a guess that Apple will eventually produce a tool for this when people start to really migrate away from Objective-C. You can also currently use Objective-C code from Swift.

Q: Can we use Swift within our existing Objective-C programs?
JP: Yes, you can intermix Swift and Objective-C. See articles at Apple about this.

Q: Have you seen any API differences between Swift and Objective-C in documentation so far?
JP: Yes, many of the API changes Apple announced were meant to better support Swift. There are certain method interfaces that won’t have equivalence in Swift, for example the NSNotification center and the add notification block don’t have a Swift equivalent. I think it’s because of the way they named that method. Another case is any variatic argument functions or methods like ellipses, the three dots, which don’t convert to Swift.

Q: Have you done any comparisons or benchmarking on the performance of Swift compared to Objective-C? Can you comment about the compile time of Swift?
JP: We have done only minor profiling, which is still a work in progress. I think that whatever profiling that you see isn’t exactly going to be representative of real life usage. In terms of compile time I haven’t seen a major difference, but I have only worked with very small examples. When people start porting large apps into Swift, then you’ll be able to see the performance ramifications and have informative benchmarks on that.

Q: The Objective-C method dispatch scheme is different from vtables, so is Swift binding to Objective-C objects or Swift objects?
JP: It uses some hybrid of the fully dynamic ObjC message send and the not so dynamic vtable approach. From what I’ve seen, if the vtable can be accessed first then it will be, then the more dynamic approach of calling the message dispatch will be used.

Q: Are protocols essentially pointers to vtables?
JP: I haven’t looked into protocols, so I couldn’t tell you if they’re implemented with the vtables as well.

Q: What are some of the most common errors or the most common gotchas you’ve run into? Any with problems type inference?
JP: I haven’t had much issue with type inference. It’s been tricky trying to introspect all the possible types. In terms of writing Swift apps, probably the biggest problem is getting used to the syntax. A big problem is more in the difficult of fully understanding how to call certain things because the headers from the frameworks you use are auto-generated.
Person 2: Type inference does not auto-cast, so you should be careful i.e. in accepting user input. There is also no data hiding, so no way to declare anything private.

Q: Swift properties seem to be conceptually different than Objective-C properties.
JP: The main difference is that Swift properties look like ivars in Objective-C but also have functions associated with modifying them. You can get Swift properties from the ObjC method asking for its ivars.

Q: How does Swift connect with UI?
JP: Swift looks pretty similar, almost as if you’re building a UIViewController using Javascript. Ultimately, it almost reads like ObjC, so if you’re familiar with APIs and the frameworks then there shouldn’t be much of a problem adapting. Storyboards are the exact same format.

Q: Is there any way to declare variables and methods as private?
JP: No, although Apple has unofficially said that’s a high priority for the summer. You can technically generate Swift headers from ObjC code so that’s how would keep implementation secret.

Q: Has Apple said when they think Swift will be ready?
JP: I’m not the best person to speculate, but I think it will take more time than iOS 8 ships. They will try to make that deadline though.

Q: What iOS support will Swift have?
JP: Swift will support iOS 7 and up.

Q: How far do you think Swift will go?
JP: I see Swift being very popular but I don’t see Apple open sourcing it entirely and I think that’s a pretty big deterrent for being on non-Apple platforms.
Person 2: I think it’s going to be bigger than ObjC very soon in terms of community size, sample, etc.

---