Under The BridgeUnder The Bridge

Stylishly Swifty

Good talk and links here to keep you abreast of evolving Swift paradigms:

Swifty? Emerging patterns and idioms

Last Tuesday I gave a talk at Swift London called Swifty? looking at interesting patterns emerging from the community, as well as how Swift 3 will shape idiomatic code. You can see my slides on Speaker Deck.

The talk covered several topics, so I thought I’d link to some examples for those who want to learn more.

This is an even better post on namespacing:

Dear Erica: No-case Enums?

Dear Erica, Why would you create an enum with no cases?

This is such a great question! No-case enumerations represent a fairly obscure Swift “power tool”, and one that most developers are unaware of.

The answer, in a nutshell, is that they enable programmers to establish a mini-namespace with little overhead and an assurance that you can’t accidentally create type instances. Under their umbrella, you can group static members into namespaces, build singletons, create cohesive collections of functionality with a minimum surface eliminating freestanding functions, and in one outlier case provide services built around generic types…

And this is an interesting pattern for applying private type extensions which suits well our predisposition towards exposing only designated functionality, a position which is subject to some full and frank discourse over where they’re considering it as not just a style choice but an enforced language construct, if you’ve picked up on that brouhaha; if not, we’ll put an addendum here if/when something actionable happens. In the meantime, check out

Concealment design pattern in Swift

This article introduces a design pattern that I call Concealment, and demonstrates how to use the pattern in Swift code.


The Concealment pattern enables types to support novel, related functionality without adding nonessential members to their interface.


User-defined types can easily be overused in a codebase, giving more prominence to things than necessary. A common example is having a data model entity be involved with tangentially related concerns; such as validation checks, business rule processing, and display formatting. It is preferable to conceal the augmentation and usage of your types behind an API expressly built for a single responsibility, rather than expose those implementation details to all the types’ consumers…

Yep, we agree there; anything that reduces cognitive load is a Good Thing!


First Class Functions in Swift

10 Swift One Liners To Impress Your Friends

Enum Raw Values and Failable Initializers; Mixing Initializers

#257: Property Observers on Local Variables 🐤

How can I extend Array<MyStruct> with a custom function that should only work for these arrays?

Specifying function execution contexts

What are Protocols with Associated Types?; Type Erasure; Inception

Swift Type Aliases: Use Early and Often

#29 An alternative to if let and guard let

#32 Errorify String

Naming Things in Swift

Swift 3 Protocols

Refactoring to Clarity in Swift

Generic Protocols with Associated Type

Swift sequences: The art of being lazy

Swift Hashable

Bond: “A Swift binding framework” ; Bond Tutorial: Bindings in Swift

Express Yourself Swift Style

A Simple Undo/Redo Implementation in Swift

Loose coupling using default implementations in protocol extensions

SwiftTips: “A collection of Swift tips & tricks that I’ve shared on Twitter”

A Simple Undo/Redo Implementation in Swift

Using @autoclosure when designing Swift APIs

Working with text output streams

Statements, messages and reducers

Monadic Computation in Swift. Why?

Strongly typed identifiers in Swift

Identifying objects in Swift

Refactoring Reveals Truths

Chaining methods in swift — (Don’t confuse with optional chaining)

Lazy Cartesian Products in Swift

Using Lazy Variables to Work Around Swift Initialization Rules

Observable: “The easiest way to observe values in Swift.”

Friday Q&A 2017-12-08: Type Erasure in Swift

Patterns for Working With Associated Types

Extend Collection (including String again in Swift 4!) with isNilOrEmpty

Useful Optional Extensions

First class functions in Swift

Composing types in Swift

Transforming collections in Swift

Custom operators in Swift

Swift Tip: Extensible Libraries with Protocols

Swift Tip: Capture Lists

Swift Tip: Local Computed Variables

A Collection of Interesting Swift Features

JohnSundell/SwiftTips: “A collection of Swift tips & tricks that I’ve shared on Twitter”

Luur/SwiftTips: “Swift tips and tricks”

Handling non-optional optionals in Swift

How Do I Write If Case Let in Swift?

Enums And Optionals

Strongly typed access to Info.plist file using Swift

Tuple Comparison

Unowned Properties in Swift

Core Data iSunny iDays

Why “iSunny iDays”? Why, because iCloud is going iAway! That’s no surprise for those of you paying attention since 2014 at least, but now it’s sorta-kinda official. As usual, Michael Tsai has a good roundup:

The Deprecation of iCloud Core Data

