iPhone migration: restore from backup or setup from scratch?

In moving to my fifth iPhone I decided it was time to try a fresh install instead of transferring state from my previous one. Apple’s transfer process has always worked works seamlessly but that Star Trek-like transportation of your old phone to the new makes the new one seem, well a little less new somehow. Previously I would have feared losing something small but vital by not using the transfer process but with so much now synchronised between devices by iCloud, it seemed that the most painful and important items were covered. My willingness to experiment was also mitigated by the knowledge that if it all went wrong I could still re-install the new phone from my old backup.

Without the need to wait for a gigabyte of data to be transferred to the new phone, I was up and running very quickly and enjoyed seeing what differences there are between an out-of-the box configuration and my own. With the exception of turning off the sound and vibration notifications for new email, I have customised very little to start with: I want to see if there are any settings or features I have previously overlooked because of some decision I made 7 years ago. Working through my list of apps and choosing to only reinstall those I know I have used recently was also enlightening—there were applications I had forgotten existed buried in never-opened folders, and including some that now crash on startup. I noticed others that are no longer being updated but the developers have instead issued a whole new app instead. I learned that the telltale sign for this is when you tap on the application in your “purchased” list and it fails to display anything about it.

Having chosen which apps would survive the migration and downloaded them all, the main pain point was having to re-authenticate in all of them. The reduced number of apps kept this manageable and I would guess about 50% enabled the use of iCloud Keychain which made it a two-tap process. Given the tedious and error prone nature of typing in a complex password onto a phone keyboard I am shocked that the other 50% do not enable this. Those apps which forced me to lookup and retype my password are certainly strong candidates for deletion if there is an alternative.1

By not restoring from backup, any applications that store state locally and not in the cloud would lose their data. I was a little worried about my Angry Birds progress but then realised I had not played the game in a very long time anyway, and so far I have discovered only one application which stores data I would like to keep. It is a free app and its paid for version supports data export, which seems fair enough. WhatsApp messages were restored from its own iCloud backup (which it performs nightly) but I did lose my SMS and iMessage history (going back to 2008). Recent iMessages are on my mac anyway and after reviewing the older messages they were all very temporally contextual—“I am here / outside, where are you?”—type stuff. It is noticeable how much longer messages have become recently, perhaps an inevitable consequence of removing the 160 character limit of SMS.

In conclusion, unless you have apps or games that depend on local data, setting up from scratch was not at all painful and it felt really good to have a spring clean. Deleting something always requires metal energy to assess its value, or downside of its loss, and with storage so cheap it is rarely worth the effort. Consequently we accumulate bits and bytes rather too easily, and sometimes a platform migration is a good moment to assess what is no longer required, and start afresh.

  1. Anecdotally, many of those which failed to implement keychain were companion apps from established non-digital companies, for example, airlines and hotel chains. Developers competing for users on the strength of their app alone were far more likely to have implemented it. [back]

Google Maps and iOS Background App Refresh

I am posting this to the web in case it helps anyone else trying to troubleshoot a similar problem.

Recently I noticed my iPhone’s battery was ending each day significantly lower than usual, causing me to have to charge it every night instead of every couple of days. At first I suspected the extra consumption was caused by communicating to my Pebble smart watch but quickly eliminated that possibility when turning the Pebble off for a day had no effect.

After some experimentation, the change that restored my battery usage to its previous norm was disabling background apps refresh for Google Maps. This was an application I had recently installed because it works very, very, nicely with the Pebble, sending turn-by-turn navigation directions to your wrist as you walk. This completely removes the need to take the phone out of its pocket every few minutes to double check that the road you just passed was not the one you were supposed to turn down! However I do not use it frequently enough to justify doubling my daily power consumption…

iPhone Voicemail Setup Problems (& Solution)

The first time you select the voicemail button your an iPhone, in typical Apple fashion, it offers to help you configure your voicemail. This was much nicer than the traditional voice prompts one normally has to navigate, but the final step (talking to the network) repeatedly failed for me. Google indicated that it might be necessary to manually activate the voicemail by calling 1750, but that did not work for me. O2 customer service suggested that turning the voicemail off then on again would help (1760 [send] then 1750 [send]) but the setup failed again.

