The Incredible Shrinking Docs

Wouldn't you know, I was wondering about documentation in Xcode 8, and indeed it has fundamentally changed. The DevPubs team has hugely reduced the size of the docs and apparently integrated them with Xcode so that there is no longer a need for a separate download step.

Running the Xcode 8 beta, I find I'm able to browse the docs with WiFi turned off. I know I'm looking at the Sierra docs, because NSGridView is there. Furthermore, docsets are no longer listed in the Downloads pane of the prefs panel. It's like magic — kudos to the DevPubs team!

I'm guessing this news about the docs was announced during the Platform State of the Union. I missed that session when it was live-streamed, so I'll have to watch it later. I'll see if it confirms my understanding, and I'll think about implications for AppKiDo.

The Developer Tools people at Apple have a lot of momentum lately. I can't remember when it felt so much like they were working hard to connect with us, to show that they hear us (the culture around Swift seems incredibly positive), to create cool tools, and to take away pain points.

I wonder if squashing the documentation size was important not only for Xcode but for the Swift Playgrounds iPad app and/or future possibilities for using iPads for development.

The New Adventures of Old AppKiDo

I have been making progress on a reboot of AppKiDo, which is a Mac app that I wrote for browsing the Cocoa documentation that comes with Xcode. AppKiDo stopped working in 2014, during the betas of Xcode 6, because of changes in the structure of Apple's docsets.