… When installing the Xcode 8 beta, I noticed that all of the symbols related to iCloud Core Data were marked as deprecated in macOS 10.12 and iOS 10, with the comment “Please see the release notes and Core Data documentation.” Strangely, the Core Data release notes and What’s New in macOS 10.12 documents make no mention of this. What’s New in iOS 10 simply says that “Several NSPersistentStoreCoordinator symbols related to ubiquitous content” have been deprecated.

I asked on Twitter what was up, and no one seemed to know. No one had anything nice to say about iCloud Core Data, either, though no doubt many developers still rely on it. I hoped that all would be explained in today’s WWDC Session 242: What’s New in Core Data. Alas, reports are that absolutely nothing was said about iCloud in the session…

No need to panic immediately, they’re not pulling a Parse on us or anything like that … yet … but you certainly would be well served to adopt an alternate solution if Core Data iCloud sync appears anywhere in your technology roadmap. Apparently the mothership has something in the works, but if you have an immediate development need for Core Data cloud sync, there’s one clear choice:

It seems clear that the way forward is Ensembles, unless you want to write your own sync engine or wait for Apple to announce one. I hope that the deprecation will spur more of the community to coalesce around Ensembles.

Indeed. We’ve been vaguely aware of it since the 2013 announcement, but we’d managed to miss until now that there’s a commercial with source access Ensembles 2 that includes CloudKit and other backends, whilst the original remains open source on GitHub. And in the likely event that you agree that seems a clear way forward, this is a good time to jump on board:

The Core Data Sync Deprecation Sale

If you move to Ensembles now, you not only get the usual support, documentation, and source code, you also get it all at half the standard price. The sale will continue until macOS Sierra is released later this year.

Whilst that sync thing is still up in the air, Core Data itself moved forward nicely this year, most notably in that standing up your stack is now much more straightforward:

Concurrent Core Data, Now Easier Than Ever

Core Data has a popular opinion of being hard to use, especially in concurrent environments. Why is that the case? First, it truly is complex because it solves a hard problem. Second, until WWDC16 Apple haven’t really said how to best set up the Core Data stack. There were many options, each with its own issues, that we had to choose from.

That’s why I’m super happy that things get clearer in iOS 10 with the introduction of NSPersistentContainer…

We’ve been pretty happy with JSQCoreDataKit for our Swift projects, but soon as your deployment targets allow, there’s all sorts of win with the new stuff here!

And as a final note, if you’re all excited about the new playground stuff — and who isn’t? — check out the explorations here:

Using a Core Data Model in Swift Playgrounds

Is this a great time to be alive, or what?


Building The Perfect Core Data Stack

Cleaning up Core Data Fetch Requests

Seam: “Seamless CloudKit Sync with Core Data”

Core Data on iOS 10, a brief overview with an Example

A Swift Implementation of the Core Data Stack Using NSPersistentContainer

Moving Core Data Files

Kuery: “A type-safe Core Data query API using Swift 4’s Smart KeyPaths”

The Laws of Core Data and rebuttal

Working with Codable and Core Data

A Wild URL Appeared!

This is an interesting article about using Swift pattern matching for routing deeplink URLs:

URL Pattern Matching

The majority of URL routing libraries use a pattern syntax that can match each element of a URL’s path in one of three ways:

  • Equality: Path element must match the pattern expression
  • Value-binding: Path element can be anything at all, and will be made available in a parameters dictionary
  • Wildcard: Path element can be anything at all, and will be discarded

… There are a few reasons I don’t much like this approach:

  • The pattern matching is abstracted away using special syntax.
  • The parameter name userId is repeated and stringly typed, so it’s susceptible to typos.
  • parameters[“userId”] should never be nil, but the compiler doesn’t know that, so we must force unwrap or add a guard statement.

As it happens, Swift’s built-in pattern matching can be used for each of the three pattern types…

Proceeds to walk through the design process of a few abortive approaches, and ends up with the URLPatterns library here:

I prefer this approach to the approach taken by most URL routing libraries for a few reasons:

  • It’s simple to bypass URLs and open a deeplink directly, e.g. by calling DeepLinker.open(.Home).
  • The pattern-matching code is no longer in a third-party library, which makes it easier to debug.
  • The pattern-matching code leverages Swift’s built-in pattern-matching, which means it can be customized and extended.
  • The pattern-matching and routing processes are separated into two steps. This provides an override point if needed…

Neat! For even more niftiness, check out the Generator approach in URLs and Pattern Matching mentioned in the comments.

