Tomorrow’s Reviews

Reviews starting tomorrow:

Swifty Quicky: Checking for a tuple in an array

Screen Shot 2016-05-23 at 4.33.31 PM

let a: [(Int, Int)] = [(1, 2), (3, 4)]
a.contains((3, 4)) // no!
// error: cannot convert value of type '(Int, Int)' 
// to expected argument type '@noescape ((Int, Int)) throws -> Bool'

Screen Shot 2016-05-23 at 4.33.35 PM

let a: [(Int, Int)] = [(1, 2), (3, 4)]
a.contains({ $0 == (3, 4) }) // yes!

Jordan Rose:

Tuples can’t conform to protocols, so they don’t count as Equatable.

SwiftTweaks – iOS Swift Library For Tweaking User Interfaces On Device

SwiftTweaks is an open source library that allows tweaking of your user interface on device from Khan Academy. This allows you to try out those changes without needing to recompile.

SwiftTweaks allows you to set up different variables for tweaking which when bring up the Swift Tweak interface you can then tweak those variables to make sure your UI looks right when on device.

SwiftTweaks was inspired by FBTweaks, but was designed specifically for apps written in Swift.

This animation from the readme shows SwiftTweaks in action:


You can find SwiftTweaks on Github here.

A nice time saving library for tweaking user interfaces.

Original article: SwiftTweaks – iOS Swift Library For Tweaking User Interfaces On Device

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


Signature component for iOS in Swift

image of this control

BuildTimeAnalyzer – Xcode Plugin For Analyzing Swift Build Times

Build Time Analyzer from Robert Gummesson is an Xcode plugin that provides an overview of how long it takes to Xcode to build individiual Swift files.

Build Time Analyzer was created so you can easily find any bottlenecks causing large build time increases.

Here’s an image from the readme showing Build Time Analyzer in action:


You can find BuildTimeAnalyzer on Github here.

A nice tool for easily analyzing build times.

See more Xcode Plugins.

Original article: BuildTimeAnalyzer – Xcode Plugin For Analyzing Swift Build Times

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

Preview-Transition – iOS Component For Creating Preview Image Galleries With A Parallax Effect

Preview-Transition is an open source component submitted by RAMotion allowing you to easily create an image preview gallery with a nice parallax effect.

With Preview-Transition you can customize the look of the gallery including the image size, the navigation bar, text, and coloring, and when clicked images are opened with a nice transition effect.

This animation from the readme shows Preview-Transition in action:

Preview Transition

You can find Preview-Transition on Github here.

A nice open source preview gallery component.

Original article: Preview-Transition – iOS Component For Creating Preview Image Galleries With A Parallax Effect

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

Ordovician Swift: Evolutionary Advances


SE-0088: Modernize libdispatch for Swift 3 naming conventions is accepted with revisions. “libdispatch on Darwin already presents Objective-C compatible types to allow its objects to participate in automatic reference counting. We propose extending this support to present a design that feels “object-oriented” and inline with Swift 3’s API guidelines, all without adding runtime overhead.”

Under the current 2.2 system, dispatch looks like this:

let queue = dispatch_queue_create("com.test.myqueue", nil)
dispatch_async(queue) { 
   print("Hello World") // etc

The new system modernizes the calls to look “Swifty”, eliminate snake case, and provide a user experience that better mirrors the readability and flow of modern Swift.

let queue = DispatchQueue(label: "com.test.myqueue")
queue.asynchronously {
    print("Hello World") // etc

Team feedback:

The community and core team are both very positive about this massive improvement to the libdispatch APIs.  Much of the discussion has centered around specific details in the proposal – for example the “.asynchronously” method on DispatchQueue.  This great discussion leads to several requested revisions in the proposal:

  • Rename the DispatchQueue.[a]synchronously methods to “.async” and “.sync”, to follow the term of art.
  • Rename DispatchIO setHighWater, setLowWater –> setLimit(highWater:), setLimit(lowWater:)
  • Rename setTargetQueue(queue:) and DispatchSource.setTimer
  • Rename Semaphore, Group and WorkItem: .wait(timeout:) –> wait() and wait(withTimeout:)
  • Expand source handler methods to take the same arguments as async()
  • Expand DispatchQueue.after to take the same arguments as async() in addition to the when: argument

SE-0081: Move where clause to end of declaration is accepted. Team feedback:

The feedback on this proposal was strongly positive from the community and core team.  Some concerns were raised (e.g. about possible interaction with the future “generalized existentials” feature) but further examination turned up that they were at issue regardless of whether this feature is accepted.

The core team agrees that this syntactic structure allows a more natural and beautiful way to structure complex generic constraints, and that “where” clauses should be considered secondary to the primary signature of the declaration (e.g. func, class, etc) in question.

SE-0075: Adding a Build Configuration Import Test is accepted.  Team feedback:

The community and core team are both very positive about adding this functionality.  It is precedented by the __has_include feature in Clang, and may have applicability allowing “conditionally available” features for SwiftPM modules in the future.  The core team spent a significant amount of time discussing the proper naming for this, and came to agree that “canImport” (as proposed) is the best name for this conditional.


SE-0041: Updating Protocol Naming Conventions for Conversions is rejected. Team feedback:

The feedback on the proposal was generally positive about the idea of renaming these protocols, but the specific names in the proposal are not well received, and there is no apparent confluence in the community on better names.  The core team prefers discussion to continue — if/when there is a strong proposal for a better naming approach, we can reconsider renaming these.

Active Reviews

Upcoming Reviews

Awaiting Scheduling

If you enjoy these Swift Evolution updates and want to say thank you, consider picking up a book or two. Swift Documentation Markup teaches you how to use Swift’s documentation system to better annotate your code. Playground Secrets and Power Tips unlocks the power of Xcode’s Swift playgrounds. And if you’re looking to pick up solid, day-to-day Swift skills, look no further than the Swift Developer’s Cookbook. (It’s not exactly a cookbook but the name was chosen long before WWDC 2015, so we kind of got stuck with the title.)

iOS Dev Weekly - Issue 251 - May 20th 2016


Chris Lattner made an announcement this week about the scope of the 3.0 release. The good news is that the date won't (or more likely, can't) slip, but unfortunately the stable ABI is going to be pushed into Swift 4, where it will be the highest priority.

I'm not too worried about the postponing of the stable ABI. Yes it means a larger binary and an inability to use precompiled libraries, but I’m not sure that’s stopping a huge amount of people from adopting the language. Note, I’m not saying it’s not stopping anyone, just that the group this affects is fairly small.

How much of this postponement is due to the massive success of the open source Swift project? The community has contributed a huge amount of proposals for the language, and many of them have been implemented or are targeted for 3.0.

My guess? It’s likely that this volume of high quality community input came as a surprise to the Swift team. Certainly, if it was still closed source, the scope and features of Swift 3 would have been different.

Is this a good thing? Well, delays are proof that the Swift team aren't superhuman and Apple need to keep an eye on priorities. However, I’d say it’s a net positive, and I’m pretty happy with how the development process for Swift has turned out.

Dave Verwer


WWDC Alternatives

This is a surprising move from Apple! Links to AltConf, Layers, Jim's Beard Bash and The Talk Show Live have all been added to the official WWDC site. These events (and others) all make San Francisco an even more amazing place to be during that week, and deserve to be celebrated. Bravo.

Android Instant Apps. Use apps without downloading them

Dear Santa Craig. I've been a very good developer this year, and would like it very much if you would add this feature to iOS. Unless the elves are already working on something like this for iOS 10, this would continue the great work you all did with deep links. This would give a huge boost to app discovery, which is something the store really needs. Thanks very much! Dave

Sponsored Link

Native iOS Charts from shinobicontrols: ​Data visualization on mobile

Create high performance, visually stunning native iPad and iPhone applications using shinobicharts for iOS. shinobicharts offers an extensive feature list and a huge range of chart types, no matter if you’re developing in ObjC, Swift or Xamarin. Download a free 30­-day trial today.


Statistics on SwiftPM package usage

It's early days for stats like these as the Swift package manager is not yet officially released. However this list of the most popular packages and package authors is going to be something to watch as the package manager gets more adoption. Thanks to Honza Dvorsky for putting this together.


Pattern Matching

Olivier Halligon with a great four part series (1, 2, 3, 4) on pattern matching in Swift. This has been in my list of pending links for weeks now, but I wanted to wait until the series was finished before posting it. You should read all four parts.

What's new in Swift 3.0

I liked this illustrated summary of the major Swift 3.0 changes by Paul Hudson. It's all very well seeing the proposals fly by, but code examples really help to show the impact of the changes and that's what you'll get here.


New networking library from Elvis Nuñez which shipped a 1.0 this week. It's designed to be a lightweight wrapper around NSURLSession and friends, with good support for testing and simplicity at its core. Worth taking a look at.

Protocol-Oriented Views in Swift

I really liked this article by Natasha on adding an animation to a view using Swift protocols. It takes a simple, common problem and shows a clear benefit to the protocol oriented approach.


How to Use Images to Improve Mobile App UX

This article isn't so much about icons, but the other imagery that you can use to give your app some personality and colour. Nick Babich has some some good advice on what kind of images to use, how to format your content around the images and tips on how to ensure text stays legible.

Design with me

Want to spend 13 minutes watching Michael Flarup design an icon for a Mac App? I did, and really enjoyed it.


How to make your code sustainable - what they don't teach you

An entertaining talk from Christin Gorman on the dangers of over-engineering. Yes, it's a talk about Java for the web, but the concepts are still relevant.


New Swift, Core Data and Cocoa Books

There's plenty of books available covering Swift these days, but which one is right for you? Keith Harrison has some recommendations.


Simplify Your Job Search with Hired

Set your own price, and get offers from top companies like Uber, GitHub, & Stripe. 🚀

iOS Engineer, VSCO, Oakland, CA

We're growing a creative community of 30+ million users every month. Join us.

iOS Developers - Grab R&D in Singapore, Seattle or Beijing

Join the sharing economy with Southeast Asia’s leading ride-hailing platform!

And finally...

Welcome to Google Instant Apps

Made me chuckle... 😃

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

ParticlesLoadingView – Swift Component For Creating Custom Loading Indicators With Particle Effects

ParticlesLoadingView is an open source Swift component from Patrick Balestra for creating loading indicators with custom particle animations.

ParticlesLoadingView utilizes SpriteKit allowing you to drop in custom particle emitters created using Xcode’s Particle Emitter Editor.

. You can easily customize the shape of the loading view for different styles.

Here’s an animation from the readme showing different custom loading views:


You can find ParticlesLoadingView on Github here.

A nice component for creating custom loading indicators.

Original article: ParticlesLoadingView – Swift Component For Creating Custom Loading Indicators With Particle Effects

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

Swift: Things I really wanted that won’t make it

Here’s a short list of things that aren’t (or probably aren’t) going to be in Swift 3, that I was hoping to see.

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

Fixed Ranges, Striding, and Range Operators. This splintered down into a series of I believe four separate proposals of which only the first one (improving floating point math) has gotten into review. A lot more work to be done here. Plus extending striding to collections.

Disambiguating SPM Naming Conflicts. My idea would be to come up with a way to allow multiple packages to share the same simple names (like “JSON Parser”) and differentiate them based on their source repo. Swift names should be simple and concise. Namespacing modules (“MySwiftStringUtilityCollection”) is very unSwift so overlap is not just likely, it’s already happening.

The language would adjust to add import as as well, so same-named modules (or modules with difficult names, or submodules) could be pulled in with simpler access from code.

Most of this depends on the overworked and overwhelmed build team, plus it would then require a Swift Evolution proposal for the “import as” component. There are already bug reports of package conflicts in the wild and this would introduce a simple way to add resolution.

Introducing Build Configuration tests for Simulator/Device targets. I gave up on even trying to do #if debug (if one is going to do the configuration tests, there doesn’t seem to be a large enough middle group that wants a preconfigured simple test) but I think #if target(device) (vs simulator/emulator) is doable and useful. Backburnered, along with any platform tests (Windows, Linux, Unix, Apple) until there’s time.

Method Cascades. Dart-like for the win. Postponed until after 3.x at a minimum. It’s language additive, which makes it less critical for 3.

Interpolated String Formatting. Brent Royal Gordon started this off and then it went into limbo. I think it’s important to be able to not just add \(aFloat) into strings but be able to do some kind of inline safe formatting about the number of decimal places, leading zeros, etc.

Core Error. Not hugely popular but not entirely dead, I thought it would be nice to have a built-in basic “default error” to throw that included source site (where the error was thrown) and an optional customizable string and/or dictionary. This wouldn’t replace any other errors but it would provide a convenient error for anyone building scripts and playgrounds (or, let’s be honest, simple apps) where you didn’t want to build something more carefully and extensive with individual error condition cases.

Macros. Didn’t happen. Won’t happen for a while.

Decimal Numbers. Ditto.

Duplicating and modifying immutable structs. Brought up “with” on list, showed an implementation, it got discussed, went nowhere.

Final by default for Swift-sourced classes (would not apply to anything from ObjC), where you enable subclassing rather than disable it. Seemed to split down between Swifties (for it), ObjCHeads (against it).

A Result Type for use in completion blocks, rather than the data, status, error signature we currently have. Big war over Result (specific use case, measurable benefit) and Either (just a thing that could be built and used for this). I prefer Result.

Intrinsic Member Collection for Enumerations. There’s a pull request but that’s about it.

Expanding Cocoa Touch Defaults. The idea was to take a cue from the better-imports from ObjC (SE-0005) and extend the pruning and defaults to other common classes. This isn’t a Swift Evolution process but I have no contact point with whom to take it up with for Foundation and UIKit. (initial unreviewed list), and I’m not yet satisfied with which defaults I actually want to push on.

There’s actually two more items on my list that just might squeak through:

Adding the Unfold Sequence. Kevin’s sequence -> UnfoldSequence  was part of SE-0045 and the only part of the proposal not to be accepted. After a spate of bikeshedding, I think the name sequence() was not hated, but it’s unclear whether this needs a new proposal (it’s getting kind of late to the party) or can be shoehorned in. SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib in review to 5/23

Evan Maloney’s end to the Strong Weak DanceI was writing this up, and I checked the pull request and behold, it is now in the proposal queue as SE-0079. Still not sure this will go through but it would make coding a lot better.

Okay, that’s my (partial) list. What’s yours?