I’ve been thankful to find a new audience here on Medium, but for some time I’ve yearned to have a little place on the internet to call home. By the same token, though iOS is my career and passion — I have missed dipping into some front-end development.

To that end, I’d love to introduce you to the new home of all my articles going forward:

Swiftjective-C

Swiftjective-C!

I created it using Jekyll, and the whole entire thing is open source as well. Thanks for reading all these years, and I hope you’ll follow along with me at my new home.

Until next time ✌️.

Introducing Swiftjective-C was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.

Modern Drawing on iOS

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

The history of photography is rife with interesting stories of how the medium developed. Among them, digital photography is one of the more exciting bits of its history. It’s still quite a nascent craft, with its history tracing back to as recently as 1957 when the fine folks at the National Institute of Standards and Technology slapped a photo into computer memory.

The translation from the analog to the digital was an inflection point. We’ve experienced a similar shift on iOS starting with iOS 10, though many engineers have yet to discover or adopt the latest innovation for drawing images — UIGraphicsImageRenderer.

Setting the (CG)Context

Core Graphics, based on the Quartz drawing engine, has provided iOS developers with lightweight 2D rendering capabilities since iOS 2. Its utility knows almost no bounds, as image masking, PDF document creation, parsing, and other similar functions are baked right in making it a no nonsense choice for any sort of drawing task.

For that and many other reasons, if one hits the Googles on how to create an image from something on screen they’ll likely end up with something like this:

let drawSize = CGSize(width: 20, height: 20)

UIGraphicsBeginImageContext(drawSize)
let ctx = UIGraphicsGetCurrentContext()!

ctx.setFillColor(UIColor.red.cgColor)
ctx.fill(CGRect(x: 0, y: 0, width: drawSize.width, height: drawSize.height))

let img = UIGraphicsGetImageFromCurrentImageContext()

And it works, so we move on. Though, there are several valid reasons to pump the breaks:

• UIGraphicsBegin/EndImageContext are sRGB only (sorry p3 color gamut).
• It was before the age of blocks, which are common throughout Foundation, UIKit and virtually every framework on iOS.
• Extensibility is possible, though sometimes a non trivial task.

Given its age, it’s not a shocker to say Core Graphics provides an API that’s less than ideal too many of today’s standards. Though Swift’s syntactical sugar prowess has softened the call sites to Core Graphics code over many projects, it still is what it is — a C based API built for simpler times.

In contrast, UIGraphicsImageRenderer is built for tomorrow in mind:

• It’s automagically fully color managed. For example, on the beautiful 9.7 inch iPad pro you’ll get a wide color context.
• It’s a first class object.
• It manages its context lifetime, unlocking some memory optimizations on the house from Cupertino & Friends©.
• The former implicitly means that it caches its context, meaning reuse is an efficient operation as opposed to using new renderers.

Gaining More (CG)Context

Initializing and keeping a reference to a renderer is a solid start:

let renderer = UIGraphicsImageRenderer(size: CGSize(width: 20, height: 20))

From there, the relevant parallel from the old way of doing things to the preferred, Apple approved way would be image renderer’s closure based functions for creating an image:

func image(actions: (UIGraphicsImageRendererContext) -> Void) -> UIImage

To compare apples to image renderers, one could create the same image as mentioned above from the legacy Core Graphics method by doing this:

let img = renderer.image { (ctx) in
    let size = renderer.format.bounds.size
    UIColor.red.setFill()
    ctx.fill(CGRect(x: 0, y: 0, width: size.width, height: size.height))
}

The hard work of what’s happening here has always been abstracted away by Core Graphics since day one, but now it’s more honed in to the point where we simply spit out some drawing instructions within a block.

The renderer also exposes convenient access to getting a hold of NSData of resulting images as well:

let actions:(UIGraphicsImageRendererContext) -> Void = { (ctx) in
    let size = ctx.format.bounds.size
    UIColor.blue.setFill()
    ctx.fill(CGRect(x: 1, y: 1, width: size.width - 1, height: size.height - 1))
}

let imageJPEGData = renderer.jpegData(withCompressionQuality: 1, actions: actions)

let imagePNGData = renderer.pngData(actions: actions)

In each code sample, the typealiased DrawingActions closure returns to us an instance of UIGraphicsImageRendererContext. Using it we gain access high-level drawing functions. Though Apple clearly states “higher level” drawing functions, don’t think of it as a crutch. There is support for most drawing tasks, such as utilizing blend modes by leveraging CGBlendValue:

let image = renderer.image { (ctx) in
    UIColor.blue.setFill()
    ctx.fill(CGRect(x: 1, y: 1, width: 140, height: 140))

    UIColor.yellow.setFill()
    ctx.fill(CGRect(x: 60, y: 60, width: 140, height: 140), blendMode: .luminosity)
}

That said, you may be left missing the drawing functionality you might’ve thought left behind from the traditional context.

For example, filling in an ellipses still requires a R.O.C.G.C. (regular old Core Graphics Context, obviously). To fill out the drawing functionality (pun somewhat intended), an image renderer context has one available.

Take note of the last two lines, where the cgContext allows us to fill out the circle:

let img = renderer.image { (ctx) in
    let size = ctx.format.bounds.size
    
    UIColor.darkGray.setStroke()
    ctx.stroke(renderer.format.bounds)

    UIColor.blue.setFill()
    ctx.fill(CGRect(x: 1, y: 1, width: size.width - 1, height: size.height - 1))
    
     UIColor.yellow.setFill()
     ctx.cgContext.fillEllipse(in: CGRect(x: 51, y: 51, width: size.width/2, height: size.width/2))
     ctx.cgContext.rotate(by: 100)
}

Giving a Renderer More (CG)Context

I really need to stop with the (CG)Context bit, but I feel too invested at this point so please just excuse me 🤠.

You have noticed that a graphics renderer will also accept a UIGraphicsImageRendererFormatobject into two of its four available initializers:

public init(size: CGSize, format: UIGraphicsImageRendererFormat)
public init(bounds: CGRect, format: UIGraphicsImageRendererFormat)

This rendering format has a few options to aid in further specifying the intent of your resulting drawing operations. It also has a useful bounds property we’ve been using in the previous code samples that’s derived from its associated graphics context. Using this formatter one can tweak opaque or scale preferences, among other things.

For example, CALayer and its A8 backing store format was introduced in iOS 12 and provides developers with free memory optimizations. If you’re certain, for example, that you’re drawing wide color content using sRGB colors, you can have the renderer optimize for that since the backing store would otherwise be larger to accommodate a larger color range rather than just 0 to 1:

// iOS 10/11
let format = UIGraphicsImageRendererFormat()
format.prefersExtendedRange = false

// iOS 12
let format = UIGraphicsImageRendererFormat()
format.preferredRange = .standard // Turn off iOS 12 optimization

Many of these decisions will likely be tied to the current trait collection, so it stands to reason that the renderer format can also be fetched on a per trait collection basis as well.

No need to mince in my own words here, Apple’s documentation explains this very well:

// Returns a format optimized for the specified trait collection, taking into account properties such as displayScale and displayGamut.

// Traits that are not specified will be ignored, with their corresponding format properties defaulting to the values in preferredFormat.
public convenience init(for traitCollection: UITraitCollection)

No worries if you opt to forgo any of this, as UIKit provides sensible default values for you should you not provide explicit ones. As such, if you do nothing, UIKit gives you the resulting format from its factory method, defaultFormat — which provides a format configured for the highest fidelity possible as supported by the device it’s executed on.

Take care to make this choice upfront, however. If you want to configure things, do it at your renderer’s initialization point as the formatter itself holistically represents immutable configurations that it will always use during drawing operations.

All of this hopefully should remind you how extensible and flexible an image renderer can be. For example, hanging a quick extension off of any view to create a circle avatar would be painless and performant (as performant as using cornerRadius can really be, that is) since one could reuse the same renderer and its context:

private var rendererKey: UInt8 = 0

extension UIView {

    var renderer: UIGraphicsImageRenderer! {
         get {
             guard let rendererInstance = objc_getAssociatedObject(self, &rendererKey) as? UIGraphicsImageRenderer else {
                self.renderer = UIGraphicsImageRenderer(bounds: bounds)
                return self.renderer
             }

             return rendererInstance

        }
        set(newValue) {
            objc_setAssociatedObject(self, &rendererKey, newValue, objc_AssociationPolicy.OBJC_ASSOCIATION_RETAIN)
        }
    }

    func circleImageView() -> UIImageView {
        let img:UIImage = renderer.image { ctx in
           layer.render(in: ctx.cgContext)
        }

        let imageView:UIImageView = UIImageView(image: img)
        imageView.frame = renderer.format.bounds
        imageView.clipsToBounds = true
        imageView.layer.cornerRadius =(renderer.format.bounds.width/2).rounded()
        return imageView
    }
}

// Generate a circle image and image view of any view instance
let anImageView = myExistingView.circleImageView()

PDFs FTW

A quick sidebar to mention that the PDF variant of the abstract UIGraphicsRenderer class is very similar to its image rendering sibling. In fact, their method declarations are almost interchangeable, save UIImage vs Data:

let renderer = UIGraphicsPDFRenderer(bounds: view.bounds)
let pdf = renderer.pdfData { (ctx) in
    ctx.beginPage()

    let header = "Welcome to TTIDG!" as NSString
    let attributes = [
        NSAttributedStringKey.font : UIFont.preferredFont(forTextStyle: .body),
        NSAttributedStringKey.foregroundColor : UIColor.blue
    ]

    header.draw(in: CGRect(x: 0, y: 0, width: ctx.pdfContextBounds.width, height: ctx.pdfContextBounds.height), withAttributes: attributes)
}

