Separating Apple Watch from iPhone as a Public Health Good

At their September event, Apple spoke of their annual upgrades to their iPhone and Apple Watch lines. While the iPhone update was mostly limited to the processor and camera, the Apple Watch had some more significant improvements, notably including the capability to capture an electrocardiogram, atril fibrillation detection, fall detection, and an emergency SOS feature.

While the original pitch for the Apple Watch included health features, it was more concerned with being a workout accessory and general activity tracker. Over the years, it has grown more sophisticated at being not just an accessory, but a true guardian of the wearer’s health. Features like ResearchKit are making it possible for medical research to be conducted on people on a daily basis. It’s clear Apple is going to continue moving the Apple Watch in this direction.

This has potential to be transformative to public health, but there’s a problem: this device is limited to people who have iPhones, which makes up about 2 in 5 US phones and 1 in 5 phones worldwide. That means these features are not available to the vast majority of smartphone users, a market that is currently starved for a comparable product. And while there are finally some signs of life for an alternate smartwatch platform, Apple’s actively working with the FDA on some of their features; they’re simply better positioned to have accurate results.

When the iPhone launched, it was tethered to a computer running iTunes, but with its fifth release, the iPhone went PC-free and became fully self-sufficient. While it’s unlikely that the Apple Watch could ever be completely run without a connection to some other device, surely there will be many features that aren’t dependent on an iPhone. The health care features alone would be transformative for many people; there are absolutely people who would buy an Apple Watch just to have a modern health guardian device. Are they obligated to make the Watch work without the iPhone? Of course not. But it would dramatically expand the market for the device, and provide a marked improvement to the health and lives of people who can’t get one today.

So yeah, Apple wants to remove the headphone port from the iPhone, apparently. Nilay Patel wrote a rant article on The Verge describing how removing the headphone port would be “user-hostile and stupid” (like, it’s in the title of the article). He makes a compelling, if incomplete, case for why it hurts you for Apple to force this change, citing the potential for a return of music DRM, need for additional pricey adapters, major compatibility issues, and the fact that nobody really wants this.

Nilay’s article is written under the argument that it would be “user-hostile” to remove the headphone port. I’m going to define this as acting against the user’s wishes, or being designed without the user in mind. It seems pretty reasonable that a user would not want hardware compatibility issues, DRM-encumbered music, or significantly more expensive headphones. And users already have lots of devices compatible with the 3.5mm headphone port. Therefore, to remove the port in a way that is not user-hostile and stupid, Apple would have to provide more value and benefit than they are taking away, on top of whatever new features they provide.

Following it up, John Gruber writes a rebuttal comparing this transition to Apple’s removal of floppy drives in the late 90s by writing about how this will be a positive for Apple. A rebuttal should address the core argument made, and John’s rebuttal completely fails to do that.

Read More

2011 is coming to a close, so I’d like to take a moment to highlight a few apps and games on Mac and iPhone that have been invaluable to me. I broke this out into four categories, each with two apps. I have purposely omitted iPad, because frankly, I rarely use my iPad (and I prefer the TouchPad over the iPad), and don’t feel I’ve played with enough iPad apps to really give it a fair shake. So I’ve left that off to focus on iPhone and Mac apps and games. I hope you’ll check out all of these great apps.

Read More

iCloud looks like it will be an incredible technology for moving app data between devices. This is inherently a good thing, and it will open avenues for many new types of apps. But, there is a fundamental problem. Right now, the only way to access it is through Objective-C APIs embedded into iOS and Mac OS X. Under the hood, they are obviously talking to the network and doing the business of syncing data, but that networking layer is not exposed or documented, and would have to be reverse-engineered in order to understand and use. So the only way for developers to move their data through this system is through a pre-compiled bundle that gets referenced within an application.

This has a few interesting practical repercussions. If you build an application targeting iCloud, you can only ever put it on two platforms – Mac and iOS. You will never be able to port it to Android, WebOS, Windows Phone, or the web (mobile or desktop). If you sync data through iCloud, And, you will never be able to have a server component that can do things with your data all the time.

Here’s some examples of what I’m talking about. In my To Do list app, Todolicious, one thing I would love to be able to do is to push badges to your iPhone and Mac showing the number of To Dos you have left. When you tap a To Do to mark it as done, suddenly all your devices would show the correct number on the icon. With the sync server I was building, this was fairly trivial; wait for the user’s list to change, and send a signal to push the count everywhere. But if I back Todolicious with iCloud, I have no way of speaking between my server and iCloud (and I’d still need a server of some kind to send the notifications, after all).

Similarly, if I were to build a web app version of Todolicious (which I was planning on), I could not get access to that data within iCloud at all. I’d have to have either to sync to both iCloud and a custom solution (unwieldy, poor UX and network traffic, and otherwise gross), or not load existing data at all (completely negating the benefit of having such a web app).

