Under The BridgeUnder The Bridge


So, last year when all the excitement was frothing about this Protocol-Oriented Programming “revolution,” First Protocol-Oriented Language and all — did you take a quick look, chuckle to yourself “Ah, they’ve rediscovered Mixin-Based Programming, isn’t that cute?” and move on? Yeah, us too. But it turns out there is a good bit more depth to plumb! Here’s an excellent tutorial style introduction, released as a teaser for the RWDevCon 2016 Vault video collection:

RWDevCon 2016 Session 303: Introduction to Protocol-Oriented Programming

Here’s the key points:

  • protocols with extensions are almost perfectly superior to inheritance
    • you can do almost everything you can with inheritance
    • and, they can work with value types
    • and, they allow retroactive modelling
  • but, protocols with associated types (PATs) are different beasts
    • you give up dynamic dispatch
    • but you can model more intricate type relations

Or if you just want one nugget to mull over, I’d say most of it is in this slide:


And here is an absolutely essential series on associated types from Russ Bishop:

Swift Associated Types

Sometimes I think type theory is deliberately obtuse and all those functional programming hipster kids are just bull-shitting as if they understood one word of it…

Swift Associated Types, cont.

I don’t feel like I fully covered one aspect of protocols with associated types: why can they be such a pain to work with?

Swift: Why Associated Types?

So the philosophical answer to the question of Why Associated Types? is that the Swift core team believes they are a better way to model concepts. They don’t have the problem of multiple conformances, they encapsulate the details of a concept cleanly, and they’re less fragile.

And there you have it. By way of example, here’s a few practical applications of protocols to make common tasks more elegant:

Protocol-Oriented MVVM in Swift 2.0

Protocol Extensions, Meet List Controllers

Stupid Swift Tricks #5: Pickable Enums

Upgrade your TableViews with Loading State

And a wide-ranging selection of other inside baseball style musings on generics and protocols to help you grok the gestalt here:

Swift Protocol Extension Weirdness

Improved Protocol-Oriented Programming with Untyped Type Aliases (part 1) and part 2

Generic Protocols & Their Shortcomings

Trimming Swift generics

Generics and the Art of Inference Part 1 of 3

What the 55 Swift Standard Library Protocols Taught Me

Protocols with Associated Types, and How They Got That Way

Protocol-Oriented Problems and the Immutable ‘self’ Error

The why of nonmutating

Beyond Crusty: Real-World Protocols

Working with Swift: Adopt a Protocol or Pass a Function?

Doubling Down on Protocol-Oriented Programming

Plenty there to keep you pondering for a while we trust!


Practical Protocol-Oriented-Programming slides (POP💥) and video from Natasha The Robot with writeups

Polymorphism and Protocol Extensions

The why of nonmutating [TL;DR For value type protocol conformance]

Protocol Oriented Programming in Swift

Using protocol compositon for dependency injection

Framework Package Flocking

Thinking of wrapping up some of your code for the public in a framework? Here’s two nice walkthroughs of the gritty details of setting that up for both CocoaPods and Carthage:

Creating your first iOS Framework

We’re going to build a framework that exposes a function called RGBUIColor(red:green:blue) that returns a new UIColor created from those values. We’ll build it using Swift, with Carthage as our dependency manager. Our framework will be consumable using Carthage, CocoaPods, or git submodules…

Creating Cross-Platform Swift Frameworks for iOS, watchOS, and tvOS via Carthage and CocoaPods

In this post, I’d like to show you how to create a Swift framework for iOS, watchOS, and tvOS and get them distributed via Carthage and CocoaPods… Check out one of my libraries that uses this method to see how it’s set up with real code and tests: ZamzamKit

Good stuff, yep. But what if you want to support that upcoming hotness the Swift Package Manager? Why yes, here’s a presentation that’s got that sorted too:

Creating a Swift Library walks through producing Snorlax, “The ultimate lazy library”,

Snorlax currently supports the following platforms:

  • Mac OS X
  • iOS
  • tvOS
  • watchOS
  • Linux

Using the following Package Managers:

  • CocoaPods
  • Carthage
  • Swift Package Manager
  • Adding as an Xcode Subproject

That’s veritably exhaustive, that is.

If you just can’t wait for Swift 3 to try out SPM, check out

Dependency Management with the Swift Package Manager

But something not being officially released has never stopped inquisitive developers experimenting in the past. So in this article I will introduce the SPM, show you how to install it and existing packages, and how to create your own…

