Fixing a Slow, Unresponsive, Crashing iPad by Restoring from a Backup

My pertinent experience for this blog post is with an iPad (specifically a "the new iPad" which is generally referred to as the iPad 3) but I expect that these same results would be experienced for any iOS device (iPhone, iPod Touch, etc.). No matter what your device, if you have direct experience with using this technique with a device that is slow, unresponsive, and/or crashing, please post a comment about your experience (whether or not it helped, anything you did different, etc..) as that will very much help other readers.

My iPad had become very unreliable: it crashed (or perhaps I should say it spontaneously rebooted) regularly and when it was running, it was very slow to respond and at times downright unresponsive. The condition got worse and worse to the point where I simply couldn't use it because it just wouldn't respond for more than a few seconds before automatically restarting of its own accord.

The good news is that I was able to get my iPad back working like new by restoring it from a backup; the bad news is that by the time I tried this approach, it had become very hard because the first step in the process is to do a full backup of the device and that was very, very difficult because of my iPad's propensity for spontaneous reboots (but fortunately, with a lot of patience and persistence, I was able to get my iPad to backup).

Now, to be clear, when the iPad was merely painfully slow, I had considering doing a restore from a backup but, though it's easy and straightforward enough, doing a restore from a backup does take a bit of time and so I was reticent to do it without some indication that it might help. For that reason, I searched for guidance and I wasn't seeing people prominently pointing to doing a restore from backup as a troubleshooting step to try and so I didn't jump to do it; as I said already, that that proved costly because things go so bad that I almost couldn't successfully backup the iPad. And that then is the reason I'm writing this post: my hope is that when others search in the future for what to do about extremely slow-to-respond (and even entirely unresponsive) iPads, iPhones, and iPod Touches that crash and/or spontaneously and automatically reboot, they'll find this blog post and be encouraged to try restoring from a backup--and then of course I further hope that those who do try this approach will get the same results that I did: iOS devices that work like new. Please let me know in a comment if it does or doesn't work for you.

Now as to the process of doing a backup and restore: I won't get terribly detailed here because you can find the key details on Apple's Support website. But some notes:

  1. As I mentioned, this process is easy and straightforward but it does take some time; accordingly, make sure you'll be able to dedicate your device to this task for an extended period of time (in other words, don't expect to start this and be able to then take your iPhone somewhere a half hour later).
  2. To do the backup and restore, I used iTunes, not iCloud and I recommend that you do the same as it will certainly be faster. However, I don't know any reason that it wouldn't work using iCloud.
  3. Since what you're going to be doing is reinitializing your device from a backup, the first thing you need to do is backup your device so that the backup you're using for the reinitialization is current.
  4. Then you need to erase your device; this is mentioned but not actually described in the link above. You can do this via iTunes or you can do it directly on the device. I believe these are not entirely equivalent approaches but rather a factory reset via iTunes is a more extensive reset than merely erasing the content and settings directly on the device. I erased the content and settings directly on the device and that worked great for me. Note that the information on erasing the content and settings directly on the device does not mention turning off Find My iPad (or Find my iPhone or whatever is appropriate for your device) but to keep yourself out of trouble, I recommend turning that setting off. I turned it off prior to doing the backup (step 2 above) so that Find My iPad was completely out of the picture and couldn't cause any issues.
  5. Once your device has been erased/reset, you need to restore it from your backup. This part will take the longest. Fortunately, you can just let it run while you do other things.
  6. Once you've restored the backup, if all goes well, you should hopefully be in really good shape with your device! Specifically, your device should work like new. If it doesn't then unfortunately, you are probably dealing with issues that this approach won't fix. But if your device is working well at this point, you'll want to go back and turn on Find My iPad (or Find my iPhone or whatever is appropriate for your device). In addition, if you're an iCloud Keychain user, check the iCloud Keychain setting (it's on the same screen as the Find My iPad setting): I found that it was off and needed to be turned on (but fortunately, so far that's the only setting I've found unexpectedly changed during this process).

