The “Twist”

As long as I can remember, people have complained to me about the frailty of Apple’s various cables. Lightning cables, the cables on the power bricks. The old 30-pin cables. You name it, people say they are always having to replace them because they fray, short out, etc.

No doubt, the cables Apple makes are far from perfect in this regard. They’ve gotten thicker in recent months, probably as a long-overdue response to this complaint, but time will tell if the new thickness is any help to these unfortunate people who have had to pay to replace fraying cables.

I have to confess, though, I always have to struggle to empathize with people over their cord issues, because in the many years I’ve been using Apple products, I’ve never had a single cord fail on me. Is this extreme luck? I doubt it.

Having borrowed cords from friends over the years for a quick charge, or to plug my phone into my laptop, I’ve noticed a pattern. Many of my friend’s cords look as though they’ve been through a war, whereas just about any of mine look like they were unpacked out of their original boxes yesterday.

cables

Guess which cable is mine?

I won’t speculate why my friends’ cables are so often yellowed, sticky, etc. But I can say with certainty that the way most developers wrap their cables has a great deal to do with the condition they end up in after a few months. I’ve seen all sorts of variations of wrapping the cord around itself, around devices, twisting them into knots, etc. Usually, the ends are completely stressed when they are done wrapping. And then they throw them into a bag that way for several days at a time.

I’m not saying that Apple’s cables shouldn’t be able to withstand a bit more torture than they get from most people, but there is something to be said for being a bit more careful.

And that’s where the “twist” comes in.

I first encountered the twist when I was a young musician. The one aspect of playing an electric instrument that I’ve always hated is dealing with the instrument cable. After a live performance, especially, the cable would be so twisted up in knots, and I’d have only a few minutes to pack up all my equipment and get off the stage for the next act. So I’d wrap the long cable into a circle using my arm, or just shove the cable into a bag any which way, which led to me needing to replace my cord about every six months or so.

Then one day, a sound engineer I was working with taught me the trick. Make sure both ends of the cable are free to move. Then, hold the end of the cable in one hand, and use your second hand to bring a loop of the cable over to the first hand, making a twisting motion as you do so. Allow the free end of the cable to spin freely. Repeat until the entire cable is in nice, even, flat loops.

This literally changed my life. I use this technique with every cord I own, and it works flawlessly. I almost never need to replace instrument cables anymore. I can pack several cables in seconds, and everything stays neat and orderly for the next show.

It works particularly well with Lightning cables and other Apple cables, too, as demonstrated in the following video.

For longer cables, such as the ones I use for playing music, I use a velcro tie to keep the loops together. On shorter cables, I just gently wrap the ends around the loop, creating a simple hook.

The best part is not only does this prolong the life of your cables, it makes stowing away the cables into bags and pouches much easier. And it makes keeping the cables separated from each other much easier, too. No more knots.

Learn this trick, and I swear, unless you are pulling the plug out by the cable (which I really hope you aren’t) or you are stressing the cable in some other way during actual use, you should never have another problem with any of Apple’s white cables again.

Unless your cats get to them. I can’t do anything about your cats.

x2y for Mac 1.1

The Common Aspects list was always slated to be the key feature of version 1.1 of x2y for Mac. I decided to ship 1.0 with two major features of the iOS version not yet included, in the interest of getting the product shipped within a reasonable time frame. (The other feature is iCloud sync, coming in version 1.2.) I figured I would need at least a week or two to tackle adding a sidebar and all the new learning that would involve, given this was the first Mac app I was coding myself.

Above all, I wanted to use standard controls as much as possible, as I wanted x2y to look like a native Mac app. That meant using a Source List, with the blurred translucent background, standard controls for showing and hiding, and a look that was similar to the built-in Sierra apps. If you compare x2y to the Notes app, you'll see where I drew my inspiration (minus the paper texture, of course).

One little detail I wanted to add that I'm particularly happy about: if you have typed in custom values for your x1 and y1 fields, the app automatically fills them in for you when you click the add ratio button. Just give the new ratio a name, and save. Or replace those values if you want to save a different ratio.

Having access to the ratios you use most often with one click has always been a feature that sets x2y apart from most other aspect ratio calculators. I'm glad I took a little extra time to make sure I got it right. There were some gotchas along the way that I hadn't anticipated. (nextKeyView was interesting, for instance. And drag and drop reordering of an outline view was an eye opener.) But it was a great learning experience.

Add NSSplitViewController and NSOutlineView to the growing list of classes with which I am now familiar.