And once you’ve got your SPM library ready to go, be sure to submit it to the package catalog for SPM hosted by… wait, who?

IBM Swift Package Catalog

Create, share and discover the many new libraries, modules and packages being created since Swift moved to Open Source.

The IBM Swift Package Catalog enables the Swift.org developer community to leverage and share code across projects…

Truly, these are strange times we live in, aren’t they now?


CocoaPods 1.0: “I’m incredibly happy to say that, after an incredible four and a half years of development, we just released CocoaPods 1.0…”

SwiftPM Packages on GitHub: Statistics

Creating Objective-C and C++ packages using Swift Package Manager

Making Private, Cross-Platform Swift Frameworks With CocoaPods

Framework: “A template for new Swift iOS / tvOS / watchOS / macOS Framework project ready with travis-ci, cocoapods, Carthage, SwiftPM and a Readme file”

SwiftPlate: “Easily generate cross platform Swift framework projects from the command line.”

Using Swift Package Manager with Carthage

Build a Universal Framework for iOS using Swift

Using ‘swift package fetch’ in an Xcode project

Building a command line tool using the Swift Package Manager

SwiftPlate: “Easily generate cross platform Swift framework projects from the command line”

Dependency Management for iOS projects with the Swift package manager

Feeling Testy

Here’s an interesting talk on approaches to testing your apps:

An Artsy Testing Tour

Artsy has four iOS applications; all of them are open source, and all of them take different approaches to testing. Why? Because different testing techniques work better or worse in different circumstances…

Like the bit here on Core Data dependency injection,

You might give an object a Core Data managed object context instead of having it access a singleton. We use dependency injection for stubbed managed object context as well as for the network synchronization code. Energy uses in-memory Core Data managed object context that can be quickly and cheaply created, then destroyed for our unit tests. Part of what we can test is how an object modifies the Core Data stores, so we can create a managed object context, inject it into the object that we’re testing, and then the object does something, and then we can inspect the managed object context to see that the changes that had been performed on it are what we expect…

And you can check out all the discussed implementations yourself from this list:

Every element extremely enlightening!

Another one that came out this week is

Running UI Tests on iOS With Ludicrous Speed [EDIT: Translated to ConditionTester.swift]

They’re using a custom KIF fork, mind you, not the Xcode 7 UI Testing hotness. Well, we like it, anyway.

While we’re talking about dependencies and all, there’s been a lot of developments on that front since our last roundup when Swift and XCTest were both brand new. Wow, seems a long time already, doesn’t it? Here’s some articles and code worth checking out:

Swift: The Only Modern Language without Mocking Frameworks

Better Unit Testing with Swift

Four Types of Dependency Injection in Swift

iOS Unit Testing: Dependency Injection with Structs in Swift

Real World Mocking in Swift

Mocks in Swift via Protocols

Cuckoo “was created due to lack of a proper Swift mocking framework. We built the DSL to be very similar to Mockito, so anyone using it in Java/Android can immediately pick it up and use it.”

iOS Functional Testing With User Stories, Ui Test and Local Server

Testing with Swift – Approaches & Useful Libraries

Continuous iOS Code Coverage With Jenkins and Slather


Mocking Dependencies with Generics “TL;DR: You can inject code dependencies in a transparent way by using generics and typealias.”

Creating a Custom XCTest Assertion

Testing Dictionaries with Swift and XCTest

Depedency Injection in Swift

Cleanse: “Lightweight Swift Dependency Injection Framework.”

Swifjection: “Dependency Injection library for Swift”

Kakapo: “Dynamically Mock server behaviors and responses in Swift.” + #254: Dynamically Mocking Network Requests with Kakapo

Making burritos with Swift (or How To Mock Classes You Don’t Control)

Mocks in Swift via Protocols

Running tests with Clang Address Sanitizer; Undocumented Xcode Sanitizer Settings

How to Do XCTestCase tearDown Wrong …and Right

Testing the User Interface with FBSnapshotTestCase

How to Make More Useful Swift Mock Objects

Bluepill – Open Source Tool For iOS Testing In Multiple Simulators With Added Reliability Features

Testing in Swift: Protocols & View Models

Testing and mocking without OCMock

Let Your Swift XCTest Methods Throw

XCTest and Optional Unwrapping

Xcode 8.3 new APIs: Waiting in XCTest

Controlling Siri and Asynchronous Testing With XCTest

Deep Dive Into iOS Automation At Grab – Integration Testing

