Thoughts on WWDC 2013

Polarising

…is the word that Gruber has been using to describe the new iOS 7 design, even before WWDC began, to an extent that I wonder if Apple PR discreetly suggested it to him as means of damage control. As if to say: ‘If you hate it, that’s OK. A lot of people will hate it, but a lot of people will love it, too. That being the case, it must have some merit, right?’

I was wowed at first by its first appearance in the video introduction at the keynote, but my opinion of it has steadily fallen since then. I would describe my overall feeling on it as ‘sinking’. I don’t hate it; it hasn’t polarised me. But it makes me worry.

Since Tim Cook took over, I haven’t doubted that he’s the person for the job or that Apple would continue being Apple. I found people’s claims of lack of innovation to be ridiculous–nothing more than trying to scare up some controversy for the sake of page views and drama. But this is the first thing that’s starting to chip away at my confidence.

I’ve seen so many quick mockups on Twitter in the past week that look so much better than what Apple is actually putting out. And that shouldn’t happen. Just add a little more depth, some better colour choices, some shadows, and it makes a huge difference. Why are some random people on the internet able to do this, when Apple apparently can’t? This is not supposed to happen. I don’t understand why it’s happening.

Yes, it’s a beta, but more than that, it’s also a huge marketing push–much more than it is a beta, considering most people hearing about this aren’t developers. Just go look at apple.com right now if you don’t think Apple is 100% committed to this design at this point.

In a word: it looks unfinished. It looks like not enough time was spent thinking this through, and looking at it every day. Maybe I’ll get used to it, and change my mind after I stare at it long enough. Maybe not.

My hope is that this isn’t anywhere near the final design, and that it will get a lot better before the final release this fall. My fear is that it won’t change much between now and then.

Automatic photo organisation

Yes. I need this.

Siri

From what they’ve shown, it seems barely improved at all. Not good. Siri is so far behind what Google provides. Apple isn’t taking this seriously. Very frustrating.

Game Center

No more green felt. I’ll take it.

Made-For-iOS Game Controllers

Barely mentioned, but I’m excited about this. It could totally change gaming on iOS and bring console-style games to the platform. A lot of games simply do not work without physical buttons, and I like to play those types of games. I’d love to play them on my iDevices.

And it’s only one logical step away from playing games directly on Apple TV: If you can play a game with a separate bluetooth controller on your iPhone, which is sending the picture (16:9) and sound to your Apple TV via AirPlay–why even involve the iPhone in this at all?

Of course, the App Store Games section is currently dominated by cheap, exploitative in-app-purchase junk. This precludes the type of games I’m hoping for just as much as the current lack of physical buttons. We’ll see, I guess.

iOS In The Car

I use my iPhone in the car. Can I use this car-optimised UI without buying a new car?

…Well, why the hell not?

iTunes Radio

Pandora’s algorithm is really good. Rdio and Spotify don’t come close. I’ll give this a try–why not?–I’m already paying for iTunes Match.

It has Song History, a feature Pandora has desperately needed since forever. Pandora doesn’t seem interested in improving their product lately.

iCloud Keychain

Could Apple really have just solved The Password Problem? It’s too early to say for sure, but… it seems like they might have.

Even if I somehow lose access to iCloud or the Keychain breaks in some way, as long as I still have access to my email (which isn’t iCloud, for me), I’m never more than a password reset away from access to most sites, so there seems to be no real risk, and everything to gain. Never having to think about passwords again… that’s quite the dream.

OS X McCain

I was expecting less than what we got, so I was happy.

I’m most excited about the improved dictation, which works offline and shows words as you speak them (doesn’t iOS need this, too?). I have Dragon Dictate, but I never use it because the UI is so horrible. The dictation built-in to Mountain Lion is pretty good and works everywhere, with the exception of these two issues.

I have never been comfortable using multiple monitors–on any operating system, and I’ve tried them all–but the new support for it in this looks good enough that I may actually give it another try.

The name certainly isn’t as fun as the cats. I don’t hate it; it just doesn’t really do anything for me.

iWork for the web

