Under The BridgeUnder The Bridge

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

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:


Tuples are not sequences: Enumerating tuple values in Swift

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

Divide and conquer How modularizing your apps is helping us to scale our Xcode app

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

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

Parse Drops the BaaS

So the veritably seismic news of the week, should you rely on Parse for mBaaS services, is their pulling a StackMob:

We have a difficult announcement to make. Beginning today we’re winding down the Parse service, and Parse will be fully retired after a year-long period ending on January 28, 2017. We’re proud that we’ve been able to help so many of you build great mobile apps, but we need to focus our resources elsewhere…

If you think hosted services are a business opportunity, here’s source for a head start :

Parse Server was built in Node.js and works with the Express web application framework. It can be added to existing web applications, or run by itself. Check out the server and migration guides here, the open-source repository here, and the example project here. We encourage you to provide bug reports and feedback via the GitHub issues on the Parse Server repository. There’s even a developer wiki, which can be found here.

Nearly everything you’ll need for your app is supported in Parse Server, with the main exceptions of Push delivery, Analytics, and Config…

So that’s something. For a great roundup of rants and insights on just how little that something is, head over to Michael Tsai’s and check out Sunsetting Parse. All worth reading to share the pain, but here’s some particularly good giggles:

Guy English:

If it had been me shutting down Parse I would have changed the home page to not point out how many “Trust Us”.

Jeff Lawson:

“But seriously developers, trust us next time your needs temporarily overlap our strategic interests. And here’s a t-shirt.”

Joel Bernstein:

The subtext to the Parse shutdown is “never trust a Facebook platform ever again, for any reason”

Feel the burn!

Moving on, you can always take Marco Arment’s advice:

For whatever it’s worth, running your own Linux servers today with boring old databases and stable languages is neither difficult nor expensive. This isn’t to say “I told you so” — rather, if you haven’t tried before, “You can do this.

But if you’d really, seriously, rather not have to add maintaining your own backend to your load, there’s a crowdsourced list here that looks good:

ParseAlternatives: A collaborative list of Parse alternative backend service providers.

Current categories are:

Personally, we’d like to try out CloudKit one of these days…


iOS Dev Tools: Backend Services

How To Migrate Your App And Protect It From Shutdowns Like Parse’s

Top 5 Parse Alternatives

Migrating My Data From Parse

AppCoda.com Parse series:

Deploying Parse Dashboard

Parse Server: A Viable Open Source Platform?

Parse Server – 100 days later

Migrating to Parse Server: Adventures With Heroku and Why We Broke Up

Parse Server Tutorial with iOS

The Grand Opening

So, just in case you spent the weekend being dead — and probably didn’t miss it even if you were — Swift.org is a thing!

And unlike previously accustomed source dumps, this is going to be the working repo going forward:

“The Swift team will be developing completely in the open on GitHub,” Federighi told Ars. “As they’re working day-to-day and making modifications to the language, including their work on Swift 3.0, all of that is going to be happening out in the open on GitHub.”

Open, indeed — to general surprise, the entire commit history of Swift went public; check this visualization out:

Over 5 years of work, 23,000+ commits condensed into 8 minutes

Rather interesting is the focus in bringing Swift to the cloud. There’d been these Perfect people,

Wouldn’t it be amazing if you could develop every aspect of your apps, front and back end, all using Swift™? We think so. That’s the vision behind Perfect. Perfect is the first enterprise-grade web server and web toolkit for the Swift programming language…

which looked like a rather … selective … interest. But that’s not what Apple thinks:

“IBM has been a major source of that feedback for us, and they’ve been eager since they got started with Swift, saying “how can we take these applications we’re writing for enterprise all the way from the mobile platform into the cloud?” …

Where we expect the community to really push is the cloud framework, and we think there will be a lot of energy to adapt Swift into the datacenter…

And why yes, IBM is right out of the gate with support for Swift, in your browser no less:

Today, IBM introduced an online 2.2 Swift Sandbox. John Petitto writes, “We love Swift here and thought you would too so we are making our IBM Swift Sandbox available to developers on developerWorks.”

Another Swift browser REPL is at Swiftstub.com.

Well, the idea that community participation will drive adoption might work out, and might not, but we know one thing for sure in less than a week:

Swift’s comments and test suite are on track to be one of the most correctly spelled and best indented ones in the industry! 🐙🐱

Indeed. If you can’t find any more speling misteaks and feel like getting in on the Linux development action, here’s a great start:

Introduction to Open Source Swift on Linux