Making Mock Objects More Useful

Mimus: “Swift Mocking Library”

Using protocol compositon for dependency injection

Introducing Protocol-Oriented BDD in Swift for iOS Apps: Part 1

Time traveling in Swift unit tests

Resetting iOS Simulator for UI tests

Why you should co-locate your Xcode tests

Keeping XCTest in sync on Linux

How to test a Swift package on Linux using Docker

XCTest closure based expectations

Tests that don’t crash

Avoiding force unwrapping in Swift unit tests

Using unit tests to identify & avoid memory leaks in Swift

Delay/Wait in a test case of Xcode UI testing

Network Stubbing Options for XCTest and XCUITest in Swift

Xcode unit tests with ⌘+S

Mocking in Swift

Unit testing asynchronous Swift code

Swift Mushroom Clouds

Our friends at DZone have a new guide out worth reading for a grand overview of the cloudscape these days:

DZone’s 2016 Guide to Building and Deploying Applications on the Cloud

The question isn’t whether or not to use the cloud; it’s when and how. This guide contains everything from building 12-factor apps to hiring full-stack engineers. Navigate through a 90+ cloud solutions directory and start coding right away. Dive into the research findings from 700+ developers on *aaS adoption, cloud security models, container use (including Docker), and more.

Historically we’ve tended to have a fairly detached regard for the state of the cloud, it being so far over our heads and all, but we’ve been contemplating the idea of moving into full stack engineering due to the way Swift clouds are mushrooming all over the place. No, seriously, mushrooming; just check out the current list from awesome-ios:

  • Perfect – Server-side Swift. The Perfect library, application server, connectors and example apps.
  • Swifter – Tiny http server engine written in Swift programming language.
  • CocoaHTTPServer – A small, lightweight, embeddable HTTP server for Mac OS X or iOS applications.
  • Curassow – Swift HTTP server using the pre-fork worker model. [And check out the rest at github/kylef!]
  • Zewo – Venice based HTTP server for Swift 2.2 on Linux
  • Vapor – Elegant web framework for Swift that works on iOS, OS X, and Ubuntu.
  • swiftra – Sinatra-like DSL for developing web apps in Swift
  • blackfish – A fast HTTP web server based on Node.js and Express written in Swift
  • swift-http – HTTP Implementation for Swift on Linux and Mac OS X
  • Trevi – A powerful Swift Web Application Server Framework Project
  • Express – Swift Express is a simple, yet unopinionated web application server written in Swift
  • Aeon – Aeon is a GCD based HTTP server for Swift 2.
  • Taylor – A lightweight library for writing HTTP web servers with Swift
  • Frank – Frank is a DSL for quickly writing web applications in Swift
  • Kitura – Web framework and HTTP server for Swift by IBM
  • Swifton – A Ruby on Rails inspired Web Framework for Swift that runs on Linux and OS X
  • Dynamo – High Performance (nearly)100% Swift Web server supporting dynamic content.

Personally, we’re inclined to agree with people who like the look of Swift Express

Being perfectionists, we took the best from what we think is the best: power of Play Framework and simplicity of Express.js

Express is an asynchronous, simple, powerful, yet unopinionated web application server written in Swift…

…but we may just be biased because the authors are from Lviv. We were there a couple years back, it’s pretty cool.

Here’s some helpful introductions to server-y Swiftness:

Hello Server Side Swift

Getting Started with OpenWhisk Server Side Swift

Swift + Kitura on DigitalOcean


And some help that’s not server specific, but likely to be of interest to living out on the bleeding edge here:

Cross-platform Swift “A talk about writing Swift targeting multiple platforms. Given at App Builders 🇨🇭 2016.”

Practical Cross-Platform Swift

Swift And C: Everything You Need to Know

swiftenv: “Swift Version Manager — allows you to easily install, and switch between multiple versions of Swift.”

Let us know about your experiences with any of these frameworks!


Building Slack Bots In Swift

Why I’m Not Using Swift On The Server (Yet)

Server Side Swift vs. The Other Guys — 1: Input

Try out Swift packages in the IBM Swift Sandbox

Super Spectacular Server-Side Swift!

BluePic: “is a sample photo sharing application for iOS that shows you how to connect your mobile application with Kitura, Bluemix services, and OpenWhisk actions.”

Swift on the Server – Where Are We Today?

Cross-Platform Swift by Boris Bügling

Building Your First Web App in Swift Using Vapor

Swift on Linux

