Mr. Fusion

In the past, users had a couple of choices when it came to hard drive options. First: a conventional hard disk, in which a series of rotating platters spin at high speed and store data magnetically. These HDDs are known for large capacities (upwards of 3 terabytes), but lack somewhat in speed. Second: a solid-state disk, in which data is stored similarly to a USB key (only much larger). SSDs lack the high-capacities of their HDD counterparts and are more expensive per gigabyte, but make up for it with a massive speed boost. I/O operations on an SSD are considerably faster than an HDD.

Users building a custom PC or retrofitting a Mac Pro will often install both an SSD and HDD. Place the OS and your apps on the SSD, and they will benefit from the speed. Store your music, video and files on the HDD and get the storage space you need. Easy as pie. But there's a footnote: Anything on the HDD cannot take advantage of the speed boost, and moving files back and forth between the two is a bit slow and can be annoying.

Enter Fusion Drive. With the latest iMac and Mac mini refreshes, Apple introduced this feature as standard. While this concept is nothing new to most hardware-hackers, it is a surprising addition to the Mac ecosystem. The idea behind it is to take an SSD and an HDD and just… combine them. Two physical volumes exist in hardware, but the OS and applications will see only one large logical volume. Mountain Lion has now gained support for managing these drives and their combined volume automatically. What's more, the OS does the hard work of moving files back and forth between both disks to optimize read and write times for things you use most often. OS X and your apps live on the SSD, along with documents and data you access most often. Things you use less often are pushed to the HDD, and exists happily without needing the speed.

But as soon as the words Fusion Drive left Phil Schiller's mouth, we began to wonder: How easy would it be to replicate this in a Mac without official Fusion Drive hardware? Well, as it turns out, it's easy. Mountain Lion and Apple's Core Storage technology don't care if the two physical disks have a pretty Apple sticker on them. It will happily fuse two drives of any type together, assuming they are both formatted as (J)HFS+.

I decided to attempt this, and followed this guide to get started. I grabbed a Crucial M4 SSD from NewEgg (they were on sale that day, wonderfully).

The details are as follows: Core Storage has the concept of a Logical Volume and a Logical Volume Group. To build the (pseudo) Fusion Drive, you first boot into OS X's recovery tools. Note, though, that you can't boot into the recovery of a drive you want to fuse, as doing the operation will wipe out all data on disk. So I took advantage of OS X's Internet Recovery to repartition before reinstalling.

Once in the recovery partition, open Terminal and do the following:

diskutil cs create <name for group> <BSD name of SSD> <BSD name of HDD>

This will repartition both drives, and combine their physical volumes into a single logical volume group. You can then create one large logical volume as so:

diskutil cs createVolume <logical vol. group ID> jfhs+ <name of volume> 100%

Once this is done, simply close Terminal, open Disk Utility, and revel at your new Fusion volume. Reinstall OS X using the recovery tools, and you should be done.

After getting everything back from my Time Machine backup, I ran a few tests, and noticed a significant increase in speed. The OS indeed was storing data on the SSD until it ran out of space, at which point it started prioritizing. I won't go into the nitty gritty details, but I expect to see an major overall boost in system responsiveness, all while sitting on top of 624 GB of storage. Awesome.

Update: I've run into some issues with sleep and hibernation. It appears that, with my pseudo Fusion Drive enabled, attempts to save hibernation state when the system goes to sleep will cause the process to fail, rendering the system unbootable. You must boot from an external recovery device and Repair Disk to get the system to boot again. Disabling hibernation for the system seems to fix the issue. Do so as follows:

sudo pmset -a hibernatemode 0

(key)Chained Up

