Archive for February 8, 2017

Wednesday, February 8, 2017

Ultra Accessory Connector

Jordan Kahn (MacRumors, iMore, ArsTechnica):

Apple is planning to adopt a new connector type for accessories for iPhone, iPad and other Apple devices through its official Made-for-iPhone (MFi) licensing program. Dubbed the “Ultra Accessory Connector” (UAC), Apple has recently launched a developer preview of the new connector type to prepare manufacturing partners for the component that in some cases will replace the use of Lightning and USB connectors, according to sources familiar with the program.

Measuring in at 2.05mm by 4.85mm at the tip, the 8-pin connector is slightly less thick than USB-C, and near half as wide as both USB-C and Lightning. The space-saving connector is similar in shape to ultra mini USB connectors on the market that are often bundled as proprietary cables with accessories such as Nikon cameras (like the one pictured below).

Vlad Savov (via Dan Frakes):

People familiar with Apple’s plans tell us that the company has no intention to replace Lightning or install this as a new jack on iPhones or iPads. Instead, UAC will be used as an intermediary in headphone cables.

At present, a pair of Lightning headphones can’t be made cross-compatible with USB-C devices, and equally, USB-C headphones only work with USB-C audio sources. But if you insert UAC in the middle, you’ll be able to swap between Lightning-to-UAC and USB-C-to-UAC cables with the same pair of headphones, allowing you (admittedly with the help of a couple more dongles) to switch between the various connectors on the fly. UAC will make it possible for your headphones’ firmware to adjust on the fly, recognizing whether it’s receiving audio from a Lightning or USB-C connection and playing it back appropriately.

I Wish Apple Loved Books

Daniel Steinberg:

I’ve joked that if Eddie Cue loved reading the way he clearly loves music, then iBooks, the iBookstore, and iBooks Author would be amazing. Not only aren’t they amazing, they aren’t even good.

It’s like they’ve assigned a committed carnivore to design the meals and cook for Vegans. You need someone who loves and understands vegetables and shares the commitment to not using meat or meat products.


I was an early embracer and adopter of iBooks Author. I could produce beautiful books. The software was initially frustrating but they improved it in significant ways early.

Then they stopped.


Yesterday, I uploaded my latest version of my book to Gum Road and to iBooks. Within minutes I was getting email notifications of sales of my book on Gum Road.

An hour later my book was approved for sale on iBooks. This is remarkably quick. It used to take days. I looked online and my book wasn’t on the iBookstore yet. Also, my name was still listed incorrectly.

Via Adam C. Engst:

After an initial burst of enthusiasm, both iBooks and iBooks Author have languished, iCloud Drive’s integration with iBooks is flaky, and the iBooks Store never recovered momentum after Apple was found guilty of ebook price fixing back in 2013.

Bradley Metrock:

So let’s think about that a minute. You’re using software called “iBooks Author.” What, exactly, are you authoring? Um…iBooks. Yet, for some reason no one can explain, you can’t say that.


Next, Steinberg discusses the interplay between the EPUB format, the iBooks format, and attempting to provide his readers with updates. He nails this - it’s unnecessarily clumsy.

John Gruber:

iBooks Author was announced in January 2012, when the iPad was two years old. The iPad itself, seemingly, would be a fine device for creating books with iBooks Author. But iBooks Author remains Mac-only.

Update (2017-02-09): Nick Heer:

iBooks Author was most recently updated in September; prior to that, it was updated almost exactly one year prior. That’s a glacial pace for an app, but it isn’t out of line with many of Apple’s other Mac applications.


I think there’s a tremendous opportunity that Apple is sleeping on.

Swift and React Native at Artsy

Orta Therox:

It is pretty obvious that Swift is the future of native development on Apple platforms. It was a no-brainer to then build an Apple TV app in Swift, integrated Swift-support into our key app Eigen and built non-trivial parts of that application in Swift.

We first started experimenting with React Native in February 2016, and by August 2016, we announced that Artsy moved to React Native effectively meaning new code would be in JavaScript from here onwards.


The stricter type system in Swift made it harder to work on JSON-driven apps.


Native development when put next to web development is slow. Application development requires full compilation cycles, and full state restart of the application that you’re working on.


So, you’re thinking “Yeah, but JavaScript…” - well, we use TypeScript and it fixes pretty much every issue with JavaScript. It’s also no problem for us to write native code when we need to, we are still adding to an existing native codebase.


It’s worth highlighting that all of this is done on GitHub, in the open. We can write issues, get responses, and have direct line to the people who are working on something we depend on.

Update (2017-02-12): Ash Furrow:

So when Eloy proposed writing apps in JavaScript – JavaScript! – I was unenthusiastic. However, Eloy is the most pragmatic and level-headed developer I know, and he reached the decision to move to React Native after months of careful study, so I kept an open mind. And I’m glad I did.

I decided to look into JavaScript and started contributing to JS web projects at Artsy last year. And I was surprised to see that the modern JS development workflow is slick. Like, really slick. The tooling has been built with developer experience front of mind, and it shows. Orta goes into more detail in his post, but suffice it to say that compared to Xcode and Swift development, the JS workflow is matured and polished.

Toward a Galvanizing Definition of Technical Debt

Michael Feathers:

In Ward Cunningham’s original formulation, Technical Debt was the accumulated distance between your understanding of the domain and the understanding that the system reflects. We all start out with some understanding of a problem, and we write code to solve that problem. But, we learn as we go. If the code doesn’t keep up with that learning we continually stumble over a conceptual gulf when we add new features. The cost of adding features becomes higher and higher. Eventually, we simply can’t.

If this definition sounds unfamiliar, or a bit different than what you’ve read before, it’s probably because Technical Debt has become conflated with another concept - general systems entropy. It’s easy to write code quickly and not pay attention to good factoring. Over time, all of these small omissions of care accumulate and we end up with code that ends up looking more like a jungle than a clean understandable guide to the behavior of a system.


For a while, I’ve been using a different definition of Technical Debt. It helps teams frame their work in a way that highlights their choices and it can lead to better ones.

Technical Debt is the refactoring effort needed to add a feature non-invasively

ReadKit 2.5


ReadKit 2.5 is a major update that introduces a new design and contains various improvements and fixes. Beside the new UI, this version also adds support for the Touch Bar on the new MacBook Pro.

After my post in December lamenting the lack of updates, ReadKit got several quick bug fix updates, and now this. It’s great to see it continuing to improve.

For the last few weeks, I’ve been using ReadKit with Tiny Tiny RSS (via the Fever plug-in). This seems to work really well. It’s both faster and more reliable than Fever itself was. (I initially tried Miniflux, liking the simpler design, but ran into a series of bugs/errors with both the MySQL and SQLite backends. I also tried Feedbin and liked it, but I prefer to self-host.)

Previously: Goodbye Mint, Goodbye Fever.