When an iOS update fails

After iOS 4.3 was released, I dutifully attached my iPhone 4 (running iOS 4.2.1) to iTunes and selected to Update. I wasn’t expecting any trouble. My iPhone had never been jailbroken or modified in any unauthorized way. I was running the latest version of iTunes. This was a completely mundane task. What could go wrong?

Apparently, quite a bit.

After successfully downloading the update file and initiating an install, an ominous message popped up in iTunes—informing me that the update had failed due to a 1013 error. Adding insult to injury, the message further noted that my iPhone was now in “recovery mode” and I would need to restore the iPhone to get it working again. Confirming this, the “Connect to iTunes” screen was glaring from the iPhone’s display.

Uh-oh. While I could see that my afternoon plans were now in jeopardy, I wasn’t yet concerned about the ultimate outcome. I would do the time-consuming restore and be on my way.

iTunes had different plans. After clicking to Restore, I wound up with the exact same 1013 error at the exact same point in the installation process. Now I was concerned.

It was time to check Apple’s support articles—notably the article that lists the various iOS alert messages and what they might mean. Here I learned the following:

“This error may be the result of the connection to gs.apple.com being blocked, redirected, or interrupted. Adjust your hosts file or security software to ensure that connections to gs.apple.com are not blocked.”

Here’s what this means: At least with more recent (iPhone 3GS and newer) iOS hardware, Apple requires that iTunes check in with its gs.apple.com server before permitting any update or install. From Apple’s perspective, the purpose of the check is to prevent installation of “unauthorized” iOS versions. If iTunes can’t reach the server to make the required check, you get the 1013 error. That’s what was happening to me.

At this point, I knew why this was happening—and was a bit embarrassed that I had not realized the cause right away. While I had never jailbroken this iPhone, I had experimented with jailbreaking other iOS devices I owned. In particular, mainly as part of research for an article I had written, I had attempted to downgrade the iOS version of an iPod touch. As I explain in more detail in the just cited article, this requires adding a line to the Mac’s host file (located in the /etc directory) to redirect iTunes from checking Apple’s gs.apple.com server to instead checking the Cydia server or a local TinyUmbrella server.

That is precisely what I had done. I thought I had remembered to remove the redirect line after I was finished with the article. Apparently, I had not. I’m not sure why I didn’t get this error when I had installed other recent iOS updates, but at least I knew why I was getting it now. After deleting the redirect line in the hosts file, I attempted to restore my iPhone one more time. Success.

What’s the moral of this story? I can imagine a few suggestions from readers, none of the them especially flattering to me.

One might be: “Serves you right. That’s what you get for messing around with jailbreaking. Don’t expect any sympathy from Apple.”

Another might be: “Read your own article. It clearly states you need to remove this file before attempting to update or restore in iTunes. You forgot. It’s not Apple’s fault.”

Points taken.

Still, I am not ready to accept the entire blame for my update hassles. Apple could do better as well.

First, as Apple indicates, there are potential causes for this problem that are not related to jailbreaking. So let’s not lay all of this on the jailbreaking doorstep.

Second, I fail to understand why Apple can’t offer more informative alert messages. Simply saying that you have a 1013 error is of no value to the typical user. At the very least, the message could include a link to the support article that gives the additional information. Otherwise, Apple sets up users to have no immediate recourse other than panic.

Finally, why have this error message pop up at the point in the update process where the iPhone has been erased and forced into recovery mode, requiring a time-consuming restore? Why not check for these errors before going down that one-way street? That way, the process could exit gracefully, with the iPhone not updated but at least still functioning.