Why Mobile + Swift = BFFs

By Chris Bailey

The Swift programming language from Apple is the strategic direction for developing applications for iOS devices. Swift will ultimately replace Objective-C, so it could be argued that Swift and mobile are best friends forever. In this context, though, “BFF” refers to the “back end for front end” (BFF) architecture pattern developed by ThoughtWorks and used at SoundCloud and Real Estate Australia (REA).

The BFF pattern

User-facing applications need to support a number of different clients, which will typically include both desktop web and mobile devices. In most common scenarios, the applications provide a general-purpose API provided on the server, which both the web and mobile clients interact with.

This presents some challenges as the needs of desktop web and mobile clients can be very different. For example, desktop web applications are concerned with the first paint time (the amount of time it takes between a user initially visiting a website to receiving usable information). Mobile clients, on the other hand, already contain the majority of the user interface and indeed usually need to be able to handle offline use.

Mobile clients have concerns about the size and frequency of data connections, as well as CPU, memory and battery usage. Desktop web, on the other hand, can be assumed not to have these resource constraints. Additionally, mobile clients may provide additional functions to the user, taking advantage of location awareness or mobile payment capabilities.

Sign up for our newsletter
Stay on top of the latest mobile news and insights.

In order to deal with these different requirements from the clients of the server APIs, the “back end for front end” pattern was created, with one back end created for each front-end user experience.

Breaking down the silos

One of the advantages of the “back end for front end” pattern is that as the server API back end is specific to the front-end user experience, it can (and should) be owned by the front-end team. This provides huge advantages in terms of productivity and agility.

The front-end team contains all the developers needed to add features that require new or updated server APIs, without needing to hand off to a separate team that may have different priorities, ensuring they don’t become blocked and they have more rapid development and test cycles. Additionally, release cycles can be aligned with client and server components updated at the same time based on client needs rather than being blocked until the back-end team makes the server API available.

Single-language teams

The introduction of the front-end team owning its own back-end server API does introduce its own challenges, particularly for smaller teams. For example, building resilient and scalable server APIs is an additional skill set that has to be learned. Using the same programming language for the client and the server can minimize this, making the cross-skilling much easier and indeed providing additional advantages in being able to share source code between the client and the server.

This has not been possible in all cases in the past. While desktop web could be backed by Node.js and Android could be backed by Java, iOS clients needed to be backed by a server API created in another language. With the arrival of Swift on the server, front-end iOS teams can now easily take ownership of end-to-end features.

Written By

Chris Bailey

Runtime Architect for Swift at IBM

Chris is a Senior Technical Staff Member (STSM) and Runtime Architect at IBM. He has worked on programming languages for over 15 years, largely focussing on Java, Node.js and Swift. He is a committor for the Swift core libraries, and a member of the steering team for the Swift Server…

Other Articles by Chris Bailey
See All Posts