How Apple Can Improve the Apple Watch Without New Hardware

I wrote recently that I've been somewhat disappointed in the first generation Apple Watch. A lot of that has to do with the limitations of the hardware, but a sizable part is related to the software as well. Apple can only release new hardware so often, but they can update the OS much more frequently. Here are a few areas where I think there's room for significant improvement without new hardware.

Context Awareness

Right now, the Apple Watch does pretty much the same things regardless of the time, your location, the weather, etc. For a "smartwatch," the Apple Watch isn't all that smart. But the Watch has access to a trove of data about you and your habits via your iPhone, and it could take advantage of that data to act smarter. Imagine if the Watch could switch faces based on whether it's a weekday or weekend, or show different complications based on whether there's bad weather in the forecast. WatchOS could automatically re-order your Glances to load the most relevant ones first - for example, showing the MLB Glance first if your favorite team is in a tie game in the bottom of the 9th.

Complications could also improve a lot by including some contextual information. For example, the Timer complication is great when I have a timer running. When I don't, it just sits there displaying "SET" and taking up space. Users could assign priorities to complications, so that another could appear when one has nothing to show. If no timer is running, the weather could appear in its place. Even better, the OS could make some smart decisions about which complications to show. If I'm traveling, I might be more interested to know the current time back home than in the current moon phase. Likewise, if it's Friday afternoon and my schedule is clear for the weekend, I might be more interested to see what tomorrow's weather will be like. Giving developers access to context information could help apps provide context and priority clues to the OS.

Re-Think the App Launcher

Let's face it: The app launcher on the Apple Watch is a mess. The tap targets are too small, even on the 42mm model, and organization is difficult at best. It's a far cry from iOS, where a simple grid of icons has served users well for years. The honeycomb-style app launcher on watchOS feels like Apple prioritized how it looks over how it works. It's possible that the real answer here is to re-think the app model itself on the Watch. But that's a huge change, and there are a few improvements Apple could make without fundamentally re-thinking whether apps make sense on the Watch.

