Introducing SpotifyLogin

Earlier this year, I joined Spotify as an iOS engineer and am spending much of my time improving the way our users enjoy music. It’s a super exciting mission for anyone passionate about technology and art and I hope to be able to share more about that work when it’s public.

Outside of the day-to-day work though I also run several popular open source Swift projects and enjoy speaking publicly about Swift. It’s only natural that one of my first public-facing side projects within Spotify will be a Swift library.

Hello SpotifyLogin

Today I’m proud to share with you SpotifyLogin, Spotify’s first pure Swift open source framework and the latest addition to our public SDKs.

SpotifyLogin takes care of the flow needed to obtain a Spotify API token. It’s built with the latest version of Swift and takes advantage of modern iOS standards while offering a significantly simplified API (taking into account lessons I learned from writing open source projects) and a signficantly smaller footprint than the corresponding part of the current Objective C SDK.

How to use

SpotifyLogin can be installed via Cocoapods or Carthage and is as simple to use as:

On Spotify and Swift

Swift is the fastest growing programming language in the world and our existing Objective C SDK didn’t make life easy for Swift developers. The main objective of SpotifyLogin was to make it much easier to intgerate Spotify with Swift projects.

Our iOS engineers are passionate about Swift and our level of Swift usage is regularly evaluated at Spotify. We have several teams working fully with Swift. However, due to limitations of Xcode and past versions of the language, the majority of our work is still done in Objective C. This is likely to change with Swift 4 and XCode 9.

Until then, SpotifyLogin signals our commitment to a Swift-y future. We also use our SDKs internally to build mockups, prototypes and hacks and the hope is that this project (and future Swift projects within Spotify) will encourage more Spotify engineers to learn and practice their Swift skills.

Check it out on:

github.com/spotify/SpotifyLogin

Log in with Spotify from your app in Swift was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducing ObjectiveKit

Remember the big Dynamism-in-Swift debate of May 2016? If not, here’s a quick refresher:

Dynamic Swift

In short, the argument is that there are many types of problems that developers are currently solving with the dynamic features of the ObjC runtime. As we are (possibly) heading towards a future where Swift replaces Objective C completely, Swift will need to provide its own native dynamic solutions.

On iOS and macOS, for the foreseeable future at least, Swift will run on top of the Objective C runtime and this means we have full access to these functionalities. Sadly, they are a real pain to use in Swift. We can make it better…

Hello ObjectiveKit

ObjectiveKit is a new Swift framework for accessing Objective C runtime functions.

It makes things like introspection, modifying methods and creating classes at runtime super easy in a way that feels as native as possible to Swift.

How does it work? All you need to do is initialise an ObjectiveClass object that is typed to the class that you want to introspect/modify, then use one of ObjectiveKit’s many functions. Here’s a quick example:

Playing around with the Objective C runtime is both fun, educational and super useful for debugging. However, it is also dangerous — please exercise extreme caution before using it in production.

Check it out on:

github.com/marmelroy/ObjectiveKit

Introspect and modify classes at runtime in your Swift app was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Multi threading and concurrency are essential for the modern app …and yet Grand Central Dispatch, the system level library for managing concurrent operations, has one of the more cumbersome and unfriendly APIs in the iOS SDK.

No more.

Swift 3 brings with it many improvements to Grand Central Dispatch syntax and usage. This is a quick look at some of what’s new.

dispatch_async

Previously, we would choose the dispatch method (sync vs async) and then the queue we wanted to dispatch our task to. The updated GCD reverses this order - we first choose the queue and then apply a dispatch method.

One of the most common GCD patterns is to perform work on a global background queue and update the UI on the main queue as soon as the work is done. This is what it looks like with the new API:

Queue attributes

You will notice that queues now take attributes on init. This is a Swift OptionSet and can include queue options such as serial vs concurrent, memory and activity management options and the quality of service (.default, .userInteractive, .userInitiated, .utility and .background).

The quality of service replaces the old priority attributes that were deprecated in iOS8. If you were used to priority queues, here’s how they map over to QOS cases:

* DISPATCH_QUEUE_PRIORITY_HIGH:         .userInitiated
* DISPATCH_QUEUE_PRIORITY_DEFAULT:      .default
* DISPATCH_QUEUE_PRIORITY_LOW:          .utility
* DISPATCH_QUEUE_PRIORITY_BACKGROUND:   .background