I also added the option to customize the main toolbar of the app, including using large icons, if desired. That one was easier than I thought it would be.

I continue to be surprised at the ease with which I have translated my familiarity with iOS APIs to those in macOS. Apple has really made a good effort to make macOS development easier over the years.

x2y for Mac 1.1 is available now on the Mac App Store.

The Premise

Here’s an exercise for you.

Start with a basic premise: Apple has lost its way/ can’t focus/ has too many things on its plate/ doesn’t have a sense of the future like they used to/ hates pros/ etc.

Next, take everything Apple does for the next year and filter it through that premise, emphasizing anything that remotely supports it and ignoring anything that doesn’t.

There. I just saved you from reading Apple commentary for all of 2017. You can easily predict the blogosphere's reaction to anything Apple does.

I’m being facetious, of course, but it does seem that much of what passes for big thinking around Apple circles these days is basically confirmation bias.

We’ve been here before. Welcome to the late 90s.

Hey, I get it. I don’t like to admit I got it wrong. Or that I’ve been unfairly harsh about things that I later understood were actually reasonable compromises. Or that facts later came to light that made previous comments I’ve made seem silly.

It’s hard to face that we sometimes get emotionally charged when we first encounter news. But rather than changing our minds in light of new evidence, too many of us are doubling down on the emotion.

We seek out more support of our original premise, rather than reading the facts and then drawing independent conclusions.

If you let yourself fall into a confirmation bias loop in order to protect your ego, pretty soon everything you say or read has to fit into the premise, no matter the facts. That’s why dropping Airport devices is not an example of Apple tightening focus. It’s a sign that the car project has taken so much of Apple’s focus away that they no longer know what’s truly important anymore, so they are dropping products they shouldn’t. And so on.

Pretzel logic.

Never mind that even if the car had once been a big project, it doesn’t appear to be anymore. Apple actually seems to be re-evaluating what is critical to the future of the company and taking steps accordingly. Isn’t that what everyone says Apple should do?

But Apple doesn’t have focus is the premise. It has to be true. It has to remain true.

Apple can’t actually fix what you think is wrong with Apple. What would you have to write and podcast about then?

It doesn’t help, of course, that the people who read your work cheer you on every day. Of course they do. You’re telling them what they want to hear. You are confirming their bias. They naturally love you for it.

So now you feel an obligation to the greater community to find evidence of the premise every day. You are doing community service. Aren’t they lucky to have you, finding more proof of the premise? Isn’t Apple lucky that you are here to point out everything they are doing wrong, which is everything?

Here’s another recent example of the crazily overblown criticism Apple is getting lately. Power bricks for the new MacBook Pros.

OH MY GOD, THEY DROPPED MAGSAFE! THOSE BASTARDS!

That about sums up the average reaction, right?

Let’s try that again, only we’ll start not with our premise, but with the pros and cons of the changes to the new power bricks. We’ll then draw a conclusion based on what we find. We’ll keep in mind what people have previously found lacking in Apple power adapters, and rate the new ones based on how well Apple addressed those concerns.

Pros:

  • If the cable frays, you can replace just the cable, not the whole brick
  • Cables are available from anywhere, since they are standard, which means cheaper replacement options
  • The Apple-supplied cable is thicker than the old cable, and thus less likely to fray in the first place
  • The separated cable can be plugged into an external battery, rather than the wall, at least in theory. No need for an extra cable for the battery.1
  • The brick can be stowed separately from the cable, making it easier to put into slimmer bags
  • The power cord can be plugged into either side of the MacBook Pro, since it has multiple ports that can accept power
  • The USB-C connector on the brick can be used to charge other devices, such as phones, iPads, etc. You can travel with less stuff.
  • USB-C is a great, solid, reversible, standard connector that makes firm contact and doesn’t get accidentally unplugged. It will soon be on just about every electronic device you buy, making the brick potentially even more useful for charging things in the years to come2
  • You don’t have to go to an Apple Store to buy an expensive replacement or spare, because anyone can make a compatible brick. Cheaper alternatives again, just as with the cable.
  • The brick is smaller and lighter than previous bricks

Cons:

  • No cute little fold-out feet to wrap the cable, though the detachability makes that less necessary
  • No MagSafe, which was a very cool innovation
  • No light indicating when the device is actually charging
  • Apple no longer includes an extension cable, though the duckhead is the same as older models and will accept your old extension cable(s), as well as international connectors.3

