OS X El Capitan

Thanks to a tweet from Michael Steeber, I learned that I have the dubious honor of having been the first person to tweet the literal phrase “OS X El Capitan”, which happens to be the name of of Apple’s forthcoming OS X 10.11 operating system.

I did some research of my own and believe this claim is true. I don’t think this is some great victory or proof of my insightfulness, but I do admit to thinking it’s at least moderately cool.

Out of curiosity, I used Twitter’s now-awesome advanced search to zero in on the day when I first tweeted the phrase, June 19, 2013. This must have been in the aftermath of WWDC 2013, shortly after Apple had debuted its new OS naming strategy, after places that are distinctly Californian. People were joking about future code names like OS X Sacramento, OS X Carmel, or gasp!, OS X San Jose. I thought these were all poor choices because they would not be evocative of the spirit of California in the same visceral way that Mavericks was:

I quickly followed with a quip about using OS X El Capitan:

Though to be honest I don’t remember exactly what grammatical pedantry I was alluding to. What’s (not really) important is that I was the first to use the phrase, two years before Apple announced the name of the OS.

And while I’m patting myself on the back, let me give a shout out to Mark Hachman, who while similarly throwing out possible names for future OS releases, managed to make the first ever reference to “OS X Yosemite”:

Those who can, do. Those who can’t, teach. Those who can’t teach, tweet early and often.

WWDC Video Downloader

It’s great that Apple has, for years now, made videos of most WWDC content available free of charge on the web. A problem arises though, when you realize that you want to quickly check the content of some specific session, only to realize you are either offline, on a slow internet connection, or just don’t have the time or patience to connect to Apple and download the video.

I’ve found it useful to use Olivier HO-A-CHUCK’s wwdc-downloader script, which he has recently updated for the 2015 URL conventions.

Essentially you just download the script to a disk with a ton of free space, run it, and you’re left with a permanent archive of all the videos and PDFs from a given year’s WWDC.

I’ll be waiting until I get home to run this script, since by then all of the videos should be available, and I’ll have easy access to that aforementioned big hard drive. It’s great though that he has updated it so promptly this year.

Keeping Up With WWDC

Each year, WWDC kicks off with a keynote address chock full of the company’s tentpole announcements for the coming year. I always find it difficult to keep in mind even these, ahem, key points. But it gets “worse” as the day goes on, and then as the week goes on, as nuanced announcements are indicated by revelations in the Platforms State of the Union, and the extensive, in-depth sessions that fill out the remaining days of the week.

It’s all too much. Exciting, but still, too much.

Fortunately, master information compilers like Michael Tsai swoop in to help organize links to the most significant download points and technical summaries, as well as pertinent pages from non-Apple sources such as one explaining the process for using VMware to create a standalone test version of OS X El Capitan.

Michael Tsai: WWDC 2015 Links.

Michael’s blog continues to serve as a great argument for the value of RSS and blogging. Subscribing to it is a great way to keep your finger on the pulse of a great number of pertinent issues to Mac and iOS developers, both during WWDC week and a throughout the year.

Whose Phone Is This?

On the latest episode of Core Intuition, my co-host Manton Reece described the experience his wife had of leaving her iPhone behind on an airplane, only to have the airline thankfully announce over the airport loudspeakers that the phone had been found.

When they returned to claim it, they asked how they had been able to determine the name of the owner from the locked phone? The answer? They “just asked Siri whose phone it was.”

Apparently this is common knowledge to the airline employees, and to no doubt countless iPhone users, but it was news to Manton and me. You can try it yourself: if you have an iPhone, and have set a contact card as “My Info” in Siri’s preferences, lock your phone and then ask Siri: “Whose phone is this?”

On the face of it, it seems like a great feature. Who wouldn’t want to empower the well-intentioned finder of one’s lost phone to make an effort of returning it?

The problem to my mind is not that Siri shares my name and contact information, but that it goes a step further, showing not only my main telephone number, but my physical address, all my telephone numbers, email addresses, as well as my AIM, Twitter, and Facebook accounts. It also happily provides my birthdate, the names of my wife, mom, dad, brother, heck, the names of any person I have assigned a relationship to.

When my friend Dan Moren gave me a ride to Çingleton last year, we killed time in the car playing with Siri’s abundant personalization features. Anybody with access to my locked phone will soon learn that Dan is in fact more than just a friend to me:

Screen capture showing personal details revealed via Siri