Build an end-to-end Swift app with Watson APIs

Tailored Swift – coming soon to a cloud near you

Serverless Swift: Running Swift Code on Amazon Lambda

Building a Production Server Swift App: Lessons Learned

SwiftyBeaver/SBWebsite: Logging in server-side Swift; Deployment of a Swift Vapor App to the AWS EC2 Cloud

My Thoughts on Server-side Swift: Routing

Kitura/iOS: Running a Web Server on your iPhone

Swift… Swift everywhere

Getting Started with Server Side Swift: 1.0; Getting Started with Server Side Swift: 1.2

Deploying Server Side Swift to Linode

SCADE: Cross-Platform mobile development with Swift ; Swift for cross platform client & server side development

Server-Side Swift Live Coding

Server-Side Swift: Comparing Vapor and Perfect

Current Features & Benefits of the Top Server-Side Swift Frameworks

Building a Swift Web API

Vapor 2: Less code, more power.

Errors On The Server

Too True Tone

So did you skip past those bits about the “True Tone” ambient light sensing display in the hobbit-sized iPad Pro as sounding kinda gimmicky? Well, turns out that this DCI-P3 thing is actually A Very Big Deal:

Understanding the 9.7″ iPad Pro’s Display: How DCI-P3 & True Tone Work

DCI-P3 will be the gamut to have when UltraHD content rolls around, and Apple choosing it instead of Adobe RGB was a well planned move. While it’s not very relevant now, it certainly will be in the future, and Apple has already ensured that iOS and its app ecosystem manages color correctly to render sRGB content and DCI-P3 content correctly…

Looking at the Future

As with most things released by Apple, there is an amazing amount of underlying technology that makes this new display shine. This new product is also a glimpse of how our screen technology will evolve over the coming years, so now is a good time to start understanding how these changes are going to affect our products.

As a developer, you’ll quickly realize that the scope of these changes will make your update to Retina graphics look like a walk in the park…

In case you missed it, there’s ColorSync Support in iOS 9.3 (!)

… but if you actually start using color management right now, there’s issues to be aware of.

Whilst we await the brand new color management day to dawn, if you have a cutting edge iMac or iPad, here’s some more links to try this stuff out:

The Wide Gamut World of Color — iMac Edition

The 9.7-inch iPad Pro Color Gamut

Wide Gamut Test Paget

And if you don’t, well there’s your excuse to treat yourself!

h/t: Michael Tsai!


Improving Color on the Web

How to Tell if Your App Is Handling Colors Correctly

Bringing Wide Color to Instagram

Make The App Store Great Again

In case you didn’t visit the Dev Portal this week, there’s a new mini-site worth flipping through:

Making Great Apps for the App Store

Hopefully this facelift presages attempts to address the not-so simmering frustration out there:

Life and Death in the App Store

For all but a few developers, the App Store itself now resembles a lottery: for every breakout hit like Candy Crush, hundreds or even thousands of apps languish in obscurity…

Just Landed Is Shutting Down

Essentially, there’s a massive oversupply of apps, and the app markets are now saturated and suffering from neglect and short-term thinking by the companies who operate them…

What no indie developer wants to hear about the App Store

But the truth is, even if Apple gave indie developers everything they wanted, it wouldn’t matter much over the long term…


People don’t pay for functionality, at least not anymore. They do pay for content and services, but they don’t pay for functionality…

Fixing the Apple App Store

My take: I don’t think the App Stores are broken; I think they’re doing exactly what Apple wants them to, because Apple’s interest is in supporting the corporate app developers and the larger studio developers…

Et cetera. Perhaps we’ve already had a trial balloon for one of those presaged attempts; if so, it went over … poorly.

Paid App Store Search

  • “It’s downright embarrassing that App Store search is still so bad…”
  • “They need to de-crappify the Store…”
  • “Apple has done some dumb things in the company’s history, but this stands out as particularly stupid…”
  • “Why wasn’t search already better?”
  • “would exacerbate much of the App Store’s dysfunction…”

Well, that’s kinda a downer of a post so far, isn’t it. So let’s pick it up a bit with this inspiring manifesto:

Built an iOS game. It became #1 in the App Store. Here are revenue numbers and what I learned.

I built an iOS app called A Dark Room that hit the #1 spot in the App Store. Here is the article The New Yorker wrote about it.

  • 2.26 million downloads in under two years (free and paid combined).
  • #1 game in the US for 18 days straight (20 days overall).
  • 26,859 ratings of which 23,833 are 5-stars (4.73 average rating)…

