For anyone developing for Apple’s platforms, Apple Developer Documentation is a essential resource. On the web at https://developer.apple.com, it’s one of the few places to get detailed authoritative information about Apple platforms.

Unfortunately, information on most Apple Developer pages is harder to understand than it needs to be because of a simple misconception apparent in the design of the pages.

(Full disclosure: I applied to work on the Apple Developer Documentation team in 2017, had a positive experience, and was invited to reapply later or apply to another team, but did not because I did not want to relocate.)

An example illustrates this clearly. Landing on this page on iPhone:

Identifier for what? What session?

When there is more screen space, as on iPad, the results are a little better:

By looking in the navigation bar, and noticing the third of four items that is the immediate parent of this page, we can see that we are in fact looking at an instance property of ARSession, the fundamental starting point of Apple platform AR experiences.

Saying “identifier is an instance property” is incomplete, equivalent to saying “identifier is an instance property on”. Instance property on what? It’s an incomplete statement.

This is the flaw: Each page is designed as if it completely independent, and the parent is of no relevance other than as the source of the navigation.

If there is any doubt, inspecting the element on desktop confirms that the navigation bar that embeds ARSession has the aria accessibility tag “Breadcrumbs”:

The misconception is not the fault of ‘the designers’. The documentation is organized in a single unified hierarchy; the pages have designed with best practices for a website organized in a hierarchy. And the unified hierarchical organization of developer.apple.com is good, actually: good for navigation and good for general organization of a massive complex topic.

This is why the page becomes even less intelligible on iPhone: Breadcrumbs are the first thing to be sacrificed, as it’s a safe assumption this not important information. On pages that describe aspects of objects in object-oriented programming, this is a fundamental mistake.

To look closer and at possible low-impact solutions, it’s necessary to look at the what this concepts being presented actually are.

Object-Oriented Programming: State and Behavior

Object-oriented programming remains fundimental to development for Apple platforms and everywhere and not just for legacy reasons. One key reason is that object-oriented programming helps make programs easier to reason about — managing complexity being a fundamental skill of software development.

What is an “object” in object-oriented programming? One definition perfect for us is an object encapsulates state and behavior.

“State and Behavior” maps to the categorizations of identifier above: state is encapsulated in Instance Properties and Class Properties, and behavior is encapsulated in Instance Methods and Class Methods.

What is “encapsulated”? It means, among other things, that these properties and methods are defined in terms of the class, or object. They have no “global” meaning. They only have meaning as part of the object they are in.

Another analogy would be transitive verbs in English grammar. A transitive verb requires a direct object to be grammatically correct. Conversely, an intensive verb does not and can stand alone: I am going to shop [period], with shop being intransitive. A transitive verb requires a direct object to receive the meaning: I am going to buy [period] is grammatically incorrect if there is no direct object in the sentence specifying what the speaker is going to buy.

Instance Methods and Instance Properties, and Class Methods and Class Properties, make no programmatic sense outside of the type — why the page for ARSession.identifier is unintelligible.

Solution: Seeing in Context

On iPhone or other compact size classes, as seen in the first image above, currently the type is not even visible without tapping the dropdown “Documentation.” A simple stopgap solution is evident. Pages in the instance/class object-oriented categories could show the parent of the current page. While a deviation from general principles of navigation, the immediate benefits of seeing the type that the page is in fact about will make these pages dramatically easier to understand.

In the long term, documentation teams need to work with designers to find a way to identify how to present all of the necessary context on each page for each symbol. If the symbol is a instance method or class method or instance property or class, it’s essential for the type to be displayed prominently.

There are more possibilities for embedding domain knowledge into the navigation and presentation. For example, the Vision framework uses a multi-level series of subclasses on the base VNRequest and VNObservation to specialize vision capabilities, an appropriate design choice for functionality that is is specialized additively: Subclasses add new functionality but retain superclass’s methods and properties, which remain essential.

Currently, though, to try to understand a Vision subclass requires keeping multiple pages open and manually reconciling them, as well as reading superclasses while trying to keep track of . Embedding superclass methods in the child page, either with specialized notes or just as a reduncdency, would make Vision Request and Observation specialized task pages more complete and easier to understand.

Regardless, developer.apple.com needs to ensure. The site is essential, and is generally fast, complete and good looking. Web sites remain the best way of presenting these vast libraries of information. With the slightest tweaks, surely the result of misconceptions rather than intentional, the ability of Apple to communicate to platform developers will be even more effective.

Mike Sanderson is an iOS developer in Brooklyn, NY.

When I taught English as a Foreign Language in China, the best example of paralanguage I had was “Are you coming today or tomorrow?”. Inherently ambiguous in writing, the question was usually not ambiguous when spoken: It could be pronounced “Are you coming today or tomorrow?”, (today⬆ or tomorrow⬇?) expecting arrival in the next two days; or “Are you coming today or tomorrow?”, the entire sentence asking a yes-no question if arriving in the next two days (today or tomorrow⬆?).

Another example of ambiguity and paralanguage is the second clause in the title of this post, more a question of emphasis: It could be pronounced asking about specifically what is the referent of a model; or asking in a more general sense about the quote, “a model to follow”, that is deployed across marketing channels by Work & Co marketing to imply Forrester Research’s endorsement. Two pronunciations:

• What is a model to follow?
• What is ‘a model to follow’?

This message asks both questions.

To give background, my former employer, Work & Co, has been under federal investigation by the NLRB since September 14. Work & Co is under federal investigation specifically for violations of the NLRA for firing me for trying to discuss the abusive and corrupt HR process Work & Co subjected me to in my last 5 months from March to August 2021. The full write up will be longer than a post, which is why I am first drawing out specific issues to focus on from the Work & Co corruption:

The first question is “What is a model to follow?”. On the page, “Process”, it is folowed by the quote “We ask our clients to participate directly with us in an intensely collaborative process based on specific KPIs, rapid prototyping, and continuous testing and improvement.” However, I think I recall first seeing “a model to follow” specificaly attached to Work & Co’s practice of not using timesheets, unusually for an agency. Since hourly timesheets are widely despised and mostly useless anyway, tracking work by the day is great, doing it at the resourcing level will usually make sense, and I can endorse that.