Of course, you don’t have to share all this information with whatever stranger manages to pick up your phone. Simply disable Siri access from the lock screen, and nobody will be able to access your private information using it. Of course, this means no airline employee who finds your phone tucked between the seats will be able to easily return your phone to you, either.

Alternatively, you could change the information on your “My Info” contact card. For example I could add an entry “Daniel Minimal” to my Contacts list, and only include a telephone number or email address. The problem here is much of Siri’s usefulness (as we discussed on the podcast) is rooted in it knowing specific details about you. Requests such as “give me directions home,” “call my mom,” or heck, “text my sweet, sweet ride to Montréal,” will fall upon deaf ears if you don’t include this information in the card that you associate with Siri’s “My Info.”

Depending on how paranoid you are about what happens when a stranger gets ahold of your phone, you might read this and decide to do nothing, to delete all the personal information from your “Me” contact card, or to forbid Siri from being accessed when the phone is locked. Personally, I don’t think any of these solutions is ideal. I’d like to be able to ask Siri to share some of my personal information from the lock screen, to increase the odds of my lost phone being returned. But I’d like to draw the line somewhere reasonable, without having to share every last detail about myself with the stranger who is holding the device.

Off By One Half

A friend was complaining that his wrist size falls more naturally between two size holes on his Apple Watch sport band. The holes are spaced so closely together that they don’t really give you an option of improvising an extra hole.

To increase the odds of a good fit, Apple includes two “holey” band segments with the Sport product: one for “Small/Medium” and one for “Medium/Large”. The natural result of this for many of us is that we get to choose which of the band segments to use. If you’re a “medium” then you’re likely using one of the last four holes on the smaller band, or the first four holes on the larger one:

Small, medium and large watchband holes on Apple Sport band.

I thought it would have been a supremely “Apple thing” to do if the holes that overlap, at the medium-sized positions, were carefully offset such that they were in fact half-sizes on one band in relation to the other. So, I drew lines through each of the holes’ (rough) centers, to see where the lines correlate on the opposing band segment:

Apple Watch Sport band hole alignment

Putting aside my imperfect placement of the watch bands on the floor, this is pretty interesting! Maybe not precise enough to indicate Apple intentionally designed it this way, but it’s convenient that the holes line up offset from one another. If your wrist size lands in the “medium” zone on the Sport band, switching from the “Medium/Large” to the “Small/Medium,” or vice-versa, could be just the adjustment to help fine-tune the grip of the watch to your wrist.

Update May 20, 2015: Jörg Schwieder on Twitter offered an insight that I hadn’t considered: the way the holes line up linearly on the floor is not a sufficient comparison because, in the case of the longer strap, the excess overlap that then slides under the counterstrap narrows the overall diameter of the band, such that it squeezes slightly tighter on your wrist.

I’m not sure if this exactly counteracts the size discrepancy of the hole placement. It’s possible the discrepancy was itself an intentional design to counteract this phenomenon. In any case, if you try to switch up from a small band to a larger band, and it feels a little snug yet, you might try trimming (egad!) the long end of the strap so that it creates less volume under the band when you tuck it away.

Another sizing hack this brings to mind is that, if you find something comfortable to glue to the underside of the non-hole half of the band, you would effectively increase the volume and tighten up an otherwise loose fit.

Nineteen Years

Nineteen years ago today, I joined Apple as a full-time employee.

I was 20 years old, on the verge of 21. I dropped into a workplace filled with the most ambitious, most laid-back, most serious, most bizarre, most intelligent, least obsessed-with-intelligence people I have ever met. They made up, and were made from the culture that is Apple.

If you had told me 19 years ago that Apple would become the most successful company in the world, I would have believed you. Even at its lowest points, the place seemed to be teeming with latent success. It’s why I wanted to work there so badly, and why I’m so glad that I did.

The Risks And Rewards Of Criticism

Marco Arment responded to speculation by Eli Schiff that he and other Apple developers hesitate to criticize Apple for fear of retribution.

I was particularly surprised by the section of Schiff’s post that described Shifty Jelly developer Russell Ivanovic’s experience of being cut off by Apple from what had previously been a well-supported position. The way it’s described in the post, Ivanovic’s close marketing ties to Apple were severed when he decided to launch a version of his app on the Android Play store before Apple’s App Store. I haven’t listened to the podcast yet, but it sounds great, and may provide slightly more details about the situation.

Ivanovic’s experience sounds devastating, but it doesn’t strike me as treatment that many developers should live in fear of also suffering.