During the presentation, I kept waiting for them to acknowledge that the possibility exists that someone, somewhere, might actually want to work on a document IN COLLABORATION WITH OTHER HUMAN BEINGS. …It didn’t happen. Nope, we’ll all continue to be stuck emailing files back and forth forever, apparently!

It seems like such a frustratingly obvious step away from being a viable Google Docs competitor.

But after thinking about it for a few minutes, what it’s really designed to compete with is Microsoft Office. Yes, iWork for iOS reads Office formats, but nobody really wants to switch back and forth between it and Office all day. iWork for the web is for people who own a Windows PC and an iPhone, but no Mac. These people might only be willing to buy iWork on iOS if they can also use it on their computer. Smart.

Did you happen to notice that the long-rumoured Office for iPhone was suddenly released mere days after this announcement, on a Friday? Huh.

Craig Federighi

This guy was awesome. I would call him equal to Steve Jobs in presenting ability. Just thought that bore mentioning.

Designed by Apple Ad Campaign

I was hoping this would just be a one-off video for the keynote, but it appears not. They’re really going to be pushing this hard. I don’t like it.

I always thought of ‘Designed by Apple in California’ as a nuance, a finishing touch, a small delight for you to find, hidden away where you least expected it; in the same way as the not-quite-circular rounded corners, or the feel of the metal and glass against your fingertips, or the solidity, balance and perfect distribution of weight, or any other of a thousand tiny details that most people would never notice but were just waiting there for you to discover over the time you spend with the product. In a word, it was: subtle.

An ad campaign–any ad campaign, no matter how tastefully executed–is not.

AT&T's GoPhone Prepaid Brand to Gain iPhone and LTE/HSPA+ Support

AT&T’s GoPhone Prepaid Brand to Gain iPhone and LTE/HSPA+ Support

I’m glad to see T-Mobile is forcing some changes at the other carriers. Maybe if AT&T ever starts being proactive instead of reactive, then we’ll talk again.

Yahoo's great new weather app

Yahoo’s great new weather app

It combines weather data with user-uploaded photos from Flickr. Marissa Meyer gets it.

What’s remarkable about this is that someone in Yahoo had a good idea like this, and they were given the resources to build it and ship it. This sounds simple, not something that should be worthy of note–it should just be the way all companies work–but they don’t. If you’ve ever worked at a company anywhere near the size of Yahoo, then you know about the politics and bureaucracy that come with the experience, and the stifling effect that can have.

Indeed, before Meyer became CEO, when was the last time we saw anything like this out of Yahoo? But since she arrived, we’ve had the great Flickr app update, and now this. My only wish would be: More like this, faster. But I can see why they can’t rush, or the high level of quality that Yahoo is slowly-but-surely building could quickly unravel, from the clamour of too many dissenting voices. I suspect Meyer is keeping the teams small and focused, for good reason.

This sort of thing makes me feel good, not just about Yahoo, but about the software business in general.

Google Maps for iOS is broken in a fairly major way, after a recent update

Google Maps for iOS is broken in a fairly major way, after a recent update

After Apple Maps took me to the wrong place once or twice, I switched to using Google Maps exclusively. But I noticed it’s been behaving very strangely recently, relating to automatic screen dimming. But before I explain the issue, some background is necessary.

All about Auto-Lock

iOS has a feature officially referred to as ‘Auto-Lock’, which really is just a fancy way of saying the screen will turn off automatically after a period of time of not interacting with it. You can configure the amount of time it takes before this happens in Settings > General.

It’s worth noting, for reasons that will become clear, that Auto-Lock behaves differently when the device is connected to power (e.g., my car charger), compared to when it is on battery. On battery, the screen will turn completely off after the Auto-Lock interval has elapsed, and the only way to turn it on again is to push either the home button or the sleep/wake button; but when connected to power, the screen will only turn most of the way off, and can be turned all the way on again simply by touching any part of the screen. Most importantly, in this latter case, touching the screen does not send any touch events to the app which is visible on the screen; you could have put your finger right on top of a button, but the app would not know that you had touched the button while the screen was dimmed. This makes sense, because in the dimmed state, you may not be able to clearly see where the buttons and other controls are placed, so it would otherwise be easy to interact with something unintentionally.