Long list of Do’s and Don’ts for developing, marketing getting featured, and making sustainable income. Read them!

Another interesting metrics-laden post-mortem on Almost Impossible! here: iOS Game Revenue & Launch Details

Now that you’re all fired up, for massive collections of marketing resources check out:

App Marketing Stack: “A Curated Directory of Tools & Resources on App Marketing and Mobile Growth.”

iOS Dev ToolsApp Store & Sales

ios-marketing-resources: “Awesome list of iOS app branding/marketing tools.”

The iOS App Marketing Strategy Guide

And there might be some more nuggets in our earlier roundups on marketing, landing pages, videos, and screenshots.

And finally, whether you’re indie or not, handling marketing or not, no doubt a bane of your App Store development is the review process, ’tis it not? Besides Apple’s new Guidelines page mentioned up at the top, here’s some more help:

Under the Radar #21: App Store Rejection – “Tips on avoiding rejections by Apple’s app-review staff and what to do when your app get rejected.”

App Store Review Guidelines History: An annotated list of all changes to the Review Guidelines back to 2014.

Good luck!


How To Write App Store Descriptions

Monument Valley in Numbers: Year 2

The Complete App Store Optimization Checklist: 2016 Edition

The Savvy App Store Submission Checklist

Good practices to influence your app revenues using App Store reviews

AppReviewKit: “An alternative solution to remind your users to review your app.”

The App Store Keyword Algorithm Update Takes Effect

In-App Purchasing Lessons from the Top 50 Game Developers

App Store Optimization — The Definitive Playbook

App store optimization: How to win Google Play and App Store search

The Essential List of 35 App Promotion & Marketing Strategies

7 Advanced App Store Optimization Strategies

Black Hat App Store Optimization

Apple’s New Search Ads: What You Need to Know

Top 10 Apple Search Ads FAQs: Answered

Our Experience with App Store Search Ads

Socking simians

How to make Apple Search Ads work for your App

Top 21 research-driven app store optimization tips (ASO)

App Store Optimization Monthly

Find the Best App Store Optimization Tools – ASO Tools List

Apple Search Ads Campaign Structure Demo

Apple Search Ads Best Practices to Scale Impressions

Apple iOS App Store Optimization Tips: 5 Mistakes to Avoid

Black Hat ASO — Where to Draw the Line

Surviving the App Store

The App Store Optimization Stack [1/4]

108+ App Marketing Strategies to Boost Your Downloads

65 Simple Ways To Promote Your Mobile App

Sequences: The .next() Generator

Here’s a nice gentle introduction (h/t: This Week In Swift) to modelling an algorithmic collection using the SequenceType and GeneratorType protocols:

Sequences and Generators [EDIT: Disappeared!]

Let’s imagine, that we want to learn the new language. Spanish, for example. Your professor told you, that you will have one lesson each N days starting from today. But the bad thing – your professor doesn’t want to work on Sundays. So if the lesson is on Sunday, it will be rescheduled to the next day. We want to receive the schedule – Array<NSDate> for M days.

Grab the playground here, and walk through creating an NSDate sequence with

  1. A generator class for a defined number of iterations
  2. Using AnyGenerator for a bounded number of iterations
  3. A generator class for an infinite number of dates

along with using .prefix(), .filter() and .lazy() to make that infinite sequence actually usable in Swift 2, since filter() is no longer a free function like in Swift 1. More detailed explorations of laziness can be found here:

Being Lazy

True Lazy Sequences

Experimenting with Swift Sequences and Generators

And what do you get when you add indexability to a sequence? Why, a collection:

Swift Collections

Generic Collections, SubSequences and Overloading

For an application of the generator concept to a no doubt common modelling problem you’re presented with, check out

Practical Swift: pages generator – build once, use many

In the real world, at some point, we all have to deal with data that is fetched from a backend service, page by page. It’s called paging. Everybody does this! Nothing to be ashamed of 😉 Here is one of the ways in which a Swift pattern (well, not specific to Swift, but visible in Swift) can be used to build a neat solution that allows me to fetch data in chunks and display it in the application…

And finally, check out SwiftSequence, “A μframework of extensions for SequenceType in Swift 2.0, inspired by Python’s itertools, Haskell’s standard library, and other things,” for some handy manipulations:


Use as an alternative to recursion: Recursive Tail Calls and Trampolines in Swift