And while we’re discussing routing, if you want something more conventional, this looks like a good choice:

JLRoutes: “URL routing library for iOS with a simple block-based API.”

  • Simple API with minimal impact to existing codebases
  • Parse any number of parameters interleaved throughout the URL
  • Wildcard parameter support
  • Seamlessly parses out query string and fragment parameters and passes them along as part of the parameters dictionary
  • Route prioritization
  • Scheme namespaces to easily segment routes and block handlers for multiple schemes
  • Return NO from a handler block for JLRoutes to look for the next matching route
  • Optional verbose logging
  • Pretty-print the whole routing table
  • No dependencies other than Foundation

Looks like a sweet dropin to handle just about everything you’d want, that!


Simple Deep Linking in Swift

iOS: How to open Deep Links, Notifications and Shortcuts

Audit Those Version Checks!

Here’s an extra-special class of problem to watch out for in your iOS 10 testing: Brain-dead version checking. Remember the gales of laughter we all had at those silly, silly Windows programmers when they had to skip Windows 9 because of Windows 95 version checks? Well, this is pretty embarrassing, but apparently there’s a good number of us that aren’t any smarter than Windows programmers:

That’s just painful. But there can’t be that many instances of that out there, right? Right? Let’s check this fine article:

Efficient iOS Version Checking

A GitHub search shows that there are over 8000 results calling substringToIndex:1. All of that code will break with iOS 10. It will instead assume iOS 1, where the only apps that existed were jailbreak apps.

Oh, dear. Well, we know that of course you personally, Dear Reader, would never do anything like that … but we very strongly indeed suggest that you do as full an audit as possible of any codebase you expect to be running on iOS 10 to make sure the Evil Code Elves didn’t sneak anything like that in behind your back.

Read the article for more discussion than you probably need of various ways to address this problem. We say “probably” because you’re all programming in Swift now, aren’t you? so you can just use Swift’s #available operator if you really need to check a specific System version. If you’re not, hey the article dives into its implementation, so copy what you need!

PSA: File Those Radars

Yep, you’ve heard this before if you’ve been around a while, but it can’t be repeated too often:

File radars early and often: The importance of bug reporting

There’s a longstanding debate in the Apple developer community over the value of filing bugs through the Apple Bug Reporter system, commonly known as Radar. Some believe it’s invaluable, the only way to give Apple the feedback they need to ensure bugs get fixed. Others believe it’s valueless, a black hole from which little action or satisfaction ever escapes…

Right now, though, right when the first betas hit, there’s some breathing room. And that’s where radar comes in. If someone at Apple wants to get a bug fixed, they need a radar to point to. If they want to get a bug fixed as a matter of priority, they need a lot of radars to point to. Otherwise they simply won’t be given the time to do it.

That’s also why it’s meaningless whether or not someone else has already found and filed the same bug. First, if everyone assumed that, no bugs would be filed. Second, duplicate filings can be considered like “up votes” that, in volume, shift priority more than they do individually…

So, if you are a developer working on iOS 10, macOS Sierra, watchOS 3, or tvOS 10 apps and you’re encountering bugs, please consider filing radars early and filing often.

Even if you never hear back about them, there are people working on those operating systems right now, people who want to make great software and provide for great experiences — people who will deeply appreciate the radars you file, and your having their backs.

Worth reading it all, but that’s the main points — even though Radar is pretty much useless as a communication tool, it’s the only way to contribute to internal priorities there is. For instance, consider the suggestions in this excellent article on that new Apple File System:

Although APFS does checksum metadata blocks it does not do anything to provide resilience for data blocks. That is a huge omission in a modern filesystem, a point I tried to politely but forcefully make in the File System Lab directly to a responsible engineer. I got the feeling that the APFS team is divided on the necessity of this feature and some people on the team would appreciate some ammo to help win the argument internally. I would encourage anyone who agrees to file radars ASAP requesting this feature…

More importantly filing radars is effectively a vote for a feature and the APFS team is listening. You will never have a greater impact on APFS than going to bugreporter.apple.com and filing radars requesting missing features like parity on data blocks or copying snapshots.

Update: Here is my radar on Data Block Integrity if you want to duplicate it. Even if you copy-paste it your separate report counts as another “vote”.

And if you’re not convinced yet that it’s worthwhile to put in this effort … at least dupe @steipete’s Expose verify state

Steps to Reproduce:

Write a radar

Get it back for review