If anything, a tiny display like a watch is most suited to something like a simple grid. The Watch would be a great place to use the same predictive technology that iOS uses to suggest apps on the search screen. Imagine that clicking the crown presented you with a grid of apps based on a number of contextual clues, like your current location or how recently you launched the app. I'm guessing the most Watch owners only use a handful of apps at most, so chances are good that the first screen would contain the app you're looking for. (This is the app you're looking for.) If you're looking for something more, you could swipe through additional pages of apps ordered however you like, much like iOS.

Make Better Use of Hardware Buttons

How often do you really want to send a drawing or heartbeat to someone using your watch? If you're like me, almost never. On a device that has only two physical buttons, it certainly seems like a waste to devote one of them to a communication panel that almost always goes unused. At the very least, I'd like to see Apple let users assign that button to another function. Alternatively, it could bring up another menu (perhaps Glances?) that might be used more frequently. The same goes, at least in part, for the crown itself. Fixing the app launcher would help make it feel like clicking the crown at least opens something useful.

More Watch Faces

Watch faces are one of the most fun aspects of the Apple Watch. The face is the part of the watch I see the most, and a new face can make it feel Iike a new device. I have a few faces that I use often, ranging from a Modular face with lots of data to a minimal utility face that feels more stylish.

Unfortunately, there aren't as many faces as I'd like. Apple added a few new ones when watchOS 2.0 came out, but most weren't faces that I'd use regularly. So far, watch faces haven't been opened up to third party developers, and I think I understand why Apple is proceeding cautiously on that front. But if Apple is going to keep watch face development to themselves, I wish they'd help us out and release a few new ones! They've refreshed the lineup of Apple Watch bands every six months or so, and it'd be great if faces were on a similar schedule. There are so many styles, colors, fonts, and configurations to work with that it's hard to believe they're out of ideas.

Ultimately, a lot of the limitations of the first Apple Watch relate to the hardware. The CPU is too slow and/or the battery too small for the watch to be as snappy and responsive as I'd like. At the same time, a few software updates can go a long way. I hope Apple has enough of an open mind about the Apple Watch as a platform to re-think some things about how it works. Even with the same limited hardware, it could be a much more useful device with a few relatively small changes.

Considering an Xcode for iPad Pro

Lately I've been giving some thought about what it would take for me to be able to replace my laptop with an iPad. I do most of my day to day work at a 5K iMac. I only use the laptop for work when I'm traveling or need a change of scenery. For example, yesterday we had some beautiful weather here in Washington, DC, so I spent some time working at an outdoor table at Starbucks.

An iPad wouldn't need to be as fast or capable as my desktop computer, but there is one big requirement: Xcode. As an iOS developer, I spend a huge amount of time in Xcode. Without it, I can't get very much work done on the iPad. Fortunately, there have been rumblings lately that Apple is developing a version of Xcode for the iPad. I hope that's true, and I gave some thought to some of the areas Apple would have to tackle in order to pull it off.

Text Editing

Of course, a lot of time in Xcode involves manipulating code via a text editor. This is probably the easiest thing to get right. There are many capable text editors on iOS today, and there's no reason Apple couldn't build one into Xcode.

Interface Builder

Many apps are laid out using storyboards in Interface Builder. Developers can drag and drop interface elements and set up constraints that define how they relate to one another visually. It's a great (and occasionally frustrating) tool that offers a ton of fiddly options and settings. Interface elements can be large or very small – as small as 1 pixel in length or width.

At first I thought this might be a deal-breaker for Xcode on the iPad. Manipulating tiny UI elements with precision isn't something that wide fingers are good at in the same way that a mouse is. Sure, zooming and panning could help, but that seems like it might be time consuming and unwieldy. Then I realized there's another solution: the Apple Pencil. I don't think it'd be required, but the Pencil might be ideally suited for this task. Just like making a detailed drawing, developers could use the Pencil to edit small elements with precise detail. Panning and zooming would still be an option for developers who don't own a Pencil.

File Handling

There's no getting around it: Developing apps involves working with a lot of files. You've got source code files, storyboards, icons and images, database schema, and more. Not only do developers need to organize the files within their project, they often also need to add them from other sources. For example, a designer might send me an updated set of icons for an app I'm working on. I need to import those into Xcode, replacing the existing set or adding them as necessary. That means Xcode for iPad needs robust support for moving files into (and out of) the app, something that iOS apps haven't always been good at.

There's also the question of where project files will be stored. I'm still not comfortable using iCloud Drive for critical applications. Other document storage providers like Dropbox don't always support two-way editing, so opening files in an app creates a copy instead of modifying the file in place. Xcode could store project files within the app's local storage, but that means it's totally siloed away from editing by other apps. None of these are ideal, but I suspect we'll have to live with it.

Source Control

Related to file handling is the issue of source control. Any developer worth their salt keeps every code base in a source control repository. Xcode on the Mac supports Git and Subversion repositories, but the support has never been that great. It always felt like source control was tacked on to Xcode almost as an afterthought. My guess is that we'll be stuck with Apple's implementation, but hopefully Xcode for iPad will give Apple a chance to re-think the feature from the ground up. I have no doubt that Apple realizes source control is critical to app development, and without a command line to fall back on, I have my fingers crossed that they'll build a great source control tool on iOS.

Command Line

Speaking of the command line, source control isn't the only part of development commonly accessed that way. Tons of apps make use of tools like Cocoapods or fastlane when building apps. These aren't just conveniences; In many cases, they're critical parts of the development process. A lot of apps simply can't be built without them. This might be the trickiest part of putting Xcode on the iPad. Let's be honest: Apple isn't going to give us command line access to iOS. Even if it did, a lot of command line developer tools rely on modifying data across application bundles in a way that isn't possible on iOS.

I imagine Apple will tackle this through a combination of new tools and keeping the Mac as a backup. There are some interesting hints that Apple is working on their own implementations of some commonly used command line tools. Over time, those could be integrated into Xcode for iPad. It wouldn't be quite the same as using the command line, and a developer's options would be more constrained, but it's better than nothing.

At the same time, the Mac is still out there. For things that simply can't be done on the iPad, developers could open up their project on the Mac. At least at the outset, Xcode for iPad won't be a complete replacement for its Mac cousin, and nearly all developers will still have a Mac to work with.


Presumably, Xcode for iPad would only be capable of producing iOS apps. There's just no way Apple is going to build some kind of "Mac simulator" for the iPad, and even if it did, the user interface to Mac apps would be unworkable. Mac app development is going to stay on the Mac.

At the same time, I'm assuming that Xcode for iPad would be limited to the 12.9" iPad Pro. There's probably not a technical reason that it couldn't run on the new smaller iPad Pro, but I just don't think a 9.7" screen will be enough space. Heck, I don't really feel comfortable in Xcode on the Mac unless I have a big screen like the 27" display on my iMac!

The larger iPad Pro is probably also the only iPad with sufficiently advanced hardware to run Xcode. Even on a powerful Mac, Xcode can really get your CPU working hard and consumes a lot of RAM. It's possible the 9.7" iPad Pro could run Xcode as well, but its 2GB of RAM (vs. the 4GB in the larger iPad Pro) might be too small. Either way, compile times will be slower than on a modern Mac. The A9X is a fast CPU for a mobile device, but it's a lot slower than the CPU on a new iMac or even MacBook Pro.


If all this sounds like a lot of contortions to go through just to build apps on the iPad, there are some distinct advantages as well. The most obvious is portability. When I travel, I don't always want to bring a laptop with me, especially if I'm not planning on doing work. Yet I often do bring my laptop, in case a work emergency arises that I need to address. Having Xcode on my iPad would probably give me enough of a safety net in those situations that I could leave the laptop at home.

It would also be incredibly convenient to run iOS apps on the same device I'm using to build them. Imagine running your app in split-screen mode with Xcode. The iOS Simulator on the Mac is pretty good for what it is, but nothing beats running an app on the real hardware.

In recent press events, Apple has presented the iPad as a PC replacement and a place to do serious work. Building a version of Xcode for iPad is a tall order, but also creates opportunities to re-think some of Xcode's UI for new devices. If Apple is serious when it says the iPad is the future of personal computing, it makes sense to tackle Xcode sooner or later. I'm looking forward to seeing what they come up with.

A Small Defense of Apple's In-App Purchase Rules

From time to time I hear some complaining within the iOS ecosystem about Apple's rules about in-app purchases. Of particular note is the requirement that digital products must be made available through the in-app purchase system. Companies can also sell the product through their own web sites, but IAP must be an option the price must be the same in both places.

The restriction means that it's not possible to do things like buy books through the Kindle app. Amazon doesn't want to pay Apple's 30% cut on IAP sales, and I don't believe the IAP system is even equipped to handle a catalog of Amazon's size. Instead, users have to navigate over to Amazon's web site (without a link from the app, mind you) and buy the book there, then re-open the Kindle app.

It's a fair criticism, but I've also run into a few situations where I'm glad Apple's rule exists. I'm a baseball fan (let's go Red Sox!) and for the last few seasons I've subscribed to MLB's excellent MLB.TV streaming service. When I first signed up a couple of years ago, it wasn't possible to sign up via in-app purchase, so I created my account through the MLB website.