However, my view of the lack of timesheets did change as my situation at Work & Co deteriorated, in response to months of bullying. I do think it contributed to upper management’s belief that “quality and speed of work” was subjective, not objective, and I had to accept whatever they decided to declare about my code despite my contention the “quality and speed of work” could in fact be objectively measured.

(In fact, when I was first asked to leave the project and company on June 22, the Director of HR said “Quality and speed of your work”, but on July 26, Aug 4, Aug 13, her phrase changed to “quality of work”. I had to correct her every subsequent time: “and speed?” I asked. “And speed” she affirmed. My current guess is while she was confident that lawyers would treat my code as hieroglyphics, the project managers would have to weigh in on “and speed” and they declined, for among other reasons, everything was tracked in the project management system.)

The second question of “What is ‘a model to follow’” is more utilitarian — stepping back, what is this quote for? I’d been seeing it across Work & Co for years, and I saw it again on the page on PowerToFly when I became aware of that effort to open a pipeline of new marginalized people to replace the marginalized employees they have bullied, fired and alienated.

PowerToFly, which I was not familiar with, says “Our Mission Is: Connecting Diverse Talent To Big Career Moves” and on their about page, “empowering underrepresented talent”.

I posted my questions for PowerToFly on Friday. I am appending another question to PowerToFly:

• What are the standards for text in this box? Is this body text just a empty box where companies that have paid the fee to become a partner are allowed to write whatever they want? Is recruitment just another form of sales — all’s fair in recruitment and marketing?

If this quote, “a model to follow”, is about timesheets and client process, why is it suitable for inclusion on . Of course companies can pump themselves up; and it was that Work & Co has the top 0.1% designers and gets the biggest, splashiest contracts that I was happy doing the engineering for the iOS apps, as I have done successfully for 8 1/2 years now. And as I said Friday, Oct 22, I doubt PowerToFly would be set up to detect this and the company

But if PowerToFly’s mission is to empower marginalized people — and Work & Co is a “partner” — I don’t think it’s appropriate to allow . And I think Forrester Research, if it does mean it’s an independent research company, should look. If nothing else, the federal investigation is advancing, facts are sworn in my affidavit, and Work and Co has submitted their response — apparently bog-standard defenses to violations of the NLRA Section 8(a)(1), that I was so terrible and not one other person cared about my problems, etc.,

PowerToFly should look at what they are letting Work & Co say and imply, if they want to stay true to their mission and not send more marginalized people into the maw — where the Director of HR controls not just ordinary HR, but also the harassment complaint process, as complaints are sent directly to her email, and also receives a copy of anything sent into Work & Co’s annoymous feedback form. This is not a safe place for marginalized people.

And Forrester Research doubtless would want to look at where their years-old quote is being deployed. Right now it seems to suggest that if marginalized people are looking for a place they can do their work free of harassment and bullying, Work & Co is “a model to follow”. I suggest with what is still to come out, this is not a good look for an independent research company with a reputation to uphold.

Teaching paralanguage in China was so fun. Because Chinese students are drilled in tonal pronunciation as part of learning standard Mandarin, my Chinese students of English would be able to reproduce emphasis of pitch almost immediately, and they could themselves hear how immediately it improved their pronunciations. They would ask me, “if this is so important, why don’t we get taught this, often, from the beginning?”

It’s a good question, and my explanation was: “Because it’s unconscious”. Native speakers don’t think about it, it comes naturally, and that’s why it doesn’t get brought up enough — I agree it doesn’t — in the EFL books and lessons because — we just don’t think about it.

It recalls another offhand comment about paralanguage, from the person who taught me both linguistic anthropology and also investigative journalism: “You can use this as a lie detector.”

PowerToFly on LinkedIn: We're thrilled to announce our newest partner Work & Co and welcome

I can only assume this is related to recent events inside Work & Co, which displayed to everyone, starkly, how Work & Co upper management actually deals with their marginalized employees who don’t know their place — why since September 14, Work & Co is under federal investigation:

The NLRB is only investigating this final weeks of Work & Co’s cover up, when on Aug 20 I posted first vaguely and then on Aug 27 posted substantively with documents and video in an open Slack channel, and asked to have a public discussion about how I had been treated over the past weeks and months.

At Work & Co, marginalized people who try to bring allegations of mistreatment for a public internal discussion and said are instantly scolded, as I was on Aug 20; marginalized people who try to substantiate their claims are fired, as I was on Aug 27.

Both under the guise of rules against “calling out”. Is a policy against “calling out” the new legal way to smear and punish marginalized people who make unwelcome allegations, however substantiated?

As someone who is, to put it quickly, not gender confirming and not neurotypical, I would hope that if you do ask your new partner about this case, PowerToFly would not accept vague handwaving about my mental state, with statements about alleged respect for my privacy allowed to dodge questions about abuse and let loose with innuendo.

Another way to put this to PowerToFly, re: Work & Co, is: Do you know where you are directing marginalized people? Do you know why?

I do not expect PowerToFly to verify my claims. But since you have proudly announced Work & Co is your partner, and now advertising that you want to send more marginalized people to replace the employees they have alienated and fired, I have questions.

• Does PowerToFly consider its partners’ policies for employee speech? Is a policy that does not allow “calling out” compatible with a safe environment for marginalized people? If such a policy against “calling our” is acceptable, is it acceptable to reply to an employees posts by invoking the policy to cut their mic on a substantive change, allowing the company to character their actions and the employee’s actions internally without any response?
• Does PowerToFly consider its partner’ policies following accusations of abuse? If someone makes an allegation against a specific person in upper management, is it appropriate for a PowerToFly partner to continue to have that person deal with the person they made the allegation against? After my first post on Aug 20, I was sent another message from the Director of HR, as if nothing had happened; the next week, I was encouraged to again get on a private call with the abusive director of HR.
• Does PowerToFly consider its partners’ policies on HR complaints or formal harassment complaints? In April 2021, I was asked to leave a project I had worked on in various forms for 18 months, including shipping on-time in June 2020, three months into the pandemic. I though the reason I had been given were not legitimate, and asked for an investigation under the company’s expansive harassment policy, — I had identified the lines “intimidate, belittle, humiliate” -- but to keep the temperature low, specifically not alleging protected class bias or asking for any action, just investigation. 4 months later it was still being stalled, and the preliminary answer I received in August was astonishing —just to start, I was told I couldn’t be harassment because there were concerns about the quality of my work. On Aug 17, after her abusive conduct had been caught on a Zoom recording, while still trying to get me to join another call with the seniormost tech partner, the Director of HR said in a Slack message she would get me the result in writing by the end of the week (coincidently after our next scheduled meeting, Aug 20) but she never did.