The solution that eventually worked for me was to configure voicemail in the “old-fashioned” (“non-visual”?) manner by dialling 901 and then following the tedious voice prompts. Once this had completed, I retried the iPhone visual voicemail setup using the same PIN as I configured at the voice prompts, and it worked first time.

So is the iPhone any good?

As revealed in my previous post, I recently purchased an iPhone. The reason for this is that the Internet stopped working on my old phone, and since I needed a new portable Internet device anyway and the web being the iPhone’s forté, it seemed like the best choice for my requirements.

But is it any good as a phone? The answer is undoubtedly yes, but it’s not “great”… yet, a few more software updates ought to fix that. Missing features that, upon reflection, I never used on my old phone include voice dialling (I’m sure voice recognition systems are not tested on west country accents!) and video calling. The one feature that is sorely missing is a character counter in the SMS application, a horrendous omission now there are call plans without unlimited text messaging. The other feature that people talk about is the keyboard which is a joy to use—last week’s Heathrow Express post was written and edited entirely on the iPhone.

Debugging an iPhone

While a Mac usually “Just Works”, when it does encounter an error situation, OS X often emits a a very vague message that can make debugging a long-winded process. For example, suppose you have recently brought home a shiny new iPhone and upon connecting it to iTunes you receive: “Could not connect to iPhone because an unknown error occurred (0xE8000001)”.

According to the web, it seems the most common cause of this is connecting the iPhone via a USB hub instead of directly to the computer, but I had no USB hub. Also, most people were experiencing this as a transient fault after regularly and successfully synchronising their iPhone for some months, while mine was a new connection—all very perplexing.

Fortunately, OS X is really UNIX in disguise, and so while the user interface tries to only display friendly messages, the technical details are being logged in the same way as any other UNIX system, hence I checked /var/log/system.log:

Jul 16 12:45:05 yvaine [0x0-0x10010].com.apple.iTunesHelper[136]: MobileDevice: 
AMDevicePair: Could not mkdir /Users/ned21/Library/Lockdown: Permission denied
Jul 16 12:45:05 yvaine [0x0-0x10010].com.apple.iTunesHelper[136]: MobileDevice: 
store_dict_osx: Could not create /Users/ned21/Library/Lockdown/
6b90d8c839e8ec9e74d2dffce9a2e111daf84f7b.plist: No such file or directory
Jul 16 12:45:05 yvaine [0x0-0x10010].com.apple.iTunesHelper[136]: MobileDevice: 
AMDevicePair: Could not store pairing record at 
/Users/ned21/Library/Lockdown/6b90d8c839e8ec9e74d2dffce9a2e111daf84f7b.plist

Aha!—a simple case of “permission denied”. (Which, lets be honest, to a non-techie person would be no less cryptic than the message that the GUI actually displays.) This did present another mystery though since permissions on ~/Library look normal:

yvaine:~ ned21$ ls -ld Library/
drwx------+ 42 ned21  ned21  1428 22 Jun 10:34 Library/

except for that little + sign at the end of the permissions string. A quick check on another mac indicates that this is in fact not normal, and means that the directory has an extended ACL (this is the same convention as in Linux) but unlike Linux, OS X does not have getfacl(1) and setfacl(1) commands for viewing and manipulating ACLs—use “ls -le” instead.

yvaine:~ ned21$ ls -lde Library/
drwx------+ 42 ned21  ned21  1428 22 Jun 10:34 Library/
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
 1: group:everyone deny delete

I have no idea how these ACLs were added to my directory, but let’s wipe them out:

yvaine:~ ned21$ chmod -a# 1 Library/
yvaine:~ ned21$ chmod -a# 0 Library/
yvaine:~ ned21$ ls -lde Library/
drwx------  42 ned21  ned21  1428 22 Jun 10:34 Library/

And my iPhone worked like a charm.