So there is a serious ecosystem lock-in problem for apps that wish to target iCloud. All of these problems go away when iCloud is made available as a server-to-server API. A big benefit in the promise of cloud computing includes service interoperability, but right now iCloud is merely a data silo. I have filed this as a bug, rdar://9598555, for a server-to-server API (through which you could build code that speaks to iCloud on your server or on other platforms). I dearly hope Apple addresses it.

Such a server-to-server API would drastically decrease the friction of setting up cloud services to complement an iCloud-backed app, and would lead to better apps and more pleased users.

Two years ago, I began working on a new Twitter client for iPhone, named Streamlines. I hinted at it about a year ago, and has been a driving force in my development of MGTwitterEngine and a ton of open source projects. I’ve come to the conclusion that I won’t have time to finish and release it, as there’s still probably another 6 months of development needed to really ship it, and hostility from Twitter and from users of other Twitter clients make effort into building one unsustainable. However, I think there are UI concepts in there which are totally unique and have never been seen before, so I’d like to share them with you before this project is lost to the annals of dead projects.

Read More

For a little less than a year, I’ve been writing code built atop Twitter, specifically Matt Gemmell’s MGTwitterEngine. I’ve got a few things running on this code, which I’ve not talked about publicly (other than minor hints on Twitter), but have been well-received by the few people who have seen it. Still, these projects have needed to extend both MGTwitterEngine and related libraries to add functionality or fix bugs. I’ll spend this blog post documenting some of those changes across the different projects.

Read MoreLink

Ars Technica:

ChangeWave queried 4,068 current and potential smartphone consumers last month and noted that a full 21 percent said that they would prefer Android on their next smartphones—a jump of 15 percentage points from the year before. Comparatively, 28 percent of respondents said they would prefer iPhone OS; this makes the iPhone the leader in this category, though this number dropped four percentage points year over year.

Many iPhone developers and Apple enthusiasts are quick to shrug off the Android platform, for a variety of reasons ranging from aesthetic and design, to functionality and developer tools. Many of these criticisms are certainly valid. But iPhone has its own share of problems, and certainly is deficient in many ways to the Android.

With Google’s press conference tomorrow, and CES for the remainder of the week, there will be a lot of focus on the Android platform. It will become a much stronger platform in 2010. It will be interesting to see how Apple responds with iPhone OS 4.0 (which history suggests they’ll probably talk about in March).


VillainousStyle is a drawing library for defining a visual style from a chain of individual drawing instructions. Each instruction modifies the drawing context to perform common operations; such operations include shadows, fills, borders, and shapes. It allows for multiple style sheets which can be used to theme an application in multiple visual contexts. VillainousStyle sits on top of CoreGraphics, and does not use WebKit for rendering at all. It is a fork of the VSStyle and VSShape classes, originally from the Three20 project.


VSStyleSheet is an abstract superclass for a set of styles. Subclass it and add methods for each style you wish to add. You will likely want to create a protocol for your styles to implement, to ensure that your stylesheet implements all the necessary styles.

There is a global stylesheet, which can be thought of as the “active” stylesheet. Call +[VSStyleSheet setGlobalStyleSheet:] to change the active theme, which will fire a VSStyleSheetChangedNotification. When that gets fired, you’ll want to tell your views to update their styles and redraw.


Styles affect drawing and positioning. Most will affect the next VSStyle objects in the chain.

  • Fills

    • VSSolidFillStyle – Fills the current shape with a solid color
    • VSLinearGradientFillStyle – Fills the current shape with a gradient between two colors
    • VSReflectiveFillStyle – Fills the current shape with a glossy-style gradient between two colors
  • Borders

    • VSSolidBorderStyle – Draws a border around the current shape with a solid color
    • VSBevelBorderStyle – Draws a beveled edge border for a 3D effect around the current shape
    • VSFourBorderStyle – Draws a border around the current shape with four colors, one for each edge
  • Shadows

    • VSShadowStyle – Draws a shadow behind content with a given color, blur, and offset
    • VSInnerShadowStyle – Draws a shadow inside the content with a given color, blur, and offset
  • Positioning

    • VSBoxStyle – Adds a margin or padding to the content area
    • VSInsetStyle – Adds edge insets to the content area
  • Content

    • VSTextStyle – Draws text inside the current shape
    • VSImageStyle – Draws an image inside the current shape
    • VSMaskStyle – Clips the drawing area to an image mask
    • VSShapeStyle – Clips the drawing area with a VSShape object


Shapes affect the fills and borders, but do not clip the content styles.

  • VSRectangleShape
  • VSRoundedRectangleShape
  • VSRoundedLeftArrowShape – a rounded rectangle with a left-facing arrow
  • VSRoundedRightArrowShape – a rounded rectangle with a right-facing arrow

