Seeking Beta Testers

I’m wrapping up development on a major update to Manifest, my time tracking app for iOS. In order to make sure that the app is stable and easy to understand, I’m looking for beta testers to help put Manifest through it’s paces.

The update is focused on setting and reaching goals as you track your time. Manifest is a great app for freelancers and independent developers who need to track time across a number of projects.

If you’re interested in joining the beta, please sign up!

Sign up for Manifest Beta

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.

Considering the iPhone(s) Plus

I’ve been thinking lately about my next iPhone, and more specifically, what size it’ll be. To my surprise, I’m more and more inclined to give the larger iPhone Plus a try.

I didn’t seriously consider buying the iPhone 6 Plus when it was first released. The 6 was a significant enough size jump from the iPhone 5 that going even bigger didn’t make a lot of sense to me. Despite being a little slippery, I’ve enjoyed the 6 overall, and haven’t felt much need for a bigger screen.

And yet, the Plus is starting to make more sense to me, and the change in thinking has a lot to do with how I use my iPad. I enjoy using the iPad for more involved tasks or reading a book, but if I’m just sitting on the couch browsing through Twitter or skimming a few articles, I almost always use my phone. That’s true even if the iPad is nearby. It’s just easier to use the device that’s already in my hand or my pocket. That’s where a Plus phone could come in. If I’m already using my phone in place of the iPad in some situations, it’d be nice to have a little more screen real estate. I wouldn’t give up using my iPad, I’d just give myself a little more room on the device I use most often. A little extra battery won’t hurt either.

In the past, I’ve had two main practical concerns about the 6 Plus: one-handed use and size in a pocket. The former concerns me less than it used to, for the simple reason that I don’t use the iPhone 6 one-handed all that much either. As for how a Plus might fit in my pocket, I imagine I’d have to try it to really know. What I can say is that I find myself taking the 6 out of my pocket when I’m sitting, so the Plus likely wouldn’t be all that different. I don’t expect it’d be an issue when walking around.

Fortunately, since Apple lets you return products within the first couple of weeks after purchase, I can give the Plus a try with my next phone without worrying about buyer’s remorse.

Fearing an Apple TV Service

Word has been building that Apple is planning to launch a subscription-based Internet TV service near(ish) future, and I’m afraid. My fears can be neatly summed up in one word:


Almost all traditional TV has ads, except for a few premium channels like HBO. And they’re horrible. During a typical one-hour TV show, roughly 18 minutes are given over to ads, leaving only 42 minutes for actual content.

In the late 1990s, devices like TiVo appeared that let viewers record or pause shows, then play them back later, fast-forwarding through the ads. (The same was possible with ye olde VCR, with a bit more legwork.) Big media companies hate these devices because they let people skip over the ads that bring in revenue. Fortunately for TV viewers, there’s not a whole lot the media companies can do about it. I’ve been using a TiVo-style DVR for about ten years, and I rarely see TV ads outside of live sports.

Enter a TV service from Apple. In order to launch its service, Apple will need to secure the rights to distribute TV content from the media companies. In those negotiations, media companies are operating from a position of strength: they have the content that everybody wants. Certain to be among their conditions in any contract with Apple: un-skippable ads.

You might’ve seen these kinds of ads if you’ve watched shows on Hulu. Guess why: Hulu is a joint venture of NBC/Universal, Fox, and Disney/ABC. It’s also worth noting that buying a paid subscription to Hulu Plus doesn’t get rid of the ads, it just gives you access to more content. In short, Hulu works the way the media companies want it to: You pay for access to the content, and you’re forced to watch ads too. No DVR in the middle, no skipping the commercials. (And no variety in the ads. Seriously, how many times in a row can they show the exact same commercial?)

A TV service from Apple is likely to work a lot like Hulu. It might have a greater variety of content or a better UI, but the commercials will be there to stay. Why is it filling me with fear if it’s so similar to existing streaming services? Because an Apple TV service is likely to be far more successful and widely used than Hulu. It’ll turn a niche product into a widespread one, and the ad model will come along for the ride. Once everyone is used to un-skippable ads, they’ll be awfully hard to get rid of. We’ll be back where we started 20 years ago: watching the same ads for Chevrolet pickup trucks for 18 minutes out of every hour. (Oh, and those 18 minutes? That’s 30% of an hour, which just happens to be the same percentage that Apple takes as a cut from sales on the App Store. Certainly a coincidence, but an eerie one.)

I tried to watch a show on Hulu recently, and I couldn’t get through it. After ten years of commercial-free TV, I just couldn’t stand to be forced to watch the same ad over and over. I’d rather record something on my TiVo, watch it later, and skip the ads. Sure, Hulu will let me watch on my phone or iPad wherever I go, but the experience is much worse. An Internet TV service would have to offer a lot more than portability to get me to watch all those ads again. I can’t believe I’m saying this, but I’d rather keep giving Comcast (Comcast!) my money and using my trusty DVR.

CloudKit 2015

Early last fall, I wrote a post about the strengths and weaknesses of CloudKit as a back end for iOS apps. In part, I was inspired by a post by Brent Simmons, and Greg Pierce chimed in about why he chose to build the sync service for Drafts on CloudKit. At the time, I had some reservations about CloudKit, but it was also too early to say much for certain. A lot has changed since then, and my views on CloudKit have shifted significantly in favor of using it.

One of my concerns last year was that CloudKit might not gain wide adoption, and then quickly be abandoned by Apple. I think it’s now safe to say that won’t happen. Apple has pretty much gone all in on CloudKit with their own apps, including cornerstone apps like Photos. That alone is enough to ensure CloudKit’s longevity. Moreover, CloudKit seems to be reasonably popular among iOS developers for many of the reasons that Greg outlined in his post. Unlike some of it’s predecessors, CloudKit should be with us for a while.