The memory and activity management options are new for this year’s Apple OS releases (OSX 10.12, iOS 10.0, tvOS 10.0, watchOS 3.0). These include the ability to start a queue in an inactive state with .initiallyInactive or set a custom autorelease setting for your queue with .autoreleaseInherit, .autoreleaseNever and .autoreleaseWorkItem.

Work items

Queues are not the only part of GCD to get a Swift OptionSet. There’s an updated Swift syntax for work items too:

A work item can now declare a quality or service and/or flags on init. Both of these are optional and affect the execution of the work item. The flags are an option set that includes the following options: barrier, detached, assignCurrentContext, noQoS, inheritQoS, enforceQoS.

dispatch_once

dispatch_once was very useful for initialisation code and other functions that were to be executed once and only once.

In Swift 3, dispatch_once is deprecated and should be replaced with either global or static variables and constants.

dispatch_time_t

dispatch_time_t was a function that translated a specified time to a UInt64 that could be provided to a queue. The updated GCD introduces a much friendlier syntax for this (farewell NSEC_PER_SEC). Here is an example with dispatch after:

The .seconds is part of a new enum called DispatchTimeInterval. The cases have an associated value representing the count. It currently supports:

* .seconds(Int)
* .milliseconds(Int)
* .microseconds(Int)
* .nanoseconds(Int)

dispatch_assert

Also new in this year’s Apple OS releases are dispatch preconditions. These replace dispatch_assert and allow you to check whether or not you are on the expected thread before executing code. This is particularly useful for functions that update the UI and must be executed on the main queue. Here’s a simple example:

Additional resources

There are many more GCD improvements included in Swift 3 but the official documentation is still incomplete at the time of writing. To go deeper:

• apple/swift-evolution
• Concurrent Programming With GCD in Swift 3 - WWDC16 - Videos - Apple Developer
• apple/swift-corelibs-libdispatch

A quick look at Grand Central Dispatch and Swift 3 was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yesterday, the first day of WWDC, was full of exciting improvements to all of Apple’s platforms. For me, the most impressive update of all was to animations in UIKit. Meet the brand new UIViewPropertyAnimator.

Until iOS10, performing gesture-based and interruptible animations on iOS was a pain — often requiring a third party framework. Facebook’s POP was created for this very purpose and my most recent open source project, Interpolate, tried to tackle the same problem.

It’s great to see this kind of functionality finally built into UIKit and I’m sure it will allow for many more ‘magical’ apps on iOS.

How does it work?

Animations are essentially interpolations between UIView properties that you define in a closure. You can either let an animation run with a duration or you can connect a gesture to update the animator’s fractionComplete property. All the animations are easily interruptible and reversible by default.

Here’s a simple example:

To go deeper, check out the docs:

• UIViewPropertyAnimator
• UIViewAnimating

A quick look at UIViewPropertyAnimator was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducing Interpolate

In a recent (excellent) talk at try! Swift, Adam Bell argued that we should bring back the magic iOS apps lost when the world abandoned skeumorphism. I couldn’t agree more.

Magic on iOS often comes in the shape of interactive gesture-driven animations. There’s something incredible about seeing the action on the screen respond perfectly to your touch. Do you remember your reaction to inertial scrolling the first time you saw it? to the old version of Twitter for iPad? to 53’s Paper?

Interactive gesture-driven animations are hard work and usually involve interpolating different types of values following a gesture’s progress. I wanted to make it simpler…

Hello Interpolate

Interpolate is a new Swift interpolation framework for creating interactive gesture-driven animations. Here’s an example of it in action:

The 🔑 to Interpolate is — all animation is the interpolation of values over time. A movement is just an interpolation from one CGPoint to another, a color change is an interpolation between two UIColors etc.

Interpolate is able to interpolate a wide range of types (more are coming). To use, just create an Interpolate object, give it a from value and a to value and apply it to the target view in a closure.

All you then need to do is to get a progress value from your gesture recognizer and provide it to the Interpolate object. That’s it. The code looks like this:

Interpolate is not just for dull linear interpolations. For smoother and richer animations, Interpolate supports the following functions out of the box- EaseIn, EaseOut, EaseInOut and Spring. You can even supply your own Interpolation functions (via a protocol).

Let’s build some magical apps…

Check it out on:

github.com/marmelroy/Interpolate

Interactive gesture-driven animations in your iOS app (in Swift) was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.