As a company, Apple doesn’t care about individual developers. This works both ways of course: they don’t go out of their way to help, but also don’t go out of their way to harm. When a developer benefits or suffers at the hands of Apple, I believe it’s always thanks to either a wide-sweeping corporate policy that affects all developers, or to an individual at the company whose everyday choices on the job can have a profound impact. An editor who chooses to feature an app on the store, for example, or a reviewer who chooses to notice and raise a fuss about a slightly non-compliant behavior in an app.

I’m confident that at the level of individuals within Apple, efforts are almost always in the spirit of helping developers. You don’t have to meet many Apple employees to form an opinion that, on the whole, the company is made up of good people. So, naturally, the majority of folks there are working to cause good outcomes for people both inside and outside of Apple. The culture at Apple leans towards building people up rather than tearing people down. This is, incidentally, why their products tend to be so great. And why in spite of some truly confounding decisions, the company tends to promote stellar third party products through its App Stores.

On the other hand, the company is huge, and you simply can’t have that many thousands of people in varying positions of power without having at least tens or hundreds of spiteful, angry, petty people in positions of power. Oops, that sucks. While I was trying to make sense on Twitter of Ivanovic’s unfathomably petty experience, another slighted developer chimed in. Matthew Drayton, who like Ivanovic lives and works in Australia, pins his own similar experience on an individual:

I can’t quite tell if the implication is that the same individual is likely to be responsible for the “blackballing” that both Drayton and Ivanovic say they’ve felt. But for the sake of Apple, I hope it is indeed down to one person. One person can often be fired, reprimanded, or simply decide to move on. It would obviously be much worse if there were a systematic policy of suppressing developers who fail to “walk the line,” to to speak.

The risks of being critical are usually not on the scale of upsetting an entire company and suffering its wrath. Instead they are on the scale of possibly upsetting, or merely frustrating, or even just vaguely losing attractiveness to an individual whose help you would otherwise have enjoyed. This is true both in the context of Apple and outside of it. For example, an off-hand remark about the bitterness of the coffee at your local shop might earn you a less professional effort on your next visit.

On the other hand, an astute barista may take the criticism to heart and become hell-bent on ensuring your next cup exceeds expectations. This is what happens when well-formed criticism meets the ears of a confident, competent individual: the facts are taken to heart and studied, perhaps grudgingly. But upon reflection and determination that there was merit in the complaint, respect for the source of provocation goes through the roof.

These are the risks and rewards of criticism: depending upon how far your opinions reach, you may garner either immense respect or massive disdain from the individuals who consider it. In that light, is it risky to be publicly critical of a company upon which you base your entire livelihood? Possibly. But it could be just as risky to remain meekly under the radar while the thoughtful professionals at that company go out of their way to reward the people whose meaningful criticism they value.

Crazy Apple Car Rumors

When I first heard rumors about Apple’s alleged development of a car, I disregarded them without thinking. The idea that the company would stretch its focus so far away from its current line of computer software and hardware products seemed ridiculous, and happened to overlap with countless jokes over the years about the hilariousness that would ensue if Apple entered this, that, or another market.

My head jerked to attention however when the Wall Street Journal recently added its weight to the rumors, giving a code name “Titan” for the project, and asserting that there are hundreds of employees already working on the team.

Even in the wake of this revelation I clung to my skepticism, sensing that it would simply be too “out there” for Apple to tackle the automotive market. I agreed with reasons cited by folks such as Jean-Louis Gassée, who dismisses the idea as fantastical based on comparatively low profits, challenging customer-service obligations, and the absence of Moore’s Law-style advances over time in automotive technologies.

But today’s report from Jordan Kahn of 9to5Mac, listing a variety of automotive-industry experts who are now working for Apple, has really got me doubting my earlier dismissiveness.

What does it mean that Apple has hired a significant number of people with expertise in the auto industry? To me it means that they are either making a car, or that they are making a product that they know will uniquely leverage the abilities of people familiar with cars.

Personally, I’ve flipped over to being cautiously optimistic that the Apple car will become a reality. My first inclination was to worry that it represented a deparature of focus for Apple, and that it would mean stretching their limited resources even thinner. But the 9to5Mac story drives home that a lot of the expertise required to pursue this dream, if that’s what they do, can be hired from outside the pool of software and hardware engineers that Apple has typically employed. I think it’s reasonable, for example, to be optimistic that a drive-train engineer’s efforts are not being wasted by working on a car instead of a MacBook Pro’s cooling fans.