Wrapping Up

Replacing the code that kinda just works with the code that’s more recent and supports more relevant formats is typically not high on the proverbial list.

Maybe it should be, as is the case with UIGraphicsImageRenderer. You likely won’t have to twist many arms to persuade iOS engineers to make the switch, “No ✋ — I don’t want block based, automatically color managed, extensible drawing code that already manages its context lifetime — that’s awful” said…..nobody?

Until next time, may your drawing exploits with UIGraphicsImageRenderer be many and productive 📸.

Jordan Morgan (@JordanMorgan10) | Twitter

If you enjoyed this week's post, please feel free to go ahead and NSRecommend(this, where: below);

UIGraphicsImageRenderer was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s UIView What’s New #PunGameStrong

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

And here we are. We’ve finally got a good look at iOS 12 and all it has on offer. Though some chose to view it as a tame maintenance release, tagging it as such is a disservice and there was plenty to digest during the WWDC keynote.

Each year, I dive in on the latest version of iOS and try to bring up some of the new APIs that our favorite framework, UIKit, has brought to the table. In no particular order, let’s dig in on some of the enhancements that caught my eye.

UITextInputTraits

Apple continues its push towards keeping its user‘s data private and secure, so it’s no surprise to see Cupertino & Friends© extend the password autofill APIs.

New this year is the ability to suggest a new password for your users, and supply your password parameters dictated by business requirements to iOS when suggesting such a password. This is done via the UITextInputPasswordRules class:

let createNewPasswordTextField = UITextField()

