JTSActionSheet – Simple, Customizable Replacement for UIActionSheets on iPhone

If you’ve spent any time working with UIActionSheet, then you’ve probably bumped up against some of its frustrating API limitations. My new open-source replacement, JTSActionSheet, will help you if your project has any of these requirements:

Check it out on Github. Feedback is welcome. The above screenshots are both made with JTSActionSheet. It will be a significant part of my next iOS app, code named “Time Zones.”

|  25 July 2014

Shawn Blanc’s Delight is in the Details – New Version has an Audio Interview with Yours Truly

It’s 2014. Books you already own can be updated with new stuff, which is awesome. If you own Shawn Blanc’s Delight is in the Details, there’s a new version out today with new chapters, videos, and audio interviews.

Shawn invited me to record an audio interview for this new update. I’m really satisfied with how our conversation turned out. Give it a listen if you’d like to hear me speak candidly about my creative upbringing, healthy shame, and how the sausage gets made when I’m working on an app.

If you haven’t read Shawn’s book already, there hasn’t been a better time to buy it. As a person who does creative work, I found it simultaneously challenging and reassuring.

|  23 July 2014

UIFontWeightTrait Ignored When Creating a New Font – TextKit Bug or a Jared Goof?

Given the following code and a device running iOS 7.1 or later:

 NSDictionary *fontTraitsDictionary = @{UIFontWeightTrait : @(-1.0)};
 NSDictionary *attributesDictionary = @{
                                       UIFontDescriptorFamilyAttribute : @"Helvetica Neue", 
                                       UIFontDescriptorTraitsAttribute : fontTraitsDictionary
 UIFontDescriptor *ultraLightDescriptor = [UIFontDescriptor fontDescriptorWithFontAttributes:attributesDictionary];
 UIFont *shouldBeAnUltraLightFont = [UIFont fontWithDescriptor:ultraLightDescriptor size:24];

 NSLog(@"%@", shouldBeAnUltraLightFont);

I would expect the value of shouldBeAnUltraLightFont to be an instance of HelveticaNeue-UltraLight, but instead it is:

<UICTFont: 0x908d160> font-family: "Helvetica"; font-weight: normal; font-style: normal; font-size: 24.00pt

I am following the Apple documentation as far as I understand it. Why is the font family and font weight information completely ignored?

Things I’ve Tried

Here are some of the things I’ve tried:

Regardless of these changes, the font returned is always a vanilla instance of Helvetica at normal weight. The only exception is when I remove the UIFontDescriptorTraitsAttribute key/value pair from the attributes dictionary. This results in a 24-point, normal-weight instance of whatever font family I specified.

Things I Can’t Use

Why This Matters

A design calls for an ultra-light system font, which in practice should be an instance of Helvetica Neue UltraLight. I could manually specify something like this:

font = [UIFont fontWithName:@"HelveticaNeue-UltraLight"];

The problem with this approach is that it’s prone to errors. When iOS 7.0.3 was released, Apple quietly renamed all the Helvetica Neue italic font filenames, which broke a lot of apps that were manually specifying the old font names. So I need a solution that is resistant to future errors of this kind, but still allows me to get a specific weight of a system font.

I’ve cross-posted this to Stack Overflow if you have an answer.

|  23 July 2014

Why are Inflation and Deficits Bad?

My old college friend, writer and philosopher Adam Kotsko, on the misleading common rhetoric about defecits and inflation:

A disproportionate amount of political debate centers around vague abstractions: government spending, deficits, and inflation. The latter two are supposed to be particularly horrible, leading to hyperinflation (and therefore Hitler) or else mountains of debt that are impossible to pay off (and therefore Hitler).

A moment’s reflection will reveal that these three technocratic abstractions are actually code words for “stuff that makes rich assholes powerful.”

|  11 July 2014

Birthday Cake M&M’s – The Dawn of a New Era

I tried Birthday Cake M&M’s for the first time tonight, and they are far stranger than I had expected. I had assumed that, like their Peanut Butter or – crucially – their Pretzel forbears, each candy piece would contain a morsel of actual cake. The truth is that Birthday Cake M&M’s are concocted to taste like fake processed chocolate cake – an artificial artificial flavor.

I’m tempted to cite the Jelly Belly’s Dr. Pepper jelly bean as a precursor, but that’s merely intended to amaze the customer with a feat of flavor science. In contrast, Birthday Cake M&M’s take food engineering as a given, presenting the (synthetic) synthetic cake flavor as an end in itself. Birthday Cake M&M’s assume that the customer already craves artificial chocolate cake for its own sake, not because it tastes like a slice of Real™ chocolate cake (which it doesn’t).

In the ontology of Birthday Cake M&M’s, it isn’t:

artificial chocolate cake flavor

but instead:

artificial chocolate cake flavor

It’s essential to point out that artificial chocolate cake flavor cannot exist independently of Birthday Cake M&M’s. On the contrary, it is Birthday Cake M&M’s that bring artificial chocolate cake flavor into being, as a pond ripple is born from a stone.

Birthday Cake M&M’s shift the boundary between the real and the artificial forward by many millenia. It’s as if everything that came before artificial chocolate cake has now been blessed. Agricultural advancements, technological innovation, manufactured goods, indeed the whole of human ingenuity, have been adopted into the family of the real – at least up through the point in human history that cake mix started shipping in a box.

Thus, through the second-order synthesis of the Birthday Cake M&M, the first-order synthetic is no longer distinct from what is genuine. The synthetic is synonymous with the real. Technology is nature, and vice versa. The Buddha is at home in a Xanax bottle.

A new era has dawned.

|  11 July 2014

“The Best of Both Worlds” – Yours Truly on CMD+Space

I was a guest on today’s episode of Mike Hurley’s CMD+Space podcast. Check it out if you’re curious about my thoughts on the past and future of App.net, the strategy behind the design of Unread, and my feelings on the decline of the indie iOS software business.

|  3 July 2014

They Make Such Bloody Good Cameras

The iPhone makes it so easy to feel like a great photographer. The following photo was made in two steps: a quick one-off shot straight from the lock screen camera, and a VSCO Cam filter (with a minor crop).

My wife and son.

This is one of the best photos I’ve ever taken, and it took less then sixty seconds to shoot, edit, and share it. Here’s the untouched original:

Untouched original.

Bravo, Apple.

|  2 July 2014

I Love Teleportation - A Summary of a Wishful Day

|  1 July 2014

I Hate Flying – A Summary of Our Day:

Nota Bene – If you are one of the many people expecting to meet with me in person or over Skype tomorrow, my apologies for probably missing our appointment.

|  1 July 2014

OvershareKit to be Maintenance-Only for iOS 8

Last fall, after I had finished the model controller layers of Unread, I felt a pit in my stomach. The next big task in front of me was sharing. I knew I wanted Unread to have lots of sharing options, but I dreaded writing them. I had already written tons of them in the course of making Riposte for App.net. Great sharing features are non-trivial to write. It’s even harder to make them reusable (Riposte’s were not). There are many concerns to think about:

There was no way to tackle all of these issues within the limitations of UIActivityViewController on iOS 7, which is why I decided to make OvershareKit. You can read the reasons in detail on OvershareKit’s Github page, but here are the highlights:

Those are just a few of the reasons why I decided to build something like OvershareKit for Unread. Justin Williams was in a similar position with his projects around the same time, so we decided to integrate his code for managing system accounts into the broader framework that I had conceived.

Bear in mind that at the time OvershareKit was being developed, it was still unclear whether Apple would ever provide better inter-app communication and sharing APIs. After seven OS’s, it was easy to believe that Apple frankly didn’t care. I was frustrated by their lack of concern, and dissatisfied by the lack of an open-source framework to bridge the gap. It was my hope that OvershareKit would become more than just a pet project between me and Justin.

But now that the iOS 8 developer preview is here, with its powerful Extensions APIs, what should be done about OvershareKit? Extensions are Apple’s answer to the problem that OvershareKit was created to solve. It seems to me that it’s better for all involved – both developers and users – for any app that’s using OvershareKit to migrate to Extensions and the UIActivity frameworks.

OvershareKit is now an unnecessary middleman between users and services like Pinboard and Instapaper. Almost any service that users want to access via OvershareKit already has great first- or third-party apps on the App Store. The burden of responsibility should belong to them to provide great sharing features via iOS 8 extensions.

I think this should apply to all future OvershareKit development, too. For example, many of Unread’s customers ask for Evernote support. Evernote has a rich and complicated API. It doesn’t make sense for outside developers like me to spend limited resources building support for Evernote. I want Unread to have Evernote, but the costs outweigh the benefits. It’s a sacrifice I was willing to make back when Apple provided no alternative. But now that Extensions are coming, the math has changed.

I don’t plan on adding any new features to OvershareKit. I will make sure that all of its existing features continue to operate bug free on iOS 7 and iOS 8. It may take several months (or longer) for extensions to be developed for all the services that OvershareKit currently supports. In the interim, I want to be sure that apps like Unread can continue to rely on OvershareKit.

If you have an app or service you can’t live without, I urge you to write to its developers and ask them to consider adding support for UIActivity extensions in iOS 8.

|  27 June 2014

Preferred Orientation

I’m pretty sure the following generalization is true, with few exceptions: every iPad app has been designed for a preferred orientation. I think this is true whether the designer was conscious of the preference or not.

iOS lock screen, awkward in landscape.

I’m not saying that the non-preferred orientations are poorly designed, nor am I saying that they’re not useful. I mean only that every iPad app has an orientation in which it looks and works best – the way we say of a person’s appearance that he or she has “a good side.”

Here are some examples, off the top of my head:



Notable Exceptions

|  26 June 2014

Happy Birthday, Henry

The boy turns one year old today.

Happy Birthday, Duders.

|  26 June 2014

Nitpicking iOS Notification Banners

We’re all familiar by now with the iOS notification banners that appear at the top of your screen. These slide into view from offscreen in a top-down direction.

In general these are great. They’re certainly a big improvement over the full-screen alerts from iOS 4 and earlier. But the banners can get annoying when they slide over app content you need to see, especially navigation bars.

The nuclear options – the ones that turn off banners altogether – are too extreme. Luckily iOS has a simpler way. You can dismiss a banner early by swiping up, from the bottom of a banner to the top edge of your screen.

Here’s my nitpick though: why is this gesture only allowed in a vertical direction? The target region is so small that in practice I often end up triggering a tap, i.e. the exact opposite of what I intended to do.

Perhaps it’s for logical consistency. The banner appears top-to-bottom, so dismissing it occurs in reverse. But this isn’t an important enough spatial rule in my opinion.

You should be able to swipe horizontally to flick a notification off screen. We did it this way in Riposte and it was awesome.

Can you think of a good reason why horizontal dismissals shouldn’t be allowed?

|  24 June 2014

David Rönnqvist on CALayer Animations

David Rönnqvist has a new post today, "Multiple Animations", on the interplay between competing explicit and implicit CALayer animations.

David’s site is gorgeous, but it’s also a textbook case for why we need RSS. David publishes new posts infrequently, yet none of them should be missed. Subscribe to his site here.

|  23 June 2014

Healthy Skepticism – My Critique of HealthKit as Both iOS Dev and Registered Nurse

Of the many new APIs announced at WWDC this summer, HealthKit has been particularly thought-provoking for me. At the risk of sounding like that guy, I think I have a somewhat priviledged perspective of HealthKit. There can’t be that many former registered nurses who’ve switched to iOS app development and tried to start a healthcare data company.

I’ve devoted the better part of the last four years to understanding the healthcare industry, both its current problems and its possible futures. Along the way I’ve learned many things – some hopeful, some downright depressing. I ought to describe how HealthKit looks from my vantage point.

Before jumping into HealthKit, let’s take a step back and look at the past and present state of healthcare information – what it is, where it’s stored, and how it’s transmitted and used. I’ll limit my description to the US since that is what I’m most familiar with.

Stacks of Paper

When I was a nurse, I worked in critical care. A typical patient at my hospital was brought in via ambulance or helicopter from an outlying urgent care facility. Though I worked at a hospital in Nashville, it was not uncommon for us to admit patients transferred to us from hospitals as far away as Kentucky. A transfer patient would be wheeled out of an ambulance and onto my ward by EMTs hired to ferry patients between hospitals. Tucked into the corner of the mattress, I’d find several fat manila envelopes filled with stacks of paper printouts from the outlying facility’s electronic health record system (EHR). There were so many pages it wasn’t possible to use them as a working reference. Instead, I primarily relied on the verbal report from the EMT to learn a patient’s past and present condition. It was only later, after our doctors had a chance to review the reams of paper printouts, that the full picture would begin to be revealed.

Though the transfer patient may have been in the outlying facility for days or weeks, as far as our EHR was concerned, today was Day Zero. Discontuity between caregivers’ records increases the likelihood of mistakes. Doctors and nurses go through a great deal of training in order to verbally communicate patient data as efficiently and safely as possible. This training helps us offset the risks of fractured medical records. Those stacks of paper became a supplementary reference, secondary to verbal reports. It would take a day or two before our own EHR would be populated with enough of that patient’s data to become a primary reference.

From Paper to EHRs

Until relatively recently, the vast majority of medical records in the US have been recorded on paper. From routine doctor visits to lengthy stays in critical care, every piece of data – lab results, medication orders, progress notes, etc. – were written or typed on paper and stored in massive warehouses. It wasn’t until the 1990s that electronic health records (EHRs) started to gain widespread traction. Doctors and hospitals were under no legal obligation to use EHRs, so the only providers to use them did so for organizational efficiency.

There have been numerous studies of the impact of EHRs on patient care, with mostly positive results. The consensus is that EHRs improve institutional logistics (billing accuracy, resource management, etc.) and help decrease medical errors, if sometimes at the expense of time spent at the bedside. They also contain latent possibilities for medical research and population health management – but only if most doctors and hospitals go fully paperless.

Though there are hundreds of EHR vendors, a mere handful of major players have dominated the market – companies like Epic, Cerner, Allscripts, and Meditech. Every vendor has its own unique software stack, from data storage to caregiver applications. There is no common database linking all these software products together. Every institution’s medical records are trapped within proprietary silos. Any interoperability with other EHRs has been made possible only on an ad hoc basis, at the whimsical discretion of EHR vendors and their customers. In practice, interoperability is virtually nonexistent. Patients are transferred between institutions with a stack of paper printouts, or nothing at all.

There are two main reasons why EHR interoperability hasn’t happened: it would be bad for business, and technical standards are lacking.

Interoperability Would Be Bad for Business

It’s disappointing but unsurprising that EHR vendors would keep medical data trapped inside their silos. If medical data were distributed via a shared database, their products would be reduced to either dumb pipes or thin client apps. Being a dumb pipe is bad for business. Selling thin clients isn’t a great option, either. EHR user interfaces are notorious for their terrible design. As a former registered nurse, I have plenty of interface design horror stories I could share with you. The reason these apps are so poorly designed is simple: they’re enterprise software. The customer is the hospital administrator, not the bedside nurse. The real money is in long-term, multi-million-dollar contracts with institutions who aren’t anyone else’s customers.

Interoperability isn’t in the interests of most healthcare providers, either. As a healthcare provider, you want the other institution to make it easy for you to see their data, so you can make your facility more efficient. But you have a neutral or negative interest in providing the same openness in return. Why would you invest in infrastructure that makes it easy for your patients to go somewhere else? Business models or legal requirements – or both – would have to change in order for EHR vendors and healthcare providers to be willing participants in a world of shared medical information.1

Interoperability Would Be Technically Challenging

There are technical obstacles to interoperability, too. Medical information is incredibly complex to model. It’s edge cases from top to bottom. Even something as simple as defining the possible values for a person’s gender raises difficult questions about biological versus preferred sex. Out of necessity, a number of protocols have been developed over the years that can encapsulate medical data in transit between subsystems within a given institution.

The most commonly used protocol is called HL7 – a gargantuan protocol with many variants. In the real world, no two institutions use the exact same implementation of HL7. Most systems in the US use one of the 2.x versions, which are pipe delimitted, prone to error, and not human-readable. Here’s a typical HL7 message for a lab result:

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4
 PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^
 OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730|||||||||
 555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD
 OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F

Yeah. Right. That’s a far cry from the tidy, readable JSON response from your garden-variety social media API.

There is a newer 3.x series of HL7 that is based on XML, but few EHRs in the US are actually using it. Thus the 2.x sample above is the current state-of-the-art of medical data exchange. Since HL7 2.x is pipe-delimitted, it is easy for implementers to insert data between the wrong pipes, breaking the already weak links between EHR subsystems. This happens so frequently that an entire industry exists just to solve this problem.

The deeper problem with HL7, in my opinion, is that it isn’t designed for persistence. It’s a means to encode ephemeral messages. The actual work of when and how to send messages, and where to store their contents, is left up to each EHR vendor. Linking together EHRs from two different vendors would be an enormous engineering task. A shared repository of private medical records would need something much more readable and resilient than HL7. It would need to look more like the JSON messages used by modern, RESTful web APIs.

HITECH and Meaningful Use

Earlier in this post I wrote that EHRs didn’t begin to gain widespread traction until the 1990s. This was an overstatement of the facts. The reality of EHR usage is that – even as late as 2009 – fifty percent of US hospitals were only only halfway electronic. Most just converted the easy stuff to electronic records, like lab results. Less than one percent (!) of them had completely moved beyond paper records. Many still had no electronic records at all.

The 2009 ARRA act passed by the US Congress included a landmark set of reforms aimed to drag US medical institutions kicking and screaming into the 21st Century – or at least the 20th. Not to be confused with the “Obamacare” reforms, the HITECH Act obligated US healthcare providers to demonstrate “meaningful use” of electronic health records. Meaningful Use, as the program has come to be called, ties Medicare reimbursements to EHR usage. A series of requirements, broken up into stages, will be rolled out over the next decade. Each successive stage unveils more stringent rules. Institutions that meet or exceed the current criteria in a timely fashion will earn bonuses on their Medicare reimbursements. Institutions that don’t will face penalties. Medicare reimbursements are bread-and-butter for healthcare providers, so there is strong motivation to keep up with the demands made by Meaningful Use.

The Meaningful Use criteria are still being defined, but the ones that have already been put into play are praiseworthy. Institutions must be able to electronically transmit a Continuity of Care Document (CCD) upon demand. A CCD is a brief summary of a patient’s past and present medical conditions. This requirement is aimed to solve the “stacks of paper” problem above. The CCD is a glorified PDF, but it’s the next best thing to having truly interoperable EHRs. Other Meaningful Use requirements are aimed at improving patient safety by requiring barcode scanning before administering drugs (BCMA), or requiring doctors to use specially-designed software to write orders instead of pen and paper (CPOE).

The most intriguing part of Meaningful Use is that it places the burden of proof on medical care providers, not EHR vendors. It’s up to each institution to select an EHR that supports Meaningful Use criteria. EHR vendors are in a mad rush to update all their products to meet the minimum requirements in time.

It is not yet known if Meaningful Use will ever require true interoperability between EHRs. If that happens, I would be extremely pleased, as a software developer, a former nurse, and a patient. With congressional lobbying being what it is in the US, I doubt EHR vendors or healthcare providers will ever let true interoperability become a legal obligation.

The False Promise of HealthKit

To a layperson, the introduction of HealthKit at WWDC looks like Apple might hope to provide the foundation for a future of shared medical data. The example use cases looked pretty cool at a glance. According to Apple, your doctor could conceivably have easy access to vital signs obtained by a Withings blood pressure cuff connected to your iPhone. The list of HealthKit partners, like the Mayo Clinic and Epic Systems, was particularly impressive. But I don’t think either HealthKit or Apple is in a strategic position to escape the forces that keep our medical data trapped in the status quo.

The first problem with HealthKit is that it can only model a tiny fraction of the spectrum of medical data. There is a very long list of things it can’t do: track medication doses, doctor’s orders, procedural notes, etc. But let’s assume for sake of argument that HealthKit eventually ships with model classes for every conceivable type of medical data. It still wouldn’t be able to bring about EHR interoperability.

As I discussed above, interoperability is technically challenging no matter who attempts it. Apple clearly has the capacity to tackle the technical issues if it really wanted to. The central problem for interoperability is one of motivation. Who has the power to compel all the hospitals and EHR vendors in the US to open up read/write access to their medical records?

In my estimation, there are only two entities capable of doing so. The first and obvious one is the government. If Meaningful Use ever mandates one-hundred-percent interoperability, then the industry would have no choice but to comply.

The second entity would be a for-profit company that offers healthcare providers a mutually-benefical partnership. This company would compel hospitals to allow them access, but with a carrot instead of a stick. If there was a way that hospitals could benefit from partnering with an open EHR framework, then they might happily allow their siloed data to flow freely between competing institutions.

Unless I am misjudging Apple’s intentions, HealthKit looks like it’s another way to keep high-end customers loyal to the iPhone and other Apple products. As such, it’s against Apple’s interests to make HealthKit available on competing platforms like Android or Windows. But for stored medical data to be of any significant use to healthcare providers, it can’t be limited to just A) patients who own iPhones and use HealthKit apps and B) providers with EHRs configured to access those apps. It’s unreasonable to expect that either healthcare providers or EHR vendors would devote limited engineering resources for the sake of a handful of patients, especially when the laundry list for pending Meaningful Use requirements is still so long.2

In practice, I expect HealthKit will have little or no impact on professional healthcare delivery.3 I think the experimental partnerships between Apple and the companies listed during the WWDC Keynote will remain exactly that: experimental. It will take a lot more than HealthKit to make a dent in the universe of healthcare.

  1. Clayton Christensen’s book on the business of healthcare offers a fascinating exploration of these kinds of problems. 

  2. This logic is the same for any hypothetical Apple wearable device, too. 

  3. The personal fitness industry is another story, however. HealthKit is an excellent, well, fit there. 

|  19 June 2014