Observe that it’s simply “Open” no matter the internal state

Expected Results:

An additional exposed field that shows if there have been significant changes.

Actual Results:

We need to rely on guesswork or subtle language changes (which are inconsistent though) to try to guess if there has been progress.

to help out the people who do all the work here!


Hmmm — looks like the wide consensus that filing duplicate Radars is a valid way to indicate support may be incorrect:


If you happen to have any informed perspective on this issue, please share!


Writing good bug reports

Have a Simulator problem? File That Radar, then send it to Russ Bishop!

Brisk: “A macOS app for submitting radars”

Getting On Board

So how bad is the retention on mobile apps these days? Pretty bad, you probably guessed; but this bad?

How to Make Your Users Open Your App Again

According to studies, one in four mobile apps is abandoned after a single use. So apart from focusing on first impressions and engaging users during the first launch you should think about how to keep bringing them back over time… Ask this question before you start building anything: How can I ensure that users will keep coming back?

  1. Start a drip email campaign during onboarding.
  2. Update users with their results by email.
  3. Use personalized notifications: push, SMS, chat bots.
  4. Leverage of social mechanics.

Read the whole thing — the infographics are great. For more perspective on long term retention, check out

Your User Onboarding Flow Is Too Shortsighted

Yes, the initial goal of user onboarding is to teach someone how to use your app. But if all a user has done is learned the ropes of one feature, the job isn’t done. Good user retention means going far beyond basic user onboarding. Retention has many stages, and if you want to keep your retention numbers high, you need to think about user onboarding past the first day…

For some specific tips, check out

User Onboarding Best Practices

It’s easy to make onboarding exclusively about the product—logistics, how-tos, and the nitty-gritty details about your product. But your onboarding still needs to be all about the customer. That starts by creating a seamless user experience centered around buyer personas and jobs-to-be-done to align the promise of your product with the onboarding experience…

A common theme you’ll notice here is exposing only appropriate functionality. Why, a “design pattern”, we could call that idea:

Design Patterns: Progressive Disclosure for Mobile Apps

Progressive disclosure is a strategy for managing information complexity. When you use progressive disclosure, you show only the information necessary at that point in the interaction. And you display more advanced functionalities of the app interface as the user interacts with it…

A most important aspect of that progressive disclosure is to never ask the user for a permission when there’s any chance they might refuse it, as they probably will if the benefit is not obvious and immediate. Good advice here:

Mobile UX Design: The Right Ways to Ask Users for Permissions

When it comes to requesting permission, the worst thing an app can do is to bombard users with permission requests without any notice or explanation. Both asking your users for permission too early or for too many things at once are common mistakes. And yet, many apps still do that…

So there’s plenty of food for thought. Some more links with gritty details you may find useful:

How Zendesk Onboards New Users is a neat teardown — check the rest at UserOnboard too.

UI Interactions “The best UI Interactions for your inspiration, every day.” — onboarding specifically

iOS Onboarding without Signup Screens

Cross-Platform Onboarding Without Signup Screens

Onboard is a particularly clean and simple framework for quickly adding onboard screens.


OnboardingKit: “A simple and interactive framework for making iOS onboarding experience easy and fun!”

How to perfect your mobile app’s login screen

Onboard: “An iOS framework to easily create a beautiful and engaging onboarding experience with only a few lines of code.”

How Great User Onboarding Helps These Messaging Apps Grow to 1 Billion Users

SwiftyOnboard: “A swifty iOS framework that allows developers to create beautiful onboarding experiences.”

Tutti: “is a Swift library for creating iOS app tutorials and onboarding experiences.”


So that was a bit of a relief of a WWDC this year, eh? Generally in line with the more sober predictions, no massive upheavals anywhere, nice steady evolution and new integration points in all sorts of interesting places! Even keep 32-bit for another year, only the clearly underpowered A5 devices got dropped this time around. Videos are pouring into WWDC.app for your viewing, and while you try to block out the time to watch them all and join the discussions at WWDC16 on Github, which looks like a neat idea:

The purpose of this project is to create a place where the exchange of opinions about WWDC16 sessions can take place. For each video there is a corresponding GitHub issue that serves as a place for a discussion regarding a specific video. Enjoy!

here’s some links to get you up to speed:

Andy Bargh’s newsletter this week, WWDC 2016 Initial Impressions quickly hit the high points for developers.

Op-Ed on WWDC 2016: What We Got, and What We’re Still Missing is a solid evaluation of the tentpole user updates this time around.

