acb's technical journal


Cross-platform code sharing with Carthage made easy

Imagine for a moment that you're developing applications for both iOS and macOS (and perhaps an Apple Watch app as well) that share functionality: perhaps they're the desktop and mobile versions of the same product, or perhaps they're two distinct apps which nonetheless rely on some algorithmic secret sauce you developed. Both projects are fairly large and complex, and undergoing active development, and there is a substantial amount of code shared between both apps, which is also undergoing development.

The simple approach would be to have the shared code in both apps' Xcode projects, separately. Of course, the problem with this is that the common code is in two distinct codebases, both of which are being developed. Unless special effort is taken to keep it synchronised, it will diverge, and the technical debt you will end up with will be two increasingly different versions of code which does (mostly) the same thing, which would then take increasingly more effort to unify into one body of code.

A better approach would be to take the common code (making sure, first of all, that it is nicely modular and loosely coupled to whatever uses it) and move it to a separate codebase, where it can be maintained separately, and then to modify the apps which depend on it to import this codebase. There are several ways to do this: one could use a feature of the version control system, such as git submodules, or one could use an Xcode-specific dependency management system such as Cocoapods or Carthage. Here, I will be using Carthage; my choice of it is because it is more lightweight than Cocoapods (and does not require replacing your XCode Project with an encompassing Workspace under its management), and also higher-level than git submodules. In particular, this approach involves creating a Framework project, containing your shared code (and unit tests for it) and encapsulating it into a Framework, placing that in a git repository, and configure the projects for the apps that use this to import the framework using Carthage.

A cross-platform Framework

We need the Framework to be a cross-platform framework. For the sake of simplicity, we assume that the code for it is not going to contain any platform-specific code such as UI code (though if it does, it can be implemented with conditional compilation). As such, we create a macOS “Cocoa Framework“ project, which has two targets: a Framework target and a Tests target for unit tests. (Making it a macOS project means, for one, that the tests can run without launching the iOS Simulator.)

We add our code to the Framework target (structured into a hierarchy of groups as we see fit), and then add some tests to the testing target and run the tests to make sure that the code compiles and works. Once that's done, all we need to do is to make it cross-platform, and make it work properly with Carthage.

Making it cross-platform is relatively straightforward; firstly, we need to add the other targets to the build settings: we go to the Build Settings tab of the target, and change Supported Platforms. Xcode's interface for this is a single-choice drop-down menu, so we need to select “Other” and then add all the platforms we wish to support, including both simulator and device variants. The names for these devices are somewhat idiosyncratic (often having originated before the modern marketing name for the platform was settled), and are:

  • iphoneos and iphonesimulator for iOS.
  • watchos and watchsimulator for watchOS.
  • appletvos and appletvsimulator for tvOS.

The settings should look something like:

The framework project will also contain a header file, named typically name-of-framework.h, and declaring version number and string values. To make this cross-platform, we need to edit it slightly, replacing the line which reads:

#import <Cocoa/Cocoa.h>
#include "TargetConditionals.h"

#import <UIKit/UIKit.h>
#import <Cocoa/Cocoa.h>
(Adding other cases for tvOS and watchOS if needed.)

After this, we can try selecting an iOS device type from the target menu in the Xcode menu bar and building the framework for iOS; it should succeed, as it does for macOS.

Preparing it for Carthage

Next, we need to put our framework on Git in a form that is useful to Carthage. This is fairly straightforward, though there are a few things to keep in mind. The way Carthage works is as follows: when you run carthage update, it reads a list of Git repositories from the Cartfile, and for each one, checks it out to the Carthage/Checkouts directory, runs a build with xcodebuild, and puts the resulting Frameworks under Carthage/Build, organised by platform. From there onward, it is your responsibility to incorporate the built product into your Xcode project, as in the Carthage instructions.