So what exactly was wrong with my iPad that the backup and restore appears to have rectified? Well, I had thought all the issues I was seeing (in addition to the poor performance and reliability, I had one app update that just wouldn't finish, leaving the app in a sort of state of limbo; I couldn't remove it by clicking and holding and hitting the "x" to delete it, I had to delete it via the Manage Storage area of the Usage area of the General area of the Settings app) were perhaps because some of my iPad's solid state storage had gone bad (and I was hoping that upon the backup and restore, iOS would avoid using the bad parts of the storage) but after the restore I noticed that my iPad gained around 3 GB of additional free space. Interestingly, when my iPad was misbehaving so badly, the amount of free space reported for the iPad in iTunes did not match the amount of free space reported by the iPhone itself; however, after the backup and restore, the 2 reports matched. I checked my iPhone, which doesn't have performance issues, and the report of its free space in iTunes matches what the iPhone itself reports. This all leads me to believe that mismatches (at least significant mismatches) between the reports of the free space provided by an iOS device and iTunes may be a good indicator that something is seriously amiss with that iOS device. Certainly in the case of my iPad it seems there were some serious "cobwebs" in there that were cleared out by the backup and restore. But regardless of exactly what was going on, I'm just glad it seems to be better now and I hope it stays that way!

As they say, your mileage may vary but I very much hope your results are as good as mine have been!

iOS Messages App Handles Replies to Group Messages Completely Wrong

Imagine if you will an email program in which Reply All is not only the default reply option but also the only reply option. Most annoying thing ever? Nope: a text application that works like that would be the most annoying thing ever--and as it happens, that's exactly how the iOS Messages application works: if you receive a group message (or group MMS or group SMS or group iMessage message or whatever else) on an iOS device, you can reply to all the recipients of that message but you cannot reply directly to only the sender*. I'm shocked that Apple--that anyone--would implement Reply All as the default for replying to a group message and I'm even more dumbfounded that this is the only reply option available: surely it is not unimaginable to Apple that some users might value the ability to reply back only to the sender of any given group message as a per-message option.** But hey: mistakes and bad decisions are made by all of us in life; it's not the end of the world! But it sure would be nice if it were fixed: Apple, please recognize the disaster that this implementation is (if by no other means than by way of all the annoying group text replies that your employees themselves surely receive as a result of this implementation) and fix it. My thanks!

*Workaround (albeit one that, as well as I can tell, pretty much no one ever uses): create a brand new message to only the sender. The keyword there is "workaround": it is not by any means a justification for not enabling a direct "reply to sender" functionality in the Messages app.

**There is apparently the ability to turn off group messages at a global level in iOS. This apparently prevents you from being able to send group messages; I do not know if it prevents you from receiving group messages or not. Going back to the earlier email analogy, this would be like an email program that won't let you put more than a single recipient on any given email and potentially like an email program that won't let you receive emails unless you're the only recipient on them.

Your Website + Mobile Devices

When I first got an iPhone in 2008, mobile websites weren't all that common--and this was perfectly fine because the browser on an iPhone is very capable of working with "regular" websites (save those using Flash, of course). But in the time since, mobile websites have become all the rage. This is a very good thing as mobile-optimized websites are certainly more convenient on mobile devices than are sites that are designed for desktop browsers. But the vast majority of mobile-optimized websites only present a fraction of the content of the full website. So what's a visitor to do if he/she wants to get content that's on the full website but isn't on the mobile-optimized site (or, due simply to personal preference, just wants to use the full website on his/her mobile device)? The obvious answer is "visit the full website" but that's where things get tricky: it has been my experience that more frequently than not, mobile-optimized sites "trap" you and disallow you from getting to the full site.

Trapped on a mobile site--how does this happen? Well, let's talk about how you get there in the first place: you don't go to something like mobile.mysite.com, do you? No, you just go to www.mysite.com just like you would on your computer; either that directly presents mobile content to you or it redirects you somewhere like mobile.mysite.com. How does the redirection happen? The site is developed such that the User-Agent value in the request header is inspected and when it is determined that the value provided corresponds to a mobile browser, the site serves up the mobile content or redirects you to the mobile site. You're probably then starting to see the "how" of getting trapped on a mobile site: because the site always does this header inspection, you always go the mobile site, no matter how hard you try to get to the full site.

Trapped on a mobile site--why does this happen? This is a bit more of a complex question. The simple answer is the "how" answer. But why are sites developed this way to begin with? The intent is good: referencing back to the first paragraph, mobile-optimized websites are certainly more convenient on mobile devices and so site developers and owners want to give you the most convenient content for your device. But what so many of these site developers and owners are missing is the other things I said in the first paragraph: there's (generally) content on their full site users might want to access plus some users might just simply prefer to use the full site, even on a mobile device. Look, it's your site and you can do what you want. But if what you want is to serve your site's visitors in the way they like best, don't trap them in your mobile site. It appears that many mobile-optimized sites don't even consider this: they don't give you a link to get to the full site and, due to the aforementioned User-Agent request header analysis, they trap you in the mobile site no matter how hard you try to get to the full site. But there's another class of mobile-optimized sites that trap you and these are in a sense far more discouraging: the sites that do give you a link to the full site--but don't bother to test that it actually works. This is discouraging because it starts with a greater understanding as compared to the other class of sites that trap you--specifically, the understanding that site visitors might want to get to content on the full site--it's just not followed through effectively and as a result, it's vastly more frustrating because they leave you hitting their "visit full site" button in futility, looking like a fool. And this is by no means rare--I see this all the time. Folks, you have to test this stuff! Some of you probably think you do: but using an emulator/simulator isn't sufficient (clearly!). I understand: it's hard to test mobile sites properly because you have to actually use a mobile device and that's a pain. But whipping out a mobile device and pressing the "visit full site" button on your site, isn't all that difficult, is it?