Password are a touchy thing. Users trust that applications will handle password in a way that is both secure and transparent to their intervention. As a user, the only time I want to think about a password is when I might worry if my data is secure (such as when I'm logging in to a service). Once that's done, I don't want to think about it anymore, save for the occasional lock icon in the window chrome. Password dialogs are annoying. Certificate verification sheets are confusing. Security alerts are scary. All of these things, however, are necessary.

On OS X and iOS, developers rely on the Keychain to handle simple security. Keychain handles the storage of sensitive user information: passwords, certificates and identities. It also transparently encrypts and decrypts this information on the fly. Most users don't even know what the Keychain is, let alone how much it does to keep their data safe.

Keychain is secure, tried and tested. It works. I'd even argue it works well as a technology. However, there is a glaring elephant in this ever-so-tightly secured room: The Keychain doesn't sync. Period.

Well, if you only have one password to enter, no big deal, right? *pop* Password dialog. Four seconds of your day. Done. Some apps, however, have an issue: They store many passwords. Possibly hundreds. Take Coda, for example. Web Designers could have dozens of sites and server configurations. Each with a password. Then the shiny new Diet Coda comes out, and suddenly they are hit with a realization: If my site settings all sync over, will my passwords? If they don't… *gulp* …will I have to reenter them? ...*all* of them? Oh, boy.

But Keychain did sync. In an era long past and forgotten, the Keychain kept in sync via MobileMe (nee .Mac). If I entered a password for an application on one machine, that application would miraculously have access on my other machine. No fuss. No password dialogs. It just worked.™ What happened, you ask? Well, Keychain sync was one of a few features that were lost in the MobileMe-to-iCloud transition. Alright, with any paradigm shift, features are bound to fall off the map. As an optimistic developer, I accept that. They usually come back in a release cycle, perhaps in a completely rethought way. Project deadlines are tight. Features get punted. Lists get shorter.

However, it's now been two major OS cycles since Apple killed Keychain sync. Bugs have been filed, of course, but Apple already knows the problem. That's not contested. Users may have forgotten that the Keychain ever sync'd at all. Passwords are just one of those things you have to enter on every computer, after all.

So let's look again at Keychain as a technology. It was first introduced in Mac OS 8. Today, it lives as part of the Security framework. It is one of the oldest APIs most developers will touch in their travels. It's crufty, as many older APIs are. It's Core Foundation-based, but it feels older. It's inconsistent in paradigm and style. It's different on iOS than it is on OS X. That point in particular is one of my sore spots. But still, most of all, it doesn't sync.

How do we, as developers, remedy this? Do we wait for a new sync solution for Keychain? How long will that take? Will it come with 10.9? 10.10? Too many questions. Too many unknowns. Passwords are the user's sensitive information, just like e-mails, reminders, and events, right? They should sync. Users should expect it. Developers should have access to it. But we don't, from a trusted, central source, anyway.

As such, we have to ask ourselves: Is Keychain still useful? Of course it is. It's the most secure place to put this data. But given the widespread availability of consistent cryptography service APIs on OS X and iOS (CommonCrypto, for example), we have to then ask: If I want to sync this data, is it easier to just reimplement it completely? …often the most existential words a developer will mutter in a day.

Do I have an answer to this problem? No. Developers will take whatever course is right for their users. But that's not the Mac way. Consistency. Uniformity. Just works. That's the Mac way. We need a central way to do this. Soon.

Is iCloud a members-only club?

One of the best technologies that Apple introduced last year is iCloud. It's designed to be useful in syncing both documents as well as library-style data (bookmarks, contacts, calendars, etc.). In this regard, many APIs were added to OS X Lion to help developers take advantage of this powerful sync ability.

Both iOS 5 and OS X Lion have it built in, and apps are slowly starting to adopt support for it. However, one thing has started to creep into my mind: iCloud doesn't work for apps sold outside of the Mac App Store. "Why?" you may ask. What's different about a Mac App Store-sold application? Well, to answer that we have to dig a little deeper.

OS X Lion introduced (or perhaps just exposed) a new mechanism for system security called Entitlements. Any application that runs on a user's system does certain things to accomplish its mission. A Mail application talks to remote servers, reads and saves messages onto disk, etc. Entitlements are a way for a developer to tell OS X what your application will be doing in terms of interacting with the user's data as well as the outside world.

Applying the iCloud entitlement tells the system that your application wants an iCloud container. This container, under the hood, is stored in the Mobile Documents subfolder of your user's Library folder. The entire contents of the container are sync'd periodically by the system with all other registered iCloud devices (iPhones, iPads, iPod touches, and Macs alike). In this way, anything your app stores in its iCloud container will get pushed to all other devices when the need arises.

Therefore, a properly-entitled application should be able to use iCloud, right? Even if it's sold outside of the App Store. Well, this doesn't appear to be the case, for un-obvious reasons.

One might say that this is because of sandboxing. Sandboxing, a hotly talked about technology, is also built on Entitlements. The gist of sandboxing this: Your application can tell the OS everything you are allowed to do, as opposed to just what you are going to do. In this way, an application that tries to access the Internet without having the proper entitlement set can be stopped from doing so.

Entitlements, though, aren't restricted to sandbox'd applications. You can happily apply entitlements to an application without the sandbox. Therefore, back to our original question: A properly-entitled application should be able to use iCloud no matter where its sold, right?

Xcode will let you apply the entitlement for iCloud to your application. It will let you build said application without pause. After building*, trying to launch the application will fail with the following error:

taskgated: killed com.mycompany.MyApp because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed

Hmm. Interesting. The application is not allowed to use the entitlement. It appears that the entitlement only works if you have a Mac App Store receipt within your application bundle (something that is only placed when the App Store installs the application).

So, coming back around, we can deduce that Apple is taking the stance that iCloud is for Mac App Store applications-only. I can somewhat see this argument. iCloud is a server-based technology. Data flows in-and-out of iCloud through applications that a user downloads. By saying that only applications from the store can interact with iCloud, Apple is adding the layer of knowing that any app using iCloud was personally approved by them.

But this begs the question: "What other technologies might become part of this members-only club?" iCloud isn't the only server-based technology Apple has or might introduce in a future version of OS X.

* As a Release build. Debug builds always work with iCloud for test purposes.

All Good Things…

Today is my last day at Apple.

After four internships and another wonderful year, I have decided to take my leave. I have had the opportunity to work with great people on great things during my time here, and am sad to leave them. Apple has been the best learning and growth experience I have ever had, and I would recommend it to anyone who values creativity, innovation and a strong work family.

From here, I will be making the move up to Portland, Oregon to join awesome Panic.

It's been an honor. Thank you.

Logan

Schoolhouse and I: Parting Ways

I am both proud and saddened to announce that I will no longer be the developer of Schoolhouse. Several months ago, I began working full-time at Apple as a Software Integration Engineer. In accordance with Apple's employment rules I cannot develop Schoolhouse any further as it presents a conflict of interest between Apple and myself.

I will therefore be handing Schoolhouse to Thomas Lister (@sayo), who I trust can take it to heights even greater that I thought possible.

In short term, the Lion compatibility update (3.2.2) has been submitted by Thomas and is now pending with Apple's review team. As soon as they approve it, you should all have happy Macs again. :)

Goodnight and good luck, my friend.

It was fun.

Schoolhouse and Lion

I am currently aware of an issue in Mac OS X Lion that prevents Schoolhouse from functioning properly. Unfortunately, I cannot do anything until Apple approves an update to come for Schoolhouse. I'm currently waiting for this, but have heard no timeline as of yet.

Sorry guys, hang in there...

Logan

Schoolhouse on the Mac App Store

Schoolhouse is now available on the Mac App Store! And even better, it's available for an introductory price of $4.99!

Download Schoolhouse on the Mac App Store

You must be running 10.6.6 to have the App Store.

If you have bough Schoolhouse already without the App Store, you will not be able to use the store for automatic updates. Updates will be delivered in-app just as they always have.

If you choose to purchase the app from the store, you must first drag Schoolhouse to the trash so the store recognizes that you don't have it installed.

Schoolhouse 3.2

Schoolhouse 3.2 is now available via auto-update and the website. This version fixes a lot of long-standing bugs and adds a few nice little details, like a score column for the list view and QuickLook for file attachments, as well as a new Class Schedule view that lets you enter your schedule and see it by week and month, as well as mark class sessions as cancelled on certain days.

Schoolhouse 3.1.5

Posted a quick update to Schoolhouse this morning that fixes a pesky bug that occurs when switching the course for a task when viewing the current course. Get it via the Check For Updates... menu item in the Schoolhouse menu.

Schoolhouse in Mac OS X Lion demo

Schoolhouse icon in the Lion demo

Engadget

Pretty cool. A few people pointed this out to me. The Schoolhouse icon is on one of the the home screens in the demo. Next to last icon in the next to last column in the next to last row.

Schoolhouse in Ars Design Awards, on MacAppStorm

Graphic property of Ars Technica

Ars Technica, the wonderful tech website, saw the sadness in many a Mac developer's eyes when Apple decided to restrict the Apple Design Awards to iPhone and iPad apps only. As such, Ars Technica decided to hold a little awarding of their own.

In the form of the Ars Design Awards for Mac OS X.

The coolest part of this, for me? Schoolhouse is nominated in the "Best Student-Created Application" category. I'm very humbled and excited. It's such a good feeling to see something you've created respected enough to attain a place in the nominations. Among the other candidates are, of course, some of the best Mac apps out today, including Transmit, Pixelmator and Dropbox.

This should be a fun and welcomed replacement for our development community's efforts.

Thanks, Ars Technica!

Update: It's also come to my attention that Schoolhouse is featured on MacAppStorm today in their 20 Time-saving Mac Apps for Teachers. More awesomeness than I expected.

Update: I WON!

New Blog Design

So I've been working this past week on a new design for my website, and this is the result. It's minimalistic, simple and clean. And yes, it's Helvetica.

I like Helvetica. In the right hands, of course. Helvetica is like a scalpel. It's a precision instrument that can carve out really cool designs. Comic Sans, however, is a chainsaw. It's only purpose is to bring annoyance and pain to as many people as possible simultaneously.

So yeah, that's my new blog in a nutshell.

Schoolhouse 3.1.2

Today I pushed Schoolhouse 3.1.2, which fixes an outstanding issue with MobileMe syncing not properly handling the Course Folders introduced in 3.1.

Schoolhouse 3.1 Released

Today I'm pushing out Schoolhouse 3.1, the first maintenance update for Schoolhouse 3. This build adds several features that were highly requested, including the aforementioned course folders and a new, more powerful calendar view that is more akin to iCal.

Schoolhouse 3.1

I've been working now and then on Schoolhouse 3.1, for those of you who keep up on these kinds of things. I'm interweaving my dev time with my school projects and my part-time job, but I do have some small amounts of time every few days to get some work done.

So what changes, you might ask, are going to be in it?

Well, first off, is an autosaving feature. I've had several people email me about situations where they leave Schoolhouse open constantly and have accidentally let their batteries die, and thus, since Schoolhouse never closed, nothing was saved. Autosave will remedy this by saving automatically every few minutes if things change.

Next is Course Folders. They will work similar to how Terms did in Schoolhouse 2, in that courses can be grouped into Folders. The folders can represent whatever you choose: semesters, quarters, majors, professors you like vs. professors you hate, whatever.

Those are just two features that are going to be in Schoolhouse 3.1. What else is in store I'm no revealing yet.