Future Ideas

  • iPhone static library
  • Cappuccino library
  • File-based stylesheets that can be read/written from VSStyleSheet objects
  • GUI builder for styles
  • More styles!

The templates that ship with Xcode are not the greatest. Some of them are inconsistent and don’t enforce good coding standards (e.g. missing a dealloc method). Other templates which would be useful just flat out don’t exist (e.g. an NSOperation subclass, or a protocol header file). This project aims to supplement or replace the built-in templates for Xcode to speed up coding and improve the quality of code.

Coding Standard

All files will be processed by Xcode. The generated source files must produce consistent, readable, commented code. The code must have these characteristics:

  • Each file must have a comment block at the top describing the file.
  • Each class must implement its superclass’ designated initializer and dealloc.
  • Stub methods must be organized by their purpose, class or protocol. — Each group must be organized by their class hierarchy, with protocol stubs following. — Each group must be prefaced by a pragma mark naming the class or protocol the methods were implementing. — Clusters of methods (such as relating to KVO) should be organized along the lines above, with a pragma mark.
  • All method implementations should contain a method call to their super implementation if needed.
  • All method implementations should contain a commented out stub line that will signify where to insert their code.
  • All comments must be in the form of two slashes //, and none using the /* */ form. This will allow developers to comment out large blocks of code as needed.

Wish List

  • Different people want different things in their template. For instance, someone may want to include an implementation of observeValue:… for every class. Would be nice to have a template generator application (yeah yeah, very meta) which would make templates customized to the developer.

URL Shrink is a new OS X tool with a very simple purpose – converting URLs to shorter permalinks on various web services. As the internet has matured, and services like IM, IRC, and Twitter have forced us to write shorter messages, it was clear that a system was needed that was as ubiquitous as Quicksilver.

For now, the main service of URL Shrink is just converting a URL that is on the clipboard, although this will be expanding over time (including things like a system text service, a command line client, a Quicksilver plugin, etc.). To do this, there is a keyboard shortcut (option-shift-space) which will convert the URL in the background to a tiny URL using one of the services provided. If you’ve selected one as your favorite, it’ll choose that one. For example, I’m personally partial to, so all the URLs that are processed by URL Shrink on my machine go through

At a low level, URL Shrink is a system where multiple shrinking engines can be added. It was designed to be extremely easy for developers to write just a little bit of code to integrate with other web services, including private URL services. For information on that, see the project page below.

URL Shrink is licensed under the BSD license. I encourage its adoption within other applications; I’ll be adding .framework and .a targets for building this into Mac and iPhone apps respectively. Indeed, the project was born out of the URL shrinking capacity of another app I’m working on.


I could not be more pleased about this news. iTunes 8.1, which was released about an hour ago, renamed “Party Shuffle” to iTunes DJ. I’ve used Party Shuffle for a long time as a queue of music to play for day-to-day work, and have been frustrated with Apple’s Remote iPhone app and its lack of support for Party Shuffle. But their 1.2 App Store update, also released earlier today, has full support for it.

iTunes DJ divides iPhone users into two groups – guests and, for lack of a better term, the admin. The admin’s iPhone is paired to iTunes as before, and they get the iTunes DJ playlist added. You can skip through songs, cast a vote (addressed below), and request songs. While iTunes DJ is playing, selecting a song anywhere else throughout the app brings up a menu asking if you want to add to iTunes DJ or play on its own.

Guests don’t have to pair their iPhones to iTunes. They get to see a modified Now Playing screen, devoid of playback control. They can, however, request songs for iTunes DJ, and cast votes for songs. When they request a song, it automatically casts a vote for it.

Votes are pretty simple on the facet, but appear quite useful. Songs in the queue can be voted on by anybody. As they get voted on, they are automatically resorted in the queue by number of votes. However, you might get some guy at the party vote-clogging all night; fortunately, votes can be shut off by the admin.

All in all, this is the Big Deal feature in iTunes 8.1, and seems very well thought out.

Tim Cook, acting CEO of Apple:

We’re not going to play in the low-end voice phone business. That’s not who we are, that’s not why we’re here. Goal is not to lead unit sales, but to build the world’s best phone.

Hopefully this kills the stupid iPhone nano rumors. Kills ’em dead. It’s not coming, people.


The EFF is submitting requests for DMCA exemptions to the US Copyright Office. Among others, they are asking for an exemption for iPhone owners to be able to jailbreak their own devices.

Note that this is different from exempting the iPhone Dev Team, who create and distribute the jailbreaking solution, from lawsuit and/or persecution under the DMCA. This is solely for iPhone owners to do what they want with the device they paid for.