Testing is always mandatory, of course, but testing something broken is only going to prove to you it's broken--and if your site always inspects the User-Agent request header and serves the mobile content or redirects to the mobile site, your site is broken (in regards to allowing users to get to your full site). So if you're inspecting the User-Agent request header and serving the mobile content or redirecting to the mobile site in all circumstances, you don't need to test: first you need to make some code changes (and then you need to test those). If you don't have a "visit full site" link on your mobile site, this is complicated--how then do you know if the user wants to be on the mobile site or the full site? Serving the mobile site to mobile browsers by default and providing a "visit full site" link is the best approach. And if you're doing that then the code changes you need to make are to implement a system whereby if the user actually clicks that link, it supersedes the action taken to supply the mobile content based on the User-Agent request header. There are lots of approaches you can take for this but make sure whatever you do, it's permanent, at least for the duration of the user's session. That means you can't simply add something like a URL parameter of "fullsite=true" and expect that to be good enough because then when the user actually clicks on a link within the full site, he/she will be right back to mobile site. Using a URL parameter like "fullsite=true" is a good idea but you need to implement a system to allow the user to stay on the full site until he/she indicates he/she wants to get back to the mobile site (and, by the way, just as it is the best approach to give users a "visit full site" link on the mobile site, you need to give mobile users on the full site a "visit mobile site" link so they don't end up trapped in your full site). You can do this however you see fit--dynamically add something like "fullsite=true" to all the full site URLs, use a cookie variable that you inspect on every request, whatever you want--but be sure you do something or you're only going to create an even more frustrating experience than if you prevent the user from visiting the full site to begin with (and yes, I've seen this issue too).

Bear in mind that you're not in the clear here just because you're only providing the content to software that someone else developed: just today I was looking at a Wordpress site and while it provided a "visit full site" link, even when I clicked on it, I still ended up redirected back to the mobile site. In fact, experiencing this issue in such a widely used system as Wordpress was the catalyst for me to write this post. I guess if you've made these same mistakes as a developer you can console yourself with the fact that even such well-known software has this issue (or at least did as of whatever version it was that was used by the site I was on).

I know I sound crotchety here but a) I guess I am, sorry--I'm just truly flabbergasted as to how often this issue occurs b) seriously, I run into this issue all. the. time. c) did I mention that I see this frequently? and d) I really am trying to help (it took a long time to write this--I didn't do it complain, I did it to shed light on the issue so readers will get this right on their sites).

2012-01-23 UPDATE: I was hoping this post would generate more views, comments, and general traction that it apparently has. I guess it's that I don't have a good mechanism for socializing it properly. But please help me out: if you read this post and agree with it, send the URL to offending sites (via the Contact Us page or whatever)!

Getting Started with iPhone Development

My CFUnited presentation "iPhone Apps + Adobe ColdFusion," is about so much more than just using iPhone Apps and Adobe ColdFusion together! It's a really good place to start when you're looking to get into iPhone development, regardless of whether or not you're interested in making calls to a remote ColdFusion server. Certainly there is great information in the presentation for anyone who wants to make calls to a remote server, particularly a ColdFusion server, but you don't have to be interested in making remote calls from your iPhone apps to find the information in the presentation useful. So check it out! The related link for this blog post gives the link to my blog post "iPhone Apps + Adobe ColdFusion" from Friday containing links to the presentation in PDF format and to the code resources in a ZIP file.

iPhone Apps + Adobe ColdFusion

I'm presenting "iPhone Apps + Adobe ColdFusion" right now (well, right now as this post is going live anyway). And in this post, I am making the PDF version of my presentation file available via this link (note: the file location and link may change in the future but on this post on my blog itself the link will always be kept current).