Apps can temporarily override the Auto-Lock setting in order to force the screen to stay on for as long as they want. This is usually accomplished with UIApplication -setIdleTimerDisabled:. Regardless of what an app does with this setting, it the operating system restores it back to the standard behaviour once the user returns to the home screen or switches to another app.

Previously, both Apple Maps and Google Maps would override Auto-Lock while navigation was in progress (by setting the value to YES), but restore it after navigation ends (by setting the value back to its default, NO). In other words, simply having the app open was not enough to keep the screen on; you actually had to be in the middle of receiving directions. This is a sensible trade-off between battery life and providing the user with essential information when necessary.

What Google broke, and how they broke it

As of the most recent Google Maps update, the screen now dims automatically, several seconds after the app has provided a direction, in cases when there are no future directions planned for some amount of time. The difference here compared to what I described above is that instead of using the time interval since the last user interaction, Google Maps uses a combination of the time interval since the last direction and the time interval until the next future direction, to determine when to dim the screen.

This is in fact not iOS’s Auto-Lock feature in action; one reason you can tell is that, contrary to how Auto-Lock works, touching somewhere on the screen while it is dimmed in Google Maps does result in a touch event being sent to and reacted to by the app. One likely result of this is disabling location tracking, which is what happens if you touch anywhere on the map (i.e., most of the screen) while the app is in the middle of giving you directions. This is extremely inconvenient: the map no longer shows your current location, but instead is frozen at the location where you happened to be whenever you last touched it, which is almost certainly not what you wanted when you were in the middle of looking at directions for how to get someplace.

Most likely, Google Maps is using the UIScreen brightness property to force the screen to dim after a time interval of its choosing, rather than allowing iOS to use the system-wide configured Auto-Lock interval. This is probably because of the app’s intention to brighten the screen again in anticipation of the next direction coming up; indeed, the way they apparently implemented it is the only way I can think of that it would even be possible to accomplish this, since there is no API (as far as I’m aware) to allow an app to bring the device out of an Auto-Locked state. Moreover, the screen brightness setting, being an entirely different mechanism than Auto-Lock, does nothing to prevent user interaction with UI controls.

In short, Google Maps prevents the device from going into Auto-Lock, but then implements its own feature which is similar in some ways to Auto-Lock, but not the same.

It gets worse. Most of the time, touching the screen after Google Maps dims it, in addition to cancelling location tracking and making you curse in frustration, restores the screen brightness to its original level. But sometimes, it doesn’t. Again, because the operating system’s own Auto-Lock feature is not being used here, it is up to Google Maps to set the UIScreen brightness back up to the level that it was previously at before it was dimmed. But it sometimes fails to do that, in which case you can tap the screen all you want, but it will never go back to being visible. In fact, since UIScreen brightness makes the change system-wide (the same as if the user had changed it in Settings), even pressing the home button to return to the home screen, or switching to a different app, will not fix the screen brightness! The contents of the screen will remain nearly invisible until you press the sleep/wake button to turn the screen completely off, and then press sleep/wake or home to turn it on again, which for some reason sets the device back to a reasonable brightness level (perhaps in some way related to the Automatic Brightness setting Edit: Explained here).

Need I explain that when you are in the midst of trying to drive a car, this is not really a good thing to have to be fiddling with?

Thinking about how I would implement this as a programmer: Before dimming the screen, I would copy the value of UIScreen brightness into a temporary variable, and then when it was time to brighten the screen again, I would copy that temporary variable back into UIScreen brightness. Fairly simple. But it’s easy (for most programmers) to see how this approach could go wrong: If I somehow accidentally copy the value of UIScreen brightness into the temporary variable when the screen was already dimmed, then the original brightness value would be lost; and every time the user or the app tried to restore the screen to its original brightness value, it would just be set to the dimmed value instead, every time, indefinitely. This could happen in the event of a race condition, possibly resulting from an event firing more times than expected in quick succession, or through unsafe use of multithreading. Although this is only my speculation, I have seen similar bugs enough times that this would be one of the first things I would look for if I were trying to debug it.