I agree with most of the arguments — storyboard references make life easier, keeping things small and modular helps avoid many of the downfalls and IBDesignable/IBInspectable is seriously cool.

However, it’s still hard for me to 💖 storyboards & nibs, my feelings are a lot more 🌀 (i.e. mixed). Here’s why:

Can’t handle our scale

Earlier this month, I attended mobile@scale at Facebook’s HQ in London. It was a fascinating day of presentations from Facebook, Google, Twitter, Spotify and Soundcloud. They shared many of their experiences and best practices when working on apps at scale. Here’s a note I made:

Roy Marmelstein on Twitter

3/ XCode, nibs and storyboards don't scale.

The main reason was build times and merge conflicts.

Facebook and Google might be special cases, with thousands of classes and hundreds of engineers sharing the same codebase and yes, by keeping your storyboards small and modular, merge conflicts are a lot less likely in a small team.

However, if you are working for a start-up with significant scaling ambitions, relying heavily on storyboards is the same as placing a major technical debt on the company and forcing a significant future rewrite when the team grows.

Application flow

Storyboards are great for laying out the flow of the application but they force a very linear idea of what that flow is. Implementing more modern navigation concepts and deep linking is significantly harder with storyboards and can easily result in the much feared “storyboard spiderweb”.

Also, it severely restricts your ability to build non-generic gesture-driven user interfaces — think Snapchat or Facebook’s Paper.

Data Flow

You may lay out the flow of your application in the storyboard but what about the data flow?

Apple’s solution for this, a big if statement inside prepareForSegue:sender, is very error prone and restrictive. Custom initialisers simply don’t work with storyboard segues.

One of the Twitter replies to Natasha’s post suggested using dependency injection as an alternative, which seems like a novel approach and something worth looking into.

Chchchchanges

Storyboards are not built for resuability and Natasha recommended using nibs for reusable views. Still though, designing views in nibs makes app-wide changes much harder.

Let’s take fonts and colours for example. In my current codebase, I have categories on UIColor and UIFont that reflect the current colour and typeface schemes for the app. For labels and views created in code, any change the designer makes can be applied by changing a few lines in the categories. For labels and views designed entirely in interface builder, these changes can be a huge pain to apply.

Conclusion

Storyboards are way way better than they used to be. They are fantastic tools for simpler apps or quick prototypes and they also make life a lot easier for anyone beginning iOS development.

However, the question of when to use them is still not an easy one to answer. It honestly depends on the needs and ambitions of the app you are creating and should be decided on a case-by-case basis. For now, I remain 🌀.

I 🌀 Storyboards & Nibs was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducing PeekPop

With the iPhone 6S and 6S+, Apple introduced us to 3D Touch — a whole new way for your iPhone to sense pressure on the screen. One of the coolest features employing 3D touch was Peek and Pop. When you press softly on a view, you get what’s called a Peek — a pop-up preview of the next bit of content. Press more, and you Pop it to fill the screen. When implemented well, this is an incredibly powerful paradigm.

The only downside of Peek and Pop is that it’s only available on the two latest iPhones and 80% of the world is currently running older devices (yours truly included). Why can’t we get to enjoy this cool new way to preview content?

Hello PeekPop

PeekPop is a new Swift framework aiming to bring backwards compatibility to peeking and popping. On devices that are 3D touch capable, PeekPop uses Apple’s native 3D touch implementation. On older devices, it uses a faithful recreation of the feature. PeekPop ships with a gesture recognizer that senses pressure by observing changes in the surface area of the touch (assuming that when pressing harder on the screen, more of the finger is in contact with it). It works surprisingly well. Here it is running on iOS8:

PeekPop was developed with the objective of staying as close to Apple’s previewing API so implementing it stays super simple:

The one missing feature currently is supporting UIPreviewActions on devices that don’t have 3D touch.

That will come soon…

Check it out on:

github.com/marmelroy/PeekPop

Bringing Peek and Pop to all iOS users was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducing FileBrowser

Last month I released an open source iOS framework for zipping and unzipping files called Zip.

For Zip’s example project, I wanted a quick Cocoapod that will display the file system with a nice UI and will let users use and observe Zip in action. Despite my best Googling skills, I couldn’t find such framework and ended up writing a very quick and simple implementation.

Browsing an app’s file system and interacting with files is incredibly useful (either as production UI or for debugging purposes). I decided to make an iOS file browser my next Swift project…