Honestly, of all the cons, not having the charging light bothers me way more than the others. But no MagSafe and no included extension cord (which some people use) are reasonable gripes, to be sure.

I think there’s a legitimate argument to be made that the cons outweigh the pros on this, though I would strongly disagree, having owned my MacBook with a similar charger for over a year-and-a-half now, as well as just about every other form of laptop power brick Apple has made since the Wall Street PowerBook. But I can count on one hand the number of articles I’ve read that cite any of the pros, while you can’t swing a dead cat without hitting plenty of articles slamming Apple for all of the cons over the past few weeks.

Why? Because they started with “the premise,” and ignored anything that doesn’t support it.

Apple hates Pros. MagSafe was something Pros liked. So they killed it. There can’t be a legitimate reason for it.

In fact, there’s plenty of evidence that the designers of the new power bricks gave earlier criticisms of Apple power bricks serious thought, and effectively addressed the bulk of those concerns. In the process, they had to compromise on MagSafe, which is unfortunate. But ultimately I think it’s a good tradeoff. Standard is better than proprietary. Having multiple ports that can accept power and do other things as well is better than one unique port that can only do power. You can disagree, but you can’t say it’s not a reasonable stance, based on the facts.4

Take a similar level-headed approach to most recent Apple announcements, and you’ll quickly get to a similar place on just about everything Apple is doing. There are legitimate gripes, but most of the things for which people lambast Apple are actually just the natural consequence of tough design decisions. They compromise where they have to, just like they always have. Some of the tradeoffs are worse than others. But they are tradeoffs, not vendettas against pros, or signals that Tim Cook doesn’t know what he’s doing.

Writing that story will do nothing for your retweet count, though.

Confirmation bias is a powerful thing. And it’s tough to overcome. But once you are aware of it, it’s easy to spot in the things you read and write. Be on the lookout for it. It won’t take long to find plenty of examples.

I’m not saying Apple doesn’t do plenty of things that are worthy of criticism. I’ve done my fair share of pointing out those issues here and elsewhere. And I do think there are good writers out there that are providing useful, reasonable, logical commentary on Apple these days.5 But I get the sense that the tail has been wagging the dog an awful lot lately, and that isn’t a good thing. Some of us have lost the ability to be objective. And with it, I think, a good deal of credibility.

  1. External batteries exist that charge a MacBook just fine. I’m not sure if any of the current ones provide enough juice to charge the more power-hungry MacBook Pros, though. I assume such batteries will end up on the market soon, if they don’t exist already. ↩︎
  2. If you just made a snarky comment about lightning ports in your head, congratulations. You are part of the problem. ↩︎
  3. I currently have about five of the old extension cables in a drawer somewhere, if someone needs one. ↩︎
  4. The lack of an extension cord is the one con for which I can’t find a good justification. Shipping weight and size, leading to a bigger impact on the environment, perhaps? Maybe they surveyed their customers and determined that only a small percentage actually use the extension? I’d love to know the actual reasoning behind that decision. ↩︎
  5. See anything by Rene Ritchie or Riccardo Mori, as two good examples. ↩︎

Touch Bar Support and Interface Builder

One of the many challenges I faced while building x2y for Mac was getting touch bar support working. This is a very new feature, available only on the latest MacBook Pro machines, which are barely now just starting to ship. Nevertheless, I wanted my new app to support this new hardware right out of the gate.

As is the case with most new APIs, finding documentation and examples for NSTouchBar wasn’t as easy as it would have been for something that has been around much longer. There is a nice write up on Ray Wenderlich, of course, but it involved doing all the touch bar creation in code. I greatly prefer using Interface Builder whenever possible.

I could see clearly that Interface Builder objects existed for touch bar items. Xcode 8.1 has touch bars, spacers, buttons, popovers, color pickers, etc., ready to be dragged and dropped right into your storyboards. They wouldn’t exist if you couldn’t use them. But how? I couldn’t find any good write-ups on what to do once you’ve dragged them into the storyboard. Unlike view controllers, touch bars don’t get storyboard IDs, so there doesn’t seem to be any way to refer to an IB touch bar in code. How was I going to get a touch bar to show up, without ignoring these Interface Builder built-in tools and rolling the entire thing in code?

Determined to not do it the long way, I kept poking around until I finally stumbled across this video from Nick Walter on YouTube. In it, he shows that all you need to do is drag a touch bar item to your window controller, throw on the items you want, and it should automatically show up for that window. Wire the buttons to your first responder actions, and you’re good to go. Super easy.