The good news is that a git repository of an Xcode project that produces Frameworks is already almost in Carthage-ready form. There are only a few things that need to be attended to, which are:

  • As the Carthage documentation says, the scheme in the Framework project that builds the Framework needs to be shared. When the project is created, there is one scheme which is not shared. To share it, go to the Product | Scheme | Manage Schemes menu and check the “Shared” checkbox next to the scheme; like so:
  • Schemes are stored in separate files within the .xcodeproj directory which are, by default, not checked into git. You will need to add these with git add myproject.xcodeproj/xcshareddata/xcschemes/* and check them in.
  • Carthage uses git tags for versioning, which means that the repository containing the framework must have at least one tag consisting of a version number in the format v1.2. Make sure there is one and that it is pushed to the remote repository.
  • Keep in mind that Swift Frameworks have their own namespaces, with everything being private by default. What this means is that any functions, classes or similar in your code will not be visible to the app that imports your framework unless they've been marked public.
Additionally, you may wish to remove provisioning profile and code signing settings from the framework's project, as that will be taken care of when the framework's containing app is built. It's not required, but it makes the project neater.

Building the apps

Now that we have the a git repository containing our shared Framework, using it in either an iOS or macOS apps is straightforward; one just has to follow the Carthage instructions to add it to one's project.

best practices carthage howto ios macos modularity software engineering xcode 0


Loading macOS AudioUnit instruments in Swift

Recently, I have been experimenting with writing macOS code which loads and uses AudioUnit instruments. More specifically, code which does this not with Apple's DLSMusicDevice or AUMIDISynth but with commercially available software instruments, from vendors such as Native Instruments, KORG and Applied Acoustic Systems. The end goal is to write an app which can open any instruments installed on the system, allow the user to interact with their user interface and play MIDI notes on them, with the results going through an AudioUnit graph of its own choosing. Which sounds fairly straightforward, or one would think so.

Fortunately, Apple have provided their own code examples, in the form of AudioUnitV3Example, a suite containing sample units and hosting applications for both macOS and iOS. Unfortunately, though, while this works perfectly with Apple's own units which come with the OS, its operation with third-party instruments, particularly larger and more complex ones, is variable. While some seem to work perfectly (KORG's recreation of their M1 synthesizer, for example), others sometimes crash the hosting app at various stages (Native Instruments' plugins have tended to do so when changing presets), and at other times behave erratically.

This appears to be an artefact of the AudioUnit V3 API, or possibly the internal code which bridges V2 AudioUnits to the V3 API. Presumably, while it works well enough for simple components, some more complex ones may have issues with initialisation, memory management or something similar, causing them to malfunction. The fact that, while there exist many apps which host software instruments, most of them are old enough to predate the AudioUnit V3 API, suggests that (at least for now), the key to stability is to work with the AudioUnit V2 API. Apps doing so will be in good company, alongside the likes of Logic and Ableton Live, and because of this, as V3-based software instruments come out, there will be strong incentive to ensure that the adapters allowing them to run in the V2 API will be solid. Of course, eventually the bugs will be fixed, and then the V2 API will be retired, so even if using the AudioUnit V3 API be postponed, it should not be abandoned.

One problem with the V2 API, however, is that it is old. It dates back to the Carbon days of MacOS, and doesn't even touch the Objective C runtime, let alone Swift. Objects are referred to by opaque integer handles (which may or may not be pointers to undocumented structures); they are created, modified and manipulated with functions which take pointers to memory buffers and return numeric status codes. While the AudioUnit system itself is elegant (being a network of composable unit generators with standard interfaces for parameters and a standard API for composition), the same can't be said, at least these days, for the V2 API for dealing with it. One can access most of it in Swift (with small amounts of C code for some parts, such as initialising structures which have not been bridged to Swift), but the code is not particularly Swifty.

I have written an example project which allows the user to load and play AudioUnit instruments, playing MIDI notes through the computer keyboard and operating the instrument's GUI in a window. This program is written in a modular fashion, and can be built to operate using either the V2 or V3 API; the default is V2, as that's the one that currently works correctly. The two API interfaces are in interchangeable classes implementing a protocol named InstrumentHost.


audio audiounit macos swift 0


KFIndexBar, a zoomable index bar for collection views

The MPDluxe app, an iOS-based remote controller for the MPD music playing software, uses UICollectionViews to display the contents of directories; these are displayed in one vertically scrolling column on the narrow screen of the iPhone, or a number of columns, scrolling horizontally, on the iPad. Early versions of the app, which worked only on the iPhone, used a UITableView, which provided a convenient index bar down the right-hand side of the view, allowing the user to quickly navigate long directory listings by swiping down a line of headings (in this case, letters of the alphabet). UICollectionView is much more flexible than UITableView, but the downside of this is that conveniences such as index bars are not provided; if you need one, you have to implement it yourself. Thankfully, there exists at least one implementation (Ben Kreeger's BDKCollectionIndexView, a UIControl subclass you can add on top of your collection view). After moving to using UICollectionView, MPDluxe used this class.

The problem with one-level index bars is that they do not cope well with more fine-grained navigation. For example, imagine a long list of thousands of items (such as names) in alphabetical order; scrolling to the first letter gets you only so far. It would be good to be able to zoom in, and navigate, say, between the second letters. (One potential model for how this could be done is the transport control in Apple's QuickTime Player; drag left or right to move the playback position backward or forward. However, if you drag down, then dragging left or right moves the position more finely, letting you hone in more precisely on the position you're looking for.) So I started to write a new index control, which would allow this sort of control, which became KFIndexBar.

KFIndexBar looks much like the index bar in a UITableView; it displays a set of labels over a tinted background. Touching a letter changes its value, allowing the code it connects to to scroll its collection view appropriately. As with BDKCollectionView, it also supports a horizontal orientation, allowing it to display its labels along the bottom of a collection view, rather than down the right-hand side. However, the main user-facing difference is that, if the user touches the index bar and drags to the left, a gap opens below the currently touched top-level index, and fills with intermediate indices between it and the index below it. (For example, in an alphabetical index bar, touching the label for "A" and dragging left might open a set of secondary labels reading "AA", "AD", "AF", and so on; once opened, dragging over these will scroll to the relevant location.) The user can then drag over those, scrolling to any one of them.

Below the cut, I will discuss implementation details:


architecture ios swift uicollectionview ux 0


Functionally generating UIImage in Swift

When developing iOS apps, one often needs a simple UIImage, to use as a background or texture. Traditionally, the facilities for making these on the fly have been minimal to nonexistent, leaving one with two options: either (a) write code which allocates a memory buffer, fills it with pixel values, then does the CoreGraphics dance that turns it into a UIImage, or, more commonly, (b), hacks something up by hand in an image-editing program on one's computer and puts the PNG in the app bundle. The latter has the disadvantage of inflexibility (if the dimensions or colours need to change, it's back to laboriously hand-crafting a replacement image); the former, meanwhile, requires enough work to put one off, unless image generation is a central part of the app's value proposition. However, in the age of Swift, it doesn't have to be this way.

The Swift language, borrowing from functional programming, lends itself nicely to the making of labour-saving abstractions; pieces of code which implement the outline of a process, allowing the caller to provide only the code that does the specific details they want. (This has been, to a lesser extent, possible with Objective C since the addition of blocks, but Swift has further highlighted it.) In which case, it stands to reason that we should be able to do something like:

// make an 8-by-8 black-and-white checkerboard tile
let checkerboard = UIImage(width: 8, height: 8) { (x,y) in return Float(((x/4)+(y/4))%2)  }

Below the cut, I present a UIImage extension which allows you to do exactly this, as well as RGB and RGBI variants.


cocoa touch functional programming iOS swift uiimage 0


Dropbox for paranoiacs

Like many people, I have a Dropbox account; it comes in handy for sharing files with collaborators. However, Dropbox has one significant problem: that of trust. It is a closed-source program, running a proprietary protocol; the user has no means of verifying its operation or its security, and thus using it is giving an opaque program access to one's system, and having faith that (a) it only does what it says it does (i.e., synchronising a directory tree of files between machines), (b) it cannot be quietly subverted by its creators to do other things without one's consent, and (c) it has no security holes that a third party could exploit to pwn all your stuff.

Other people have noticed this as well, and there are several existing articles on ways of compartmentalising Dropbox on a Linux system. These articles generally rely on running it in a chroot jail, restricting its filesystem access to an isolated subtree. The problem with this is that chroot is a thin layer of defense against an untrusted application; it only restricts access to the filesystem, and there have been ways to break out of it; if an attacker can get root privilege, they can get out. In short, trusting chroot to secure an untrusted application is a leap of faith.

Fortunately, chroot is not the only possibility these days; with improving CPU performance and the falling cost of RAM, a moderately powerful computer has enough power to run several virtual machines, each one running its own isolated operating system. These can be run using the freely available VirtualBox application, which is able to run its virtual machines in headless mode. In other words, it is possible to devote a small amount of memory, disk space and CPU power to simulating a small dedicated Linux box dedicated to running a Dropbox client. This box can run a NFS server, through which you can access your Dropbox files from your main machine as if they were stored locally. And, should the Dropbox client turn out to be, or be compromised by, malware, it has access to literally nothing more than a freshly-installed Linux box running itself.

The process has multiple stages: one will need to create a virtual machine, install Linux on it, install the Dropbox client (and configure it to connect to one's account), set up networking and NFS to get at one's files, and configure the host system to automatically start the virtual machine at boot time. In my example, I am using the Debian Linux distribution (in particular, Debian Jessie 8.2.0); the instructions will differ for other distributions.


dropbox linux security virtualbox 1


swiftemplate: Compile-time HTML templates in Swift

Continuing my experiments with the potential of Swift for server-side web applications, I have recently turned my attention to the question of HTML templates. In any HTML-based web app, it is useful to have a way of programmatically generating HTML with data interpolated, which typically is done through templates; HTML documents with special markup. When a page is requested, the template is processed, with the data being inserted into it, generating a HTML document which is sent back to the browser.

There are two ways a templating system may be implemented in a web application framework. On one hand, the framework itself may embed the template engine; the web app in this case would be deployed with a set of templates, which it would parse into an internal representation; then, whenever the app receives a request, the engine uses the template to generate a HTML page. (This is the approach used by many web frameworks written in dynamic languages such as Python and Ruby.) The other alternative is to do the template processing at build time; a tool compiles the template into source code in the language the web application is written in; it is then included in the app, and called as any other piece of code would be. The advantages of this approach are more compact and efficient compiled applications. It is particularly suited to compiled languages like Swift, which already have a build process.

It is with this in mind that, following on from the Malimbe framework, I have developed swiftemplate, a familiar-looking HTML-oriented templating system that generates Swift code.

The swiftemplate syntax

The syntax of swiftemplate will be familiar to people who have used other web application frameworks. A template file consists of content (typically HTML) interspersed with directives, expressions and inline code blocks. Directives begin with %% and occupy their own lines; they include the familiar for and if/else (which are augmented with closing directives), as well as a template directive which defines a template and its arguments. Inline expressions are enclosed in <%= and %>; they must fit on one line, but may contain characters not permissible in Swift's \() interpolation syntax. Code blocks take up multiple lines, and are enclosed in <% and %> brackets (each of which must be on its own line). An example template (for displaying a page about a user of a web application) might look like like:

%% template showUser(user: User)
let posts = user.posts.prefix(5)
<h1>User \(</h1>
%% if posts.isEmpty
<p>This user has no posts</p>
%% else
%% for post in posts
  <li><%= post.title %></li>
%% endfor
%% endif
%% endtemplate

The template compilation process

Swiftemplate templates are compiled to Swift code with the swiftemplate command. One or more template files (each potentially containing one or more templates) may be compiled at a time into a Swift source file; one possible invocation could be to compile all the templates into one source filem prior to compilation of the Swift code, like so:

swiftemplate -o Sources/templates.swift Templates/*.swiftemplate

In the emitted source file, each template is converted to a Swift function, having the same name and arguments as in its %% template directive and returning a String; for example, the user page template above would produce Swift code that (if indented) looked something like:

func showUser(user: User) -> String {
  var _ℜ=[String]()
  let posts = user.posts.prefix(5)
  _ℜ.append("<h1>User \(</h1>")
  if posts.isEmpty {
    _ℜ.append("<p>This user has no posts</p>")
  } else {
    for post in posts {
  return _ℜ.joinWithSeparator(" ")

(The variable containing the return result is given the name ‘_ℜ’, which stands for “result” and is also unlikely to be used by the template. Needless to say, don't name your templates or template arguments this.)

Composing templates

Given that swiftemplate input files may contain multiple templates, and that templates, in their compiled form, are just Swift functions returning Strings, it is possible to define templates in a modular fashion. Below is an example, also from the user example, which displays a set of contact details using another template as a macro:

%% template contactDetail(name: String, value: String) 
<dt class="detailName">\(name)</dt> 
<dd class="detailValue">\(value)</dd>
%% endtemplate

%% template showUser(user: User)
<h1>User \(</h1>
<h2>Contact details</h2<
<%= contactDetail("Phone", %>
<%= contactDetail("Email", %>
<%= contactDetail("Twitter", user.twitter) %>
%% // ... and so on
%% endtemplate

The state of Swiftemplate

This is the first version of Swiftemplate, and it may well have bugs. Having said that, there are extensive unit tests (though, at the moment, these only work in Xcode; once testing in the Swift build process on Linux matures, they will work there as well).

Swiftemplate is a lightweight template processor; it parses the parts it understand and passes other parts (such as the expressions following an %% if or a %% for) through to Swift without attempting to enforce correct syntax. Which means that if those parts are nonsense, swiftemplate will not warn you, but you will get a Swift compiler error in the machine-generated .swift file containing your processed templates. Be warned!

Swiftemplate runs under OSX (with Xcode) or Linux (with the command-line build tools, and the Foundation module installed), and does not depend on Malimbe or any other code; it is available on GitHub and is distributed under the Apache Licence (i.e., it may be used freely, as long as acknowledgement is provided).

html swift swiftemplate web 0


Malimbe: an asynchronous server-side web framework in Swift

Recently, I have been experimenting with the open-source beta of Swift for Linux, and in particular looking into its potential as a language for server-side web applications. As such, I present the first draft of my experimental server-side web framework, Malimbe.

Malimbe (named after several species of African weaver bird) is written in Swift and will build on Linux; no attempt has yet been made to make it work on OSX, though it would certainly be possible. The main influences on Malimbe's design have been various Python/WSGI-based frameworks (mainly Pylons/Pyramid) and the Play framework in Scala (though Malimbe is a lot more minimal at this stage). The key design decisions of Malimbe, as it currently stands, are:

  • The use of Futures (as previously described here) for concurrency. HTTP request handlers do not return a HTTPResponse immediately, but return a Future<HTTPResponse>; i.e., an opaque container to a computation, which, once complete, will yield a HTTPResponse. The Future may refer to an ongoing computation, taking place on a background thread, or (for simple responses) may be created pre-completed. Given that Futures are monadic containers (which may be mapped and flatMapped over), a request handler returning a Future<HTTPRequest> could well just call a function returning a Future of, say, a set of database rows or a JSON object fetched from a remote API, and return that mapped into, say, a page of HTML.
  • Malimbe's request-handling mechanism is a chain of objects implementing the HTTPRequestHandler protocol. This protocol defines only one method, which looks like:
    func handleRequest(request: HTTPRequest) -> Future<HTTPResponse>
    The request handler objects are typically instantiated with any configuration information they need; for most of them, this will include a next value, containing the next request handler in the chain. If the request handler cannot completely handle the request itself, it will call this and return its value. (Theoretically, it could also modify its return value with map or flatMap, though none of the ones implemented so far do.)

The main source file of a Malimbe web application, as it stands, constructs the chain of request handler, and creates a HTTPServer object (passing the top of this chain to it); requests propagate down the chain until they are handled; at the bottom is typically the Router request handler, which matches methods and paths, extracting arguments from paths, and calling the appropriate handler for each path. This might well look something like:

func itemPageHandler(request: HTTPRequest, args:[String:String]) -> Future<HTTPResponse> {
    let id = args["id"] ?? ""
    // make the item page here...

let router = Router(routes:[
	Router.Get("/items/",    handler:itemsListHandler),
	Router.Get("/items/:id", handler:itemPageHandler),

let staticFiles = StaticFileRequestHandler(pathPrefix: "/static/", staticDir:appRelativePath("StaticFiles/"), next:router)

let server = HTTPServer(handler: staticFiles)

do {
    try server.start(9999)
    print("started on 9999")

    while(true) {
} catch {
    print("error: \(error)")

Malimbe currently has a few request handlers: the path-matching Router shown above; StaticFileRequestHandler, which can conveniently serve static files (such as stylesheets and JavaScript) from a local directory under a certain path, along with a HTTP Basic Authentication middleware; others will be added in future.


Malimbe also has a simple set of objects for generating HTML in Swift code. This, Swiftily enough, has a protocol at its centre, the HTMLRenderable protocol, which allows objects to return HTML representations of them:

public protocol HTMLRenderable {
    /** Return a HTML representation of this object as a String */
    var asHTML: String { get }