Putting aside the significant effort of designing, manufacturing, marketing, distributing, and servicing a line of Apple-branded vehicles, having these products exist and in use by even a modestly large number of customers would offer some interesting benefits to Apple. Particularly, I’m curious to see how they might leverage the technological ownership of a whole car to serve their ambitions in mapping and navigation.

I thought it was a big loss for Apple when Google acquired Waze, the crowd-sourced navigation service that uses mobile phones to collect traffic data. Since then, I’ve been hoping that Apple might eventually offer a similar solution. With a suitably pre-rigged Apple car, the amount and quality of data collection might leapfrog even Waze’s impressive installed base. Imagine even 100,000 Apple cars in the US, equipped with built-in cameras on four sides, transmitting GPS and environmental graphics (anonymously and with user consent!) to Apple HQ. It might finally give Google something to worry about (assuming Google’s own cars haven’t already captured as much interest).

These rumors have fueled an enormous amount of speculation outside of Apple about whether or not they should build a car. Regardless of whether they do so or not, it’s clear from the amount of automotive-related hiring they have done that a great deal more speculation has probably been done inside of Apple, by minds that are now suited to make constructive decisions about whether Apple will build a car, what kind of car it will be, and when it will be available. I for one can’t wait to see what comes of it all.

The Siri Standard

John Gruber writes about his impression that Siri’s performance has improved over the past year:

Siri is noticeably faster than it used to be. Even just a year ago, I don’t think Siri could have held its own with Google Now pulling information like the current temperature or sports scores, but today, it does. Apple has clearly gotten much better at something everyone agreed was a serious weakness.

Michael Tsai chimes in with agreement, emphasizing improvements in reliability:

I had stopped using it because for years it would essentially throw away what I’d said. It was either unavailable (most of the time) or it didn’t understand me properly (less often). Now I regularly use it to make reminders while driving, and it pretty much always works.

I use Siri in much the same way that John and Michael seem to: for quick, relatively simple data inquiries, text messages, timers, and reminders. I share their impression that Siri has gotten faster and more reliable. It was most striking for me when I first updated to the iPhone 6:

I’m really impressed with the speed and accuracy of Siri on my iPhone 6. It’s exciting to know that Apple is making such progress on this.

Which is not to say Siri is perfect or doesn’t cause frustration to me and others. I use it frequently enough that I’m probably stymied by its misinterpretation of my command at least once a day. But the consequences of the misbehavior are usually not dire, and can be remedied right away. Usually it’s just a matter of sighing and rephrasing the command with a structure that I know will be “more Siri compatible.” And every so often, I say something instinctively before remembering “oh, that doesn’t work with Siri,” but before I’ve had a chance to cancel and restate it, I discover that in fact, it now does work with Siri. I know some people will have horror stories about Siri’s behavior, but for me, and apparently many others, It’s quietly improving all the time.

How many other Apple technologies are earning this kind of unsolicited praise right now? Especially in light of recent discussions about perceptions of a steady decline in quality, the progress by Apple in the Siri department is particularly noticeable.

What if all of Apple’s high-impact technologies were improving so demonstrably that folks were moved to praise the progress? What would the usually gripe-filled Apple blogging, Twittering, and forum-posting scene sound like? Let’s indulge the dream that these enthusiastic posts might grace the web someday soon:

It’s been weeks since I restarted any of my Airport routers. File sharing between my Macs “just works.” Great work, Apple!

Continuity and AirDrop have become so reliable, I actually worry more about data getting lost by emailing it to myself than by beaming it instantly with Bluetooth.

Just deleted Google Maps from my phone. Apple has work to do with placemarks, but these new transit directions are awesome! A huge step above what we lost years ago, and I’m so much more comfortable having Apple handle my private location data.

Tried to backup my phone to iCloud, and Apple says I’m 2GB over my storage limit. It’s cool that they do the backup anyway, and give you 30 days to decide whether to upgrade the plan or download the backup archive. Seems like upgrading is a no-brainer?

No serious complaints about my apps for a year, so Apple just updated my account to “Solo” status. It’s so great to publish updates immediately to my customers. This is a privilege and a responsibility!

OK, OK. Some of these may be a little over the top. But, a boy can dream, can’t he?

I don’t doubt that the groups at Apple responsible for these … less often praised … technologies are comprised of individuals striving to improve things as quickly as possible. It’s hard to say how much the impression of slow progress is due to internal challenges we don’t know about, Apple’s lack of knowledge about the breadth of defects, or the public’s perception being skewed by severity of the impact from problems that persist.