MLB automatically renews your subscription every year, and this year I wasn't so sure I wanted to keep my subscription, so I logged onto the website to cancel. I had to hunt around a bit, but I finally found a cancellation form. But I ran into a little snag: Submitting the form always seemed to fail with a mysterious error. (That's actually an improvement over previous years, when there was no cancellation form and you had to hunt for a phone number hidden in a block of fine print to end your subscription.) I had to email MLB's customer support in order to confirm and complete the cancellation.

A little time went by, and lo and behold, the baseball gods seduced me again. This time I decided to sign up through the Apple TV, since that's where I watch most games anyway. The process was as simple as picking the subscription period I wanted. To access MLB.TV on other devices, I can just use the Restore Purchases button instead of having to enter my MLB login credentials. Even better, now I know that if I want to cancel, all I have to do is disable auto-renewal in my iTunes account. MLB won't be involved at all, so I don't have to worry that their systems will mysteriously fail. An added bonus is that I have one fewer place to update my credit card information if my number changes.

In this case, Apple's rules on in-app purchases led me to have a better experience. Signing up was far easier than entering my contact and billing information on MLB's web site, and I don't have to log in to each device separately. While Apple's billing system isn't always perfect, I personally have never had trouble with it, and I trust Apple more than most other big companies. Apple says that their priority is to create good experiences for their customers, and this is one case where their restrictions on in-app purchases did just that.