An algorithm reference will likely come in handy in this problem space: swift-algorithm-club

So might randomness: Random number generators in Swift

Swift: The joy of sequences

Grokking Lazy Sequences & Collections

Architectural Pattern Landscape

Great article here (h/t: ManiacDev) on selecting an architectural pattern for your apps:

iOS Architecture Patterns: Demystifying MVC, MVP, MVVM and VIPER

Let’s define features of a good architecture:

  1. Balanced distribution of responsibilities among entities with strict roles.
  2. Testability usually comes from the first feature.
  3. Ease of use and a low maintenance cost.

Starts out going through the Massive View Controller we’re all familiar with,

…it might seem that Cocoa MVC is a pretty bad pattern to choose. But let’s assess it in terms of features defined in the beginning of the article:

  • Distribution — the View and the Model in fact separated, but the View and the Controller are tightly coupled.
  • Testability — due to the bad distribution you’ll probably only test your Model.
  • Ease of use — the least amount of code among others patterns. In addition everyone is familiar with it, thus, it’s easily maintained even by the unexperienced developers.

Cocoa MVC is the pattern of your choice if you are not ready to invest more time in your architecture, and you feel that something with higher maintenance cost is an overkill for your tiny pet project.

Next, the MVP option is “Cocoa MVC’s promises delivered” by redefining the UIViewController as the View,

… Does this mean that Apple’s MVC is in fact a MVP? No, its not, because if you recall, there, the View is tightly coupled with the Controller, while the MVP’s mediator, Presenter, has nothing to do with the life cycle of the view controller, and the View can be mocked easily, so there is no layout code in the Presenter at all, but it is responsible for updating the View with data and state.

In terms of the MVP, the UIViewController subclasses are in fact the Views and not the Presenters. This distinction provides superb testability, which comes at cost of the development speed, because you have to make manual data and event binding…

  • Distribution —we have the most of responsibilities divided between the Presenter and the Model, with the pretty dumb View…
  • Testability — is excellent, we can test most of the business logic due to the dumb View.
  • Ease of use —… the amount of code is doubled compared to the MVC, but at the same time, idea of the MVP is very clear.

Thirdly, No doubt you’ve heard at least in passing of MVVM and its enablers of the Reactive Cocoa ilk, which decouple similarly to MVP,

  • the MVVM treats the view controller as the View
  • There is no tight coupling between the View and the Model

In addition, it does binding like the Supervising version of the MVP; however, this time not between the View and the Model, but between the View and the View Model.

So what is the View Model in the iOS reality? It is basically UIKit independent representation of your View and its state. The View Model invokes changes in the Model and updates itself with the updated Model, and since we have a binding between the View and the View Model, the first is updated accordingly…

There is one bitter truth about reactive frameworks: the great power comes with the great responsibility. It’s really easy to mess up things when you go reactive. In other words, if do something wrong, you might spend a lot of time debugging the app…

Yes. Yes, you might. If you mix your FRP with Core Data, you will, we confidently predict.

  • Distribution —…the MVVM’s View has more responsibilities than the MVP’s View. Because the first one updates it’s state from the View Model by setting up bindings, when the second one just forwards all events to the Presenter and doesn’t update itself.
  • Testability —the View Model knows nothing about the View, this allows us to test it easily. The View might be also tested, but since it is UIKit dependant you might want to skip it.
  • Ease of use —…in the real app where you’d have to forward all events from the View to the Presenter and to update the View manually, MVVM would be much skinnier if you used bindings.

Some other worth reading discussions on architecting with MVVM:

And lastly, we’d skipped past this VIPER thing up to now, but anything described as “LEGO building experience transferred into the iOS app design” must be fun, yes?

VIPER makes another iteration on the idea of separating responsibilities, and this time we have five layers. Topping the View,

  • Interactor — contains business logic related to the data (Entities) or networking, like creating new instances of entities or fetching them from the server. For those purposes you’ll use some Services and Managers which are not considered as a part of VIPER module but rather an external dependency.
  • Presenter — contains the UI related (but UIKit independent) business logic, invokes methods on the Interactor.
  • Entities — your plain data objects, not the data access layer, because that is a responsibility of the Interactor.
  • Router — responsible for the segues between the VIPER modules.

Basically, VIPER module can be a one screen or the whole user story of your application — think of authentication, which can be one screen or several related ones. How small are your “LEGO” blocks supposed to be? — It’s up to you…

  • Distribution —undoubtedly, VIPER is a champion in distribution of responsibilities.
  • Testability —no surprises here, better distribution — better testability.
  • Ease of use —finally, two above come in cost of maintainability as you already guessed. You have to write huge amount of interface for classes with very small responsibilities.

