Archive for February 18, 2017

Saturday, February 18, 2017 [Tweets] [Favorites]

The State of iBooks in Early 2017

Michael E. Cohen:

iBooks is not quite as unreliable and confusing as it was when I wrote about it last year, but neither has it improved nearly as much as loyal iBooks users deserve. Moreover, what little support documentation Apple provides is sketchy and inaccurate, leaving the impression that even the support and documentation departments within Apple are ignoring iBooks.

[…]

Now and then, the Library window in iBooks on the Mac gets confused, showing books that aren’t there, or duplicating thumbnails for books that are there. A couple of days ago, I found two thumbnails for a short EPUB I had just uploaded. The second thumbnail was a phantom, and actually represented the next book in the window, which I only discovered by right-clicking the duplicate. A simple cosmetic problem you might think, but if I had attempted to delete the phantom copy, I would have trashed an entirely different book!

Previously: I Wish Apple Loved Books.

Swift Ownership Manifesto

Apple (mailing list):

The widespread use of copy-on-write value types in Swift has generally been a success. It does, however, come with some drawbacks:

  • Reference counting and uniqueness testing do impose some overhead.

  • Reference counting provides deterministic performance in most cases, but that performance can still be complex to analyze and predict.

  • The ability to copy a value at any time and thus “escape” it forces the underlying buffers to generally be heap-allocated. Stack allocation is far more efficient but does require some ability to prevent, or at least recognize, attempts to escape the value.

Certain kinds of low-level programming require stricter performance guarantees. Often these guarantees are less about absolute performance than predictable performance. For example, keeping up with an audio stream is not a taxing job for a modern processor, even with significant per-sample overheads, but any sort of unexpected hiccup is immediately noticeable by users.

Another common programming task is to optimize existing code when something about it falls short of a performance target. Often this means finding ”hot spots” in execution time or memory use and trying to fix them in some way. When those hot spots are due to implicit copies, Swift’s current tools for fixing the problem are relatively poor; for example, a programmer can fall back on using unsafe pointers, but this loses a lot of the safety benefits and expressivity advantages of the library collection types.

We believe that these problems can be addressed with an opt-in set of features that we collectively call ownership.

Previously: Chris Lattner ATP Interview, Swift Plans.

Dart-C USB-C Laptop Charger

David Pogue:

The Dart-C, billed as the world’s smallest laptop charger. And it really is tiny.

Yet somehow, it provides 65 watts—plenty for laptops like the 12- and 13-inch MacBooks, the Lenovo ThinkPad 13, ASUS ZenBook 3, Dell XPS 13, and so on. Really honking laptops, like the 15-inch MacBook Pro, expect more wattage (85). This charger will work on those machines—just not as fast.

How do I love this thing? Let us count the ways.

  • It has a standard USB jack embedded in the cable. That means that you can simultaneously charge your phone, tablet, camera, or whatever—with no slowdown in charging your primary gadget.
  • It has an indicator light that lets you know if you’re plugged into a working outlet. (Apple’s chargers no longer have a status light.)

It’s even more expensive than Apple’s charger, though.

Fixing (and Explaining) PDFpen 8.3.1’s Crash on Launch

Adam C. Engst:

Greg said that the reason PDFpen crashed — even before it actually launched — was because Smile’s developer signing certificate from Apple had expired.

[…]

In the past, the expiration of a code signing certificate had no effect on already shipped software. PDFpen 6.3.2, which Smile still makes available for customers using OS X 10.7 Lion, 10.8 Mountain Lion, and 10.9 Mavericks, is signed with a certificate that expired long ago, and it has no trouble launching.

What’s new with PDFpen 8 is that, in addition to being code signed, it has a provisioning profile, which is essentially a permission slip from Apple that’s checked against an online database in order to allow the app to perform certain actions, called entitlements. For PDFpen, the entitlement that’s being granted is the capability to access iCloud despite being sold directly, rather than through the Mac App Store, a feature that wasn’t possible until about a year ago.

It sounds like every Developer ID app that uses iCloud has a built-in time bomb. Something is not designed properly here. First, why does Apple issue certificates with relatively short expiration dates? They already have a means of revoking certificates in the event of a problem. Second, why does the OS check whether the code signing certificate is valid now, as opposed to when the provisioning profile was signed?

Previously: CloudKit and Map Kit for Gatekeeper Apps, More Mac App Store Certificate Problems, WWDR Intermediate Certificate Expiration.

Update (2017-02-20): See also: MacRumors, Acqualia.

Update (2017-02-22): Rick Fillion:

Due to the expired Provisioning Profile, 1Password mini wouldn’t launch. And without mini running, 1Password itself was unable to startup successfully. Both mini and 1Password itself were signed with the same Developer ID certificate. Gatekeeper allowed 1Password to run, but due to the different rules for apps with provisioning profiles, it would not allow mini to run.

As far as we can tell, the only way to correct this problem is to provide a new build of the app with an updated provisioning profile with a new expiration date.

[…]

When we generated our updated provisioning profile we also needed to generate a new Developer ID certificate. We didn’t realize it at the time, but the common name of newly created certificates now include the team identifier in addition to the company name; “Developer ID Application: AgileBits Inc. (2BUA8C4S2C)” vs. “Developer ID Application: AgileBits Inc.”. Close. Super close. But we weren’t looking for a “close” match.

Rick Fillion:

In case you’re wondering how to tell when a provisioning profile will expire you can run security cms -D -i on the Terminal to have it output information about a profile.

Update (2017-02-24): Rob Griffiths:

Follow me now, if you wish, for a somewhat deep dive into the world of code signing, as I attempt to explain—from a consumer’s perspective yet with a developer’s hat on—what is code signing, why these apps broke, why the breakage wasn’t expected, and other related questions and answers.

[…]

Follow me now, if you wish, for a somewhat deep dive into the world of code signing, as I attempt to explain—from a consumer’s perspective yet with a developer’s hat on—what is code signing, why these apps broke, why the breakage wasn’t expected, and other related questions and answers. Apple explicitly tells developers—in at least two places—that they only need these certificates to build new apps or update existing apps. So if you have a certificate that’s set to expire, but you don’t have an urgent need to update an app or create a new app, it’s supposed to be a non-event.

[…]

So the app can’t tell the user what’s going on, and even worse, the OS doesn’t tell the user what’s going on: The app just seemingly dies in an instant. That’s bad for the user, and bad for the developer, because they’re blamed for something they didn’t even know was occurring (because their app never loads, and no crash reports are generated). If the OS is going to kill the app, the OS should tell the user why it did so, so the user has some understanding about the problem.

Update (2017-03-09): Greg Scown:

Looks like Apple has addressed the Provisioning Profile issue.