iOS 10 Tidbits: Individual Read Receipts, Wake Alarm, Music Storage Optimization, and More is a good hub for discussions of the subtler changes in iOS 10 you might have overlooked so far.

But the immediate concern for most of you — well, after Swift 3.0 Preview 1 Released!, but that we knew about already — is most likely Xcode 8, which you’ll be pleased to hear looks like a pretty sweet upgrade all around:

What’s New in Xcode

Xcode 8.0 beta Release Notes

We particularly like that it’ll support both Swift 2.3 and 3 to ease the transition there.

and get this, Travis-CI already supports the Xcode 8 Beta initial release! Nice job, guys.

And boo! They killed Alcatraz, but yay! for Xcode Extensions — A brave new world

So that’s Xcode. For API changes, start out with

What’s new in iOS 10 for Developers

and move on to the various backgrounders from the mothership:

Foundation Release Notes for OS X v10.12 and iOS 10

What’s New in Core Data in OS X v10.12, iOS 10.0, tvOS 10.0, and watchOS 3.0

If you mobile:

If you desktop:

If you Safari, watch, tv, or whatever, run down the rest of the release notes list:

In other news, the App Store Review Guidelines were completely rewritten; check out App Review Guidelines: The Comic Book. Yes, the comic book. And keep an eye on AppStoreReviewGuidelinesHistory.com for updates as the new format gets digested.

The Human Interface Guidelines are completely rewritten as well — bigger fonts! obvious buttons! cards! — and the API Reference has a sharp new look and organization too. The Apple documentation beavers have certainly been busy!

And if you have a bit more time, go poke around Guides and Sample Code some more and check out all the new code goodies added this week.

What, yet more time? Write an article about some particularly nifty piece of new kit. Here’s some suggestions for starters:

And for anything we missed here, check out Michael Tsai’s WWDC 2016 Links and BNR’s WWDC 2016: Developer Reading List!


A quick list of overlooked announcements at WWDC’16

Big, bold, and beautiful: Apple’s design language is changing in iOS 10

WWDC 2016 Viewing Guide

wwdc-downloader: “WWDC 2016 video downloader script written in Swift.”

Ole Begemann’s WWDC 2016 Retrospective

The Future Is Subscribed

In case you’ve been under a rock the last couple days, we just had the biggest upending of the App Store since In-App Purchases:

Wow! So that’s the big news for this WWDC, eh? Er, actually…

“…but frankly, we’ve got a busy enough keynote that we decided we’re not going to cover those in the keynote.”

O_o Seriously? What on earth are they going to announce next week, the Second Coming and the Millennial Kingdom? Well, while we wait, the discussion rages about just how much difference this will make to indie development. To get you up to speed:

2013’s Adobe’s Subscription Model & Why Platform Owners Should Care is a great exposition of the mutual value proposition of subscriptions.

App Store 2.0 — will it change things?

We, as a company, have been on the App Store since the very first day (YES) of its existence and have over 50 million downloads worldwide. Readdle managed to build a sustainable business creating great productivity apps that people were happy to pay for.

But 2.5 years ago we saw a big shift and decline on the App Store, that hit all premium priced apps with one time purchase model.

So here are some new things that we know and our reaction to them…

Developers can gate apps behind subscriptions, within limits, Apple says: Let the redesigning of your app as a service begin!

How we made an App Store subscription success

As the co-creator of Zombies, Run!, a fitness app that transitioned to a subscription model just over one year ago, I couldn’t be more delighted. 🍾 + 🎉 all round, folks.

Before all that 🍾 + 🎉 though, I want to share the lessons we learned in the past year — a terrifying, exciting, and ultimately very successful year…

And as usual, Michael Tsai has a great roundup on Pre-WWDC App Store Changes if you feel like getting deeper into the discussions. If not, pleasant dreams waiting for that “busy enough” keynote Monday. Speculation is rampant as usual, but nobody seems to have any real clue, so let’s go with the prediction we like best:

One more nail in the coffin of the Wintel ecosystem coming from Apple

So if they do announce the next-gen PowerBook ships with ARM macOS 12 this fall … you heard it here first!


In-App Purchases: Auto-Renewable Subscriptions Tutorial

Standing on Guard

Here’s a question for discussion that will bring shivers of shared pain to the Swift programmer, no doubt:

Sneaky Swift Tricks: The fake Boolean

Moshe Berman writes, “If I’ve got a bunch of chained guard let statements, how can I diagnose which condition failed, short of breaking apart my guard let into multiple statements? Given this example:

How can I tell which of the 4 let statements was the one that failed and invoked the else block?”

How, indeed? TL;DR There isn’t a really good way. Bah.

However, besides the linked article there’s an active discussion at the Stack Overflow question, and we’d suggest checking on them to see if anything that suits you has shown up, and if not pick up some more Swifty tricks along the way. The one we like the best so far is this gist from AfricanSwift defing the =∅ (null check) debug operator:

If you have a better suggestion, that Stack Overflow question is waiting!

State of JSON Address

So this weekend we’re taking a look at a weather API service that provides data in JSON. So we’re looking around for new and/or notable and/or actively maintained developments in the JSON + Swift world. Always enjoy a good treasure hunt, don’t you?

Particularly nifty thing we stumbled across is JSONExport, which isn’t that new but was to us. If it’s new to you too, check it out:

JSONExport is a desktop application for Mac OS X written in Swift. Using JSONExport you will be able to:

  • Convert any valid JSON object to a class of one of the currently supported languages.
  • Preview the generated content before saving it.
  • Include constructors only, utility methods only, both or none.
  • Change the root class name.
  • Set a class name prefix for the generated classes.
  • Set package name for Java files.

And you have a baker’s dozen options of output for that:

  1. Java for Android.
  2. Java for Android – to use with Realm.
  3. Swift Classes.
  4. Swift Classes – To use with SwiftyJSON library.
  5. Swift Classes – To use with Realm.
  6. Swift – Core Data.
  7. Swift Structures.
  8. Swift – Struct – Gloss
  9. Objective-C – iOS.
  10. Objective-C – Mac.
  11. Objective-C – Core Data.
  12. Objective-C – To use with Realm.
  13. Swift – Mappable [not included in README — ed.]

Convenient! Or perhaps you’d like to handle Core Data serialization more directly? Here’s an option:

Groot: “From JSON to Core Data and back.”

Groot provides a simple way of serializing Core Data object graphs from or into JSON.

Groot uses annotations in the Core Data model to perform the serialization and provides the following features:

  1. Attribute and relationship mapping to JSON key paths.
  2. Value transformation using named NSValueTransformer objects.
  3. Object graph preservation.
  4. Support for entity inheritance

Or here’s another option:

Sync: “ Modern Swift JSON synchronization to Core Data.”

Sync eases your everyday job of parsing a JSON response and getting it into Core Data. It uses a convention-over-configuration paradigm to facilitate your workflow.

  • Automatic mapping of CamelCase or snake_case JSON into Core Data
  • Handles operations in safe background threads
  • Thread-safe saving, we handle retrieving and storing objects in the right threads
  • Diffing of changes, updated, inserted and deleted objects (which are automatically purged for you)
  • Auto-mapping of relationships (one-to-one, one-to-many and many-to-many)
  • Smart-updates, only updates your NSManagedObjects if the server values are different (useful when using NSFetchedResultsController delegates)
  • Uniquing, Core Data does this based on objectIDs, we use your primary key (such as id) for this
  • NSOperation subclass, any Sync process can be queued and cancelled at any time!

If you’re just looking for JSON parsing into objects without the Core Data integration, there’s … a surprising number of helper options these days:

… and a veritable plethora of others. If we and all those collections missed your favorite, let us know!

Some discussions to help you decide which of these if any suits your particular use case best:

How I deal with JSON in Swift

Everything You Need to Know About JSONJoy, SwiftyJSON & OCMapper

Swift JSON Shoot-Out

The state of JSON parsing in Swift – Part 1

Enjoy your paradox of choice!


Here’s another that generates SwiftyJSON/ObjectMapper friendly classes: SwiftyJSONAccelerator

Alembic: “Functional JSON parsing, mapping to objects, and serialize to JSON.”

Atlas: “An extremely easy-to-use and lightweight JSON mapping library for iOS and tvOS written in Swift.”

Working with JSON in Swift

JSONShootout: “Compare several Swift JSON mappers.”

Rethinking Routers in Swift using Protocol Oriented Programming — Part 1

API Endpoint Testing with Postman

Simulate APIs and Backend Server with New Postman Mock Server Feature

Paw 2 – The Missing HTTP & REST API Tester For Mac

Insomnia Is Now Open Source

Dynamic UI Testing HTTP Mocking

When JSONDecoder meets the real world, things get ugly…

Swift Tip: Networking with Codable

Typesafe API calls in Swift: Generating Alamofire Handlers with quicktype