In this tutorial, you’ll set up a Linux environment on your Mac, install Swift, and compile and run some basic Swift examples on Linux. Then you’ll take stock of the new bits offered by Apple, and finish off with a look into into the misty crystal ball of time, and guess what this all means for the future…

Oh, that’s not hard to guess, is it now?

And here’s some more suggestions for getting involved:

  • Search for FIXME in the code base and make the fix – @ayanonagon
  • Add more Unit Tests (something I wrote down as my personal strategy) – @KostiaKoval
  • Fix bugs! Yes, Swift bugs are tracked publicly via Jira!
  • As many have noticed, the Foundation Project has a lot of NSUnimplemented(). Instead of complaining (or worse, laughing about it), contribute to it! The nice things is that it’s in Swift – you don’t need to know C++. Here is a great example PR from @simjp!
  • For larger changes, write a proposal and ask for reviews from the community – amazing example by @ericasadun

As Jesse Squires said it the best: Let the revolution begin!

Pencil This In

Managed to get your Apple Pencil delivered yet? If you have, and you’ve gone through some introductory tutorials, here’s a remarkable burst of creative applications from the redoubtable FlexMonkey for you to try out:

PencilScale – Using an Apple Pencil with an iPad Pro as an Electronic Scale

Following all the interest created by my Plum-O-Meter, I couldn’t resist trying a similar experiment with my newly arrived Apple Pencil, so here’s PencilScale, an iPad Pro application that uses the Pencil as an electronic scale … The update() method simply subtract’s the touch’s force from a base weight (which is set as the current touch force when the ‘zero’ button is pressed) and multiplies it by 140 which gives the weight in grams (very roughly) …and amazingly, that is pretty much all there is to it!

PencilController – Using Apple Pencil as a 3D Controller for Image Editing

My PencilController project is a Swift app for iPad Pro that applies two Core Image filters to an image: a hue adjustment and a colour controls which I use to control the saturation … The hue filter’s value is controlled by the azimuth angle and the saturation is controlled by the altitude angle: when the pencil is vertical, the saturation is zero and when it’s horizontal the saturation is eight (although when the pencil is totally horizontal, its tip isn’t actually touching the screen, so the highest saturation the app can set is about six and three quarters).

PencilSynth – An Apple Pencil Controlled Synthesiser

PencilSynth is an AudioKit powered synthesiser (mis)using the Pencil as a joystick controller. It’s based on AudioKit’s TouchRegions demonstration and works like this:

  • The Pencil’s horizontal position on the screen defines the output frequency
  • The Pencil’s vertical position on the screen defines the output modulating multiplier
  • The Pencil’s altitude angle defines the output carrier multiplier
  • The Pencil’s azimuth angle defines the output modulation index

FurrySketch: Hirsute Drawing with an Apple Pencil

I thought it was about time to play with the Pencil for its intended purpose, sketching, and see how I could use its orientation data to affect brush strokes.

FurrySketch is a Pencil powered drawing application that draws a sort of multicoloured hair and, most excitingly, the hair’s direction matches the angle of the Pencil. It was super simple to write and, at least in my opinion, gives really nice results … If you are writing drawing apps, adding Pencil support is not only super easy, it adds real value for your users. The technique I’ve used here to draw hair is only a few lines of code way from spray cans and air brushes and I genuinely believe the iPad Pro will prove to be an amazing device for creatives.

Seen any other creative applications? Let us know! And if you’re still pondering over getting one, check out Gus Mueller’s love letter:

The Hype is Real

Every single stylus that has been made for the iPad or iPhone has been a pile of dog shit when compared to what you can do with a Wacom tablet. Even compared to what you could do 20 years ago with a Wacom tablet. The KoalaPad on an Apple //e was probably better.

It’s been hard, and upsetting. And so much money wasted on crappy iOS styluses. I stopped paying attention whenever a new stylus was announced, since I was inevitably let down.

And then this week I got the Apple Pencil (which is Apple speak for a stylus) and an iPad Pro. This new tablet from Apple has the hardware support needed to make a useful stylus. Hardware support that has been missing for five long, very long, agonizing years.

And It’s God Damn Amazing.

It feels absolutely right. Super low latency, palm rejection, and … it just works.


Scribe: A Handwriting Recognition Component for iOS

BristlePaint: Embossed Painting with Individual Bristles using SpriteKit Normal Mapping

Smooth Drawing for iOS in Swift with Hermite Spline Interpolation

Apple Pencil Controlled Christmas Tree Bowling with SceneKit

Apple Pencil Tutorial: Getting Started

Playground Power

There’s a new article for your attention up at the official Swift blog, Literals in Playgrounds:

New in Xcode 7.1 is the ability to embed file, image, and color literals into your playground’s code. Literals are the actual values of your data represented in their native format, directly within the Xcode editor. For instance, there’s no need to type “myImage.jpg” in the editor – just drag your image from the Finder and the actual image will appear in-line with your code. Instead of showing RGB values to indicate color, the playground will render a color swatch. Literals in playgrounds behave similarly to code you would otherwise hand-author in regular Swift code, but are rendered in a much more useful manner…

If you’ve been underutilizing those playground thingys so far, Playground Secrets and Power Tips is literally a great way to get up to speed,


and it’s literally up to the minute:

So what’s new in this edition? I’ve done a back to front update to incorporate all the new XCPlayground features in Xcode 7.1 beta 3: the new liveView feature that can be used with views and view controllers (and the XCPlaygroundLiveViewable protocol that supports rendering arbitrary model objects), the new ways to continue execution and capture values, etc.

Also, you’ve probably noticed the move to Markdown this year for playground documentation and Swift Documentation, but now there’s full documentation over at the mothership:

Markup Formatting Reference

Use markup formatting commands to create rich comments in playgrounds and to document your Swift symbols for Xcode quick help. Commands include page level formatting for headers and other elements, inline formatting, and images. Playground formatting commands enable page navigation as shown in the following figure … Swift symbol documentation adds descriptions to symbol completion and quick help for symbols …

So if you’re using those legacy HeaderDoc conventions, why there’s all you need to level up!

And to finish up, perhaps a potpourri of playground posts of particular perspicuity:

General tips: NSHipster’s XCPlayground and Erica Sadun’s multitudinous tidbits

Performance Testing in Xcode Playgrounds: “playground that has a similar function to the “measurePerformance” function in XCT.”

Core Graphics Tutorial Part 3: Patterns and Playgrounds: “draw it in a Swift Playground, and then copy the code to a UIImageView subclass.” Or, Overlooked playground cool stuff #3: “build, preview, and save the image to disk. Perfect for creating masks and labels.”

Swift-Diagram-Playgrounds: “two different approaches to creating Diagrams as value types.”

Numerical Algorithms using Playgrounds: “solve problems that don’t have an analytic solution.”


Little Bites Of Cocoa:

Xcode 7.3 Beta 2 introduces live interactive playgrounds; Interactive Playgrounds

Gameboard: “Gameboards built in a playground.”

XCTestPlayground: “… a simple implementation of most XCTAssert macros to use in a Playground … I use this to do TDD directly inside a Playground and then move the code as-is inside my test files.”

Using a Core Data Model in Swift Playgrounds

To The Nines

Happy iOS 9 Day! Check out all the good stuff announced over at RayWenderlich.com:

This year marks our 5th annual iOS release celebration: the iOS 9 Feast. The iOS 9 Feast consists of 9 courses:

  • Appetizers: Beginning UIStackView & tvOS Tutorials
  • First Course: iOS Apprentice Fourth Edition
  • Second course: iOS Animations by Tutorials Second Edition
  • Third course: Core Data by Tutorials Second Edition
  • Fourth course: iOS 9 by Tutorials
  • Fifth course: watchOS 2 by Tutorials
  • Sixth course: Swift Apprentice
  • Seventh course: 2D iOS & tvOS Games by Tutorials
  • Eighth course: iOS 9 Tutorial Month
  • Dessert: iOS 9 Feast Giveaway

During the iOS 9 Feast, we’ll help you get fully up-to-speed with iOS 9, Swift 2, tvOS, and watchOS 2 development, no matter how you prefer to learn. You’ll learn about UIStackView, iOS 9 Search APIs, Swift 2 error handling, GameplayKit, and much more.

Plus, we have over $18,000 in giveaways for lucky readers – our biggest giveaway yet!

Other tutorial sites worth a look are Hacking With Swift’s iOS 9 collection and the iOS 9 Day-by-Day series:

And here’s various subtleties worth knowing about:

Shipping an App With App Transport Security

There’s already been lots of great discussion about how ATS works – see, for example, Neglected Potential’s Working with Apple’s App Transport Security. Apple has also provided a descriptive tech note on the feature, clearly documenting the expectations of ATS and the exceptions that remain available to developers. And the community has noted in several articles that turning ATS off entirely is generally a Bad Idea.

This article is aimed at a different purpose: to look at the different speed bumps that can show up while building an app alongside ATS, and to explain how to get around them…

Also see Michael Tsai’s roundups App Transport Security and Shipping an App With App Transport Security.

How iOS 9’s Safari View Controller could completely change your app’s onboarding experience

With Safari View Controller, we now will have a way to “talk” to our webpage and learn a little bit about who the user is, and what they were doing, so we can do all of the following:

  • If the user already is logged into the website, you can seamlessly sign them in…
  • If they are not logged in, tailor the onboarding experience for that specific user…
  • Or, if you want to get fancy, you can even change the “intro” UI to be based on which kind of marketing the user came in from…

iOS: You’re Doing Settings Wrong

One of the apparently less known features for iOS 8 and above is the ability to deep link the user into Settings, where they can enable their Location, Notifications, Contacts, Camera, Calendar, HealthKit, etc for your app as needed…

…this gets even better in iOS 9! The Settings screen will have a back button to take the user directly back into your app! Seriously, there is absolutely no excuse to NOT use this.

Get Your App Ready for iOS 9

… iOS will now send out a notification, NSProcessInfoPowerStateDidChangeNotification, when the system enters or leaves low power mode. You can also query the current power state at any time by checking [[NSProcessInfo processInfo] isLowPowerModeEnabled].

If you have any points in your app where you might be able to save some power it’s now a good idea to check the power state and respect the user’s request to help save their battery.

Querying URL Schemes With canOpenURL

… If you build and link against the iOS 9 SDK you need to whitelist the schemes your app will query. What is important to understand is that this policy can also impact older Apps that have not yet been rebuilt with the iOS 9 SDK…

And top off your iOS 9 saviness by checking out this list of clever people and their clever tips!

Top Tips for iOS 9 Development: 12 Community Tips to Get Your App Ready for iOS 9


iOS-9-Sampler: “Code examples for the new features of iOS 9.”

Advanced Touch Handling in iOS9: Coalescing and Prediction; ForceSketch: A 3D Touch Drawing App using CIImageAccumulator

Add iOS 9’s Quick Actions shortcut support in 15 minutes right now!; Lessons learned with 3D Touch; Developing With 3D Touch; Your 3D Touch Spirit Guide; Adding 3D Touch Quick Actions; Peek & Pop; 3D Touch Peek and Pop; Exploring Apple’s 3D Touch; 3D Force Touch: beyond peek & pop; 3D Touch in Swift: A Retrospective; Turning the iPhone 6s Into a Digital Scale; 3D Touch Introduction: Building a Digital Scale App and Quick Actions; The Next Step for 3D Touch; The Trouble With 3D Touch

Getting Started with Search APIs and SFSafariViewController in iOS 9; iOS 9: Getting Started With SFSafariViewController

A First Look at Contacts Framework in iOS 9

Support Universal Links; iOS 9 Universal Links & Forgotten Passwords; iOS 9.2 Deep Linking Guide: Transitioning to Universal Links

iOS 9 Multitasking Tutorial

What’s New in Storyboards?; Secondary Views in Interface Builder’s Storyboards

Xcode Transformers – Settings In Disguise

We’re great fans of .xcconfig files and other textua Xcode build process manipulations around here, and here’s some handy undocumented feature tips for you:

Xcode Build Setting Transformations

Xcode supports the ability to substitute the value of build settings using the $(BUILD_SETTING_NAME) or ${BUILD_SETTING_NAME} syntax in a number of places including Info.plists, other build setting values, and .xcconfig files. In these substitutions it’s also possible to add operators that transform the value in various ways. You may have seen one of these in the Info.plist included in project templates:


This results in the value of the PRODUCT_NAME build setting being transformed into a representation suitable for use in the reverse DNS format used by CFBundleIdentifier. So if PRODUCT_NAME is “Whatever App” the resulting string is “com.company.Whatever-App”.

These transformations can be quite useful but don’t appear to be documented, so here’s the list of available operators and what they do…

Note that these operators can be chained, so you can do things like $(PRODUCT_NAME:lower:rfc1034identifier) or $(CONFIGURATION:upper:identifier).

Be sure to bookmark that for next time you’ve got some manipulating setup to do!

h/t: Michael Tsai!


Sam Marshall writes lots of Xcode-related goodies, check out particularly

The Unofficial Guide to xcconfig files; Managing Xcode; Using Xcode Targets

Convenient Build Settings

Stencil Xcode Plugin “is an Xcode plugin that provides the ability to create custom file templates and use them in your project to create new files groups.”

SwiftLint: “A tool to enforce Swift style and conventions.”

Setting up SwiftLint on Travis CI

“Watch Your Language!”: The Road to Cleaner Code with SwiftLint

SwiftLint Doing Its Best To Ease Conflict

Using SwiftLint and Danger for Swift Best Practices

Xcode Search: the Hidden Gems

Change your API endpoint/environment using Xcode Configurations in Swift