let newPasswordReqs = UITextInputPasswordRules(descriptor: "required: lower; required: digit; max-consecutive: 3; minlength: 12;”)

createNewPasswordTextField.passwordRules = newPasswordReqs

// Now, when iOS suggests a new password - these rules will be used to generate it

The pertinent information here is the descriptor parameter, which is a plain string that follows a certain syntax, à la the visual format language:

"key: value;"

Think of it a dictionary entry that always is followed by semicolon. It’s quite close to CSS declarations. With it, you can specify the following items:

• required : Self explanatory
• allowed : Allow a subset of allowed characters
• max-consecutive : Restrict the number of successive characters

And character classes to match against those rules:

• upper : A-Z
• lower : a-z
• special: -~!@#$%^&*_+=`|(){}[:;”’<>,.? ] and space
• ascii-printable : All ACII printable
• unicode : All unicode

To further things a little, suppose you only wanted to allow the letters “j,o,r,d,a,n” because you want the strongest password that I’ll never, ever most definitely guess, then you could do this:

UITextInputPasswordRules(descriptor: "required: [j,o,r,d,a,n]; max-consecutive: 2; minlength: 12;”)

Be aware that the framework has some validation against your supplied validation, resulting in some form of validationception.

Your parameters have to at least use two instances of the ASCII uppercase letters, digits and ASDII lowercase letters classes. Other than that, it also must be longer than 12 characters.

If you don’t meet this criteria, do you get some sort of runtime error or exception? Nope — the user agent just throws out your insecure, primitive suggestion and uses the default. Which is probably a good thing.

As a bonus, you can do the same thing in HTML by using the passwordrules attribute in your input element.

One Time TFA Codes

In one of my favorite “It just works” APIs that Apple supplies to developers, it’s hard to argue that there’s something more trivial to implement in iOS development that simultaneously brings real value to users than setting a text content type.

The powerful heuristics of iOS sucks in passwords and phone numbers, can suggest a relevant address and more. And now, that more is TFA codes, accomplished by doing nothing more than choosing oneTimeCode:

aTFAtextField.textContentType = .oneTimeCode

This also joins the new value, newPassword, which would enable the password creation prompts touched on above. The usual restrictions (if you can even call them that) is that the element accepting the password must be a text field, text view or a view that adopts the UITextInput protocol.

Of note, tvOS apps are also granted the same affordances when using the control center keyboard, the continuity keyboard or even Cupertino’s Remote App. And let’s face it, nobody wants to type on that platform so any shortcuts we can provide just promotes engagement that much more.

Text content type is powerful, but also the definition of lightweight, simple and WYSIWYG. Sometimes what you aren’t is just as important as what you are. That’s also true with framework design.

Graphics Rendering

As we’ll briefly discuss later on, iOS 12 has automatic backing store support for views. The depth of their content drives this. So, for example, if you are rendering a grey scale image on the screen iOS will employ an 8 bit per pixel backing store instead of the usual 64 bit per pixel backing store a portrait image would incur.

The cost savings is significant, in the What’s New in Cocoa Touch session, Apple engineer Josh Shaffer notes that the previous example goes from 2.2 megabytes of real estate down to 275 kilobytes.

As aforementioned, views get this out of the box. If you draw into offscreen bitmaps using UIGraphicsImageRenderer, though, iOS won’t be able to predict the developer’s intentions with the resulting image. As such, a configurable buffer backing store style has been introduced so one can take part in the memory savings:

let rendererFormat = UIGraphicsImageRendererFormat.default()
rendererFormat.preferredRange = .extended // For an extended range image

let renderer = UIGraphicsImageRenderer(size: CGSize(width: 100, height: 100), format: rendererFormat)

Above, we indicated our intention to utilize an extended range image. Though, we can also indicate that its unspecified, automatic or standard.

The Small Quick Win

Detecting user interface orientations is traditionally frowned upon via Apple’s official stance. And though trait collections offer us most of what we need, it’s still refreshing to see Apple come full circle on all the edge cases with two new additions here:

let device = UIDevice.current
let isFlat = device.orientation.isFlat
let isValid = device.orientation.isValidInterfaceOrientation

Darkness for Days

Also, we have dark mode on iOS, finally! Mojave doesn’t get all the fun!

Err…shoot, no wait — we just have API support for it. But it doesn’t officially exist. But it also kinda does too, because the code is there. It’s shipped with Xcode.

I don’t know. I’m just telling you that trait collections now know about it:

let darkTraitCollection = UITraitCollection(userInterfaceStyle: .dark)

…there’s obviously enumerations for it:

@available(iOS 12.0, *) public enum UIUserInterfaceStyle : Int {
    case unspecified
    case light
    case dark
}

…but they only apply to CarPlay on iOS 12 beta 1.

So there you go 🤷🏻‍♂️.

Notifications

Technically not part of UIKit, but I did have to highlight one welcome change aside from the new grouping capabilities. Look, dealing with notifications is often a pain from a developer perspective. While not a forgone conclusion, the more notification offerings we have to support, generally the issues that could arise grow exponentially.

You have the system notification view to toggle app permissions within iOS’ settings, possibly your own user interface to allow for granular choices, APNS to go through and oh, let’s not forget the network to contend with too.

So, the fact that you can deep link directly into your app’s notification settings from an incoming one is not a small improvement (via providesAppNotificationSettings), but a very welcome change as developers continue their journey towards simplifying notification issues for them, the end user and customer support.

🕺!

… And The Free Ones 🙌

iOS 12 is fast. A lot of the improvements we’ll enjoy come from deep within the framework itself. Here, I’ve chosen to highlight API changes you’ll need to put some time into to reap benefits.

But that’s the thing — our apps will feel a bit smoother, faster and coherent without us having done anything at all.

The reasons why range from smarter cell prefetching via the API scheduling things serially, smarter CPU diversification, more intelligent backing stores for UIView and Auto Layout (quite impressively) hitting O(n) instead of O(n²) for multiple common layout scenarios, to name a few.

Wrapping Up

Personally, I came away more impressed than I thought I would be with iOS 12. Initially, it appeared that a lot of the chatter preemptively declared that iOS 12 would be a day late and dollar short. Last year, we were treated to some marquee features within UIKit like drag and drop — so what could they throw down for us this year?

But, as is typical, W.W.D.C. brought some new stuff we weren’t expecting, hardening updates and most importantly the new APIs. Exciting times, plus — our apps are just better by virtue of simply running on the new OS. UIKit will always be at the forefront, and this year was no exception as there's still plenty of discussions left to be had around this year’s improvements.

Saddle up 📱

Missed iOS 11’s notable additions from last WWDC? Got you covered here.

Jordan Morgan (@JordanMorgan10) | Twitter

If you enjoyed this week's post, please feel free to go ahead and NSRecommend(this, where: below);

iOS 12: Notable UIKit Additions was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Fourth Annual T.T.I.D.G. quiz is here 🎊

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

It’s Christmas time for iOS engineers the world over. Mr.Cook and friends are a little less than a week away from pulling the curtains off of iOS 12. Will we see vast improvements, or the oft rumored “maintenance” release?

Time will soon tell, but until then it’s time for the fourth annual T.T.I.D.G. WWDC Pregame Quiz!

If you’d like a quick primer on how this all works or how it got started, check out the first three quizzes from 2015 ,2016 and 2017.

Participants — time to add the quiz operation to your queues⚡️!

Ground Rules

There are three rounds, and the point break down is as follows:

• Round 1–1 point each answer
• Round 2- 2 points each answer
• Round 3- 3 points each answer

The last question of each round is an optional wildcard question. Get it right, and your team gets 4 points, but miss it and the team will be deducted 2 points.

Round 1 — Swiftly Answered

Question 1:
This technique, introduced in a WWDC 15 session, declared that Swift was the industries first what oriented programming language?

Question 2:
On June 2nd, 2014 — what app became the first publicly available app written in Swift?

Question 3:
What’s the name of the instance method that’s not possible to use in pure Swift classes/objects that NSObject uses to invoke objc_msgSend and allow for dynamic method resolution?

Question 4:
Which new typealias introduced in Swift 4 extended support of archival and serialization to struct and enum types and enables type-safety for serializing to external formats such as JSON and plist?

Wildcard:
During WWDC 14 when Swift was unveiled, what was the very first public Swift string variable set equal to during its inaugural demo introduction by Chris Lattner?

Round 2 — iOS’ & its Tools Storied History

Question 1:
What framework, added in iOS 5, gave rise to the popularity of photo editing apps by exposing a powerful set of built-in filters for manipulating video and still images?

Question 2:
It’s well known that Core Data, Keyed Archiver and User Defaults allow for persistency on iOS. What other persistency option is available by default on the platform?

Question 3:
What CLI, originally released with Xcode 6 and housed within xcrun, allows one to perform various tasks on the iOS simulator, such as recording videos and opening URL schemes?

Question 4:
Developers sometimes crash their app in a controlled manner during development by invoking the abort(); function, but there is also a little known intrinsic function that generates a machine-specific trap instruction. What is it?

Wildcard:
This ridiculously long initializer, clocking in at 202 characters, is found within what Apple framework:

         initWithEnableFan:
      enableAirConditioner:
      enableClimateControl:
            enableAutoMode:
        airCirculationMode:
             fanSpeedIndex:
        fanSpeedPercentage:
   relativeFanSpeedSetting:
               temperature:
relativeTemperatureSetting:
               climateZone:

Round 3 — The Random Apple Ones

Question 1:
This game is a now a triple A blockbuster shooter, but it was originally announced at MacWorld in 1999 and was set to release on the platform as a third person action game. What game is it?

Question 2:
Steve Jobs infamously said that what was a “sweet solution” for developing on the iPhone before the advent of the App Store at WWDC 07'?

Question 3:
The iPhone’s revolutionary multitouch interface was prototyped by a team, colloquially referred to as the ENRI group, at Apple in their abandoned user-testing lab at 2 Infinite Loop — what was their original mission statement?

Question 4:
John Carmack, long a pioneer of the games industry, went toe to toe with Steve Jobs in advocating that which framework should be adopted as the Mac’s 3D Graphics API?

Wildcard:
Though the iPhone’s touchscreen has made the paradigm commonplace in today’s world — Eric Arthur Johnson is believed to have invented the world’s very first touch screen as an engineer at England’s Royal Radar Establishment in 1965. What instrument did he create a touchscreen for?

And that’s it for this year! You can find the answers right below 👇

I hope you enjoyed The Traveled iOS Developer’s Guide fourth annual WWDC quiz. Now, onward to WWDC 18!

Answer Key

Round 1:

1: A protocol oriented programming language
2: The WWDC App, this was confirmed in their Platforms State of the Union address during WWDC of that year.
3: Good ol’ performSelector:
4: Codable
Wildcard:
The variable “s” was declared as a string set equal to “Hello WWDC!”, showing off Swift’s vastly superior string interpolation API.

Round 2:

1: Core Image
2: SQLite
3: simctl
4: __builtin_trap();
Wildcard: SiriKit

Round 3:

1: Halo
2: Web Apps (Yikes)
3: To “Explore new rich interactions”, hence ENRI
4: OpenGL
Wildcard: An instrument to help operators improve handling air traffic control.

Jordan Morgan (@JordanMorgan10) | Twitter

If you enjoyed this week's post, please feel free to go ahead and NSRecommend(this, where: below);

WWDC 18: The Pregame Quiz was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.

Slice & Dice Collections Effortlessly

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

When Swift hit, we were enamored over its simplicity compared to Objective-C. Then it quickly became key to roll with protocol oriented programming. Also, forget reference types and classes. The list goes on.

And true — those things are great tools and have superb use cases. But I sense they are often lifted up as silver bullets without the necessary amount of thought that should probably be given to architectural decisions.

So in 2018, the blog posts overfloweth with Swift hackery (even on my blog 🤷🏻‍♂️) and the conference talks wax poetic of its future using functional programming parlance (yup, I’ve done that too 🙋🏻‍♂️).

Everyone seems excited about working with collections in Swift but we’ve also been able to do similar things in Objective-C since iOS 3. So today, I’m chatting about the power of NSPredicate and how you can sift through collections with it using the 🦖.

I think it’s relevant to bring it back up, as now we’re seeing developers at this point who’ve started with Swift, and then later have circled back to maintain some Objective-C. If that’s you, it’s possible that you’ve been frustrated with the amount of boilerplate or iteration you’ve had to write when using collections in Objective-C.

Today, I have might have something for you.

The Use Case

We’ve come a long way in recent years when it comes to Objective-C collections. Not more than a handful of years ago, we had to tell the compiler we were much smarter than it was:

NSString *aString = (NSString *)[anArray indexOfObject:0];

Thanks Heavens, Cupertino and Friends© eventually tacked on generics by way of type erasure. This marked a significant improvement:

NSArray <NSString *> *anArray = @[@"Sup"];
NSString *aString = [anArray firstObject];

But generics or not, we often interact with the contents of Objective-C collections by doing something like this:

for (NSString *str in anArray)
{
    if ([str isEqualToString:@"The Key"]) 
    {
        // Do something
    }
}

A lot of times, that’s kosher. But as the requirements become more complex and the relationships more varied, the code gets a bit iffy. If you subscribe to the notion that less code means less bugs and better maintenance, the simple act of querying collections can become a bother.

Predicates can lessen the blow here. It’s not about being “tricky” or cute with our code, but pragmatic and succinct.

The 10,000 Foot View

At its core, NSPredicate is used to constrain or define the parameters for in memory filtering or when performing a fetch. It really got its bones when paired with Core Data. It’s like SQL, except less awful*.

* I joke, it’s just that set based operations have never made sense to me 🙃.

You supply it logical conditions, and it helps to return things that match said conditions. This means it provides support for basic comparisons, compound predicates, key path collections queries, subqueries, aggregates and more.

As it’s used to sift through collections, you can expect Foundation classes to support it out of the box. Mutable varieties support in-place mutations from the results, whereas their immutable flavors will return a new instance:

// In place
[mutableArray filterUsingPredicate:/*NSPredicate*/]

// New instance returned
[mutableArray filteredArrayUsingPredicate:/*NSPredicate*/]

Though predicates can be instantiated from NSExpression , NSCompoundPredicate or NSComparisonPredicate — it can also be created using a string syntax. This is similar to the Visual Format Language that one can use to define layout constraints.

We’ll be focusing on the utility of using the string syntax method.

The Setup

To illustrate, let’s consider the following code for the remainder of the post:

// Pseudo code 
Person:NSObject
Identifier:NSString
Name:NSString
PayGrade:NSNumber

// An some property somewhere containing Person instances
NSArray <Person *> *employees

Query Time ⚡️

What follows for the rest of the post are straight forward examples of how to setup queries using the string format syntax.

We can start with a simple search scenario. Let’s assume we’ve got an array containing identifiers representing Person objects:

{
    @"erersdg32453tr",
    @"dfs8rw093jrkls",
    // etc
}

Now, we’d like to retrieve Person objects from an existing array of Person objects from these identifiers. Using a double nested for-loop, it could be accomplished as such:

// Assume "employees" is an existing array of Person objects

NSArray <NSString *> *morningEventAttendees = @[/*Identifiers of people listed above*/];

NSMutableArray <Person *> *peopleAttendingMorningEvent = [NSMutableArray new];

for (NSString *userID in morningEventAttendees)
{
    for (Person *person in employees)
    {
        if ([person.identifier isEqualToString:userID])
        {
           [peopleAttending addObject:person];
        }
    }
}

// Now peopleAttendingMorningEvent has what we want

The exact same result is accomplished using a predicate as such:

NSPredicate *morningAttendees = [NSPredicate predicateWithFormat:@"SELF.identifier IN %@", peopleAttendingMorningEvent];

NSArray <Person *> *peopleAttendingMorningEvent = [employees filteredArrayUsingPredicate:morningAttendees];

💫.

Predicate syntax allows for the use of SELF, which is used to great effect here. It represents the object contained within the array being operated on, so for us — Person objects.

• Another bonus is that we’ve dropped the mutability of the array definition.

It’s for this reason we can access the key paths associated with the object that SELF is representing. You’re seeing that above, as the identifier property is referenced.

Should you prefer, any key path can also be expressed via a variable using the “%K” syntax in its place. This version does the same as above:

[NSPredicate predicateWithFormat:@"SELF.%K IN %@", @"identifier", peopleAttendingMorningEvent];

Compound Predicates

It’s trivial to combine comparisons. Suppose our requirements now call for finding users attending events the same way as above, but now their paygrade must also be between 50,000 and 60,000.

If traditional approaches win out, then our first if statement will only grow:

// Same code as above same for this tweak
if ([person.identifier isEqualToString:userID] && (person.paygrade.integerValue >= 5 && person.paygrade.integerValue <= 10))
{
    [peopleAttending addObject:person];
}

But using a refactored predicate gets us there in a more idiomatic way:

NSPredicate *morningAttendees = [NSPredicate predicateWithFormat:@"SELF.identifier IN %@ && SELF.paygrade.integerValue BETWEEN {50000, 60000}", peopleAttendingMorningEvent];

The syntax allows for different operators denoting the same thing which can help hone in on readability, per your preference. For example:

• “&&” or “AND”
• “||” or “OR”
• “!” or “NOT”

As expected, these are usually aggregated into one predicate by using them in tandem with the basic comparison operators you are likely expecting:

• =,==
• !=,<>
• >=,=>
• <
• >
• <=,=<

String Comparisons

We’re often tasked with matching values based off of string comparisons. It’s well known that Objective-C shines its unrequited love for verboseness in no greater light than when dealing with NSString:

NSString *name = @"Jordan"
name = [name stringByAppendingString:[NSString stringWithFormat:@"%@ %@", @"Wesley", @"Morgan"]]

...whereas Swift just smirks and concatenates its own strings with much less fuss. As such, we can take heart that such verboseness doesn’t apply with NSPredicate and string comparisons.

// Assume mutablePersonAr is a Person array with names of "Karl", "Jordan"
NSPredicate *namesStartingWithK = [NSPredicate predicateWithFormat:@"SELF.name BEGINSWITH 'K'"];

// Now only contains Karl
[mutablePersonAr filterUsingPredicate:namesStartingWithK];

Virtually any comparison can be achieved by way of the predicate syntax’s CONTAINS, BEGINSWITH, ENDSWITH and LIKE:

// Assume mutablePersonAr is a Person array with names of "Karl", "Kathryn"
NSPredicate *namesStartingWithK = [NSPredicate predicateWithFormat:@"SELF.name LIKE 'Kar*'"];

// Now only contains Karl
[mutablePersonAr filterUsingPredicate:namesStartingWithK];

You may have noticed the asterisk above, which like many similar DSLs out there, represents a wildcard.

The ease of use really begins to come to the forefront when you combine comparison operators within one query:

NSString *predicateFormat = @"(SELF.name LIKE 'Kar*') AND (SELF.paygrade.intValue >= 10)"

NSPredicate *namesStartingWithK = [NSPredicate predicateWithFormat:predicateFormat];

// Now only contains Karl
[mutablePersonAr filterUsingPredicate:namesStartingWithK];

Further, there is even support for a mix of NSPredicate’s SQLish syntax to be mashed up with regular expressions by way of the MATCHES syntax:

[NSPredicate predicateWithFormat:@"SELF.phoneNumber MATCHES %@", phoneNumberRegex];

However, this is an opportune time to point out that the predicate format syntax is exactly what it is. A straight up string. And unless you’re Mavis Beacon, you’ll supply it with a typo every now and again.

The good news is that’ll you find out fast — as a runtime exception awaits. What we gain in power and flexibility is, in some ways, mitigated by the loss of the safety net that static analysis provides.

To illustrate, this slightly refactored sample from above will crash. Can you tell why?

NSString *predicateFormat = @"SELF.name LIKE 'Kar*') AND (SELF.paygrade.intValue >= 10)"

NSPredicate *namesStartingWithK = [NSPredicate predicateWithFormat:predicateFormat];

// Now only contains Karl
[mutablePersonAr filterUsingPredicate:namesStartingWithK];

To combat such issues, I’ve often paired predicates with NSStringFromSelector() to provide an additional layer of safety against typos and future refactoring:

NSString *predicateFormat = @"(SELF.%@ LIKE 'Kar*') AND (SELF.paygrade.intValue >= 10)"

NSString *kpName = NSStringFromSelector(@selector(identifier));
NSString *kpPaygrade = NSStringFromSelector(@selector(paygrade));

NSPredicate *namesStartingWithK = [NSPredicate predicateWithFormat:predicateFormat, kpName, kpPaygrade];

// Now only contains Karl
[mutablePersonAr filterUsingPredicate:namesStartingWithK];

A bit more heavy handed? Sure. Safer? Absolutely.

KeyPath Collection Queries

Building upon the use of key paths, NSPredicate boasts a full suite of tools to operate on them in the name of a better search. Consider the following:

// Assume a Person object now has this property on it:
// NSArray <NSNumber *> *previousPay

// Find everyone who's average previous pay was over 10
NSString *predicateFormat = @"SELF.previousPay.@avg.doubleValue > 10";

NSPredicate *previousPayOverTen = [NSPredicate predicateWithFormat:predicateFormat];

// Everyone whose previous pay's average was greater than 10
[mutablePersonAr filterUsingPredicate:previousPayOverTen];

You could switch our the @avg for:

• @sum
• @max
• @min
• @count

When you consider the amount of, albeit trivial, code that you might’ve had to author to achieve the same things outside of a predicate, these types of techniques can begin to become part of your regular toolchain.

Digging Deeper into Arrays

Much like key path queries, there is also support for inspecting implicit arrays to a finer degree:

• array[FIRST]
• array[LAST]
• array[SIZE]
• array[index]

Building from the code sample above, this allows for queries such as this:

// Find everyone who's had three previous different salaries
NSString *predicateFormat = @"previousPay[SIZE] == 3";

NSPredicate *threePreviousSalaries = [NSPredicate predicateWithFormat:predicateFormat];

// These Person objects had three previous salaries
[mutablePersonAr filterUsingPredicate:threePreviousSalaries];

And as we alluded to above, it’s perfectly find to apply multiple conditions:

// Find everyone who's had three previous different salaries and whose first one was greater than 8
NSString *predicateFormat = @"(previousPay[SIZE] == 3) AND (previousPay[FIRST].intValue > 8)";

NSPredicate *predicate = [NSPredicate predicateWithFormat:predicateFormat];

[mutablePersonAr filterUsingPredicate:predicate];

Going even further, you get gain even more power by using either of the following:

• @distinctUnionOfArrays
• @unionOfArrays
• @unionOfObjects
• @distinctUnionOfObjects

Hang with me, but assume we had an array of arrays containing Person objects, and all that we needed were the unique identifiers of the Person instances among them:

// Assume p1/2/3/4 are all hydrated Person objects
NSArray <NSArray <Person *> *> *previousEmployees = @[@[p1],@[p2,p1,p2],@[p1],@[p4,p2],@[p4],@[p4],@[p1]];

// Get every unique ID
NSArray *unqiuePreviousEmployeeIDs = [previousEmployees valueForKeyPath:@"@distinctUnionOfObjects.identifier"];

// The array would contain only unique IDs

Cool, no?

The fun doesn’t stop there, as there is even support for subqueries:

// Assume Person objects have a new property for their team:
// NSArray <Person *> *team;

// Find everyone in an employee array who has people in their team with a pay over 1 and no previous pay history
NSString *predicateFormat = @"SUBQUERY(team, $teamMember, $teamMember.paygrade.intValue > 1 AND $teamMember.previousPay == nil).@count > 0";

NSPredicate *predicate = [NSPredicate predicateWithFormat:predicateFormat];

[employeeAr filterUsingPredicate:predicate];

Subqueries are quite useful should you find yourself needing to search on an array of objects which also contain a property that’s itself a collection. So here, we’ve got an array of Person objects, and we’re peeking into their teamMember array.

Convenience is Key(Path)

Though NSPredicate is built for search, it wouldn’t be Objective-C if you couldn’t bend things from their exact purpose just a tad. No exception here.

When you think of a predicate, you think of filtering down a collection — meaning the return (or in place mutation) still contains the same stuff.

But you can, well, make it not be the same things. And we actually did that in the previous code sample. The array of arrays above was used to return an array of identifiers — NSString instances. Keypathin’ makes it all possible.

Here’s a more direct example:

// We want an array of identifier strings whose length is greater than 10
NSString *predicateFormat = @”SELF.identifier.length > 10";

NSPredicate *predicate = [NSPredicate predicateWithFormat:predicateFormat];

NSArray <NSString *> *longEmployeeIDs = [[employeeArray filteredArrayUsingPredicate:predicate] valueForKey:@”identifier”];

// Now longEmployeeIDs has not Person objects, but only strings

Wrapping Up

You can burn through Objective-C collections with sugary syntax. You can drill down to a particular subset of items without nested loops. It’s all much easier on the eyes with NSPredicate.

While Swift has first class language support to slice and dice collections, it’s really not much of a bother to utilize an object created to do much of the same things. Should you find yourself in a mature codebase or a newly minted one sporting The Dino (Objective-C), let the predicates flow freely.

Until next time✌️.

Jordan Morgan (@JordanMorgan10) | Twitter

If you enjoyed this week's post, please feel free to go ahead and NSRecommend(this, where: below);

NSPredicate + Objective-C was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.

User Interface Creation Made Responsible

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

It’s astounding to think that we lived in a pre Auto Layout world not that long ago. Auto resizing masks and CGRectMake() ruled the lands of user interface development for quite some time.

But as Apple’s devices started stacking up various point sizes, it was obvious that developers would either languish in the pit of misery that can result from too many frame calculations or embrace the power of describing relationships. The latter, obviously, won out.

And thus, Auto Layout has been used, DSL’d and criticized ever since. With its rise, though, another layout paradigm also came into prominence. The “spacer” view. Or dummy view. Container view.

Whatever you call it, we’ve all used them. But Apple, as so it often does, says there is a better way. This week, let’s chat UILayoutGuide.

But Dummy Views Rock (…and I agree)

Dummy views solve some layout problems extremely well. That’s why we all use(d) them. Expressing inter-view relationships, creating modular chunks of your user interface or defining constraints to express the coordinates or size of empty spaces between views all called for the dummy view.

In fact, even if one simply wished to center a group of controls in a particular coordinate space, a dummy view was often used to contain them.

As such, a lot of important jobs were all entrusted to a construct that was never meant to truly do any of them. If you contest that notion, ask yourself what a view actually does in an iOS application.

Or better yet, let the docs tell the story:

A view object renders content within its bounds rectangle and handles any interactions with that content.

A view is a subclass of UIResponder and can respond to touches and other types of events.

So it’s hardly disputible to reason that an important part of a view being a view is to render stuff and handle events. Dummy views, views though they are — shouldn’t particpate in any of those activities at best and do participate in some of them at worst.

Using dummy views, we’ve

• Incurred the cost of a view that’s only helping to define a layout.
• Added a first class member of the view hierarchy, joining in on all the overhead that may be associated with any task related to it.
• And as part of the responder chain, it could intercept some messages that it was never intended to handle.

😬.

There, but Not Really

But a layout guide is none of those things, nor does it suffer from any of those problems. It’s a non-rendering view, much like its more powerful cousin, UIStackView.

Unlike a bonafide view, a layout guide actually doesn’t define a view. Instead, it just represents a retangular region in their owning view’s coordinate system. That’s it. This is what allows it to interact with Auto Layout.

The API closely, and purposely, mirrors that of a view:

let scrollView = UIScrollView()

// Instead of this...
let containerView = UIView()
scrollView.addSubview(containerView)

containerView.widthAnchor.constraint(equalTo: scrollView.widthAnchor).isActive = true
containerView.heightAnchor.constraint(equalTo: scrollView.heightAnchor).isActive = true
containerView.leftAnchor.constraint(equalTo: scrollView.leftAnchor).isActive = true
containerView.rightAnchor.constraint(equalTo: scrollView.rightAnchor).isActive = true

// We can do this...
let containerLayoutGuide = UILayoutGuide()
scrollView.addLayoutGuide(containerLayoutGuide)

containerLayoutGuide.widthAnchor.constraint(equalTo: scrollView.widthAnchor).isActive = true
containerLayoutGuide.heightAnchor.constraint(equalTo: scrollView.heightAnchor).isActive = true
containerLayoutGuide.leftAnchor.constraint(equalTo: scrollView.leftAnchor).isActive = true
containerLayoutGuide.rightAnchor.constraint(equalTo: scrollView.rightAnchor).isActive = true

API Particulars

The UILayoutGuide class is designed to perform all the tasks previously performed by dummy views, but to do it in a safer, more efficient manner.

Layout guides do not define a new view. They do not participate in the view hierarchy. Instead, they simply define a rectangular region in their owning view’s coordinate system that can interact with Auto Layout.

The flow, shown above, is straightforward:

• Instantiate a layout guide.
• Invoke addLayoutGuide(_:)to the desired view.
• Set up valid constraints on the layout guide.

Let’s imagine you needed to constrain some views and center them, but only in the bottom left corner of a view. As in, if you cut the view into four corners, we want to add stuff to the bottom left one. Layout guide makes this easy as it was with dummy views without the baggage:

let bottomLeftGuide = UILayoutGuide()
view.addLayoutGuide(bottomLeftGuide)

// External Constraints
bottomLeftGuide.leftAnchor.constraint(equalTo: view.leftAnchor).isActive = true
bottomLeftGuide.bottomAnchor.constraint(equalTo: view.bottomAnchor).isActive = true
bottomLeftGuide.widthAnchor.constraint(equalTo: view.widthAnchor, multiplier: 0.5).isActive = true
bottomLeftGuide.heightAnchor.constraint(equalTo: view.heightAnchor, multiplier: 0.5).isActive = true

// Internal constraints, pseudo code for brevity
someLabel.top.equalToLayoutGuideTop
someLabel.left/right/etc

// And you can pin all the other views here that you need

Layout guides solve a particular problem so well that Apple has been laying them down on you for the last several releases of iOS, but you may not have actually noticed. Top layout guide, safe area layout guide — you’re likely familiar with these already.

If I wasn’t such a bleeding heart for writing words about coding stuff, I could’ve let this blog begin and end with one sentence: A layout guide can be used entirely like a dummy view but it doesn’t clog your view hierarchy or respond to events.

But where is the fun in that 😛?

If you want a few extra neat tidbits about layout guide, read on.

For De🐛-Ing

Look, Auto Layout goes to hell every now and again no matter what happens. You can either fight the wall of text spit out to the console or run and hide from it. If you opt for the former, take note of layout guide’s identifier property.

bottomLeftLayoutGuide.identifier = “BottomLeftGuide”

When things go sideways, you at least know if your layout guide is part of the issue (which is half of the battle):

// When constraints break, it’ll show in the logs similar to this
“<NSLayoutConstraint:0x6040002b8a80 UILabel:0x7fbb1a39dde0.left == BottomLeftGuide:0x6040001ae2a0.left + 16>”

Take note that the prefix of “NS” and “UI” are system reserved, and UIKit uses these for the layout guides that it creates.

Another technique that you can use is to query a layout guide’s layoutFrameat runtime. There are times when one must mix both a frame based approach and Auto Layout within the same view hierarchy and this can help immensely.

CGRect guideRect = someLayoutGuide.layoutFrame
aNonAutoLayoutView.frame = CGRectMake(0, guideRect.size.height, 100, 100)

Remember here though, because the layout frame is derived from Auto Layout, you’ll need to ensure the constraints have been installed before this property is of any use to you. By the time the layout guide’s owning view has called layoutSubviews — this will have the expected results.

Further, if you need to continue down the layout debugging path you may find the following two components are what you need:

• The constraintsAffectingLayout:for:) function
• And the hasAmbigiousLayout property

Using the function above, you can see all the constraints for a given axis (i.e. vertical or horizontal). Use it to see if there are any unexpected constraints influencing it:

let constraintsEffectingVertical:[NSLayoutConstraint] = bottomLeftGuide.constraintsAffectingLayout(for: .horizontal)

Lastly, the boolean property acts exactly how it’s named. It’s utility lies in the fact that you can easily check for ambigious constraints on just the layout guide using a symbolic breakpoint. If you are like me, sometimes you want the show to come to a total halt if something like this happens. I sometimes wrap this in an NSAssert() in my own side projects so I have to deal with the issue right away.

Winding Down

If brevity is the source of wit, then the layout guide may be the sharpest of them all nesteled inside UIKit. It’s insanely simple — just a plain old thing that looks like a view, smells like a view, acts like a view and….isn’t a view. It’s just a rectangular region that loves Auto Layout.

And in so many cases, that’s all a developer needs. So next time you feel yourself reaching for a spacer view, opt to embrace the simplicity and safety of UILayoutGuide.

Until next time ✌️.

Jordan Morgan (@JordanMorgan10) | Twitter

If you enjoyed this week's post, please feel free to go ahead and NSRecommend(this, where: below);

UILayoutGuide was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.

Curry favor with users by making things easy

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

Developing for the web feels like a world that’s simply left me behind. I made a concerted effort to double down on iOS development several years ago. I’ve never looked back or regretted it, and I don’t even know what the rear view mirror looks like. It’s caked in dust by this point, no doubt.

Though I’ve mentioned web related things here before, the last time I did any meaningful web development in a professional context, I was using JQuery v4.x.

So, yeah — it’s been a few years and (seemingly) several thousand Javascript frameworks later. I don’t venture into that ecosystem much, and my last trips were on account of the things I’m about to mention here.

Which is, there are some incredibly trivial things one can do on their website to couple it to their iOS app counterpart. If you have the next thirty minutes free, I’d wager you could do all of them listed here.

Let’s rock 🤘

Give your SaaS some sass

First, what’s the end game here? To simply leverage some hosted .json files on your server and put meta tags in your markup to allow users to jump straight into your app or display information about it more effectively. That’s it.

This stuff is typically key for SaaS business’ or solopreneurs because in the world we live in, where there is a SaaS website a (hopefully) native app will follow. We want to help them dance together.

It helps that iOS 11 built features specifically for this. Open up your camera, point it at a QR code. Boom — iOS shows us the actionable details. Share a link in messages. Get a rich text preview. The list goes on.

QR Code Detection

Let’s start with everyone’s favorite technology, quick response codes.

//TODO: (insert QR code joke here)

Creating a QR code that users can point to and then be prompted to download, open or route to a part of your app can be useful. Doing so can be accomplished by setting up an apple-app-site-association JSON file with an “applinks” key value pair and hosting it. You may already have this file for hand off support.

For this purpose, it looks like this:

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID":"DJGHSDJGH24.com.blogPost.yolo",
                "paths": ["*"]
            }
        ]
    }

}