But I had done that, to no avail. When I tried this in x2y, it wasn’t working. What was I missing? All I could see whenever I launched the app was the standard blank touch bar, with the lone keyboard popover button to show typing suggestions.

Typing suggestions. Wait a minute. My app basically always has an active NSTextField in focus. And NSTextField is one of those classes that gets “Automatic” support for standard touch bar typing suggestions. In other words, any NSTextField you put in your app will replace your custom touch bar with the standard typing suggestions bar. So my app was always overriding my custom touch bar from Interface Builder.

I needed a way to get my NSTextFields not to do that. Auto-correct and text suggestions make no sense in x2y, anyway, since you can only type numbers into the fields. So I didn’t mind losing the typing suggestions functionality.

A little more research, and I found the way to override the standard touch bar behavior for NSTextField: add an extension to NSTextView.

Why NSTextView? If you’re unfamiliar with macOS development, it’s important to know that NSTextFields themselves never become the First Responder in AppKit. Instead, when you click on a text field anywhere on the Mac, a hidden NSTextView called the field editor is what actually gets first responder status. So I needed to override NSTextView, not NSTextField, to get the standard touch bar to stop showing up.

Here’s the code I placed into my NSTextView extension file.

extension NSTextView {

     @available(OSX 10.12.1, *)
     override open func makeTouchBar() -> NSTouchBar? {

          let touchBar = super.makeTouchBar()
          touchBar?.delegate = self

          return touchBar
     }
}

Notice the @available ensures that this only runs on a Mac running 10.12.1, thus not crashing earlier versions of the OS that know nothing of touch bars.

I call super.makeTouchBar() to get the touch bar from my main window, as opposed to the standard text view bar. Simple enough.

Once I placed this into my app, my custom touch bar from Interface Builder stopped being overridden.

I know there are always times and situations where doing things directly in code makes more sense than Interface Builder. But for something as simple as adding a few buttons to a touch bar, it seems like a lot of extra steps to write it all out by hand, rather than dropping the objects into Interface Builder. Take a look at the tutorial from Ray Wenderlich, and see for yourself how much more work it is to accomplish a simple bar with a few buttons on it in code.

Luckily, Apple gives us the option to do things either way, even in the early days of a new class like NSTouchBar. The more I investigate this API, the more I’m convinced that touch bars were no afterthought on Apple’s part, but rather something that Apple carefully considered, not just from a hardware standpoint, but in software as well. I’m excited to see what new capabilities the touch bar gets over time.

x2y for Mac

x2y for iOS was my first app, and I’ve always been particularly proud of it. It’s come a long way in its four major iOS versions, but I hadn’t added very much to it this year. I had one small customer request (the stepper tool), but that was about all I could think to add at this point. It’s a simple tool that does its job very well. I didn’t want to tack on a bunch of extra features that no one wanted.

So I thought, rather than trying to justify some major new iOS version, the next logical move for this app would be to finally make the macOS version.

Perhaps some other iOS developers can relate to this, but simply adding a line item “Mac Version” in your task manager is not the best way to get a Mac app made. That item has been sitting in my OmniFocus for more than two years, intimidating me with the sheer scope of what it appeared to involve. It was far too easy to brush it off as something I’d have to do later, when I had more time to tackle some serious new learning.

I had done some Mac design in the past, and I’ve been using a Mac as long as I’ve been using computers, but I had never actually coded a Mac app before. I knew AppKit was going to be a challenge compared to UIKit.

But here’s the thing; the transition over to AppKit was not that bad. Consider this: I’m primarily a designer and only a part-time self-taught coder. I had very limited knowledge of Swift going into this project, having only worked with it in my two sticker pack apps. Yet I managed to build x2y for Mac, in Swift, in ten days. If I can do that, any experienced iOS developer can certainly become competent on the Mac pretty quickly.

x2y now has a spot in my Dock, and it has already proven very useful for me to be able to do aspect calculations while coding web sites, never having to change to another device or even move my hands from the keyboard of my laptop.

If you want to check out x2y for Mac, it’s available now on the Mac App Store.

If you’ve been afraid of the Mac in the past; if you’ve had a “Mac version” line item or two sitting in your task manager for a few years now, like I did; if you have this great app idea that just doesn’t make sense for iOS but would be perfect for the Mac, you should consider going for it. It’s not going to be as hard as you think. And there can never be enough great software for macOS.