These general questions are not questions that are usually asked — and I think need to be asked more often, or always.

Like many others who have been victims of abuse, I have turned to activism. Yes, I seek justice for myself against the abusers, and while I could walk away and find a new job — I would rather be making iPhone apps, as I did successfully for 8 and 1/2 years — I am determined to see this through because they were only partially successful, and I have documents and video.

I assume this is new information for PowerToFly. You probably didn’t assume it; either because you aren’t set up to detect this, and indeed, the Director of HR and others at Work & Co can be very superficially charming. And at lower levels, there are innumerable brilliantly capable people there is was a pleasure to work with. But I would urge no one go to work there until the labor case is resolved and also until Work & Co stops stonewalling about their absuive HR processes.

I had a successful 18 months, but in 2021 at Work & Co’s I experienced textbook workplace bullying; I only reluctantly came to accept the disturbing conclusion there is a cluster of capital-B bad people connected to the top, who mask their contempt for marginalized people behind splashy diversity initiatives.

I want to try to help others from becoming victims — both at Work & Co and in general. That has brought me to write this letter. I hope that you respond substantially, not in words but in actions. Because now you have been told, and sending more marginalized people into that place would be complicit in Work & Co’s workplace bullying and abuse.

Mike Sand
October 22, 2021
Brooklyn, NY

Apple announced changes at WWDC that will reshape how to think about building apps for Apple’s platforms. One surprising announcement was iPadOS , turning what was always a variation of was a surprise announcement of what is effectively a new platform.

iPadOS is a departure from the use of “universal” iOS apps for iPhone and iPad since the iPad’s introduction in 2010, when it ran iOS 3. Following hardware differences like support for Apple Pencil and the use of USB-C instead of lightning on the 2018 iPad Pro models, it shows that the iPad is looking at use cases that have no equivalent on iPhone.

iPadOS’s headline new feature was multi-window support. Now apps can run in multiple “windows”. These iPadOS windows can appear in different multitasking frames and will appear separately in the new version existing task switcher, which each window for the app getting its own placement. which is less like iPhone and more like MacOS’s feature to show all windows, called “expose”.

iPad wasn’t even the only hardware platform to split from iOS at WWDC 2019. Apple Watch apps can now run independently from iPhone apps, and have gotten their own Watch App Store as a result. This has been the obvious goal for WatchOS since its creation in 2015. Apps can continue to use a “hosting” iOS app, but are no longer required to do so. The Watch itself still requires an iPhone.

A real question about naming is why “iOS” has not changed to “iPhoneOS” — which actually would be a change back, since it was originally “iPhoneOS” publicly from versions 2 to 4. The first version of iOS was iOS (5), changed from iPhoneOS in part because of the iPad, which ran all iPhone apps from the start.

Using the iPhone to push apps to other platforms is a reason why iPadOS was a surprising move. Apple still wants to use the overwhelmingly popular iPhone to drive apps to other platforms, including iPad. For developers, iPadOS could have seemed like a burdensome a new platform to support. That concern was alleviated by the introduction of the already-teased feature in a change teased last year as “Marzipan”, now dubbed “Catalyst”.

Write once, check 3 boxes

iOS apps can now be built simultaneously for 3 platforms at once: iPhone, iPad and Mac. Apple promises this is as simple as a checkbox.

Previously a codebase that wanted to use iOS code on the Mac would need to separate our platform-independent code into a framework, then re-integrate it into a “target” for iOS or Mac. For iPad, iOS code would have its own methods to determine if it was running on iPhone or iPad, which ranged from the crude (checking if the device is an iPad) to the elegant but difficult to reason about (the system concept of “size classes” was never popular with developers).

Now Apple promises that a single codebase can run on all three platforms. Features that are dependent on platform, such as the difference between touchscreen taps and mouse clicks, will either be handled by the framework, or handled inline with a minimum of code differences.

This explains why the introduction of a new platform to support got such little attention or concern from developers, since in practice it promises to be no more work than supporting a universal iPhone and iPad app today, and supporting a MacOS app promises to now fall into that category.

Despite “Catalyst”, some apps may find that the requirements to support features such as multiple windows don’t makes sense or would result in a poor user experience. These apps may find it more aligned with their goals to drop iPad support and focus only on iPhone. (Even with iPad’s new multi-window support, developer guidance notes not every app needs to have multiple windows.) But if a codebase does handle multiple windows, they’ll be able to use that code for its iPad and Mac apps. iOS apps for Mac also will require MacOS Catalina, which will be available in the fall.

iOS for Mac in Practice

How seamless supporting multiple platforms will be in practice has yet to be determined. Our early experiments were mixed.

In initial tests with one app that we maintain for a client, it compiled and ran without issue — after we refined the handling of its window. After that, the iPad app on Mac received mouse clicks as touches interchangeable, and its support for multiple screen sizes on iPad translated perfectly to support for multiple sizes of a single MacOS window, including during resizing.

We tried to run another iPad app we maintain on Mac, but it would not build on Mac at all. It used legacy OpenGL code, which was deprecated by Apple last year. (Despite being depreciated for good reasons, OpenGL is so widely used its remove is almost unthinkable. Its deprecation was barely mentioned at WWDC, which would not be expected if its removal was on the horizon.)

How we could remove only the OpenGL code and run a subset of the app on the Mac was not immediately apparent. But this particular iPad app was a highly-custom, exquisitely designed iPad experience, and it didn’t seem like it would make sense on the desktop. The question of how we could move this iPad app to the Mac technically was a less important questions than if it made any sense to do so.

With the changes announced at WWDC 2019, everyone involved in making apps for Apple platforms needs to take a renewed look at how they choose what platforms to support. And ask themselves why, and how; the answer to why and how the different platforms are supported is set to get new answers.

iPadOS and iOS for Mac was originally published in Tendigi on Medium, where people are continuing the conversation by highlighting and responding to this story.

The path to using Core Data in Swift is less like highway and more like a perilous trail clinging to the side of a mountain.