Whatever combination of luck, hard work, and pragmatism is powering the Siri team’s “year of good work,” perhaps it should serve as a model, or at least as a symbol of hope for these teams as they move forward adding features, fixing bugs, and finessing the public’s perception of the value of their work. A world in which every group at Apple somehow achieved the standard of apparent progress that Siri has achieved would be a very good world indeed.

The Functional High Ground

Marco Arment laments his perception that Apple’s software quality is in such a rapid decline that the company has “completely lost the functional high ground.” I like this turn of phrase, even if I don’t agree with the extremity of the sentiment. Marco expands:

“It just works” was never completely true, but I don’t think the list of qualifiers and asterisks has ever been longer. We now need to treat Apple’s OS and application releases with the same extreme skepticism and trepidation that conservative Windows IT departments employ.

I myself am particularly paranoid when it comes to Apple’s future. I spent the earliest years of my professional career working for the company, and to this day I consider the education I received at Apple to have been equal parts technical and philosophical. I learned not only how to build quality software, but why it should be done: to not only serve customers, but to delight and surprise them.

For years, my concerns about Apple’s future have been largely to do with my worry that those philosophical values are decreasingly shared by Apple’s engineering staff and management. And yet, over the years, I have been surprised and delighted by the steady stream of new, quality products that Apple releases.

The current state of Apple’s software does not particularly concern me. Are there embarrassing blemishes? Yes. Does the annual schedule for major OS updates seem rushed? Of course. Are there Apple employees in positions of power who do not share Marco’s and my enthusiasm for software that “just works?” I regret to surmise that, indeed, there are.

But I’ve indulged these doubts about Apple since shortly after I was hired … in 1996. The mysterious, seemingly magical nostalgic components of Apple’s past success have always seemed threatened by the rapid waves of change that undo and reconfigure the company’s priorities. After the NeXT acquisition in late 1996, many of my colleagues and I feared the influx of new engineers would spell the end of the Mac as we knew it. In fact it did, but the new priorities of Mac OS X meshed well with the old priorities of Mac OS 9, yielding what I believe is an undisputably better, more Apple-like operating system than Apple was likely to have come up with on its own. There were many fits and starts along the way, including questions about arcane matters such as filename extensions and case sensitivity. These were but a few of many questions that would seem to make or break the legacy of the Mac. Choices were made, hearts were broken, and the Mac lives on.

Since I left Apple in 2002, I have been no stranger to criticizing the company for its flaws. The mistakes they ship in hardware and software are sometimes so glaringly obvious, it’s impossible to imagine how any engineer, manager, or executive could suffer the embarrassments. And yet, sometimes these defects linger for years before being properly addressed.

The problem has also been a focus of popular geek culture at many, many times in history. Way back in 2005, Dan Wood of Karelia was so frustrated by persistent flakiness in Apple’s software that he encouraged developers to report an Apple bug on Fridays. It worked: myself, Brent Simmons, Wolf Rentzsch, Sven-S. Porst, and countless others were moved to file bugs not just that Friday, but for many weeks to follow.