The appID key simply must be your team or app ID,(.), followed by your bundle ID.

An easy place for the JSON file to live is typically in the .well-known subdirectory:

https://wwww.anExample.com/.well-known/apple-app-site-association

Additionally, planting it at the root of your server works just fine too.

If you host such a file, the end result is that your app will immediately show to open via a notification when the user points at the QR code. The only metadata your QR code needs is the URL for your website.

No external QR code download, no more taps — nothing. It just happens.

If the user doesn’t have your app, Safari will kick in instead, taking them to your website.

Getting Particular

You have the ability to specify a few things within your applinks key-value pairs. Let’s look at what’s available:

• apps — You supply an empty array here. I would tell you why, but I would be making it up because Apple literally says nothing else about it besides that so…¯\(°_o)/¯
• details — An array of dictionaries, one for each app that your site ultimately supports. Ordering matters in the array, as iOS look up links according to it. This allows you to specify an app to handle a certain part of your website.
• details[appid] — The team ID or app ID with a period, and your app’s bundle ID tacked on.
• details[paths] — An array or strings that determine which parts of your website are supported by the app. Additionally, you can say which parts aren’t supported.

The first three entries don’t merit much more discussion. The paths entry does have some nifty options for excluding content where applicable.

For example, including “NOT ” at the beginning of the path will basically blacklist that content from being used as a universal link:

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID":"DJGHSDJGH24.com.blogPost.yolo",
                "paths": ["/posts/iOS",
                          "NOT /oldPosts/outdated/*"]
            }
        ]
    }

}

