Under The BridgeUnder The Bridge

Musings
Tip: Adding Fields To Interface Builder

Here’s a neat trick that might have never occurred to you — it didn’t to us, anyways:

How to use Xcode to set a text field’s maximum length, Visual Studio-style

There’s the [Visual Studio] GUI builder way…

  1. Select the text box.
  2. Set its MaxLength property in the Properties pane.

… when developing Objective-C and Swift applications in Xcode:

There isn’t a GUI builder way — just a code way, and it’s a little more work than it needs to be…

… That’s a lot of work. Isn’t there a way we can get a “max length” property for text fields, like the .NET people?

And why, yes. Yes, there is! The trick is simply to create an @IBInspectable extension on UITextField:

Swift extensions let you add new functionality to existing classes, structs, enumerations, and protocols. We’re using an extension to UITextField to add two things:

maxLength, a property that lets the programmer set and get the maximum length of a text field, and

limitLength, a method called whenever the contents of a text field are changed, and limits the number of characters in that text field.

Look over the rest of the article and download the sample project for an explanation of the techniques used here. Mighty handy for extending built-in types if you like doing your interface work graphically in Interface Builder … and who doesn’t?

Fire Up The Base

In case you’ve been floundering about what to do service side since Parse dropped the BaaS, here’s something you’ll want to take a look at — Google has seriously levelled up Firebase with unification and new services:

FireBaseServices.png

Firebase is expanding to become a unified app platform for Android, iOS and mobile web development. We’re adding new tools to help you develop faster, improve app quality, acquire and engage users, and monetize apps. On top of this, we’re launching a brand new analytics product that ties everything together, all while staying true to the guiding principles we’ve had from the beginning:

  • Developer experience matters. Ease-of-use, good documentation, and intuitive APIs make developers happy.
  • Work across platforms. We’ll support you whether you’re building for iOS, Web, or Android.
  • Integrate where possible. Firebase has one SDK, one console, and one place to go for documentation and support…

That’s a lot of features there, with free to minimal pricing until you’re scaled up looks like.

Particularly interesting is that they’ve put at the centre there this new analytics service,

At the heart of Firebase is Firebase Analytics, a free and unlimited analytics solution. Analytics integrates across Firebase features and provides you with unlimited reporting for up to 500 distinct events that you can define using the Firebase SDK. Firebase Analytics reports help you understand clearly how your users behave, which enables you to make informed decisions regarding app marketing and performance optimizations…

Custom audiences can be defined in the Firebase console based on device data, custom events, or user properties. These audiences can be used with other Firebase features when targeting new features or notifications.…

As it happens, we’d just been planning to get around to picking an analytics platform for the next project, as it’s been a hella long time since we last surveyed that space, or even updated with notes on the general consensus:

If marketers are going to be using analytics tools, Mixpanel or Localytics. If developers want data to play with, Flurry.

Since then, Flurry was absorbed into Yahoo Mobile Developer Suite, Localytics and Mixpanel appear to be doing fine although now we have actually accurate marketing analytics from Apple,

App Analytics is Apple’s very own analytics platform. It lives right inside of iTunes Connect. Announced at the WWDC in summer 2014, it launched finally in spring 2015 and just recently added support for tvOS apps. One might say just “another” analytics platform like free solutions from Flurry/Yahoo Mobile, Google or Facebook, but App Analytics finally provides reliable data nobody else can (Spoiler: App Store impressions, referring websites, attribution)

You should read all the rest if you aren’t familiar with it, but since it requires no technical implementation there’s no support decision to be made there so we can move on. Let’s check a couple curated collections:

Apptamin’s App Analytics Tools Round-up

iOS Dev Tools’ Analytics section

awesome-ios’ Analytics section

Well, clearly if you have trouble reaching a decision, ARAnalytics is for you:

ARAnalytics is an analytics abstraction library offering a sane API for tracking events and user data. It currently supports on iOS: Mixpanel, Localytics, Flurry, GoogleAnalytics, KISSmetrics, Crittercism, Crashlytics, Fabric, Bugsnag, Countly, Helpshift, Tapstream, NewRelic, Amplitude, HockeyApp, HockeyAppLib, ParseAnalytics, HeapAnalytics, Chartbeat, UMengAnalytics, Librato, Segmentio, Swrve, YandexMobileMetrica, Adjust, AppsFlyer, Branch, Snowplow, Sentry, Intercom, Keen, Adobe and MobileAppTracker/Tune…

And if you’d prefer to just follow the herd, looks like they’re heading for Twitter these days:

Answers Named #1 in Mobile Analytics for iOS

Back in May, Answers was ranked as #2 on iOS and #3 on Android in the mobile analytics space by SourceDNA, the world’s largest database of mobile app intelligence. Since then, we’ve been building out new features like Answers Events, which helps you track specific actions and events in real time, to better understand how users are behaving within your app.

Today, we’re thrilled to tell you that Answers has now been named the #1 most implemented mobile analytics SDK on iOS — just five months after it was named #2!

So no lack of innovation in that space, definitely. If you decide to jump on the new Firebase bandwagon, be sure to let us know how it goes for you!

Compleat Pattern Matching

There’s a great series just wrapped up over at Crunchy Development which dives deeper into Swift pattern matching than you’ve ever been, no doubt:

Pattern Matching, Part 1: switch, enums & where clauses

(note that Where “where” may be used? is everywhere, pretty much)

Pattern Matching, Part 2: tuples, ranges & types

Pattern Matching, Part 3: Custom pattern matching & syntactic sugar