Over the years I have never been at a loss for identifying problems big and small with Apple’s products, or with the way it conducts its business. I’m sure I had plenty of complaints starting in 2002, but I didn’t start blogging in earnest until 2005. Here are some highlights to remind you that things have never been fine with Apple:

  • 2005 – Keychain Inaccessibility. I lamented the poor behavior of Apple’s Keychain Access app, even after improvements that came in Mac OS X 10.4.3. Nearly ten years later, to the delight of the folks who make 1Password, this embarrassment remains largely uncorrected.
  • 2006 – We Need a Hero. I shined a light on the difficulty of implementing AppleScript support in applications. Things have steadily improved, but are still very frustrating and error-prone. At least now we have two automation languages to pull our hair out over.
  • 2006 – All Work and No Play… Apple’s first Intel portable computer was a sight for sore eyes, but a cause of sore ears. The maddening “CPU whine” persisted through several iterations of the hardware design until the machines finally became more or less (to my ears) quiet.
  • 2007 – Leopard Isn’t the Problem. Speaking of annual software release schedules, here’s my nearly 8-year old reaction to Apple’s failure to meet the planned release schedules for both Mac and iOS in parallel. Is Apple suddenly more fixated on marketing than on engineering? Not by my assessment that their statement way back then was “bluntly crafted, sleazy marketing bullshit.”
  • 2008 – NSURLConnection Crashing Epidemic. Wouldn’t it be embarrassing if Apple shipped a bug so pervasive that it could crash any app that uses Cocoa’s standard URL loading mechanism? That’s what they did in Mac OS X 10.4.11, and it took them months to fix it. When they finally did, I ended up receiving a security update credit!
  • 2009 – Is Apple Evil? Speaking of embarrassments, how pathetic is it that nearly 7 years after the iOS App Store debuted, capricious rejections are still a mainstay of iOS tech journalism? In 2009, I reacted: “Alongside the stubbornly perfected refinement of its products, marketing, and public image, the company has always worn blemishes such as these.” Some things truly never change.
  • 2010 – Surviving Success. From the midst of “antennagate,” in which Steve Jobs accidentally coined the famous anti-advice “you’re holding it wrong.” I fretted that Apple was losing its marketing cool, and that Jobs should chill out:

    He spins the truth in that barely plausible manner that used to be celebrated as the “reality distortion field,” but now comes off as purposefully dishonest and manipulative.

    We don’t have Jobs to blame any longer for Apple’s less tasteful distortions of reality.

  • 2011 – Huh. I couldn’t find any particularly cogent complaints in my archives. Maybe I was too busy reacting with panic to Apple’s new Mac Application Sandbox. I did complain in an interview with The Mac Observer about “having to come to terms with the vast amount of stuff that Apple’s doing,” but that “it’s been a persistent, joyous complaint … that Apple is doing too much.”
  • 2012 – Fix the Sandbox. Having fully digested the impact of the Sandbox on shipping apps, I drew attention to the many problems I saw in Apple’s approach to (allegedly) enhancing user security:

    Given the current limitations of sandboxing, a significant number of developers will not adopt the technology, so its usefulness to users and to the security of the platform will be diminished.

  • 2013 – Respect the Crowd. Oh, right, Maps. Remember when Apple used to have reliable driving directions, place data, and even public transit directions?

    It’s all about the data. It doesn’t matter how beautiful Apple’s maps are, or how quickly they load, if they consistently assign wrong names and locations to the businesses and landmarks that customers search for on a daily basis.

    Apple has made significant improvements to their mapping data, and there are rumors, based largely in their acquisition of transit-oriented companies, that they may restore transit directions at some point. But to this day, Google Maps remains my go-to app for transit directions, while Google’s other directions app, Waze, gets my business for driving directions.

  • 2014 – Breach of Trust. We’re getting so close to modern times by now that Apple’s tactless imposition of a U2 album on everybody’s iPhone, whether they wanted it or not, could be considered part of Marco’s current diagnosis of what ails Apple. The nut of my take on the incident:

    It doesn’t matter much that Apple inserts an unwanted music album into your purchased list. But even a little move in a direction that threatens the primacy of users is a relatively big move for companies like Twitter or Apple, whose track records have inspired us to trust that we retain more authority over the personalization of these products than perhaps we do.

And now it’s 2015, and in the immortal words of Kurt Cobain: “Hey! Wait! I’ve got a new complaint.” Don’t we all. A company like Apple, moving at a breakneck speed, will undoubtedly continue to give us plenty to obsess about, both positively and negatively. I’ve been following the company closely since my hiring in 1996. Since that time, the company has consistently produced nothing short of the best hardware and software in the world, consistently marred by nothing short of the most infuriating, most embarrassing, most “worrisome for the company’s future” defects.

Apple is clearly doomed. I think Apple is going to be okay.

Blockpass For Dummies

After I wrote recently about my tool for preventing accidental typing of my password into plain text fields, I received a large number of requests asking if I would open source the tool. I generally hesitate to open source my private tools, because I throw them together with understandably lower standards than the code that I ship to users, and because I often rely upon my accumulated convenience classes and frameworks to get the job done expeditiously.

But for some reason I’m deciding to share Blockpass on GitHub. I had to do some work to make using and running it a little more bulletproof. Rather than rewrite keychain access to avoid using my private “RSKeychain” class, I decided to just include that.

Details about how to configure and install the tool are detailed in the Readme file on the GitHub project page. You probably should not pursue the project unless you are comfortable using Xcode and building projects from scratch. I may consider building a standalone version of the tool someday, but today is not that day.

If you have any specific questions or feedback, feel free to open an issue on the project or drop me a line on Twitter.