To help with that “huge amount”, check out Generamba, introduced here :

… An average iOS developer creates only one class per screen. But for the one who uses VIPER that’s a moment of suffering. To be true – it’s a little longer than just a moment. Usually he has to create and fill with boilerplate code for around five classes, six protocols and five test-cases … That were the reasons to create our own code generator called Generamba. We got a highly extensible tool for a wide range of different code generation tasks though originally it was developed with just VIPER modules in mind.

Another application of the VIPER principles to simplifying view controllers is

Humble Object Pattern in Swift

For a side assist to the model view whatever patterns when networking is involved — and when isn’t it these days? — check out

Exploring MVC-N in Swift

… So, you cache the data, change the layer, and each one of the ViewControllers will stick it in the cache as they get data. When any other ViewController comes up, they can get the data out of the cache. No. This is bad.

This is what I refer to as the “anti-pattern”. I cannot count the number of times I have seen this, or done it myself. This is the pattern I am attacking. I am openly saying: please stop doing this. We want to write code, we want to see results right away, and we end up doing this. This is a problem…

That is what we should be doing at design time, not at the 11th hour when we are shipping tomorrow morning, and saying “I need to refactor all this”. When we have the UI/UX, we understand how the app needs to come together, and that is when we should be looking at it.

“I need data from the network. Where do I put that code to get the data out of the network?” This is where the MVC-N comes in…

For a completely different option, check out ReSwift (née ReduxKit/SwiftFlow), a Swift version of Redux:

Unidirectional Data Flow in Swift: An Alternative to Massive View Controllers

Redux is an alternative or a variation of the Flux framework that was developed at Facebook, and that Facebook now uses for most of their web applications. The main idea is that information always only flows in one single direction. We don’t have communication between individual view controllers, we don’t have individual delegator callback blocks. Information flow is structured and set in one very specific way…

Along the same Flux-inspired lines is Ziggurat iOS App Architecture.

Of course, if you have seriously simple needs, having a controller at all might be overkill:

Design Patterns in Swift: Document-View

The document-view pattern was once the preferred pattern used in Visual C++ development. Microsoft built the original Microsoft Foundation Classes around this pattern, in fact, back in the dark ages. It’s not used much today, but it’s useful when you have simple data management needs…

And finally, here’s a resource for even more deep diving into architectural patterns:



A Declarative Architecture for Swift Apps

Improve your iOS Architecture with FlowControllers

boilerplate: “Select the right architecture and functional reactive programming framework.”

Functional Core Reactive Shell

A Different Take on MVVM with Swift: “this is just my way of doing MVVM … I call it Scene-Stage-Director.”

NonReactiveMVVM: MVVM: A non-reactive introduction

iOS-Awesome-Starter-Kit: “The perfect combination: Clean Swift + ReSwift + PromiseKit.”

Getting Started with PromiseKit

Faster Together: Uber Engineering’s iOS Monorepo

VIPER architecture: Our best practices to build an app like a boss

iOS Project Architecture: Using VIPER

Viperit: “Write an iOS app following VIPER architecture. But in an easy way.”

Swift with a hundred engineers

Good iOS Application Architecture: MVVM, MVC, VIPER Which Architecture is the Best?

VIPER-S: Writing Your Own Architecture to Understand Its Importance (Part 1) + Part 2 + Part 3

Struggling with iOS Design Patterns? Embrace Modlizer

Taming Great Complexity: MVVM, Coordinators and RxSwift

Architecting iOS Apps with “Core”

Good iOS Application Architecture: MVVM vs. MVC vs. VIPER

Unidirectional Data Flow: Shrinking Massive View Controllers

New iOS Software Architecture: 4V Engine

MVVM at Scale: Not so Simple…

Driving View-State through Data for Fun and/or Debugging

iOS Architecture: A State Container based approach

Avoiding singletons in Swift

Much ado about iOS app architecture

MVVM — MVC done right.

View-state driven applications

Model-View-Controller without the Controller

A Flexible Routing Approach in an iOS App

Pragmatic iOS Development: In defence of MVC


Protocol Oriented Tips For MVVM in Swift

Swift Pitfalls: Here Be Dragons