App Review: Where We Are

Over at MacStories, Graham Spencer has a great overview of the current state of App Review. I was happy to give some of my feedback as he was putting together this article, and the end result is fantastic. Graham does a nice job of capturing the good, the bad, and some suggestions for improvement.

What amplifies the problem with App Review’s slowness is that developers have absolutely no idea how long the process is going to take. As one developer quipped, you get more feedback and transparency when you buy a pizza online than you do from App Review. Give developers some estimates so that they can better plan their marketing and development of their next update.

Worth reading the whole thing.

Barely Good Enough

Consider this a lukewarm endorsement of the first-generation Apple Watch. I received my 42mm Apple Watch Sport on launch day, and I was really excited about it. I had my expectations in check, but I think it's fair to say I wanted to love the watch. Unfortunately, I've mostly been disappointed. Yet I keep wearing the watch every day, because it's just barely good enough to keep me coming back.

By far, the biggest problem with the Apple Watch is that it's just too slow. As Dan Moren recently pointed out, what makes it all the worse is that the whole point of the watch is to get information quickly:

The problem with the Apple Watch is that we’re being asked to strap something to our wrist—to attach it to our very body—without it delivering on the corresponding promise that it will be much faster to use than our phones. The stale data and the lack of speed means that either you have to stare at your Watch for several seconds and hope the data updates; or tap on the complication to load the Watch app, which as we all know takes a good long while as well; or simply give up and pull out your phone.

Nonetheless, I keep wearing the watch, for two main features: notifications and activity tracking.

Notifications is the lesser of the two. There are times when it's nice to see a text arrive without digging my phone out of my pocket. That's especially true in the winter, when getting to my phone means going through a layer of coat and gloves. A quick look at my watch tells me whether I need to go through the trouble. At the same time, notifications are frustrating because I usually want to respond to them. Most times an emoji won't do, and I just don't want to be that guy talking to his wrist to dictate a reply. I've limited the number of apps that send notifications to my watch, but I do find a few of them useful.

The biggest feature that keeps me coming back is activity tracking. Honestly, it's great. The combination of steps, heart rate, and active calories is really useful, and motivated me to get a little more exercise. It's not an exaggeration to say that I'm in better shape today because of the Apple Watch. (I'm not the only one.) Other devices like FitBit do similar things, but if I'm going to wear something on my wrist all the time, it may as well be a device that integrates closely with my iPhone.

Without those two features, I'd probably have given up on the Apple Watch months ago. There's a ton of stuff that I thought I'd use but don't. "Hey Siri" sounds cool as an idea, but is terribly unreliable in practice. (My wife likes to laugh as I hurl expletives in frustration at an unresponsive Siri.) Sports scores and weather work properly, but are often slower than using my phone. I do use Apple Pay from time to time, but I wouldn't mind using it from my phone instead of my watch. Even complications, a watchOS 2 feature I was excited about, have underwhelmed. They're just too slow, too limited, and have too little developer support to be very useful.

That's not to say that the Apple Watch is doomed – far from it. But in order to be anything more than a marginal product, the next version needs to be far more responsive. Everything from reliability of turning the screen on when I move my wrist to loading data to opening apps must get better and faster. If the next version of the watch improves nothing except speed, that'll be a huge step toward being more than barely good enough.