The Swift String type has been extended to be HTMLRenderable; a string rendered asHTML will be quoted, with angle brackets replaced with &lt; and &gt; so that its contents are displayed as they are. If you wish to pass HTML markup back, there is a HTMLLiteral object you can wrap it in, which renders without any quoting. However, in most cases, you will want to create tags using the HTMLTag type, a HTMLRenderable representing a single tag and its contents (which may include zero or more HTMLRenderables within the tag), like so:

    HTMLTag.SPAN(HTMLTag.B(, "says:", class:"itemtop"),
    HTMLTag.DIV(self.text, class:"itembody")
], class:"guestbookitem")

(The tag's contents are the first rather than last parameters; this is because of quirks in Swift's handling of variadic arguments.)

Of course, since HTMLRenderable is a protocol, there is every reason to extend your data types to implement it, which then allows you to insert them directly in the markup:

extension Item: HTMLRenderable {
    var asHTML: String {
        return HTMLTag.P(
            "Item ", HTMLTag.B(, "(\("
        , class: "item").asHTML

The state of the framework

Malimbe is an experimental framework, still in an early stage of development. Many pieces that one would expect in a full stack are missing (notably any support for access to databases or web-based APIs). Some of these may be developed separately as other projects and imported as dependencies into Malimbe-based projects, though ideally, Malimbe would integrate them into its design. (For example, once a database framework exists, it would be the intention for it to be wrapped in an asynchronous interface that returns Futures of results.) Other components (such as session middleware, templating libraries, and a configuration system) are also missing at this stage.

Also, because Swift support on Linux is still immature, Malimbe applications will probably not be performant at this stage. For one, at the time of writing, there was no stable Linux port of libdispatch (Apple's concurrency framework, also known as Grand Central Dispatch); Malimbe uses a workaround from a Swift package named NSLinux which fakes this by spawning a thread for each dispatched block; this is obviously not something one would want on a heavily loaded production server. However, once libdispatch is ready, Malimbe will not require significant changes to use it.

Malimbe is available on GitHub, and is distributed under the Apache Licence (i.e., it may be used freely, as long as acknowledgement is provided).

futures linux malimbe swift web 1


Futures/Promises in Swift, draft 1.1

With the recent open-sourcing of the Swift language and its availability (albeit piecemeal, and not quite as we know it) on Linux, I have been spending some time playing with Swift on Linux. In my opinion, it holds promise for implementing the sorts of server-side code that often runs on Linux instances; one example would be web applications. With its LLVM-based optimising compiler, strong type system and the ability to minimise the amount of mutable state (more so than, say, Python or JavaScript), it should lend itself to performant server-side code quite well.

In any case, here is the first result of my experiments in Swift on Linux: a proof of concept of Futures/Promises. It's modelled somewhat on Scala's Futures, in that Futures are monadic containers which may be transformed with map, chained with flatMap, and, should you need to go synchronous at some point, awaited.

(For those not familiar with Futures/Promises, they're a different way of organising callbacks. With callbacks, as we know them from, say, JavaScript, Objective C or Swift, if you have a possibly time-consuming process to run, you pass it a function for it to call; it returns nothing immediately, but if all goes well, your callback function gets called with the value it was waiting for. Of course, the downside of this is the building up of a “Pyramid Of Doom”, a monstrous ziggurat of curly braces, like so:

doSomething { (a) -> () in 
   doSomethingElse(a) { (b) -> () in 
     andSomethingElse(b) { (c) -> () in 
        // now handle the value here
With Futures/Promises, you don't pass callbacks, but instead receive an opaque container type that is, at some future time, redeemable for the value of whatever computation it represents. While you don't have that value, you can do other things with it, like chain other operations on it, to be completed asynchronously. And so, our pyramid is transformed into something like;
  .flatMap { doSomethingElse($0) }
  .flatMap { andSomethingElse($0) }
  .onCompletion {
    // now handle the value here
Which, for one, looks a bit tidier; it also allows complex chains of interdependent operations to be reasoned about more easily.)

This code is currently only a rough sketch (which is why it is a gist, rather than a repository); for one, Swift on Linux's concurrency handling still leaves a bit to be desired (Apple's libdispatch is still not available, and so this uses NSLinux, which fakes Grand Central Dispatch in a somewhat basic way, spawning a new thread for each block, and having no option of running things on the main thread; needless to say, don't use this in your financial trading app just yet.) Secondly, there is not yet a concept of a failed Promise; they may be either incomplete or successfully completed. (Whether to use a Haskell-style Either/Result value or to somehow eschew that in favour of Swift's throws mechanism is a decision to be considered when implementing the possibility of failed Promises. Also, some way of sequencing/traversing multiple Futures would be useful for nontrivial applications. Finally, there is the small matter that this code defines only a Promise type and has it do double-duty as a Future as well; which makes for simpler code, though doesn't separate the twin concerns quite as elegantly. Update: I have now updated the code to split Futures (the ones you fire off with a block to run in the background) from Promises (the ones you create and fill in yourself, giving a Future to whatever needs the result).

In any case, the typical usage would look something like the following:

// Map over a Future, then do something with its result asynchronously
var f1 = Future<Int>( future: { calculateValue(...) })
var f2 = { $0 * 2 }
f2.onComplete { doSomethingWith($0) }

// two futures chained with flatMap
var f3 = Future<String>( future: { getUserName() })
    .flatMap { Future<Int>( future: { getShoeSizeOfUser($0) } }
if let value = f3.await(3.0) {
    print("The user's shoe size is \(value)")

And if you want to use Promises and do the computation yourself:

func asynchronouslyComputeAFuture() -> Future<Something> {
    // create an empty Promise...
    let p = Promise<Something>()

    // start a background process which will fill the Promise in...
    dispatch_async( myQueue, {
        let result: Something = computeTheResult() // this may take a while...

    // return the Promise's Future
    return p.future()

This is not the only implementation of Futures/Promises for Swift, nor even one of the more complete ones. There are two others which look more complete (BrightFutures and FutureKit), though both are only available for iOS and OSX at the moment.

concurrency functional programming futures linux monads promises swift 1

This will be the comment popup.
Post a reply
Display name:

Your comment:

Please enter the text in the image above here: