Playground Secrets: Update and new tricks

A big thanks to James Dempsey for tracking down not one but two new playground markup keywords. In addition to the new Xcode 7.3 experiment, note, and important markup, you can now add example and callout.

The example keyword adds a well-formated example that introduces a section that demonstrates a new concept:

Screen Shot 2016-05-03 at 9.46.55 AM

The callout in constrast lets you use any title you want, enabling you to add flexible tips, warnings, cautions, trivia, and so forth.

/*: - callout(Trivia): The superscript dot over a lowercase (or miniscule) letter i is called a [tittle]( and is considered an integral part of the letter's glyph. ![tittles](tittles.png) */

Screen Shot 2016-05-03 at 10.04.43 AM

One more great find in Xcode 7.3, is that the fuzzy auto complete pop-up now incorporates documentation markup so you can view the description of any selected item:

Screen Shot 2016-05-03 at 8.17.02 AM

I’ve updated both Documentation Markup and Playground Secrets to include the new tech features and expanded coverage with regard to callouts, Swift 3 upcoming features, and more.

Both books are available at iTunes and LeanPub. Your continued support enables me to keep revising these works and buy an occasional cup of coffee. Thank you!

Despite ridiculous technological difficulties with Pearson’s pilot Content Update Program, I am still pushing ahead with incorporating the Swift 2.2 changes into the Cookbook. (Pearson, if you haven’t heard, laid off about half or more of their workforce, has shut down  marketing, and is likely to close its developer library program.)

Despite these difficulties, I think the Cookbook (the name was chosen long before I started writing, and no, I couldn’t change it when it became clear that Swift was still evolving) is a darned nice addition to any development library.

I think you’ll like the book a lot if you can get past the title. It’s full of practical, sensible how-to and is perfect for anyone who has finished Apple’s tutorial and wants to start with real development.

Thank you for buying my books and helping me to support my family.

ParallaxCarousel – Open Source iOS Component For Image Carousels With A Nice Parallax Effect

ParallaxCarousel from Matteo Tagliafico is an open source Swift iOS component for creating carousel views with a nice 3d parallax effect.

You can implement ParallaxCarousel within interface builder and if you like you can create a flat carousel without the parallax effect. Paging dots are also shown to indicate the number of available carousel selections.

This image from the readme shows ParallaxCarousel in action using the 3D parallax effect:


You can find ParallaxCarousel on Github here.

A nice component for creating image carousels.

Original article: ParallaxCarousel – Open Source iOS Component For Image Carousels With A Nice Parallax Effect

©2016 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.

The great space-delimited comma war

From an intense disagreement this afternoon:

func foo<T: protocol<A,B>>(x: T)


func foo<T: protocol<A, B>>(x: T)

Clearly the latter wins. But why? Because orthography matters.

Strunk writes, “omit needless words”. But Strunk did not write, “omit needless keystrokes”. Space-delimited commas offer semantic and syntactic separation between two related items. It follows the convention commonly used in mathematics.

A space-delimited comma supports natural language precedent allowing the eye to scan each token as a distinct entity. It serves as a pause signal for the code reader, allowing mental differentiation between the two elements (in this case, dual protocols).

Without that pause, the two protocols blend into an undifferentiated mass, especially as they are surrounded by the angle brackets used to construct the protocol conformance and type parameter. Allowing space to breathe creates a more readable product, and is to be preferred to its spaceless alternative[1].

[1] This advantage is to be conveyed to all users, whether or not they are Canadian in origin.

Dear Erica: Why doesn’t NSLog support Swift objects

Dear Erica, when I try to run the following code in a playground, Xcode dies, with the complaint “error: ‘NSLog’ is unavailable: Variadic function is unavailable NSLog(“%@”, Foo()) Foundation.NSLog:2:13: note: ‘NSLog’ has been explicitly marked unavailable here“. What gives?

import Foundation
class Foo {}
NSLog("%@", Foo())

Your first problem is that Foo is not an NSObject.  If you subclass Foo from NSObject, the error goes away and the log statement outputs “<__lldb_expr_24.Foo: 0x7fc9d2920210>“. Still not exactly what you’re looking for, I know.

The reason is that in our discussion going back and forth I know you wanted to use CustomDebugStringConvertible with NSLog and the way you make that happen is by using normal string interpolation with NSLog:

class Foo: CustomDebugStringConvertible {
    var debugDescription: String {return "Superfoo!"}


Swift and NSLog aren’t really set up to do the format string interoperation you were looking for. However, if you’re bound and determined to do so, there is a solution:

class Bar: NSObject {
    override var description: String {return "Superbar!"}

NSLog("%@", Bar())

In this case, instead of trying to conform to CustomDebugStringConvertible, you override the built-in NSObject property to get the custom output you were looking for. Implementing description (OS X 10.10 and later) returns a string that “describes the contents of the receiver”. NSLog can then use this result to create a textual representation of your object, which can be used in a formatted string.

2016-05-02 14:12:43.106 Untitled Page 3[5161:524832] Superfoo!
2016-05-02 14:12:43.107 Untitled Page 3[5161:524832] Superbar!

Like in Swift native classes, NSObject also supports a debug variation (debugDescription, OS X 10.8 and later), which is preferred for presentation in the debugger.

Survival of the Swiftest: What’s up in Swift Evolution


SE-0068: Expanding Swift Self to class members and value types is accepted with modifications:

The review of SE-0068: “Expanding Swift Self to class members and value types” ran from April 20…25, 2016. A subset of the proposal has been *accepted*:

This proposal had light discussion in the community review process, but the core team heavily debated it.  It includes two pieces:

1. Expanding the existing support for Self to work in value types, and in the bodies of classes.
2. Replacing the x.dynamicType expression with x.Self, a purely syntactic change that eliminates the “dynamicType” keyword.

The core team has accepted the first half for this proposal.  This allows the use of “Self” as shorthand for referring to the containing type (in the case of structs, enums, and final class) or the dynamic type (in the case of non-final classes).  Most of the discussion in the core team centered around whether people familiar with the former behavior would be surprised by the (more general) behavior when using it in a class, but they came to agree that this is actually a simple and general model, and a helpful point of consistency.

In contrast, there are still a number of concerns with rebranding x.dynamicType as x.Self.  This may (or may not) be the right ultimate direction to go, but it should be split out of this proposal.  There is another outstanding proposal that would eliminate the “Type.self” syntax as being necessary, and the core team would like to resolve that discussion before tackling x.dynamicType.

A third part of the proposal, already removed, which would introduce #Self, to be replaced at compile time with the calling context for use in return types, variable types, and debug statements, will also be deferred until after the “Type.self” syntax is settled.

SE-0065: A New Model for Collections is accepted.

We propose a new model for Collections wherein responsibility for index traversal is moved from the index to the collection itself. For example, instead of writing i.successor(), one would write c.index(after: i). We also propose the following changes as a consequence of the new model:

  • A collection’s Index can be any Comparable type.
  • The distinction between intervals and ranges disappears, leaving only ranges.
  • A closed range that includes the maximal value of its Bound type is now representable and does not trap.
  • Existing “private” in-place index traversal methods are now available publicly.

SE-0067: Enhanced Floating Point Protocols [ACCEPTED] enters Review #2 with incorporated feedback to 4/29. “Revision 2 reintroduces some of the details of the Arithmetic protocol from earlier drafts of this proposal, but as methods in the FloatingPoint API, with the goal of reducing the number of overloads for basic operations. This change was requested by some members of the core langauge team. Revision 2 also incorporates a number of suggestions from the review list and corrects some typos; thanks especially to Xiaodi Wu for thoughtful feedback.”

SE-0070: Make Optional Requirements Objective-C-only [ACCEPTED] in review to 5/3. “Swift currently has support for “optional” requirements in Objective-C protocols, to match with the corresponding feature of Objective-C. We don’t want to make optional requirements a feature of Swift protocols (for reasons described below), nor can we completely eliminate the notion of the language (for different reasons also described below). Therefore, to prevent confusion about our direction, this proposal requires an explicit ‘@objc’ attribute on each optional requirement to indicate that this is an Objective-C compatibility feature.”

SE-0071: Allow (most) keywords in member references [ACCEPTED] in review to 4/29. “The Swift API Design Guidelines consider enum cases as values that use the lowerCamelCase naming conventions. This means that case names that previously did not conflict with keywords (such as DefaultPrivateRepeat) now cause conflicts, a problem that is particularly acute when the naming conventions are applied by the Clang importer (per SE-0005). To mitigate this issue, this proposal allows the use of most keywords after a “.”, similarly to how SE-0001 allows keywords are argument labels.”

SE-0061: Add Generic Result and Error Handling to autoreleasepool() [ACCEPTED] in review to 4/26. Not to be confused with Generic Result and Error Handling in Deadpool. “The autoreleasepool function in the standard library does not currently support a return value or error handling, making it difficult and error-prone to pass results or errors from the body to the calling context.”

In Review

  • SE-0017: Change Unmanaged to use UnsafePointer in review to 5/3. “The standard library Unmanaged<Instance> struct provides a type-safe object wrapper that does not participate in ARC; it allows the user to make manual retain/release calls”. SE-0017 proposes to replace the use of of COpaquePointer with UnsafePointer<Void> and UnsafeMutablePointer<Void> in the Unmanaged API.
  • SE-0032: Add find method to SequenceType in review to 5/3. I have personal issues with SequenceType, namely that there may non-terminating sequences. My issues have nothing to do with this proposal, which Kevin clarifies: “I have seen people write code like seq.lazy.filter(predicate).first, but this doesn’t actually work lazily because .first is only a method on Collection, which means the call to filter() ends up resolving to theSequence.filter() that returns an Array instead of to LazySequenceProtocol.filter() that returns a lazy sequence. Users typically aren’t aware of this, which means they end up doing a lot more work than expected.”
  • SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib in review to 5/3. Love the proposal. Hate the name mismatch. Either prefix/suffix or take/drop makes more sense to me. Worse, the beautiful and fairly obvious iterate is under fire and may become something like “ice ice baby” or “unfold(_:applying:)“. This review gets all the +1s, except for the naming.
  • SE-0052: Change IteratorType post-nil guarantee in review to 5/3. “Currently, the documentation for has the precondition that when calling next(), no preceding call to next() should have returned nil, and in fact encourages implementations to raise a preconditionFailure() for violations of this requirement. However, all current 27 IteratorType implementations in the standard library return nilindefinitely. Many users are likely unaware of the precondition, expecting all iterators to return nil indefinitely and writing code that might rely on this assumption. Such code will usually run fine, until someone does in fact pass in an iterator not repeating nil (it’s a silent corner case).”
  • SE-0066: Standardize function type argument syntax to require parentheses in review to 5/2. “This proposal suggests that we simply eliminate the special case and require parentheses on all argument lists for function types.” I’m strongly for this one.
  • SE-0069: Mutability and Foundation Value Types in review to 5/4. This one gives “mutability when you need it” to wrap Foundation variations invisibly to Swift use.
  • SE-0072: Fully eliminate implicit bridging conversions from Swift runs to 5/2. “In Swift 1.2, we attempted to remove all implicit bridging conversions from the language. Unfortunately, problems with how the v1.2 compiler imported various un-annotated Objective-C APIs caused us to scale back on our ambitions. In the interest of further simplifying our type system and our user model, we would like to complete this work and fully remove implicit bridging conversions from the language in Swift 3.”

Awaiting Scheduling

Like my posts? Consider buying a book or two. Thanks!

StateView – An iOS Swift React Inspired Automatically Updating UIView Component

StateView is an open source Swift iOS component from Sahand Nayebaziz providing a UIView subsittute that automatically updates when the data changes.

As the readme states:

StateView is a UIView subclass that uses modern thinking and inspiration from what Facebook has done with React and the DOM to make displaying and updating your views easier, simpler, and more fun.

StateViews update themselves when data changes calculating any differences and only changing when necessary.  StateViews can also automatically update their subviews which an be standard views.

You can find StateView on Github here.

An interesting component for adding some reactivity to your views.

Original article: StateView – An iOS Swift React Inspired Automatically Updating UIView Component

©2016 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.

TabDrawer – iOS UI Component For Tab Bars With A Slide Out Drawer For More Options

TabDrawer from Winslow DiBona is an open source Swift based iOS component for creating tab bars with an added slide-out drawer for displaying more options in the user interface.

With TabDrawer options can be added to each tab bar selection that are shown when the user selects an option. This makes for a great way to make use of initial screen space.

This animation from the readme shows the concept in action:


You can find TabDrawer on Github here.

A nice custom tab bar component.

Original article: TabDrawer – iOS UI Component For Tab Bars With A Slide Out Drawer For More Options

©2016 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.

iOS Dev Weekly - Issue 248 - Apr 29th 2016


Congratulations to everyone who got a WWDC ticket this year! If you didn't get one then fake Siri has some suggestions for alternative conferences 😄. I'll not be there this time but I'll be following along from home.

There's still plenty to talk about in the next few weeks leading up to the conference itself though, so let's get on with the links!

Dave Verwer


CareKit Now Available

This week saw the release of CareKit, the partner to ResearchKit. While ResearchKit helps researchers gather data and manage content, CareKit is designed more to help patients with active management of their conditions. It's available on GitHub right now and again, is already getting contributions. What a fantastic initiative by Apple.

Xamarin goes open source

After Xamarin's acquisition it was announced that it would be released as open source, and here it is! I know most people reading this are using Objective-C or Swift, but this is interesting news nonetheless.

Upcoming Requirement for watchOS Apps

If you're still shipping a WatchKit 1 app you'll need to convert it to be native before June 1st. The conversion shouldn't be a huge job but you'll want to get started on this sooner rather than later.

UPDATE: Apologies, this only affects NEW apps, not existing apps. Panic over! 😌

Sponsored Link Video Tutorials

Join over 4,000 subscribers in keeping your Swift & iOS skills up-to-date via hands-on tutorials - in video form! Learn Swift, Auto Layout, Custom Controls, Stack Views, Core Data, tvOS, Concurrency, and more - the largest collection of Swift & iOS video tutorials anywhere.


Running UI Tests on iOS With Ludicrous Speed

Peter Steinberger talks about speeding up UI tests in PSPDFKit. The issue with animations here is really interesting and I completely agree that disabling animations altogether for testing is not the right thing to do. The trick of speeding them up is a clever one though. On a similar subject Alan Fineberg also wrote about speeding up the test suite in Square Register.

Change your API endpoint/environment using Xcode Configurations

Nice tip from Daniel Galasko for working with staging/production API endpoints in your app. This is a common problem and avoids the #ifdef dance that you might be doing right now.

Xcode Search: the Hidden Gems

Searching in Xcode is very powerful, but the UI for accessing that power can sometimes feel a little hidden. Arkadiusz Holko gives us a thorough walk through of all the options available.



NSHipster gets back to the truly obscure iOS APIs this week with a look at autocorrect and how to bend it to your will inside your apps.

iOS Push Notification Background Fetch Demystified

Background fetch is a hugely useful feature of iOS, but it's a little tricky to get working. Nicholas Solter has a great article here with all of the details of getting it up and running.


Last week I linked to this article on a possible replacement for the hamburger menu, and this week Winslow DiBona has put together an implementation of it. I'm still not convinced that it's a perfect replacement given that it changes the standard tab bar interaction quite significantly, but if you're interested in giving it a go then here's an implementation!


A Quick Design Exploration of Bots within the Apple Ecosystem

So let's say that bots are the future of apps. How would they look inside iOS if they were blessed by Apple? J.B. Chaykowsky takes a look at a possible future where AgentKit is a thing. Or, if you're not convinced, you might agree more with Dan Grover or Thomas Baekdal who both take the opposite stance.

Design debugging

Debugging is a very familiar concept for developers, but not so much for designers. Marc Edwards gives us some insight into the techniques he's come up with for debugging his designs. Really interesting.


The Easiest Way to Find a Job

Sit back while job offers come to you. Instantly apply to 3,500+ companies and receive offers including salary and equity up-front. Try it today. 🙃

Text editing on iOS is kind of a mess

Join our research lab! Work from anywhere; two month contract.

And finally...

Please enter your phone number

I really, really hope this is real. 😱

This RSS feed is published on You can also subscribe via email or Safari push notifications.

StackViewController – Enhanced UIStackView Based Component For Forms And Static Lists

StackViewController is an open source component from Seed that builds on UIStackView adding a number of features for creating forms and lists.

Often UITableView is used for creating forms, but UITableView requires a large amount of boiler plate code, can be tedious when working with variable height content, and especially difficult if the layout needs to change.

StackViewController allows you to lay out views as simply as you would with UIStackView, but adds some features necessary for lists and forms such as scrolling support, autoscroll support for getting out of the way of the keyboard and customizable separator views.

Here’s an image showing a form created with StackViewController:


You can find StackViewController on Github here.

A nice component for displaying forms and static lists.

Original article: StackViewController – Enhanced UIStackView Based Component For Forms And Static Lists

©2016 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.

Sensitive – Swift Library That Dramatically Simplifies Implementing Common Gesture Support

Sensitive is an open source Swift library from Igor Matyushkin that provides a very simple syntax for handling the most common gestures.

With Sensitive you don’t need to worry about utilizing UIGestureRecognizer but rather simply add the Sensitive gesture handlers to a UIView, set your callback, and configure some variables.

This example shows how one would set up a simple double tap gesture recognizer that changes the view color.:

let view = UIView()

view.onTap({ (tapGestureRecognizer) -> Void in
    // Handle tap on view
view.backgroundColor = .greenColor()
}) { (tapGestureRecognizer) -> Void in
    // Configure gesture recognizer
    tapGestureRecognizer.numberOfTouchesRequired = 1
    tapGestureRecognizer.numberOfTapsRequired = 2

Within sensitive are gesture handlers for tap, swipe, pan, pinch, and rotation gestures.

You can find Sensitive on Github here.

A nice simple way to handle gestures with a clean Swift syntax.

Original article: Sensitive – Swift Library That Dramatically Simplifies Implementing Common Gesture Support

©2016 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.