(more thoughts on the ? in Matching with Swift’s Optional Pattern)

Pattern Matching, Part 4: if case, guard case, for case

Check out how expressive pattern matching can get by the end of that:

This look might look a little complex, so let’s split it down:

  • It uses map to transform the Array<Media> array mediaList into an array of tuples [(String?, String)] containing the title (if any) + the kind of item (as text)
  • It only matches if title? matches — which is syntactic sugar to say if .Some(title) matches — the $0.title of each media. This means that it discards any media for which $0.title returns nil (a.k.a. Optional.None) — excluding any WebSite in the process, as those don’t have any title)
  • Then it filters the results to only iterate on those for which title.hasPrefix(“Harry Potter”) is true.

Also note particularly in Part 3 about defining the ~= operator for your own types. Which, in case you were wondering,

The pattern matching operator is pronounced “twiddle-eek” not “bacon rocket”. Not only more fun to say but tells you the order in which to type the symbols.

Now you know!

Beware Visitors Bearing Tints

TL;DR — Set your tint colors explicitly if you have many peer views, and dupe this:

rdar://26227380 UITintColorVisitor causes exponentially worsening performance when adding subviews

When adding subviews to a view that obtains its tint color from the window or a parent view performance gets exponentially worse the more subviews you add. When adding 6000 subviews execution takes over 10 minutes in the following method chain…

If you want a most excellent walkthrough of how to identify that kind of problem in object code, check out

Investigating the Cause of Quadratic Time Complexity When Adding Subviews in UIKit

We like our custom tint color; but not enough to justify such an impact on performance. By deactivating the custom tint color we bring the overall run time of viewDidAppear from our example project from over 700ms down to ~10ms…

The walkthrough of zeroing in on said cause goes through identifying the culprit with the time profiler down to sleuthing through its assembly and ending up as a practical tutorial in the use of Hopper Disassembler (which you may remember us mentioning Mike Ash’s posts on ages ago; also see Hopper + lldb for iOS Developers: A Gentle Introduction) to provide pseudocode for object code you don’t own, concluding

When I started out diving into this issue I was almost entirely clueless about how to interpret complex disassembled code – now I’m still mostly clueless. However, I learned a few very handy tricks along the way:

I learned how to set breakpoints in private methods & and at any address within the assembly code.

I learned about the i386 and Objective-C calling conventions, e.g. which arguments are stored in which registers.

I learned that the addresses in Hopper match the addresses in the actual framework code (besides a base pointers offset depending on where UIKit is loaded into memory). In hindsight this sounds obvious but it definitely was not the case when starting out. This article was very helpful in getting more comfortable with working with lldb in UIKit alongside of Hopper.

These three tools allowed me to explore the code paths & relevant variables a lot faster which in turn made it a lot easier (yet still hard) to get a grasp of what was going on.

In the end I didn’t find a definite answer on how this issue could be fixed, but I found a lot of clues about how the current visitor pattern is implemented and I think I got fairly close to the underlying issue.

Most importantly I learned how to be more efficient at exploring the inner workings of closed source frameworks which will surely come in handy in future!

Yes, that’s a bag of tricks definitely worth adding to your toolkit!

h/t: @jesse_squires, Michael Tsai!

Anticipating Unanticipated Errors

Great article over at Cocoa with Love on structuring Swiftily elegant error handling:

Presenting unanticipated errors to users

The best approach for presenting error conditions to the user is to integrate feedback into the user interface about the condition that the error indicates. This could be changing an icon, colors, adding status text or otherwise changing the state of a user interface element.

This “best approach” requires that we understand the error condition and plan for it in advance.

What if we’re still implementing the app and haven’t had time to exhaustively discover possible error conditions and plan for them? What about technically possible error conditions that we cannot trigger in our own testing making planning impractical? What about error conditions that should never occur if everything is well behaved but are still semantically possible?

We need a base level tier of error handling and reporting to the user. This base level must be very low overhead (so we can add it use it without much thought during development) and while it must report an error to the user, it is primarily intended to gather diagnostic information so the source of the error condition can be understood and facilitate fixes and other maintenance…

The idea is that we end up with runtime-presented information along the lines of

error_dialog2.png

where “Copy Details” provides a full stack trace. Sound interesting? Read the whole thing! And grab the code from the CwlUtils repo on Github!

While we’re on the topic, assertions are an excellent way to anticipate those unanticipated errors; can you name the five types of Swift assertions and enumerate the differences between them? If not, check out (h/t Swift Sandbox):

Andy Bargh’s Swift Assertions

… Not only do assertions allows us to articulate our critical assumptions within code they also help us to design code that ensures the conditions leading up to those assertions are highly unlikely, whilst simultaneously providing us with flexibility and control over when those assertions are enforced.

In some cases, developers advocate that you should only use assertions when developing and debugging, whilst others recommend leaving them in in production as well. My personal preferences lean toward the latter of these two camps. My view is that although triggering an assertion failure is not good, and is definitely not a great experience for end users, I would far rather know about the failures and attempt to fix them, either though additional handling and checking in our code or redesigning things so ensure that the situations leading up to the assert failures don’t occur. For me I feel that this is a better approach to improving the quality of my applications.

We’re totally on board with that. And you should be too!

POP Art

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:

POP-comparison.001-480x270.png

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!

UPDATES:

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

Polymorphism and Protocol Extensions

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

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?

There’s also another SPM index at Swift Modules.

UPDATES:

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

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

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

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

swift-for-backend-SNAPSHOT-2016-03

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

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!

UPDATES:

Building Slack Bots In Swift

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!