UPDATE: I've been asked for my code samples from the presentation; you can find them here. To use them with NimbleKit, you'll need to create a new NimbleKit project in Xcode then drop these resources into wherever it is that you put the NimbleKit project; you'll need to overwrite the project's main.html file with this one. Note that the sayHello.cfc and sayHello.cfm files are not needed for your NimbleKit project; they are included so you can see what they do and so that you can deploy them to your own web server (of course, in that situation you'll need to change the NimbleKit code to make its calls to the server where you put the files).

Flash Player on Mobile Devices

I'm at CFUnited. If you're not here, we miss you!

Last night I attended the Birds of a Feather session (for those not familiar, this is a session that is a bit more of an open forum than it is a presentation) on iPhone development and those present asked me lots of questions about if and when Flash Player will be on the iPhone. That's outside my Adobe arena so I didn't have great answers for them (though I'm relatively certain that even if I did have great answers, I wouldn't have been authorized to share them). But I did do some asking and some research and so I give you:

The official(ish) statement:

We would like to work with Apple to bring Flash to the iPhone, meanwhile we continue to work towards bringing the full Flash Player to Symbian, Windows Mobile, Android and other smartphones enabling a more complete web experience.

Now, as I know that's not particularly enlightening, here are some blog posts I ran across which you may find of interest:

Make Sure USB Connection Not Interrupted When Updating iPhone

I just plugged my iPhone into my MacBook Pro via USB and was immediately informed that there was a new version of the iPhone software available and I was asked if I wanted to install that software. I clicked yes and the process started. While it was doing its thing, I moved over into my Windows XP instance running in VMWare Fusion. Well, part of the process of updating the iPhone involved the iPhone restarting and when it restarted, because I was using VMWare Fusion, VMWare Fusion grabbed the USB connection and this completely hosed the iPhone. Let me be clear: it didn't just mess up the update, it hosed the iPhone--meaning it wouldn't work at all. It isn't that the iPhone connecting to the Windows XP instance in VMWare Fusion hoses the iPhone inherently; in fact, in a normal circumstance, connecting the iPhone to the Windows XP instance in VMWare Fusion would be no problem at all. What is a problem, however, is the iPhone losing the connection to iTunes in the middle of the update process.

So my only choice was to restore the iPhone to factory settings and from there to restore the phone's settings from a backup. I'm not sure that before beginning the update iTunes bothers to do a backup of your iPhone (if it doesn't, it sure should and I recommend that you do your own backup before letting iTunes do a software update), but in any case it seems I was able to restore from a recent enough backup that I didn't lose much, if anything. Because I'm using over-the-air Exchange synchronization, my most imporant data (Contacts, Calendar, Email) are not synced via iTunes so fortunately there was no risk of losing any of that data.

But even though in the end I lost little to nothing, the whole process of restoring is long and a rather big pain in the butt. So for that reason alone, I highly recommend avoiding it at all costs--and that means making sure the USB connection between your machine and your iPhone is not interrupted when you're updating the iPhone's software!

Incidentally, even after restoring from a backup, I had to completely re-do my settings for my Adobe Exchange account (I'm guessing that the certificate for the phone can't be backed up). Also, although my setting for syncing an image directory on the MacBook Pro to the iPhone was still present, the image in the directory (I only have 1 image in that directory) was not on the iPhone until I did another sync and, because I use that image as my Wallpaper, I had to reset my Wallpaper after I synced the image back to the iPhone.

Emulating Task Lists on iPhone with Calendars

Without any implication that it's at all okay that Apple hasn't bothered to implement a Task List application on the iPhone, here's a method I thought up to emulate task lists using the Calendar application:

  1. In your computer's Exchange client (you can't do it on the iPhone; you have to use Outlook or Entourage or whatever on your computer), create a new sub-directory of your current Calendar (and make sure you set it to be of the Calendar type). Call it Tasks.
  2. Repeat the above step with the exception that this time call the sub-directory Completed Tasks.

Pretty simple, huh? So how do you use it? Well, when you enter the Calendar application on the iPhone, you'll be able to view the calendars for your Exchange account (when you're in the Calendar app looking at the main view, you should see in the upper left-hand corner a button labeled "Calendars" that will take you to view the calendars). You'll see that you can view just one calendar or all of your calendars; as you may also know, your main view choices include List--so you can choose to view the "Tasks" calendar and view it as a List, very much as you would expect to view tasks in a Task List application. And of course you add a new task by creating a new calendar item in the Tasks calendar.