Sweet road to somewhere else

So, what can we learn from this? Typically, it is a really bad idea to try to re-implement operating system functionality from scratch at the application level, unless you have a really, really good reason. The reason is that your implementation is likely to miss subtleties that users depend on, and introduce bugs or other discrepancies that are not present in the operating system implementation. In the best case, it ‘feels wrong’ in ways that users notice intuitively but are unable to articulate precisely. In the worst case, it fails spectacularly due to a complex condition which the operating system developers anticipated and you, an app developer with much different sorts of concerns on your mind, did not. Which is exactly what happened here.

Although, it’s not really surprising that this was attempted, considering the app in question. Google Maps uses entirely custom user-interface widgets, too. It’s Not Invented Here from the ground up. This sort of design philosophy has a tendency to pervade throughout. In other words: Google aren’t trying to make a well-behaved iOS app, but instead, an experience unlike anything else on your iPhone. Well… I guess in that respect, they’ve succeeded.

What I can’t figure out is why it was so gosh-darned important to have the screen dim and brighten according to the timing of the directions. Why not just leave the screen on all the time while directions are up, like the previous version did, and like Apple Maps continues to do? I suppose there is an argument to be made about battery life, but even then, the obvious counter would be that this should only be enabled when device is UIDeviceBatteryStateUnplugged.

But even then, I’m not sure the trade-off is worth it. I frequently glance over at the screen while driving in order to see how far it is to the next exit or how long it will be until I arrive. As long as that information is always visible, it’s not substantially different from glancing at the speedometer or gas level from time to time. However, having to tap on the screen every time I want to see the map is an extra unnecessary use of my motor skills, which makes it an unnecessary distraction, and that makes it dangerous. I daresay that, even if I didn’t have a car charger, running down the battery a little bit in exchange for a safer driving experience would be the right choice to make, don’t you think?

The simplest explanation might simply be that they were trying to mimic the behaviour of the Android version of Google Maps, which follows the same dimming and brightening pattern, but which likely has a very different system for handling these sorts of things. I’m really going out on a limb here, but: It’s easy to imagine a non-technical product manager making this decision without understanding its ramifications, and then the developers having to do it because that’s the food chain. Then again, this is Google we’re talking about, so in theory there shouldn’t be any such thing as a ‘non-technical’ person. I wouldn’t know.

Have I reached the party to whom I am speaking?

The linked discussion thread does, remarkably, feature a few responses from a Google employee. The first is your standard impersonal brush-off in the form of your-feedback-is-important-to-us (uh-huh). A more recent response makes an oblique reference to ‘optimizing’, without actually admitting the existence of a problem; but perhaps, this may be taken to indicate that someone somewhere is working on something which might hopefully be relevant to the issue at hand. This kind of exchange is typical of what happens when the people who actually understand what’s going on are not the people who are allowed to talk to you. On the other hand, Google is legendary for their lack of end-user support, so the fact that there is any kind of response at all is, perhaps, a step in the right direction. Still, the fact that the app has remained broken for so long (over a month as of writing) is very frustrating. One would expect better from a smaller company that lives or dies based on the strength of their product, but Google are long since big enough for this sort of thing not to matter terribly much to them.

Meanwhile, I’ve been forced to give Apple Maps another try, seeing as how Google Maps is pretty much unusable for me in this state. So far, the Apple Maps data actually seems not so bad, and of course, the UI has always been much better than Google Maps. So, thanks, Google, for… [puts on sunglasses] showing me the way?

Google is forking WebKit

Google is forking WebKit

I honestly have no idea what Apple was thinking with the WebKit2 multi-process model. When a Chrome tab crashes, it’s isolated to that one tab. When a Safari tab crashes, it takes down all of the other tabs with it. This is better than the WebKit1 behaviour of taking down the entire browser UI, but still… kind of missing the point, isn’t it? What good is the browser UI if none of the tabs are working?