This works much like regex, with support for wildcards:

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID":"DJGHSDJGH24.com.blogPost.yolo",
                "paths": ["/posts/iOS",
                          "/oldPosts/201?/*"]
            }
        ]
    }

}

A few random words of advice:

• Keep in mind these matches are case sensitive.
• If you’re rocking a few domains, you’ll need to roll anapple-app-site-association file for each one that your app supports. Example: apple.com would have different motives than someProducts.apple.com
• One doesn’t actually need to appended “.json” to the JSON file. Don’t ask me how I know this, or how much hypothetical time was lost to it.
• If you associate several apps within one apple-app-site-association file, iOS will handle it by presenting an alert showing each one to determine which is opened. The next time this happens, iOS will suggest the last choice as a default — but users can still switch this via a force touch or by pulling down on the notification.
• Safari handles all of this as well. If you hosted the QR code as an image, and an iOS user 3D touches on it — this exact same flows happens.

Associated Domains

As an iOS developer, you’ve got some duties too. Chief among them is to let Xcode know you’re expecting this to happen. This is done by the “Associated Domains” capability for your app binary.

Flip it on within Xcode and add some entries for each one you wish to support. Again, you might’ve spent time here already if you’ve developed for hand off capabilities.

For this particular type of routing, though, it would look like this:

// i.e. applinks:<domain>
applinks:anExample.com

As we’ll see later, this creates a handshake of sorts that confirms both the app and website trust one another. Xcode will generate an entitlement to reconcile the security aspect and apply it on your app’s behalf. Spoiler alert, this opens up the door for quick credential retrieval too, as we’ll see later.

Of course, this means you’ll need to handle the user activity passed to you within your app delegate. But, that’s a blog post for another day.

Using universal app links is great, and I hope more apps use it as time goes on. They can happen outside of a QR code context too. They enjoy certain advantages over custom URL schemes in that they are more secure due to the handshake, they can’t be hijacked or claimed by any other app and the only party who can associate one to your app, is you.

Web Credentials

This nifty trick is absolutely essential for you if your app has a log in mechanism or any user portal system online. By employing password autofill, users can tap on the lock icon in the quicktype bar that appears over the keyboard, authenticate and then have their information automatically filled out.

It’s beautiful, and I use it daily.

To allow for this to happen, there is minor housekeeping that you need to do for the text fields or text views representing your log in. Simply assign the correct values added in iOS 11 to their textContentType property so iOS knows what goes where:

loginField.textContentType = .username
passwordField.textContentType = .password

That’s all it takes from a coding standpoint — nothing more than assigning to a property (if you don’t, you leave it up to iOS’ heuristics to make the assumptions). There’s nothing left other than to respond accordingly to the incoming “did change” delegate methods or notifications that’ll be fired off with the credentials.

Technically, you could stop here and things would work….ish.

Users would just get the quick type bar, but your site’s credentials wouldn’t be offered up within it. They’d just see the lock icon, then have to auth up, search for it and select it.

Amateur hour. Obviously, we’d prefer the user’s credentials to show up immediately once either one of those text controls becomes first responder.

Establishing Trust, Again

Which brings us back to our apple-app-site-association file.

Going deeper into the same thought above, a signed entitlement tells iOS which sites you are associated with. The secure, two way link is established in particular when your app is installed or updated. At that point iOS does a wellness check by traversing your domains listed within your Associated Domains (which we mentioned above) and pings each one to see if it gets a valid association file.

If the app points to the website and the website points to the app — we’re cooking.

The entry under Associated Domains for password autofill looks a bit different than the above app links we entered before, as it’s prefixed with “webcredentials”:

webcredentials:anExample.com

XCode gonna’ Xcode. If you’re still seeing an error at this point, you might need to hop over to the developer portal and enable Associated Domains for your app ID.

As you’ve likely keyed in on, the Associated Domains entries follow the same pattern of including a service (i.e. activitycontinuation, applinks, etc) and domain:

<service>:<fully qualified domain>[:port number]

From there, it’s a case of adding that to your association file:

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID":"DJGHSDJGH24.com.blogPost.yolo",
                "paths": ["/posts/iOS",
                          "/oldPosts/201?/*"]
            }
        ]
    },
    "webcredentials": {
        "apps": ["DJGHSDJGH24.com.blogPost.yolo"]
    }
}

The only key to worry about is “apps”, which is just an array of strings (their value constructed the same way as above with app links) that represent the apps your site provides log in information for.

Once you throw that up on your site — the entire web credentials and password autofill pipeline is all set. I can’t tell you how much times this saves from a user perspective. It goes up by an order of magnitude if one uses Safari’s password suggestions as well.

Image Links

Sharing links within Messages is a ubiquitous practice among iOS users. Nothing is more rewarding than tapping on the link cards, with their inviting .png hero images sitting there beckoning us to load up a website within Safari.

Except when that doesn’t happen, and it’s just plain text 😬.

This is so easy to avoid, though, as you easily can control the title, icon, image and even video that displays. Using the open graph protocol, you can supply all of this stuff inside your site’s <head> tag.

Title (if this isn’t present, it’ll take your site’s title):

// Just in case, Javascript isn't run when generating rich links - so the value needs to be in the source. They can't be created dynamically.
<meta name="og:title" content="The Title" />

Icons (derived from a favicon or apple touch icon if it’s there. If not, you can roll with something like this):

<link rel="icon" href="path/to/icon" type="image/png" />

Image (replaces the icon if present, but still provide both because sometimes Messages prefers the icon over an image in situations like poor networking conditions)

<meta name="og:image" content="path/to/image.png" />

Video (of note, you can supply a URL to a YouTube video, which is the only video player network that’ll work if you don’t use a file iOS can natively play)

<meta name="og:video" content="path/to/video.mp4" />

That’s all it takes to get the pretty, informational rich links when your website is shared within Messages. Nice.

The “You probably are already doing this but I’ll add it anyways” Paragraph

Smart banners. At this point, you’re probably using them.

But just in case you aren’t, add a meta tag with your app ID to take care of it. When potential users visit your site, they’ll get that call to action banner at the top to download it.

If you’re wanting to hunt down your app ID quickly, just visit iTunes Link Maker. The entire meta tag can be as simple as this:

<meta name="apple-iunes-app" content="app-id=123456789">

If you need to, you can also include an iTunes affiliate string and app argument parameter to deep link to a specific controller to keep context consistent with where a user might be on your website.

Generally, though, this is tacked on your landing page and that’s good enough to serve its purpose. Now, go forth and take back what could’ve been just an ephemeral thought about your app and convert it to an install 💪.

Wrapping Up

The lot of us craft software for our 9–5 and craft software to scratch our own creative itch. Eventually, all roads lead to a website talking about one or the other. Do them both justice, step away from Xcode and throw up a json file or two or include some simple meta tags that could help slip users right into your beautiful code.

Things like this are almost like the chore list for iOS engineers. We may not think about them first, we may not wake up to crank out config files — but hey, they can help our endgame and move the needle towards exposure. So why not?

Until next time ✌️

Jordan Morgan (@JordanMorgan10) | Twitter

If you enjoyed this week's post, please feel free to go ahead and NSRecommend(this, where: below);

Techniques to Connect Websites to iOS Apps was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.

Foundation’s Powerful API to Measure #AllTheThings 📐

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

Measuring units, things or items in software won’t always be the most glamorous job for software engineers. Though not as thrilling as writing performant user interface libraries nor as fulfilling as conjuring up networking code that weaves concurrent execution with ease, measuring units in iOS is still done more often than not, wrong.

How can one author such code in an internationlized manner and not in a precipitous one? Foundation, as is so often the case, holds the answer. And it has since iOS 10.

This week, let’s look at NSMeasurement and friends.

More Common than You Think

Software has always had situations that crop up which present users with several things that are either measurable or generally quanitifiable. And when that software (iOS) runs on billions of devices across the globe, the need to represent internationalized values of those things becomes not only more important, but quite key.

Getting such measurements and units right isn’t a baseline experience, you should just expect it of your software.

So with that- these APIs aid not only just with the obvious “converter” apps, but also with games, shopping lists and everything else in between:

• Are you representing a measurement of time ⌚️?
• A distance traveled 🚙?
• The rate at which we traveled 🗺?
• The weight of an object ⚖️?

As such, the temptation to use a simple double type makes sense on the surface level and simply breaks apart anywhere else:

//Technically we even set up the variable name for failure
let milesTraveled:Double

NSMeasurement and all his Units

Following the previous example, what we really need is an accurate, bonafide construct to represent a measurement. And while miles is certainly a measurement, it’s only one that generally makes sense within the context of Murica’ 🇺🇸. As such, Foundation’s support for a measurement is tactfully generic:

public struct Measurement <UnitType:Unit>

Note that within the text, for stylistic purposes and because I code in Objective-C daily, I’ll refer to the frameworks with their NS prefix. All of these objects are properly bridged over to Swift as value types and structs.

It provides a way to provide a generic unit of measurement and also a value that corresponds to it. Its initializer will ask for both:

public init(value:Double, unit:UnitType)

Every unit will always have a symbol, though not every unit has a dimension nor will they always be equivalent to one another. It’s something to note, sure, but one will most likely work with dimensional units. But, it’s for this reason that NSUnit’s designated initializer will require only a symbol:

public class Unit: NSObject, NSCopying
{
    public let symbol:String
    public init(symbol: String)
}

