Calendar Timer for iOS 8 Coming Soon!

Martin Odersky, Creator of Scala, on Swift

In an article dated 2014-Sep-05, the creator of Scala, Martin Odersky, expresses that Swift is an evolution of Objective-C in the way that Scala is an evolution of Java. This is the way I see things, too. As of today, apps written in Swift can now be submitted to the App Store. I’m also taking a look at Node.js, also mentioned in the article, for server development and one of my next posts will discuss functional programming in JavaScript.

InfoWorld: You mentioned Swift. What’s your take or perspective on Swift, which Apple just introduced, and on another language that’s becoming popular, Node.js?

Odersky: You could say that Swift related to Objective-C is a little bit like Scala related to Java. It runs on the Apple platform, but it’s a higher level, a more functionally inspired language than the standard language. In fact, if you look at it, it borrows a lot of features from Scala. In a sense, it’s a validation of what Scala does. To see that reflected in Swift shows that we must have done something right here.

Node.js is an interesting platform because it leverages JavaScript on the server, and it has essentially the reactive programming model, the event-based reactive programming model. What we do with Scala and the Typesafe platform — that would be Akka and Play — is very similar, so we also leveraged the reactive programming model, very much so, just like Node does it, but we do that in a setting that is strongly typed.


Creating a new project for Principles of Reactive Programming (on Coursera) using IntelliJ. The JDK is the latest from Oracle for Java 7. In general for OS X, the JDKs from Oracle live in


One of the earliest exercises is with functional random generators in Scala. For expressions can serve as a compact method for implementing them. The example that I’ve been working with is creating a boolean generator based on a random integer generator. In this use case, the for expression expands to a map expression.

  val booleans = for (x <- integers) yield x > 0
  val booleans = integers map { x => x > 0 }

The map here is defined in the generator as

  def map[S](f: T => S): Generator[S] = new Generator[S] {
    def generate = f(self.generate)

Therefore, the new generator’s generate evaluates the closure

  f = { x => x > 0 }

with a freshly generated random integer to yield a new boolean.

What’s so brilliant about this simple example is not the compactness of the for expression, but how the for expression is using the newly defined map in the generator to create a new generator, along with a corresponding new generate method, using the generate method of the outer generator via self.generate. For expressions serve as syntactic sugar and, in general, can be decomposed into some combination of map, flatMap, and withFilter.

The full example is listed below.

Shared by Daniel Zhang (張道博).

MVVM in Swift: Part 4

by Daniel Zhang (張道博)

This is a continuation of replacing Objective-C with Swift in ReactiveCocoa, Part 3.

MVVM stands for Model-View-ViewModel. It is a software design architecture comparable to MVC (Model-View-Controller). The clearest description I’ve encountered is the description for the ReactiveViewModel project on GitHub.

In the tutorial app, there are Model and ViewModel services. They are both declared as protocols in the example project. This provides a way of using their interfaces without being dependent on a particular implementation that could be in Objective-C or Swift.

Model Services

The Model contains a definition of the services that are available for searching on Flickr. The protocol RWTFlickrSearch requires the flickrSearchSignal method that passes search strings to the Flickr API with the results being returned as a new stream. I described my implementation of these services in Swift in my previous post.

ViewModel Services

I also wrote the ViewModel services in Swift. They are a concrete implementation of the protocol RWTViewModelServices. At the level of the ViewModel, the services provide the connection to the Model layer by returning a concrete RWTFlickrSearch implementation from the Model layer.


MVVM, as an app design pattern, encapsulates the state of the app within the ViewModel while data sources, internal and external, are managed through the Model layer. The View layer provides the rendering of the ViewModel using tools such as view controllers and views in UIKit.

The results of successful searching using the Flickr API are shown in the screenshots. The table view is still in progress and there is a little more to do before it will actually display the photos. This is covered in part 2 of the tutorial.

ReactiveCocoa is being rewritten for Swift but they can be used together now, using the Objective-C version of ReactiveCocoa, through Swift and Objective-C interoperability.

MVVM in Swift Repository on GitHub

MVVM in Swift: Part 3

by Daniel Zhang (張道博)

This is a continuation of my translating the MVVM Tutorial with ReactiveCocoa: Part 1/2 into Swift.

I performed a relatively complex conversion of the Flickr service implementation in Swift to obtain equivalent functionality. This was done with ReactiveCocoa 2.1.8 in Objective-C, installed through CocoaPods, using Xcode 6 Beta 5.

This code, along with the rest of the app in the tutorial, performs searches on Flickr. The search logic is wrapped up such that the request and disposal of the request are a unit that result in a single result stream. This is a mostly functional approach to performing an API request. The only side effect that occurs is the use of the NSMutableSet to store the request object.

Original Objective-C Version

Swift Translation

Some key points I observed during this translation of Objective-C to Swift are listed here.

  • Classes in Swift that will be used with Objective-C should be annotated with @objc.
  • Class methods, previously marked with + in Objective-C, use the class keyword in front of func.
  • Objective-C types can be obtained through downcasting using as, e.g. aSwiftDictionary as NSDictionary.
  • Unwrapping with ! and specifying optionals with ? are a necessary part of translation.
  • Nested messages/blocks are analogous to chained calls using dot notation.
  • AnyObject takes the place of id.
  • References to protocol implementations can be referred to directly. There is no need for (<id> ProtocolName) casting as with Objective-C.
  • A reference to the protocol itself is obtained through Protocol.self.
  • Selectors are passed as Swift Strings for methods requiring a selector.
  • Closure declarations and definitions can be directly mapped to blocks but requires a healthy amount of practice.
    • Closure arguments can have a type but they can also work without a written type.
  • Internal and external names for method arguments are possible using the form:
    • func myFunc(externalName internalName:Type, externalName internalName:Type)
    • This is useful for translating Objective-C methods corresponding to this form.
    • The internal name is available to the function whereas the external name is used when calling the function.
    • The use of internal names and external names for function parameters takes some getting used to. For example, an init from a class like UIBarButtonItem looks like

          init(barButtonSystemItem systemItem: UIBarButtonSystemItem, target: AnyObject?, action: Selector)

      and can be called using the expression

          UIBarButtonItem(barButtonSystemItem: .FixedSpace, target: nil, action: nil)
      Note how systemItem is not used externally but would be available as a symbol internally to the init.
  • Type inferencing is great and is responsible for a large amount of the reduction in required code.

My experience translating this code has taught me that going back and forth between Objective-C and Swift is a realistic scenario and greatly facilitated by hints in Xcode and opens up exciting new possibilities for mixing the languages in Mac/iOS apps.

MVVM in Swift Repository on GitHub