At first, I thought maybe this was just a limitation in the initial version of Safari that shipped right after WebKit2 was released, and that it would quickly improve to be more like Chrome. But no. Nearly three years later, Safari still has the same problem, and I still see it happen several times a week¹.

Not only is this multi-process model worse than what Chrome had already been doing for years, but Apple wasn’t content to keep the code in Safari; they pushed it upstream into WebKit itself. What did they expect Google to do, switch to a worse model in Chrome in order to stay in line with WebKit?

Nah: Apple’s typical relationship to other companies is one of indifference. Most likely, Apple simply didn’t care what would happen as a result of increasing Google’s maintenance burden in this way. Well… this is what happens.

The entire internet is currently arguing over whether this is a good thing or a bad thing. LOL, internet. History will be the judge of that.

---

1. Usually this happens when I try to open an ‘Auto-Click’ bookmark, which I guess is Safari’s name for a tab group - it’s a bookmark folder that, when clicked, opens every bookmark simultaneously in separate tabs. ↩︎

Justin Williams on why iCloud Documents isn't that great either

Justin Williams on why iCloud Documents isn’t that great either

Reminds me of a fun story:

I was helping my sister set up her first iPhone, giving her advice on which things she should try. When we tried to turn on Notes for iCloud in Settings, it refused, with an error message stating that you must activate an iCloud Mail account before you can use Notes with iCloud. (She hadn’t done so because she wanted to keep using Gmail.)

Conclusion: Notes still uses IMAP for ‘iCloud’ syncing. It doesn’t use any of the three iCloud methods (key-value, documents, Core Data) that are available to third-party developers.¹

Justin’s customers probably wonder why he doesn’t just do with his notes app what the official Notes app does.

---

1. What a bizarre error message this must seem to someone not technical enough to guess the reason behind it! I helped her set up an @icloud.com email address that she would never use, and logged into the the iCloud web site (!) on a computer (!!!) so that it would automatically forward to Gmail, just in case someone ever did try to use it to send her email.

Bare Bones Software's Travails with iCloud Sync

Bare Bones Software’s Travails with iCloud Sync

I’ve been reading many complaints about iCloud for some time now, but this tidbit in particular was news to me:

And we find it noteworthy that, to the best of our knowledge, none of Apple’s currently shipping products on Mac OS X use iCloud to sync Core Data.

This is the one sole thing that every developer needs to know about iCloud right now. If only this had been common knowledge from the start. When we can see Apple themselves using it, then maybe it works… but certainly not before.

Apple's own words saying there are no hardware changes in the T-Mobile iPhone 5

Apple’s own words saying there are no hardware changes in the T-Mobile iPhone 5

This is to request a Class II Permissive Change for FCC ID: BCG-E2599A originally granted on 09/12/2012.

The change filed under this application is:

Change #1 – Adding UMTS Band IV (1700 MHz)

The addition of this UMTS band does not require any hardware changes to the approved device. There is no increase in the output power rating on this additional UMTS band and the Equipment Class remains the same. There are no other changes to the device.

Thanks to this poster on HowardForums.

Engadget, yesterday:

Apple affirmed to us that it’s not something that can be enabled via a simple software update for A1428 iPhone units already in circulation.

That’s not a direct quote from Apple, so it’s possible that Engadget misunderstood. However, assuming they didn’t: I wish PR people would learn the difference between ‘can’t’ and ‘won’t’.

More details about the T-Mobile iPhone 5 model

More details about the T-Mobile iPhone 5 model

Exact same hardware, just newer firmware. Even the same FCC ID, which I understand to mean that the FCC approval for the new bands retroactively applies to the original A1428 model. So why can’t I have this new firmware?

Apple Modifying iPhone 5 For T-Mobile Bands, Existing Devices Won't Have AWS Support

Apple Modifying iPhone 5 For T-Mobile Bands, Existing Devices Won’t Have AWS Support

I got my ‘existing device’ 3 months ago for use with T-Mobile. I got screwed.

Edit: I went and talked to the people at the Apple Store, and explained my discontent. They were friendly and helpful and I would recommend that anyone else in my position do the same. I’ll leave it at that.