When it comes to NSMeasurement, this unit type drives the majority of the work, and you can define which to use via its initializer, but more commonly you’ll use an NSDimension (which subclasses NSUnit) provided to us by Apple. Each dimensional unit will then drive down further into a given dimension that exists within the unit.

For example, say we wanted to measure time. Our unit would be duration, but we’ve got several ways to represent duration such as the second, minute and hour:

let abstractValue = 1.0

// 1 second
let seconds = Measurement(value: abstractValue, unit: UnitDuration.seconds)

// 1 minute
let minutes = Measurement(value: abstractValue, unit: UnitDuration.minutes)

// 1 hour
let hours = Measurement(value: abstractValue, unit: UnitDuration.hours)

Foundation includes a truckload of dimensional units, everything from electrical currents to pressure. Though you are free to subclass and create your own units, in fact — there is quite robust support for that, I’m not sure you’ll ever need to.

Here are some common dimensional units baked in for free:

• UnitLength : Base Unit is meters (m)
• UnitMass : Base unit is kilograms (kg)
• UnitDuration : Base unit is seconds (sec)
• UnitArea : Base unit is square meters (m²)
• UnitAcceleration : Base unit is meters per second squared (m/s²)

There are about 170 dimensional unit types and it’s likely Foundation has thought of your use case.

Operating on Measurements

Working with measurements is trivial due to the fact that they conform to equatable out of the box, so comparisons are carried out uniformly:

let abstractValue = 1.0

let seconds = Measurement(value: abstractValue, unit: UnitDuration.seconds)
let minutes = Measurement(value: abstractValue, unit: UnitDuration.minutes)

// 61.0 seconds, measured in the dimension's base unit
let totalTime = seconds + minutes

// 30.5 seconds
let halfTheTime = totalTime/2

The entire measurement API does all of the heavy lifting for you. This is true when you operate on units of the same dimension but in different forms. The result of the operation will simply provide the base unit type:

let imperialLength = Measurement(value: 5280.0, unit: UnitLength.feet)

let metricLength = Measurement(value: 0.62, unit: UnitLength.kilometers)

// 2229.344 meters
let totalLength = imperialLength + metricLength

Extending the usefulness is NSUnitConverter, which is an abstract class that converts a unit to and from the base unit of its given dimension. For most cases, that’s going to be units that adhere to a linear equation or a scale factor. As such, UnitConverterLinear will be supplied:

let imperialLength = Measurement(value: 5280.0, unit: UnitLength.feet)

let metricLength = Measurement(value: 0.62, unit: UnitLength.kilometers)

// 2229.344 meters
let totalLength = imperialLength + metricLength

// 1.385 miles
let justMiles = totalLength.converted(to: UnitLength.miles)

Don’t worry about creating conversions that don’t relate to one another. These will produce build time errors due to each type’s conversion requiring its generic unit type:

// Build error
let nonsense = totalLength.converted(to: UnitTemperature.celsius)

User Facing Values

Making these values show up in your user interface is going to be quite familiar if you’ve ventured into NSNumberFormatter’s waters. Its close cousin, NSMeasurementFormatter, use is essentially identical.

This is quite ideal, as writing these types of strings on our own time would quickly become a chore.

if (isCanada)
{
    // kilometers 👌
}
else if (isChinese)
{
    // Translate the unit 😐
}
else if (isArabic)
{
    // Translate the unit, number representation AND make it right to left 😱
}

Of course, Foundation and friends nails it:

let distance = Measurement(value:10, unit: UnitLength.miles)

let frenchDistance = MeasurementFormatter()
frenchDistance.locale = Locale(identifier: "fr")

let chineseDistance = MeasurementFormatter()
chineseDistance.locale = Locale(identifier: "zh")

let arabicDistance = MeasurementFormatter()
arabicDistance.locale = Locale(identifier: "ar")

// 🇫🇷 -> 16,093 km
print("🇫🇷 -> \(frenchDistance.string(from: distance))")

// 🇨🇳 -> 16.093公里
print("🇨🇳 -> \(chineseDistance.string(from: distance))")

// 🇯🇴 -> ١٦٫٠٩٣ كم
print("🇯🇴 -> \(arabicDistance.string(from: distance))")

Since measurements tie in closely with numbers, it’s also possible to pair a measurement formatter with a number formatter to specify digits, for example:

let distance = Measurement(value:0.2, unit: UnitLength.miles)

let frenchDistance = MeasurementFormatter()
frenchDistance.locale = Locale(identifier: "fr")

// 🇫🇷 -> 0,322 km
print("🇫🇷 -> \(frenchDistance.string(from: distance))")

let digitFormat = NumberFormatter()
digitFormat.minimumSignificantDigits = 4

frenchDistance.numberFormatter = digitFormat

// 🇫🇷 -> 0.321868 km
print("🇫🇷 -> \(frenchDistance.string(from: distance))")

There are several configurations that the measurement formatter affords to you. Be sure to glance over its documentation. Also note that the formatter will takes its default system locale when initialized, so it’s typically unnecessary to directly assign to its locale property as we’ve done here.

Testing Locales — The .easy Way

A quick foot note. Part of the magic of utilizing Foundation’s measurement and unit APIs is that they are locale aware. If you’re currently changing the location within the iOS simualtor to see how things shake out, there is another way you might prefer.

Just dupe your scheme, and pick the desired locale:

• Edit Scheme
• Hit “Duplicate Scheme”, it’s in the bottom left in Xcode 9
• Name it
• Under Run -> Options -> Application Region, then choose the region to test with

This is nice, because it’s a no fuss and deliberate approach. It requires no code changes or mucking around with the (always reliable 🤞) iOS simulator.

Additionally, you can use the same approach to test string localizations within your interface by editing the “Application Language” in the same manner you edited the region.

Wrapping Up

It wasn’t until I started working on an international team that I truly began to appreciate accurate measurements within iOS. Or — even the correct unit of measurement period.

While the rest of the world embraces the metric system, here I am sticking out like a sore thumb while communicating distances via the imperial system. Siri has a soul, and I know this because she is sick of answering how many miles equals 1 kilometer. I hear it in her cold, hard, digital voice when she answers it for 144th time for me 🤖.

Let’s all aspire to not be that app that delivers the wrong units, or incorrect measurements, in our own software. Foundation has us covered.

Until next time ✌️

Jordan Morgan (@JordanMorgan10) | Twitter

If you enjoyed this week's post, please feel free to go ahead and NSRecommend(this, where: below);

NSMeasurement was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.

Foundation Collections Get Snappier | Smarter | More Efficient

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

Foundation is the unsung hero of iOS development. Powerful due in part to its maturity and ubiquity — it boasts all of six major implementations, it treats engineers to everything from the basic object to annual optimizations under the hood at WWDC. And the best optimizations are the ones I don’t even have to make. They just happen.

With copy on write semantics for Foundation collections, this week’s topic, that’s exactly what we get.

C.o.W Primer

Both the amatuear and the veteran programmer know that we don’t go far without embracing collections, yet by and large there isn’t much thought or questioning that occurs as to what their doing behind the scenes or how exactly they work beyond our CompSci 101 course.

It can sometimes serve as intimidating subject matter, but luckily copy on write is both a simple concept and, as such, is easy to conceptualize. The elevator pitch is that instances pointing to the same object shouldn’t need to employ full copies unless one of them, does in fact, mutate:

NSMutableArray *ar1 = [@[@"TTIDG",@"Pizza"] mutableCopy];
NSMutableArray *ar2 = [ar1 mutableCopy];

Here, both variables hold the same data. So why create a full copy unless it’s actually needed? This means that instead of creating the full copy, we can just utilize pointers to the same backing store and enjoy a much more efficient O(1) operation.

All we’re talking about here is an optimization strategy. Even better, the whole technique is all in the name. We shouldn’t copy data unless it’s written to, in which case — we have a reason to carry forward the actual copy. Copy on write.

So, TL;DR — copies are super cheap now. In fact, they are almost downright free for defensive copying code. In the past, they were typically linear at best.

Foundation Implications

This means that our good friends NSSet, NSDictionary and NSArray will all benefit from the optimization made by the folks maintaining the Foundation Framework. Going back to our previous example:

NSArray *ar1 = @[@"TTIDG",@"Pizza"];
NSMutableArray *ar2 = [ar1 mutableCopy];

// Currently, both arrays point to the same backing store

// Now a mutation occurred, with CoW - this is where the copy actually takes place
[ar1 removeLastItem];

A large number of application flows might not ever reach a mutated state, thus the copy operation was effectively wasted effort. If it doesn’t occur, the only hit we’ll take with CoW is the allocation of the second collection — which likely won’t be much.

But — be mindful of what it isn’t:

NSArray *ar1 = @[@"TTIDG",@"Pizza"];
NSMutableArray *ar2 = ar1;

This isn’t the same at all, and copy on write doesn’t apply. Here we’re pointing to the exact same reference in memory. Remember that this particular optimization is all about efficient copies. Even though pointing to a reference and copying data deals with sharing said data, they are much different in implentation.

Applications

Even though copy on write is a performance optimization, it shouldn’t soley be thought as one in pragmatic terms. It’s great that it’s there, we’ll benefit from it without having lifted a finger — but how we can leverage it to do things we maybe couldn’t before?

Session 244 at WWDC 17 offered a few great examples. Suppose we have an array property:

@property (strong) NSArray *foo;

The intention of the declaration implies that it shouldn’t have mutable state. But hey — life comes at you fast:

// Trolling
self.foo = [NSMutableArray new];

Now, consider this:

@property (copy) NSArray *copiedArray;
@property (strong) NSArray *stongArray;