It’s always exciting to live through a period of exploration and evolution, isn’t it? A bit too exciting at times, you might think. Here’s a collection of subtleties you might run into out in the unexplored regions of the new ecosystem, particularly on the Objective-C borderlands where the ground is treacherous and monsters roam:

Surprises with Swift Extensions

Today, we received a report for a very weird crash with a stack trace that contained only UIKit symbols, but was clearly triggered by a specific action in PSPDFKit…

… That was it. These seemingly innocent extensions were overriding private API. Apple’s private API detection is not super sophisticated and wasn’t triggered when the app was uploaded to the App Store. It’s also not a public symbol so there were no warnings, not even a log message. Unprefixed categories are always dangerous, especially on classes that you do not own, like UIViewController. In PSPDFKit, we use categories for shared code, but prefix any method with pspdf_ to be absolutely sure we do not hit any name clashes. It’s certainly not pretty, and prefixes in Swift look even more alien, yet as you can see in this bug hunt, they are definitely necessary.

The whole story is worth a read, if you haven’t run into the overriding private API problem before — especially not of the “crash immediately on launch with the new OS point release” variety, but that’s another story altogether — or you can just cut to the chase with

tl;dr: Swift extensions on Objective-C classes still need to be prefixed. You can use @objc(prefix_name) to keep the name pretty in Swift and expose a prefixed version for the ObjC runtime.

To Optional or Not to Optional: IBOutlet

“When you declare an outlet in Swift, you should make the type of the outlet an implicitly unwrapped optional … When your class is initialized from a storyboard or xib file, you can assume that the outlet has been connected.” — Using Swift with Cocoa and Objective-C, Apple

… Except in practice there are tons of edge cases in the lifecycle of a view controller where this simply isn’t true. And what happens when you try to access emailField when the view isn’t loaded for some reason? The app crashes…

UIKit was written during the era of nil messaging, and I’ve come to realize it isn’t safe to 100% assume IBOutlets can’t be nil. Going forward I’ll be using optionals for my IBOutlets. I have a task in my bug tracker to scrub all my IBOutlets to covert them from implicitly unwrapped to standard optionals. A few extra question marks never hurt anyone; I’d rather my app not crash.

Some more discussion of appropriate outlet semantics in Outlets: Strong! Or Weak?

Seven Swift Snares & How to Avoid Them

⚠ Double-check attribute names that override protocol extensions.

⚠ For every attribute defined in a protocol extension, declare it in the protocol itself.

⚠ Do not extend an imported protocol with a new attribute that may need dynamic dispatch.

⚠ Avoid extending a protocol with a restriction if the new attribute might need dynamic dispatch.

⚠ Avoid assigning the result of an expression with side-effects to left-hand-side with optional chaining.

⚠ Avoid in-out parameters in closures.

⚠ Avoid currying with in-out parameters because the code will fail if you later change it to explicitly create a closure.

Be careful out there!

h/t: iOS Dev Weekly!


Swift Golf

Hipster Swift: Demystifying the Mysterious

10 Swift One Liners To Impress Your Friends

10 Tips when moving from Objective-C to Swift

Swift Mistakes I’ve Made – Learning Swift Best Practices

Implicitly Crashing Optionals

Avoiding the overuse of @objc in Swift

Swift With Two Twos!

It’s update day! New iOS 9.3, OS X 10.11.4, Xcode 7.3 (+ Alcatraz 1.17), and … Swift 2.2! Time to check out the latest changes — and to perk up your heart rate just a little bit, it’s “mostly source-compatible with Swift 2.1”. Which is true, but be prepared for many selector-related warnings:

We are very pleased to announce the release of Swift 2.2! This is first official release of Swift since it was open-sourced on December 3, 2015. Notably, the release includes contributions from 212 non-Apple contributors — changes that span from simple bug fixes to enhancements and alterations to the core language and Swift Standard Library.

Language Changes

Swift 2.2 is a minor language release that is mostly source-compatible with Swift 2.1. It contains the following language changes that went through the Swift’s evolution process:

Beyond these language changes Swift 2.2 also contains numerous bug fixes, enhancements to diagnostics, and produces even faster-running code…

Details on those bug fixes and diagnostics at swift/CHANGELOG.md and in the Xcode 7.3 release notes. Good discussion of the important changes over at hackingwithswift.com too:

What’s new in Swift 2.2

Naturally, those on top of things objc.io folk have their latest magnum opus Advanced Swift ready to go with 2.2 now, which looks like a worthwhile read: check out the online preview.


New Features in Swift 2.2