Meet FileBrowser

FileBrowser is a simple Swift framework to view and select files in your app’s file system. It comes with a familiar UI (based on OS X’s Finder) and powerful features like peek & pop previews and search. It’s as easy to display as:

let fileBrowser = FileBrowser()
self.presentViewController(fileBrowser, animated: true, completion: nil)

When a file is selected, the default behaviour is to push a preview viewcontroller with sharing options. You can provide an alternative behaviour by using a simple closure:

fileBrowser.didSelectFile = { (file: FBFile) -> Void in
    print(file.displayName)
}

There are even more customisation options like changing the root folder and excluding specific file types or file paths.

Check it out on:

github.com/marmelroy/FileBrowser

Browsing files in your iOS app in Swift was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.

A brief tutorial

C is 44 years old. While that may sound like an ancient age for a programming language, C doesn’t care. It’s as energetic and as essential as ever. Yes, it might not be as ‘sexy’ as Swift or Go but it’s still often the best way to perform some low level tasks. Also, it is still the subject of healthy and passionate online debate — this week my Twitter feed was full of opinions and reactions to https://matt.sh/howto-c.

A few days ago I released my latest open source project — a Swift-native framework for zipping and unzipping files called Zip (see GitHub). Zip is built on top of minizip, an open-source C library and integrating the two together was rather challenging.

I’m sure other developers will face similar issues so here’s a quick step-by-step guide on how to use a C library inside a Swift framework.

Step 1 — Preparation

First, copy the C library’s folder to your project’s directory.

The next step is to create a module.modulemap file specifying the name of the framework and the headers you want to expose to your Swift code. For minizip, it looks like this:

module minizip [system][extern_c] {
 header “unzip.h”
 header “zip.h”
 export *
}

Step 2 — Xcode configuration

Add your C library’s folder to your project. Make sure copy items if needed is deselected.

Go to your project’s Build Settings. Find the header Swift Compiler — Search Paths. In Import Paths, add a relative path to your C library’s folder using ${SRCROOT}. If your folder includes subfolders select the recursive option.

Voila! You’re ready to go.

However, there’s one more thing…

Step 3— Podspec configuration (BONUS)

To distribute your Swift framework via Cocoapods, you will need to add the following to your podspec file:

Add the C library source files to s.source_files :

s.source_files = ‘Zip/minizip/*.{c,h}’, ‘Zip/minizip/aes/*.{c,h}’

Add a relative path to the C library to the SWIFT_INCLUDE_PATHS configuration in s.pod_target_xcconfig. It’s imporant to remember that the relative path here is from the podspec’s perspective and it will likely be different to the relative path you added in the build settings.

s.pod_target_xcconfig = {'SWIFT_INCLUDE_PATHS' => '$(SRCROOT)/Zip/Zip/minizip/**'}

Next, you will need to add the module map to the s.preserve_paths:

s.preserve_paths = ‘Zip/minizip/module.modulemap’

Step 4 — Party

Check out the full example on:

github.com/marmelroy/Zip

Using a C library inside a Swift framework was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introducing Zip, an iOS framework for working with Zip files.

One of my favourite Objective C frameworks is SSZipArchive - it’s a very useful wrapper on top of minizip, an open source C library for zipping and unzipping files.

Last year I released a couple of Swift frameworks to help with phone number parsing and more general localization. For my first project of 2016, I wanted a different kind of challenge. Swift is super fun, powerful and elegant… until it needs to talk to C++ or C code. I wanted to try and create a Swift-native minizip wrapper that is lighter and takes advantage of what Swift has to offer (better type safety, progress closures, throwing errors etc).

Including a C library inside a Swift framework took plenty of xcode/podspec kung fu and I will write a more technical Medium post about that experience soon (UPDATE: It’s here).

Hello Zip

Zip is super simple and crazy fast. The easiest way to use it is via the zip and unzip quick functions. Both take local file paths as NSURLs, throw if an error is encountered and return an NSURL to the destination if successful. This is what they look like…

let unzipDirectory = try Zip.quickUnzipFile(filePath) //Unzip
let zipFilePath = try Zip.quickZipFiles([filePath], fileName: "archive") //Zip

For more advanced usage, Zip has functions that let you set custom destination paths, work with password protected zips and use a progress handling closure too.

Check it out on:

github.com/marmelroy/Zip

Zipping and unzipping files in your Swift app was originally published in Swift and iOS Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.