self.copiedArray = [NSMutableArray new];
self.strongArray = [NSMutableArray new];

// Logs out 'No'
NSLog(@"%@", [self.copiedArray isKindOfClass:[NSMutableArray class]] ? @"Yes" : @"No");

// Logs out 'Yes'
NSLog(@"%@", [self.strongArray isKindOfClass:[NSMutableArray class]] ? @"Yes" : @"No");

The copy attribute has been around since the beginning — and it’s commonly put to great use with class clusters. What’s happening here is that sending a copy message to something that is mutable (i.e. the NSMutableArray here) will still return an immutable copy. Copy on write makes life even faster in such a scenario.

Continuing on with Objective-Cisms — mutable collections are often used to build something up. This is a common technique found within many functions, where the author will then declare the return type as immutable. Yet, since a mutable array is a kind of array, this is perfectly legal:

- (NSArray <Employee *> *)allEmployees {
    NSMutableArray *container = [NSMutableArray new];

    //build up container with employees...
    //i.e. [container addObject:anEmployee]

    return container;
}

And innocently enough, we’ve sharing mutable state again. The method header deceives any caller now, the 🍰 is a lie.

Since we’ve got copy on write, we don’t even need to bother with such a qundary since copies are cheap. We can do the right thing and sleep easy on performance hits:

- (NSArray <Employee *> *)allEmployees {
    NSMutableArray *container = [NSMutableArray new];

    //build up container with employees...
    //i.e. [container addObject:anEmployee]

    return [container copy];
}

Also — Swift 👋?

Think about the bridging process. If you, or perhaps another framework, have a foundation collection returned to you that one has to use in Swift code — you’re getting the value type of the collection since the language employs value type semantics.

How does one enforce that 🤔?

…with a copy on the reference type during the bridging process. So now if that bridged data was never mutated, the whole bridging operation’s efficiency is greatly improved. Which, I suppose, is a nice seque to wrap things up.

Final Thoughts

As I positied in one of my more popular articles a few years ago, Objective-C has become stronger and more capable due to Swift’s presence alone. The sea of apps using Objective-C runs deep, and now their collections run faster. It’s not surprising, as copy on write semantics have been with Swift developers since the beginning.

And now, here we are, with Objective-C getting in on the fun now. #DinosaurNotDead, am I right?

Until next time ✌️

Jordan Morgan (@JordanMorgan10) | Twitter

If you enjoyed this week's post, please feel free to go ahead and NSRecommend(this, where: below);

Copy on Write in iOS 11 was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.

Like Creeping, Just Legally

A quick note — all of my future posts will be published on my dedicated website and this publication is no longer being updated. Thanks for reading!

Each WWDC, there is always the obscure API that finds its way into the annual “word bubble” slide of new toys for developers to use. Faintly sitting there, it stands to reason that Apple considers it a useful addition that only the few, and not the many, will use.

DeviceCheck fits that bill, and then some. You might consider it a necessity from Cupertino & Friends™, something they had to make or face the reality that engineers would find another way to do thing X or Y resulting in shady means to the same end. Because developers don’t do shady things, like ever.

So, DeviceCheck is kinda what happens when most devs want to do things for perfectly valid business reasons, but there aren’t really any good ways to do it. It’s a curious little API, our topic of discussion this week.

So, What Is It?

The TL;DR is nothing more than this: It’s an Apple approved, and guaranteed way, to identify your app as running on a valid Apple device while maintaining absolute user privacy.

That’s not the most interesting of news, I suppose. The real discussion here lies within the why part of things. And the why spectrum, in this case, could range from toggling promotional offers on a certain device, linking purchases to accounts or auditing a device for fraudulent activity. For example, who here in the room has made two different usernames or profiles to extend a free trial of some sort?

…

…..

……..

🙋🏻‍♂️.

That’s really it. We’re simply taking about helping one associate some given state for any given iOS (or tvOS) device in particular.

To get your creative juices flowing, consider that you have two apps released. If they open App One, you could assign the device to state 01 — and when they open App Two, you can query the state as it will be persisted in the same fashion and then unlock some content, discount or reward.

It’s an app-agnostic API, so leverage it as such if the occasion calls for it. But, also be aware if that presents a design constraint to you. Again, we’re talking about two bits per device — not two bits per app.

So — how does it work?

The API

I’ve always appreciated “just get to the point” type of APIs, and that’s exactly what we get here. The setup allows a developer to store two bits of information (along with a timestamp) per one device. So, instead of peeking behind several doors that Apple would rather you leave shut to identify a device, you can simply get a few bits back and be done with it:

let curDevice = DCDevice.current

if curDevice.isSupported
{
    curDevice.generateToken(completionHandler: { (data, error) in
        if let tokenData = data
        {
            print("Received token \(tokenData)")
        }
        else
        {
            print("Hit error: \(error!.localizedDescription)")
        }
    })
}

Note that the simulator won’t pass isSupported, so if you want to test it out— I guess do what we should be doing anyways and use the real thing 📱.

With that code you’re on your first step (more to follow) to be able to store either:

• 00
• 01
• 10
• 11

When you set that information, it remains valid and stored by Apple until you as the developer manually reset it or until you update it. That means you don’t have to code your way through tricky things like reinstallation, nuking all contents and settings or straight up deletion. It’s also worth noting that these values are unique per team ID.

Also, be aware that like most tokens, it’s intended for single use. As you’ll see in just a minute, you likely use this token outside of your app and on your server. It will stay valid long enough if you need to retry a request, but the big Apple just recommends invoking the same method to generate another one.

A Closer Look

You may be looking at the previous code sample and wondering how that really helps us at all. How are the bits assigned? How do you set state? All we’re doing so far is getting a token. You might’ve expected something like this:

let curDevice = DCDevice.current
curDevice.setFirstBitState(as: true)

// or

if curDevice.secondBitState() == true
{
    // Do something
}

It’s a fair question, and it’s because the client API (iOS or tvOS) only handles half of the transaction. On iOS, we’re given an ephemeral token which we send to our own servers. That validates authenticity, then we can either set the bit state or query it and fire a request off to Apple. Then Apple gives us the state we’re after.

It looks like this:

1. Client uses DeviceCheck to get a token
2. It sends that over to our servers and we decide state
3. We pass the token and state to Apple, and done

And then to query it later:

1. Client uses DeviceCheck to get a token
2. Your server queries the state of the device with Apple
3. It gets the response and your app takes the appropriate action

This is not as heavy handed as it sounds. A simple POST and wrapping up your authentication key as a JSON Web Token gets you all the way there. A request to query bit state would just need to include a JSON payload like this:

{
   "device_token" : "anAmazingUniqueToken"
   "timestamp" : 0934423486434,
   "transaction_id" : "you come up with this" 
}

And then Apple would respond with:

{
   "bit0" : false
   "bit1" : true,
   "last_update_time" : "2017-10" 
}

Coming back the other way, if one needs to update it - the payload is exactly the same except you include one, or both, of the bits you wish to update:

{
   "device_token" : "anAmazingUniqueToken"
   "transaction_id" : "you come up with this",
   "timestamp" : 0934423486434,
   "bit0" : false,
   "bit1" : true
}

In saying all of this, I assume you are aware of the other logistical trappings one must take to send web requests. For example, follow the Base 64 URL encoded JSON web token format and ensure that your authentication key employs the ES256 algorithm. Otherwise, you’ll be met with no helpful bits to use for state and instead get a nice BAD_AUTHENTICATION_TOKEN http error 🙈.

For more on how to set these requests up, what data types to use and even some example requests using curl — be sure to hit the docs.

Being a Good DeviceCheck Citizen

As with any API, there are right and wrong ways to go about things. With DeviceCheck, simple though it may seem, there are a few choice scenarios to be cognizant of.

For starters, recall that time stamp that Apple gives us during our query:

{
   "bit0" : false
   "bit1" : true,
   "last_update_time" : "2017-10" 
}

That update time is rounded to the nearest month. This could help you solve some problems that could arise from things like devices being sold to someone else. For example, if the bit state says they’ve done something they should only do once, but it’s been a year since they’ve tried that — pair that fact with other business logic to avoid locking a new customer away from content.

That directly leads us to the next tip Apple recommends, which is that this is a supplementary source to help solve these specific problems. That is, it should be paired with your business logic. Getting the bit state is a great start and certainly welcome help, but pair it with logical checks that help you ensure you’re not stonewalling new users.

It’s also mentioned that this shouldn’t affect your user interface much. I think this is fairly obvious, but an additional nudge never hurts. Most of us have several ways of knowing when to toss up your “first run” modal that introduces your app. Querying a bit state that requires at least three trips across the wire shouldn’t be one.

Lastly, Apple gave us this API for a reason. In the WWDC chat over the topic, they straight up say that they will continue to remove sources of entropy outright or at least make sure they are under user control. Read: “If you abuse our ecosystem to tag phones we will find you and eliminate your methods.”

Wrapping Up

UDID querying is out. Linking back via an IP address is hacky and easily dodged. So now the act of uniquely identifying an iOS device, nefarious reasons or not, has first class support in iOS 11. I, for one, applaud Apple’s decision to include a safe and pragmatic way to do this. Because somewhere out there is a dev with a business requirement that needs to do something like this.

Now, they can. And they don’t have to do any funky dances to do it.

Until next time ✌️.

Jordan Morgan (@JordanMorgan10) | Twitter

If you enjoyed this week's post, please feel free to go ahead and NSRecommend(this, where: below);

iOS 11: The DeviceCheck API was originally published in The Traveled iOS Developer’s Guide on Medium, where people are continuing the conversation by highlighting and responding to this story.