I now have it up and running again, in a preliminary but usable form. (The code is in a private repository; I will push it to the public one after ironing some things out. [UPDATE: Eh, why wait? The code is public at https://github.com/aglee/appkido. Remember, it's very much a work in progress.])

The best news, aside from having it run at all, is that it's launching much more quickly than it used to. There's still a lag, but it's much shorter now, because instead of laboriously parsing all the HTML files, I get almost everything I need from the Core Data store inside the docset.

There are serious limitations in the current version that will take time to address:

  • Still Objective-C API only. For example, if you search for "string" the search results won't include the Swift String class.
  • Xcode must be at /Applications/Xcode.app.
  • You have to pick the docset you want to browse at launch time.
  • Window states aren't saved between launches.
  • The "ALL" options are missing (as in "ALL Class Methods", "ALL Instance Methods", etc.).
  • And more.

As I write this, the keynote for WWDC 2016 is hours away. For the first time in a long while I am experiencing an old familiar feeling of suspense. Will there be some change to the docs in Xcode 8 that will upend everything I've been doing?

Quick Explanation of the Term "Application Bundle"

Follow-up to my previous post about receipt files. Again, this is Mac-centric.

WHAT IS AN APPLICATION BUNDLE?

"Application bundle" is Cocoa developer terminology for an application as it exists in the file system of your computer. The application consists of a number of files organized in a directory. The directory has special attributes and has a specific subdirectory structure.

WHERE IS THIS DIRECTORY? ALL I SEE IS THE APPLICATION FILE.

You only think you see a regular file. When you see an application icon in the Finder, such as the Safari icon, it looks like any other file icon. However, the Finder is telling at least two and possibly three lies about the application.

LIE #1: HIDING THE .app EXTENSION

On the file system, the name of the application is not actually "Safari" (for example) but "Safari.app", with a ".app" extension.

You can see all the .app extensions in Terminal:

ls /Applications

You can also see an application's filename in the Finder by selecting the application icon and doing a Get Info. You'll see the ".app" extension. Alternatively, if you go to Preferences > Advanced and turn on "Show all filename extensions", you'll see the .app extensions for all apps.

LIE #2: MAKING A DIRECTORY LOOK LIKE A FILE

An application is not a regular file, as it appears to be in the Finder, but a directory with special attributes and specific subdirectory structure. Such a directory is called a "bundle".

You can see the subdirectory structure in Terminal:

ls -l /Applications/Safari.app
ls -l /Applications/Safari.app/Contents

You can also see the directory structure in the Finder by right-clicking the application icon and selecting "Show Package Contents". You will see there is a subdirectory called "Contents", and within that there is a bunch of other stuff.

LIE #3: POSSIBLY A DIFFERENT NAME ALTOGETHER

Usually the Finder displays the name of the application as the directory name minus the ".app" extension. Thus, "Safari" instead of "Safari.app", "Contacts" instead of "Contacts.app", etc.

However, it is possible for applications to specify a different name to display in the Finder. The main reason for this is to localize the displayed application name. It is very rare to encounter this "lie" if English is your Mac's primary language.

Search for the term "CFBundleDisplayName" for the nuts and bolts of how developers get their apps to do this.

Quick Explanation of the Receipt File

I was explaining the MAS receipt file to a friend and decided to write a blog post instead of an email, on the principle Scott Hanselman has brilliantly advocated that we should conserve and amplify the limited number of keystrokes we have left in us.

I'm purely a Mac developer at the moment, but as far as I know this high-level explanation applies to iOS as well. No idea about watchOS.

WHAT IS THE RECEIPT?

The receipt is a file on your computer used for DRM of purchases from the App Store. There is a separate receipt for each app.

The receipt file contains:

  • Identifying information about the computer on which the app is installed — specifically, the MAC address of the device's primary network interface. Note that "MAC address", with the "MAC" in all caps, is a networking term. Nothing to do with "Mac" as in "Macintosh".

  • Identifying information about the app that the receipt is for — specifically, the app's bundle ID and version number.

  • Purchase history. Information about the app purchase and any subsequent in-app purchases.

WHERE DOES THE RECEIPT LIVE?

The receipt file is located inside the application bundle. On the Mac, it is at Contents/_MASReceipt/receipt. (If you don't know what the application bundle is, I've written another quickie blog post explaining it.)

WHO IS RESPONSIBLE FOR DRM?

The system is responsible for creating the receipt. By "system" I mean the OS in conjunction with the App Store. The system code-signs the receipt to prevent tampering. It's the job of Apple's developers to have gotten this right.

The application is responsible for validating the receipt. It's the job of the app developers to get this right.

WHEN DOES THE RECEIPT GET WRITTEN?

The receipt gets created on your computer when you download the app from the App Store. The receipt is then updated in the following situations:

  • If a newer version of the app becomes available on the App Store, the receipt is updated when you upgrade to the newer version.

  • If the app supports in-app purchases, the receipt is updated whenever you do an in-app purchase.

  • When you "Restore Purchases", the receipt is updated.

Here's what I mean by "Restore Purchases". Certain types of in-app purchases apply to all computers on which you have installed the app, not just the computer on which you made the purchase. A typical example would be an IAP that unlocks premium features. If you made such a purchase on a different computer, you may need to explicitly "restore" that purchase on the computer you are using. Apple's App Store rules require the app to provide a way for you to do this. Usually the app provides a button or menu item with a name like "Restore Purchases".

HOW DOES THE APPLICATION USE THE RECEIPT?

The application does two things with the receipt:

  • It validates the file contents to confirm the receipt hasn't been tampered with.

  • It checks in-app purchases to see what enhanced functionality the user has purchased. In-app purchases may include permanent "unlocking" of features, or they may be subscription-based, in which case the app should check the expiration dates of the subscriptions.

Both of these steps are performed by parsing the receipt file, which is a science in itself. There's an excellent article on objc.io that explains what is required:

You may wonder why Apple hasn’t provided a simple API to validate the receipt. For the sake of demonstration, imagine that such a method exists (for example, [[NSBundle mainBundle] validateReceipt]). An attacker would simply look for this selector inside the binary and patch the code to skip the call. Since every developer would use the same validation method, hacking would be too easy.

Instead, Apple made the choice to use standard cryptography and encoding techniques, and to provide some help — in the form of documentation and WWDC sessions — for implementing your own receipt validation code. However, this is not an easy process, and it requires a good understanding of cryptography and of a variety of secure coding techniques.

Of course, there are several off-the-shelf implementations available (for example, on GitHub), but they are often just reference implementations and suffer from the same problem outlined above if everybody uses them: it becomes very easy for attackers to crack the validation code. So it’s important to develop a solution that is unique and secure enough to resist common attacks.

MORE LINKS