Like many Swift issues, however, the issue is not new dangers but existing unsafe practices being revealed. One appraoch is to simply re-create the unsafe practices, such as with implicitly-unwrapped optionals; another is to wrap everything in so many levels of `guard` and `if let` that control flow becomes hidden among unnessary branches.

Regardless, the deeper that Objective-C’s assumptions have been built into a framework, the harder it is to use in the radically different world of Swift. That can be true even when attempts have been made by the system to bridge the gap, such as adding a Objective-C Generic to the NSFetchedResultsController, with mixed results.

After crashing the compiler another approach was called for.

Adapting FetchedResultsControllerDelegate

The possibilities for working with NSFetchedResultsController in Swift are limited, like many Cocoa delegates, by the requirements imposed by it: The delegate must be an NSObject, its methods must be Objective-C, and the callbacks can’t be generic.

The goal is to adapt the NSFetchedResultsControllerDelegate to hide its legacy Objective-C baggage. This can be done by wrapping NSFetchedResultsController in an adapter class, an adapter class that does meet the legacy requirements, and that passes new delegate callbacks out in pure Swift.

The first step is to recreate the delegate as a Swift protocol:

The interface here matches the NSFetchedResultsControllerDelegate almost exactly (leaving out the extraneous controller(_:sectionIndexTitleForSectionName)). The associatedtype is named ResultType, and since it will be the NSFetchedResultsController’s ResultType, it has the NSFetchRequestResult constraint, but we’re not confusing the compiler by asking it to bridge the Objective-C to Swift generics.

Notice we do still use the NSFetchedResultsController: We’re not ready to refactor that out yet; the goal right now is to adapt the delegate. So we keep the NSFetchedResultsController and its related `NSFetchedRequestResult` and `NSFetchedResultsChangeType`.

FetchedResultsControllerAdapter class

Then it’s possible to build out the adapter:

Even without decoding the generics it’s strightforard what’s going on: The delegate messages from the NSFetchedResultsController get transformed and passed on to the FetchedResultsControllerDelegate instance. Every detail needs to be considered, however, line-by-line:

Class Declaration and Properties

The class delecration, like most with generics, may not be intiutive. It can be understood in roughly three parts:

1) class FetchedResultsControllerAdapter<Delegate: FetchedResultsControllerAdapterDelegate>

The FetchedResultsControllerAdapter has a single generic type, Delegate, which is an instance of FetchedResultsControllerAdapterDelegate we created earlier. The AdapterDelegate must be a generic on the type because, as most Swift developers have learned, it can only be used as a generic constraint because it has Self or associated type requirements. Throughout the class, we will refer to this as Delegate.

Since Delegate has a ResultType, we can refer to that as well, such as in the Fetched Results Controller property:

private(set) var fetchedRequestController : NSFetchedResultsController<Delegate.ResultType>

Which is all that’s necessary to ensure the NSFetchedResultsController and the Delegate’s ResultType match.

2) NSObject, NSFetchedResultsControllerDelegate

FetchedResultsControllerAdapter is an NSObject, the requirement of the NSFetchedResultsControllerDelegate, which this class conforms to.

3) where Delegate: AnyObject

This constraint exists for memory management. Delegates are a classic source of retain cycles. If this object a strong reference to its delegate, keeping it alive, and if the delegate keeps a strong reference to the adapter — which it almost definitely will — keeping it alive, then the two objects would never be deallocated.

The best way to handle this is to delclare the property weak:
weak var resultsDelegate : Delegate?

But this can only be done with reference types; value types have no reference count because they have no references.

There are other ways to prevent a retain cycle if making the delegate class-bound wasn’t possible. The delegate (referring to the client that holds a reference to the adapter) could explicitly nil out its instance of the adapter in its `deinit` method; or in the delegate could call the adapter to set its delegate to nil (though there’s no good reason why something other than the delegate would have a refernce to this class). This would be acceptible added complexity if needed; but it’s not needed yet, and for now we just need to have the delegate property be weak.

Init

Init’s goal is to ensure that the correct arrangement of delegates is set up — which is only mostly possible.

1) init(frc: NSFetchedResultsController<Delegate.ResultType>, resultsDelegate: Delegate?) { //...

The init method sets up this wrapper class predictably: In the first parameter, it takes an already-configured FetchedResultsController, keeping various Core Data responsibilities out of this class to keep it focuses. The property (abbreviated to frc) is private(set) to force clients to use the init method; it’s publically accessible so that clients can use it freely.

The second parameter is the generic Delegate. Any client can provide an instance of any class that conforms to the protocol and it will work. One way to think about it is that for every concrete class uses, the compiler will create a new version of this class, substituting the concrete class for every use of Delegate. This is how it avoids confusing the Objective-C callers.

2) self.frc = frc
self.resultsDelegate = resultsDelegate
super.init()
self.frc.delegate = self

The call to super.init() stands out. The dance of the superclass intializers has been a source of frustration for Swift developers, but the rules often make a great deal of sense: This class can’t be a delegate of another object if it doesn’t yet exist, which it doesn’t until it has called super.

This is also the reason why delegate is optional in the init method, and instead is a publically-settable optional variable, even though this class doesn’t have much purpose if it doesn’t have a delegate: If another class wants to initialize an FetchedResultsControllerDelegateAdapter as part of its initialization process, it will need to perform the same call to super before doing so, or at least finish setting its own properties, which may include this adapter. If the adapter required a delegate as part of initaliztion, it would badly hem in clients.

It’s for this same reason that the Adapter doesn’t call performFetch() itself, instead exposing a method. Delegate methods could start firing immeditely, before the delegate is set, or clients could not be ready for delegate callbacks until some future point. Since clients can access the controller themselves, this method is somewhat a glorified reminder that the step is necessary.

Deleagte Callbacks

The delegate callbacks are straightforward, passing methods almost straight through from the @objc to the Swift protocol delegate.

However, the @objc delegate methods don’t pass in typed FetchedResultsControllers; all are merely typed to NSFetchedRequestResult. The passed-in controller could be cast to the appropriate type, but since this class is only every going to have one NSFetchedResultsController, it’s just as simple to pass that. A problem could result if for some reason this class was set to be the delegate of a different NSFetchedResultsController, but there’s no reason to do that.

The Use Site

A side effect of the generics is that clients must create a FetchedResultsControllerAdapter in effect, typed to themselves:

class MyViewController: UIViewController, UIFetchedResultsControllerAdapterDelegate {

var fetchedResultsController = FetchedResultsControllerAdapter<MyViewController>

Which may appear odd, as it’s not immeidtely apparant what the relationship between FetchedResultsControllerAdapter and MyViewController. A technique for creating non-generic concrete classes can be used here:

class MyViewControllerFetchedResultsControllerAdapter : FetchedResultsControllerAdapter<MyViewController> {}

Although the added complexity may or may not be necessary purely for readability at the site of use.

The approach taken here has liberated FetchedResultsController from the legacy restrictions on its delegates. Moreover, this adapter class only needs to be written once and then forgotten about.

With this adaptation, the liberated FetchedResultsController can start to take advantage of Swift’s amazing features to become even more powerful.

The idea behind “Engineering for Testing” is to write code not against the interface of concrete classes, but against protocols that have the same interface and the concrete classes conform to. For “real” builds, the real object is used; for testing, a mock or fake object can be substituted, allowing robust tests.

For a Core-Data–based app, this meant creating an ‘NSFetchedResultsControllerPrototol’ that we would code against. NSFetchedResultsController actaully has a generic class that it useses — its rull deleration is NSFetchedResultsController<ResultType> : NSObject where ResultType: NSFetchedRequestResult. This is perfect for us, because then we can use an associated type, and then substitute mocks for the object vended.

This approach produced no inline error when writing it out, and planning and development proceeded with the assumption this would work. When it came time to build, however, the result was different, evetually isolated:

A segmentation fault during compilation means to compiler itself has crashed. Unfortunately it’s a regular occurrence when working with generics, and there’s no option in the short term but to work around.

(But before that was a crashing mess of warnings, errors that had a tendency to look like emoji of how they make you feel: '_', <_>, etc.)

Core iOS functionality is still native Objective-C, and even when it’s represented in Swift, don’t assume it’s going to work until after validating as close to your specific use case as possible. There are still possibilities for mocking Core Data, including robust mocking; subsequent posts will explore them.

Edit: Now filed as Open Radar 35110402.

The goals is to fins a way to organize, very readable, esaiy to use and maintain.

The first way that was suggested, ealy in Swift, is to use an enum with a raw value:

enum StoryboardID : String {
    case main
    case profile
    case edit
}

This usage was popular enough that for Strings, Swift 2 automaticly uses the case name as the raw value. The above is:

let mainStoryboardID = StoryboardID.main.rawValue 
// mainStoryboardID == "main"

// But: 

enum SegueID {
    case toDetail
    case toSettings
    case toEdit = "toEditVC" // One case raw value specified
}

However, one minor downside is that to work with the string, you are always going to have to access the `rawValue` property:

let mainStoryboard = UIStoryboard(name: StoryboardID.main.rawvalue, bundle: nil)

Enums come with some other details that could interfear, or at least distract, from their use of constants. For one thing, enums should be able to be used interchangibly.

In most cases when you want to use a constant, you want t create a specific constant, not “any one of this grouping of constants.” Is there a better way to specify this?

##Static Let

Static constants just add constants as static variables (or constants)

struct StoryboardID {
    static let main = "main"
    static let profile = "profile"
    static let edit = "edit"
}

You don’t get the enum’s automatic conversion of the case into the constant string, but other than that, this is more flexible and specific:

let mainStoryboard = UIStoryboard(name: StoryboardID.main, bundle: nil)

Enums are still useful for checks: Where you know you want one of several possibilities, and need to be able to check which one you have.

guard let segueIDString = segue.identifier, segueID = SegueID(rawValue: segueIDString) else { fatalError("Unknown segue \(segue.identifier)") }

switch segueID {
    case toDetail: //...
    case toSettings: //...
    case toEdit: //...
}

The ability to enure that every case if covered is `enum`’s great benefit, and usuing enums just to hold independent values isn’t a good use of them.

Dan O'Leary on Twitter

This works but really feels like I'm being redundant nesting a Switch statement inside a for-loop. #swiftlang #codingwithfeels #allthefeels

There’s nothing wrong with a `switch` statement in a `for` loop, but this code has a lot of repetition. You could add the hours-for-day to the “Brewery” object, but the label for the day of the week (“Sun:”, “Mon:” etc.) is a UI detail that the model shouldn’t hold.

Along with the label, what changes for each row is which property to access. Storing a reference of which property to check is exactly what KeyPaths do.

The `startTime` array defines a label together with a `KeyPath` to a property. The property is not accessed, however, until inside the loop.

Before Swift 4, the best appraoch would be a `switch`, accessing the property in each caseand returning the string that accessed the property. One disadvantage is a switch/case would hardcode the relationship of index with property; if we wanted to start the week on a Monday (Or maybe the current day, with subsequent days trailing downward) we would need to add an offset and also handle overflow. (This example still hardcodes the order in the “startTime” array, but this could be generated based on locale, unlike a hard coded switch.)

This is a simple example, but shows how KeyPaths works and hints at their potential to add new flexibility.

What a great WWDC. We saw amazing new marquee frameworks, CoreML and ARKit. We saw a real effort to address longstanding pain points, addressed in a way that shows Apple takes very seriously; other longstanding missing pieces were filled in. We saw an emphasis on accessibility, across sessions throughout the conference. We saw a more diverse speaker than ever, especially women.

And the talks were as great as ever. We saw that Apple still has amazing engineers and is producing amazing technology, and the company and the platform look as strong as ever.

We saw this through a glass, dimly. Because the same cannot be said for key elements of the conference: the video production, the accompanying documentation, and the sample code provided. The sample code had issues when we could see it at all — tales already abound of developers, chomping at the bit to try ARKit, freeze-framing videos to type the blurry visible still frames of code into their computer. It’s not too late for Apple to snatch defeat from the jaws of victory.

Inspiration

The title “Build and Run” was inspired by past years, when amazing technologies on display turned out to have huge caveats or hidden catches. An alternative title for this talk was “Looks Great in the Demo.”

So the idea of the talk is to take some first impressions and ask: “Does it build?”, “Does it run?” and “Does it improve my life to be worth the complexity?”

I first started watching WWDC videos as a full time iOS developer in 2013. In 2016 I was lucky enough to win the lottery toattend, and I got more insight into how WWDC worked: You attend a session, and then you go downstairs to the labs, where the engineers await, and there you ask you questions from the session, sometimes of the speakers themselves.

On the couch, there are no labs.

So the idea of this talk was to use all the resources available to see how the stuff announced actually performed. And I’ve tried to only cover things that I personally tried, and I personally built and ran.

I originally planned to talk about each subject equally. As I got started, I found I had more to say about Dynamic Type than about everything else put together.

So the following will be quick hits:

• Swift
• Drag and Drop
• CoreML / NSLinguisticTagger
• Core Location
• Core Bluetooth

The largest portion:

• Dynamic Type and Friends

Ending with a final quick hit:

• ARKit

Swift

I’m not going to talk a lot about Swift because I didn’t get a chance to use most of the headline features. But many of them do fit in with the themes of this talk:

Refactoring

We got refactoring! It only took three years. I remember I the summer of 2014, downloading the first first XCode with Swift, wanting to make some change, and discovering the familiar refactoring menu was grayed out. I distinctly remember thinking, “That must be coming in a later beta.” It didn’t occur to me it would take three years. That would be ridiculous.

And at three years Swift refactoring is not even the most long-long awaited feature in the talk.

Swift 3 / Swift 4

Based on my initial impressions, you can have a project and go back and forth from Xcode 8 to Xcode 9 seamlessly. Swift 3 migration was a fiasco; the emphasis is on preventing something similar from happening again. It’s almost like someone got fired for that.

But has Apple Developer Tools prevented something similar from happening again, or has Apple merely prevented a Swift migration fiasco from happening again?

Keypaths

I like this because of the line in the presentation “Keypaths are important to Cocoa development.” It really suggests that the rich history and tradition of programming for Apple Platforms is not incompatible with the future. You can look up the old guides on Apple’s website on Key Value Coding (KVC) and Key Value Observing (KVO); they feel rickety now but I can’t wait to see the next generation of Cocoa.

JSON Encodable

Is this the record for greatest mass Sherlocking ever? Nearly 500 pods made obsolete at once?

Access Control

Let us never speak of access control again. Agreed.

Drag and Drop

This was the first thing mentioned in the Platforms State of the Union — The Platforms State of the Union, if you don’t know, is the “Developer Keynote” that happens in the afternoon of the keynote and gives an overview of everything that’s going to be in the conference. It was also mentioned first in “What’s New In Cocoa Touch,” the first session of the first day, held in the largest room and well attended.

And “Introducing Drag and Drop” was also the first session after What’s New in Cocoa Touch, and if you don’t know, people are lazy and don’t like to get up. This is the WWDC equivalent of running a show after the Super Bowl.

So I was super excited to try it out:

Simulator doesn’t go into multitasking!

I couldn’t believe it. I fired up the old simulator, and the gesture worked.

So I filed a radar. At at 2:33 am this morning (June 12) it was closed as duplicate. How this is not treated as a five-alarm fire in Apple,? Drag-and-drop is key to the future of the iPad and the iPad is key to the overall strategy. An astonishingly link in the development process to have broken.

Also, Drag and Drop is iPad only — a fact not mentioned in the PSOTU — was that because they thought people would here “It’s iPad only” and tune out?

I love my iPad, and my iPad before it. I hope the iPad continues to thrive. But if the thinking was people will hear “iPad only” and then tune out, I suspect it’s not a great long-term or medium-term strategy. (It evokes the most baffling omission earlier, And while I can see the use even inside one app, since the demo app didn’t come preloaded with any data, there was no way for me to test even that.)

Anyway, with my radar closed as duplicate, I’m done. Drag and Drop is cut for time — life is short.

And that became a theme again and again — an amazing new technology, and a weak link in the chain of developer tools to make use of it.

CoreML

If you had “Machine Learning” in your Keynote drinking game, you are not with us, because you died of alcohol poisoning.

CoreML seems really cool. Admittedly, I don’t know much about machine learning. First, on terminology, we should probably clear things up. There is:

ML — Machine Learning

DL — Deep Learning

AI — Artificial INtelligence

AR — Augmented Reality

VR — Virtual Reality

VL — Vitally Loquacious

The last I made up, of course. The thicket of terms is an issue. The Naming scheme for CoreML caused me a great deal of confusion. What is ML?

The Framework and the Stack

After taking with others, we realized the issue was making out what exactly “CoreML” referred to. The title page refers to “a new foundational machine learning framework”. So it’s a framework? In some senses. But there is something called a “CoreMLModel”, that gets imported into Xcode; there are other models; there is a python utility for converting them; and somehow image recognition and natural language processing fall under CoreML… or do they? Do you import CoreML to do image recognition and natural language processing?

NSLinguisticTagger

The NSLinguisticTagger talk cleared many of these issues up. NSLinguisticTagger, didn’t this already exist? Yes, but much better, and much cooler. Now it can do and do more reliably:

• Language identification — is this French, German, Thai, Burmese
• Tokenization — Identifying Paragraphs, Sentences, Words
• Part of Speech — noun, verb, adjective.
• Lemmatization (from elementary school, “find the root word”)
• Named entity recognition

The last is huge. I was ready to rush forward with an app for underlining proper names in Chinese — in a language lacking capital letters, and where proper names made up of compound common words, identifying proper names is critical. So it disappointing to see that the more advance features (everything past tokenization) will be only for 8 languages, the furthest east Russian and Turkish.

Still, I greatly appreciate that supported languages were clearly spelled out, and not left to be found out later through trial and vague unhelpful error.

The CoreML Stack

Since NSLinguisticTagger remains a conventional API, what does this have to do with understanding CoreML? Of course, the means by which words, parts speech, and named entity are recognized in each language is different. And your app can’t use all 8 languages always — the model has to be installed, which happens when certain events happen, such as the user installing a keyboard.

So the stack, and the way that NSLinguisticTagger uses models that sit between it and the underlying CoreML framework, becomes more clear.

If you want to find the NSLinguisticTagger talk, don’t bother searching the WWDC app or website for “NSLinguisticTagger” or “CoreML”. The first brings no results, the second results for the CoreML intro and the image recognition talks, but not the talk we’re looking for. You have to know to search for “Natural Language Processing.”

Indexing or tagging talks by API so they can be found in search isn’t sexy machine learning. It’s much more basic.

Core Location

Core Location got a new permissions scheme, and I mean “scheme” in the British sense of “system” and not the American sense of scheme, which is closer to why we are getting new permissions.

I really have to take exception to the single line from the stage,

“We think you’re really going to like it.”

It’s a breaking change in crucial important code, requiring branching during the transition, and if we get our single chance wrong our apps will silently fail or crash. What’s not to like?

However, after looking it over, the phrasing on this was just too strong. It would have been fine to say:

*I think as a user you’re really going to like it, and as a developer your app is going to get better results.

So now users will always have to option to give an app only when-in-use permissions, which is great. And the new flow does make a lot of sense, and is likely to get better results. Really helpful that they got entire flow on a single slide. It’s not pretty but it’s clear, always the better trade-off:

Fortunately, also announced (but not mentioned from the Core Location stage) Objective C is getting Swift-style availability checking. It’s really great to see the best features of Swift being ported back to Objective C, without the disruption that comes with innovation.

Core Bluetooth

Core Bluetooth is my favorite framework, my extremely important for my postion at Raden working with Smart Luggage — and to put an integrated scale into your suitcase

Since I have such a high opinion of the Bluetooth team at Apple, it was astonishing to be informed that background APIs are now reliable in the background, including across system events like restarts. I have been through the documentation many, many times, and missed the disclaimers that we should not rely on them. But if they’re stable now, I’ll take it.

Dynamic Type

UIFontMetrics inspired this talk — which was set up months ago, when I had no knowledge of its existence. How?

Who here knows what Dynamic Type is? (Fewer than 20 hands go up, about 10% of the audience). To summarize, Dynamic Type allows the user to set their preferred text size in the iOS settings, and apps throughout the system will make all text larger or smaller. It’s not just a preference, but has important implications for accessibility, although if if you have normal vision it can prevent eye strain.

It was introduced in the 2013 sessions in Text Kit and was among the first WWDC sessions I watched, since less than a year earlier I had been an editor in print. Dynamic Type is more than size, as the 2013 Text Kit sessions explained. The system won’t just change the point size, but will make other adjustments depending on what the text will be used for. So instead of callingFontWithSize, you call preferredFontForTextStyle and get a font that is sized and formatted perfectly for you. It’s really very ingenious and advanced.

In 2013 I got all this and went directly from the end of the session to Xcode to see how it went. And I got it working with the system fonts, calling preferredFontForTextStyle. And then I looked for the API to do this with custom fonts.

And looked.

And looked some more. I wasted some time that evening and in subsequent days looking for the API to use Dynamic Type with custom fonts, because it made no sense to me that Apple would expect us to do this but include no means to do so. Why wasn’t there a disclaimer that it wasn’t yet possible?

If this was only a replacement for system font of size, why didn’t they just say that and announce we could get started and in subsequent years it would be rolled out further? (In 2013 a similar disclaimer would have been appreciated for Auto Layout in UITableViewCells, which innumerable developers including myself found out was not supported through unpleasant trial and error.)

And I was perplexed over subsequent years as they repeatedly encouraged developers to adopt it. Just a few of the most perplexing:

WWDC 2014:

We’re going to be asking that all applications that deal with text in iOS 8 adopt Dynamic Type and you’ll see in fact that all of our system apps have already done this.

WWDC 2015:

These are the text style APIs that are used for Dynamic Type, which also give you all the Dynamic Type advantages, such as users can go in their preferences, change their font size, and your app will react accordingly.

WWDC 2016:

Don’t forget things like Dynamic Type right, where the user can set a font size and all your applications are going to react and layout right, you’re all doing that?

That there was no way to do this with custom fonts — which almost everyone uses — became more and more bizarre, less an omission than some kind of weird blind spot.

Furthermore, Apple did not lead by example. Among the places Dynamic Type is not well handled in iOS 10 is the settings accessibility menu where you turn it on:

Here is the same menu in iOS 11:

The great news in iOS 11 is not just that there’s an API for implementing DynamicType with custom fonts. It’s that it looks like someone has gone through and systematically asked what developers needed to support Dynamic Type, and then provided it.

In addition to UIFontMetrics, there are other APIs, some of which already existed but have been made easier. There is UIContentSizeCategory, a property not just on a UIKit object’s traitCollection—traitCollection being another iOS technical innovation that developers aren’t quite sure what to do with — but on UIApplication.

You can see in iOS 11 that the switch has moved to the next line to accommodate larger text sizes . Not only do they provide a convenient API to do this, but instead of taking the opportunity to talk up Interface Builder like a parent telling their child broccoli is candy, the sample code provides examples for programmatic Auto Layout and using setFrame, which they call “manual layout.” Frames were never officially deprecated, and it’s great to (belatedly) see the acknowledgement that developers who use them for whatever reason shouldn’t be left out in the cold.

The Dynamic Type session in 2017 is hitting it out of the park on fonts and layout, and then got to the question of how to handle the size of images under accessibility:

So many questions! No wait, the presenter is going off stange, come back!

Apparently this had been addressed in What’s New In Cocoa Touch, which I watched live from my desk at work, before I had logical issues resolved; guess I missed something substantive when switching monitors.

This will be as big a change as the switch to @2x images with retina displays. And yet it was six slides on this topic and then over. Where was ‘Jill from Adobe’ to take the stage and show how easy it is to integrate export of PDFs into our existing workflow? Where was a systematic demonstration of how this is going to work?

Where was any reference to where we can get more information about this?

In the meantime it has fallen to outsiders to begin to explain how this works.

Phasing like “make sure you are” highlights that the presenters on stage are not working with an idea of their audience that reflect the range of organization challenges faced by developers. Are the same individuals who just sat through 20 minutes of API examples also composing assets? Are the same individuals who just sat through 20 minutes of API examples able to give orders to designers about how to conduct their workflow? Probably not.

Core Location provides an apropos contrast: Developers can take the new location permissions to their organization for the simple reason that Apple says we have to do this.

Yet unless Apple wants to make this an App Store rule or technical requirement — which would have negative ancillary consequences, especially for any less sensitive issue than location privacy — developers will need to see these changes within their organization. Developers will have to see this to designers, to clients, to managers. Apple gave us almost nothing to make this case.

Dynamic Type did come up in one of the “design shorts” videos. It was a great summery by designers for designers. it was also the second of three topics addressed in a ten-minute clip. So to pass this info from the design short to designers, we would to specify which range of the talk they should watch.

Sample Code

The Dynamic Type demo app brought further issues in last mile to getting developers what they need to implement this. I thought I had trouble because I don't’ care about Pokemon. But that was not the issue.

The first wasn’t anything to do with the Dynamic Type team, but not tangential because it’s a link in the chain: In Beta 1, Markdown in Xcode looks like shit.

It’s not the weird text justification on the lowest line, though what’s going on with that? The use of a half-d0zen fonts in one screen violates basic font usage. The decision to use a serif font for body when every other font is sans-serif is ridiculous; especially since of course markdown in Xcode has formatted code interspersed with body text constantly. A sans-serif would better meshed with the sans-serif font used every other place in Xcode. There’s also no way to customize the fonts.

Another issue with is that this code was called out from the stage as being a “recipe book.” There are four view controllers: It’s like a recipe book had two recipes for chicken, one for fish, one for tofu. A single example of each isn’t a good recipe book.

Finally, hope you looked at those bullet points in the markdown. Regardless, quick guess, which screen is the “BattleViewController” below?

If you thought the `BattleViewController` is the screen that says “Battle!” you would be incorrect; that is the “ScorecardViewController”. The `BattleViewController` is the screen titled “Opponents”. There is no screen to show the battle itself, which takes place the moment you click the button; the battle is over before the run loop.

This is serious because trouble getting orientated adds cognitive load at the exact moment developers are going to figure out even more complex issues. Putting a confusing series of labels conflicts with the purpose of the code existing in the first place.

In the actual sample code, there are several good examples of how to handle Auto Layout and “manual layout” — it is refreshing to see the acknowledgement that, yes Virginia, sometimes you want to work with frames.

A final note on the presentation of the sample code. The presenter clearly knew her stuff. Unfortunately, she spoke English with a thick accent, which I could understand, but a non-native speaker of English might find impossible (When I taught English as a foreign language abroad, students told me directly a thick accent makes it much more difficult to understand. At one point I was even called on to do English-to-English translation between Chinese and South Asian speakers of English)

Hearing the speaker should not even be an issue, because the sessions should be closed captioned.

The lack of closed captioning is another regression. I remember at WWDC 2016, sessions that were broadcast on monitors on the first floor were closed-captioned live. Closed captioning should be a straightforward task if the script is provided in advance. It is embarrassing to have a conference that gave such prominent attention to accessibility to not itself be accessible.

On a related note, the WWDC app did not support Dynamic Type.

(As of this write up, videos now have a caption icon appearing on the video but read “unknown cc” and no captions are appearing.)

Editing

The most obvious regression in this year’s WWDC production was the video editing.

Maybe it was the move to San Jose, and if the high quality video production of 2015 and 2016 was by in-house Moscone professionals. Or maybe it was the decision to try to broadcast all sessions live, which was unnecessary, especially if it led to a regression on any other metric.

Appallingly for the purpose of WWDC session videos, many sessions showed slides for only seconds at a time, and showed only the presenters on stage in frame. Picture-in-picture, where the slide occupies the frame with the presentor in a box to provide a visual connection to the words, was mainstay of 2015 and 2016 session videos and incredibly underused this year.

Picture-in-picture should be the default, and if the slide is too packed to allow it, show the slide. Don’t forget what the goals of these are.

It is possible to hypothesize that a lack of technical appreciation led to the poor choice of editing. However, in the session “Localizing Swift Playgrounds”, at one point the presenter asks the audience to look, with an exaggerated arm movement he presses the clicker — and the shot never moves away from the presenter alone. Someone just didn’t do a very good job on the video production.

Astonishingly, when one session had to be redubbed — apparently there was an audio recording problem, though that’s not noted anywhere — the editing still showed the presenters alone in frame for long periods. We’re looking at a video with the lips and body motions off sync. The 2014 and earlier format of only slides served us all well for years — there’s no reason to not note the audio issue, show presenters when they come on and go off stage, and go to a slides-only video that served us well 2014 and before.

ARKit

Since I have expereince making Augmented Reality apps, I had planned to end the talk with a ARKit demo, but I spent the whole weekend fighting with Auto Layout.

ARKit is legit. I tried to come up with a better term that “legit”, in the Urban Dictionary sense of “A modern synonym for words such as ‘cool,’ ‘ill,’ ‘tight,’ or ‘dope.’ Used to describe a noun that is of a particularly excellent quality” but did not come up with anything better.

It’s such an asotinishing, amazing acomplihsment by Apple. That we can use in an apps and it will run on hundreds of millions of iPhones in the fall is incredible.

As noted, developers are now freeze-framing the . And there’s no “ARKit Programming Guide.” There’s only a single sample app that scratches the surface of the possibilities. And the ARKit Framework page has an odd mix of links to classes and links to restanding pages, under the heading of “Topics.” It’s very hard to see how to reach a starting point here.

(A larger look at the “new documentation” is beyond this, except to assert it is a huge regression. Appallingly, class references and protocol references do not include return values in the list. Since a function without a return value is valid, there’s no way to know if a function has a return or not without clicking through.)

Also, there’s no sample code anywhere. In fact, trying to find any sample code throughout Apple’s developer documentation is now a scavenger hunt.

If this is the future of developer documentation then Apple hasn’t learned the past lessons of dynamic type, Swift migration failures and others, and expect WWDC 18 to feature prominent corrections of these shortcomings.

Conclusion

Would I want to live in an alternate world where this talk ended

What Apple announced at WWDC was meh, but production values were great and the sample code posted immediately!

Of course not. But the videos and documentation and sample code are spans in the bridge to bring these technologies to developers and on to users.

Moreover, at WWDC Apple Engineers talks to thousands of developers — literally, thousands. There are hundreds of thousands of developers who they didn’t talk to, who still have unanswered questions.

The lesson of past years is to not assume that Apple knows these issues exist, and like Swift 3 migration and missing Dynamic Type APIs, they problems are so obvious that of course there’s a fix the works coming soon.

And it’s not because developers are whiny and demanding — we have the same goals! If the serious issues with videos and documentation and sample code aren’t resolved — in weeks, not months or years — then our lives are going to be more difficult, less developers are going to use these new amazing technologies.

We really lucky to get to work in this field, and we owe that to Apple. We have the same goals, and let’s communicate, and all move forward to this amazing future together.