Unfortunately, there's no way to designate a calendar item as complete; that's why I use the second calendar called Completed Tasks. But there's one more unfortunate thing (referenced in my iPhone 2.0 Insights blog post) that comes into play here: you can't move calendar items from one calendar to another on the iPhone. Totally inexplicable pain in the butt, but it isn't the end of the world to just move the items over on your computer (if you don't care about completed tasks, you can always just delete them on either the iPhone or your computer and not worry about the Completed Tasks calendar).

Using 2 directories and calling them "Tasks" and "Completed Tasks" is just my choice: obviously, you can change the names of the calendar sub-directories as you see fit and you can create more than just 2 if you'd like.

Note: this definitely works with iPhone synched up over the air with Exchange; it may or may not work in other configurations (all I can say is that prior to synching over the air with Exchange, I was not aware of any way to synch with multiple calendars nor to view multiple calendars on the iPhone).

Note: I am aware that there are 3rd party Task List applications available for iPhone, however, given that none of those are able to synch with Exchange, they do not suit my purposes. I also don't know if any of those can alert me like calendars items can.

iPhone 2.0 Insights

UPDATE 7/13/2009: The iPhone 3.0 Firmware is now out and it has a bunch of great new feature. Unfortunately, many of the things I felt were lacking in the iPhone 2.0 Firmware were not addressed. But one was and so I've updated the information below accordingly. Look for the "UPDATE" tags.

I thought some of you might be considering iPhone 2.0 and so I thought I'd post these insights (to add, I'm sure, to all those insights others have posted of late). For those who like executive summaries, here you go: I recommend iPhone 2.0.

I am using earlier generation hardware with the new 2.0 firmware so I can't review 3G for you or any other new features of the iPhone 2.0 hardware.

Major Pros of 2.0 Firmware:

  1. Data push. This works really well for calendar, contacts, and email. I've never had a phone with data push before so I can't make comparisons (my main point of comparison is to Palm and synching locally to Outlook). My favorite features are multi-contacts groups and multi-calendars--I have always wanted this in order to keep my business contacts separate from my personal contacts and to keep my business calendar items separate from my personal calendar items. In iPhone Contacts and Calendar you can choose to view all or just one particular contacts group or calendar, respectively.
  2. Directory lookup. This is the other part of Exchange integration: you can look up any contact in the Adobe directory.
  3. Extensibility via add-on apps obtainable with the App Store application. There are numerous useful apps available, many of which are free.

There are also existing pros like the browser, the Google Maps app, the solid camera, the in-phone voice mail control, and the chat-style text message conversation threads.

Major Cons of 2.0 Firmware:

  1. If you set the view of Contacts or Calendar to a particular contacts group or calendar, respectively, then exit the application, the view sometimes changes to all when you re-launch the application.
  2. While there is a way to set the default calendar for new calendar items and there is a way to set the calendar for a new calendar item when it is created, there is no way to move a contact or calendar from one group to another and there is no way to set the default contact group for new contacts and there is no way to set the contact group for a contact when it is created (instead it automatically goes into the contact group you're viewing or, if you're viewing all, it goes into the top-level Contacts group).
  3. There is no support for Tasks. There are some 3rd party apps available, some even free, but these do not synch with Exchange Tasks.
  4. There is no copy and paste. Word has it that Apple just doesn't see this as a priority. Unfathomable. UPDATE: Copy and paste is now present in the 3.0 Firmware!
  5. There is no "quick text" for SMS...and since there's no copy and paste, there's absolutely no way to send a text message without typing the whole thing in. UPDATE: Well, at least you can copy and paste in 3.0 Firmware, which is better than nothing.
  6. No trial period for add-on apps that cost money (ditto for add-on apps that are free, but of course that's a moot point).
  7. No ability to configure how many recent calls are stored. You're stuck with the default, which is something like 50 or 100. I would like to see a configurable setting for number of recent calls displayed and I would like for one of the options to be "all" so that there is no limit. This device has gobs and gobs of storage space--it has 1000 times the storage space of my Kyocera QCP-6035 that I bought in 2001 and that device could be configured to store up to 999 recent calls with no problem--so storing an effectively limitless amount of recent call information should not be an issue--and just to be safe, it could be programmed so that if space did fill up, the last item went out every time a new item needed to come in.
  8. No ability to replicate contacts, calendar items, etc. This would be really useful, particularly on calendar items. When you go to the dentist, do you make your next appointment? I think most of us do. And so you put it immediately into your iPhone. Well, you're standing there looking at the item that got you there that day; wouldn't it be nice to copy it and just change the date and time for the new appointment? Obviously the dentist is just one of many examples of how useful this functionality would be.

BlogCFC was created by Raymond Camden. This blog is running version 5.9.002. Contact Blog Owner