The other, bigger concern was that apps were pretty much the only interface to CloudKit. If I needed to migrate data away from CloudKit, I’d have to write an iOS or Mac app to do it. Moreover, there was no way to build a web interface to a CloudKit-based app. That all changed at WWDC 2015 when Apple introduced CloudKit JS and CloudKit Web Services These provide a lot more flexibility, and for me, piece of mind. Although I’ll almost certainly start using CloudKit exclusively through apps, an having an HTTP interface means I can expand in the future if I feel the need. Even if I never end up doing anything with it, it’s nice to know I have options.

I remember thinking last year that there were just a couple of smallish hurtles before I’d be totally comfortable adopting CloudKit. In 2015, Apple has cleared them with room to spare, and I’m confident in saying I’ll use CloudKit next time I need to build a sync service for an app. (Hopefully before too long – but more on that later.)

Apple Watch First Thoughts

Now that I’ve had a couple of days to use my Apple Watch, I jotted down a few initial thoughts. Here they are, in no particular order.

Use Cases

I’ve found the Apple Watch particularly handy in situations where it might be inconvenient to dig my phone out of my pocket. For example, I was at a baseball game over the weekend, and was able to read texts and other notifications without having to go fishing for my phone. (A particular challenge since it was a chilly night and I was wearing gloves.) I did find myself going to the phone to reply, but at least I didn’t have to fetch my phone as often.

I also really enjoy the quick access to weather info from the watch face. I have the current weather configured as a complication on my watch face, and tapping the weather launches the Weather app. (Bonus, it lets you bypass the app launcher. See below.)

Watch Faces

Playing with the watch faces is really fun, both choosing a face itself, and customizing them with complications. I’ve mostly been using the Utility face. (Activity in the upper left, moon phase or battery in the upper right, weather on the bottom.) I do wonder why some faces allow fewer complications. The Motion face is a good example – there seems to be amble room for a complication or two, but the face doesn’t support them. Why not?

It would also be nice to have more faces, and I do think we’ll get them sooner or later, either from Apple or third parties. Faces are the “iPhone case” of the Apple Watch – the ideal place to personalize your watch. (If Apple decides against third-party faces, maybe they’d allow third-party complications?)

The App Launcher

The one thing I really don’t like about the Apple Watch is the app launcher screen. It’s terrible. Sure, it looks cool, but it’s really not very useful if you’re trying to get at a particular app. The icons are too small, so they’re really hard to tap on, and the blob-like arrangement of apps makes it hard to find an app quickly. It’s also hard to get apps into the position you want using the iPhone’s Apple Watch app. The blob doesn’t always move in the way you expect when rearranging apps, so moving one can cause others to shift out of alignment.

I find myself yearning for a simple paged grid of icons, similar to the iPhone home screen. No, it’s not sexy, but it would get the job done. A page-based layout would also make it easier to keep frequently-used or themed apps together, so you don’t have to go hunting for them. A 3×4 grid seems about right for the Apple Watch screen size, and would probably even allow the touch targets to get a bit bigger. You could even use the digital crown to scroll through pages. My fingers are crossed the Apple will reevaluate this screen sooner rather than later.


Glances are a great way to get some quick information and launch an app for more depth. Since the app launcher is so unpleasant to use, I find myself launching apps using Glances whenever possible. For example, I’ll open the MLB At Bat glance to check the Red Sox score, then tap it to launch the At Bat app for a more detailed look. (18-7 against the Orioles? Ouch.)

Right now, third party Glances are read-only, but a few of Apple’s let you interact with them. The Now Playing Glance is a great example: You can play or pause, skip forward or back in the current song, or change the volume. Hopefully Apple will let developers make interactive Glances soon.

Third Party Apps

Based on some of the pre-launch reviews, I expected third-party apps to be pretty slow. Fortunately, I’ve been pleasantly surprised to find them fairly responsive. Overall, apps that load fewer graphic elements seem to be the fastest, which makes sense when you consider that many graphics are being copied from the iPhone over Bluetooth or WiFi.

As predicted, lots of apps don’t seem quite right on the Apple Watch. They either try to do too much, don’t do enough, or focus on the wrong things. There’s also a clear difference between Apple’s own apps and third party apps, simply because they can do more – animations, sounds, taps, sensors, more flexible layouts, etc. It offers a glimpse of what’s possible on the watch, and a lot of third party apps will be vastly improved when they have access to all these tools.


One of the most unique features of the watch is the ability to send drawings, taps, and heartbeats to other Apple Watch users. Unfortunately, there aren’t too many people who have them yet, so it’s a little like only being able to text one or two people. This could be a lot of fun if the Apple Watch takes off.

The animated emoji are a fun idea, but a little strange or creepy at times. I think I’d prefer just bigger versions of regular emoji. (Apple Watch does let you send regular emoji, but only one at a time. Why not allow multiple emoji in one message?)


The battery seems great so far. In my first two full days of use, my battery has ended the day around 45-50%. It’s been enough of a non-issue that I took the battery meter off my watch face.


The charging cable that comes with the Apple Watch is significantly longer than the iPhone’s Lightning cable. It’s really nice if, for example, you don’t have an outlet right by your nightstand. Here’s hoping this year’s iPhones come with longer cables too.

I got the white sport band and have found it quite comfortable to wear, and relatively easy to put on and take off. I haven’t had problems with sweatiness under the band, although in fairness, it hasn’t been particularly hot out. Overall I find the Watch (Sport, 42mm) quite light and natural-feeling on my wrist.