Business Owner Stories

View Original

IT Problem-Solving for an iPhone Failure

Photo courtesy of pixabay.com

Apple makes excellent hardware and their software is very well designed and tested. Some would even say it is the best, but even the best can fail. I experienced such a failure after completing an “Update All” process on a large number of apps. I also decided to allow the operating system to do this unattended (overnight).

Now Apple would not have an “Update All” feature if it were not safe, would they? Nor would they allow such processes to take so long without recommending that this is done in the background or while the phone is not being used, would they? Apple verifies everything in its ecosystem, don’t they?

That was my assumption. That turned out to be a wrong one, and coming from the world of IT, that was a mistake, two mistakes, to be exact: updating many items at once and doing this unattended. I should have known better. Having neglected good habits, I needed to go back to what I knew: best IT practices.

The symptoms

When I logged into my phone the following morning, I immediately noticed that the keyboard response was delayed. Then I noticed that the entire phone was slow. After an hour of doing the usual reboot, restart and poking around, I also noticed that my phone was becoming extremely warm. Finally, my battery was draining very fast. This was all bad news.

It was obvious the phone was trying to churn through something and failing. In the IT world, the first suspicion is that a virus or malware application was the culprit. However, Apple iOS devices very rarely have issues that are much more common on desktop OSes. As a matter of fact, if you follow Apple’s basic processes, by doing regular OS updates, regular app updates, no jail-breaking, and following recommended security measures, this should not be an issue. And in this case, it was not.

I was now into hour two of my troubleshooting and nothing I had done up to that point seemed to fix the issue. It was clear something in the iPhone was continuing to stress the processor, slowing down everything, and wearing out my battery.

Regarding the latter, I also noticed that it was very uneven, sometimes the battery percentage would drop 10-15% instantly and then other times it would stop draining the battery. The processor though, was still running hot continuously, so even if the OS was doing its best on the battery at times, there was still a serious problem. It was running so hot that it was hard to hold.

Step one: Dealing with the Heat

Jim Hightower used to say: “if you want to clean out the swamp, you have to first get the hogs out of it.” What he meant is to deal with the most obvious issue first. For my phone that was the dealing with the heat. I could sit there all day and try to fix the other issues, but if my phone overheated, there would be nothing left to salvage.

In IT, heat is the by far the greatest enemy. I have spent many nights working to install temporary cooling solutions into server rooms during power or cooling system failures. Damage to systems from excessive heat is expensive, and a phone is not inexpensive either.

So, I decided to work on the phone in phases, then putting it in the refrigerator for short periods between the phases. Interestingly, when I did, not only did the phone cool off, but the processor also seemed to slow down, almost as if being in a cold dark place signaled to the phone that it was time to cool it, literally.

Step two: Slowing the Processing

Typically, the reason CPUs overheat when cooling is functioning properly is because they are working too hard. This is what happens when hobbyists overclock their CPUs to squeeze more performance out of them.

There is always a threshold at which point the system must stop to prevent an actual meltdown of the CPU in the computer. A well-designed computer will typically “crash” or stop the operating system before allowing a fire hazard to occur. It was therefore interesting that putting the phone in the fridge also seemed to slow the CPU.

This idea also led me to consider another possibility. The fridge is rather insulated. As a matter of fact, I remember reading that a fridge is the best place to try to outlast a house fire (I presume temporarily) or even a nuclear blast (I presume one that is far enough away). This means that a fridge does a decent job of blocking radiation, and, quite possibly communications.

If I stopped the various ways that the phone was communicating, maybe I could thereby also slow the CPU. Now a phone is a persistent little bugger when it comes to communicating. From Bluetooth to Cellular and everything in between, it has lots of ways to do so. It is designed to communicate at all costs, because after all, that is what it is supposed to do.

So, I shut down all the ways it communicated and sure enough, the CPU stopped working so hard. So, I had narrowed down that it was one (or perhaps more than one) of the communication apps that was the issue. Of course, almost all apps communicate in some way, even if it is just to secretly report back to the manufacturer what I am doing with that particular app.

What I was reasonably certain about at this point was that I was dealing with a bad app, one that communicates.

Step three: Taking Inventory

Another problem is that I have a lot of apps; my phone had a whopping 181 apps! I know that for some app collectors out there, that is not much, but for me, that was a lot. I actually had no idea I had that many. Wow. Now that the immediate issues of heat and processing where dealt with, it was time to take inventory of what we had.

I obviously do not really need that many apps. I decided to make a list of all of them and crossing out all the ones I would not need anymore. I also noted which ones I had paid for, which ones required a login, which ones I could re-install later, and which ones I could not identify at all.

When I was done, I was able to pare down the list to just 58 apps I absolutely did not want to get rid of. Of course, that did allow me to remove 123 apps. Now, FYI, removing apps is ordinarily simple, but I was working with a terribly slow phone, one that I had to keep putting in the fridge at regular intervals. I now had a very good list of apps on my phone. A nice spreadsheet to keep handy.

Step four: Keeping it Simple

From now on, I will be much more judicious in deciding what apps to install – just because it is free doesn’t mean I should have it. I am also realizing that money spent on some apps was just a waste. Good info to keep in mind.

One of the most important lessons from IT is to keep things simple. By installing all those apps, I had neglected that important lesson. Simplicity makes troubleshooting a lot easier – I only had 58 apps to worry about now.

Another plus was that many of the remaining apps were Apple apps, mostly the ones that come with the OS. While those were less likely to be the problematic one(s), I could not rule them out. Yes, Apple-designed apps can also have bugs, or perhaps more likely, have an issue with a non-Apple app that could be conflicting with it.

So, was my problem solved with just 58 apps left? Unfortunately, no. I had to go deeper and remove some of my remaining apps.

Step five: Go to the Backup

One big problem with my remaining apps is that they are also where I store much of the data that I need to keep safe. Everything from a contact management database, to sales records, to conversations I could not lose. Apple says that removing apps does not remove the data, but I was not going to rely on that promise. I had to remove more apps, but I needed to ensure the data was safe.

Fortunately, one IT habit I am extremely strict about is backups. I back up my phone locally on a weekly basis and I had backups on my computer. I could have backed up to the cloud as well, but I could write an entire article just on why I do not do that. Anyhow, I had backed up my phone to my computer, so I needed to check if I could access my backups before I started to delete more apps.

In order to access the computer, I had to communicate with it. But I had turned all that off. Sure enough, using an Apple Lightening cable to access the backups on my computer did not work. Ouch. Also, since my backups were a few days old, that would also restore the other 123 apps. Then again, removing them did not solve the problem, so there was a possibility none of those apps were the problem, either.

Consequently, Apple also offers a “wireless” link via Wi-Fi, but that still requires the Lightening cable to be plugged in and communicating with iTunes, so if any Apple folks are reading this: that’s not really a wireless solution, now is it? In my case, the cable connection was not being recognized at all, so no Wi-Fi connectivity either.

Of course, none of this mattered if I did not have access to the backups with my phone.

Step six: Duplicate Your Data

In IT when backups are not accessible, a panic mode sets in. Backups are usually a last resort after extensive troubleshooting. Not only is there a possibility that the troubleshooting was so thorough that stepping back from the current point may not be possible, but there is also the realization that data may be lost. When this happens, it is important to think outside the box.

I have had two situations at work where backups were not available after a catastrophic server failure. Both times, I was still able to recover the data, but it can become expensive. What I did was build a new server as identical to the defective one as possible, and then transferred the data physically – by moving the data drives to the new server. It was time-consuming and expensive, but it worked both times.

Now with phones, the situation is a bit different, especially Apple phones. Apple strictly enforces the mantra: that thou shalt not open thy Apple under any circumstance. Now I have opened lots of Apple devices, but phones are very tricky. Again, I needed an out-of-the-box solution, literally.

What I did was use another iOS device (an old phone with no phone number) and used Apple’s wireless transfer capability to essentially create an identical phone with all the same apps & data. Because I did not actually physically transfer the data between the two phones, I could not be sure that all my data was actually safe, but from what I could tell, things looked pretty good.

Step seven: Take the Leap of Faith

This last step occurs at different stages of a major computer failure depending on the conditions and the readiness of the tech who is working on it. With every crisis, there is point at which it becomes necessary to leap to whatever system we have repaired, replaced, or duplicated. It then becomes the primary system, while the other is completely repaired or replaced.

Knowing when that leap needs to be taken is something that can only come from experience – this is especially critical with systems that absolutely must work and/or must be up 24/7/365. In my 25 years of working in IT, I have always been lucky when taking that leap – I have never lost any data. Part of that success comes from fastidious preparation, long-term planning, and being a stickler for security – it was not always easy, especially when it came to justifying expenses, but at least I can say that I never lost any data.

I was equally lucky with the phones. When I switched over to the old phone, everything worked. There was also no lag, overheating, or battery issue. I now had a reliable duplicate and was ready to do a complete reset on the original phone.

Step Eight: Completing the Repairs


Once I had a duplicate phone to fall back on, I did a complete reset of the original phone. I restored everything to the defaults that are typical of a brand-new iPhone. I checked to see if it was working properly (it was) and then set it up like a new phone, connected it to iTunes, and restored my apps from backup. The phone is now as good as new.

I suppose I could have done the restore to defaults right from the beginning, but at what risk? What if I could not access my backups afterwards? I would have lost all my data, which would have been devastating. So, in order to do this properly (and I highly recommend everyone does it that way), I followed 8 careful steps that I have learned from my past career working in IT:

  1. Dealing with the heat

  2. Slowing the Processing

  3. Taking Inventory

  4. Keeping it Simple

  5. Go to the Backup

  6. Duplicate your data

  7. Take the Leap of Faith

  8. Completing the Repairs

Conclusion

In IT the most important thing is to be as prepared as possible. That said, failures happen and so do mistakes. I made two crucial mistakes in the beginning: I made too many changes (updates all the apps at once), and I allowed these to happen on their own (automatic updates). I also trusted in a company’s promises and reputation. This landed me in a heap of work, and it took me a whole day to repair a simple phone issue.

Yes, the issue itself was actually quite simple to fix, but doing it safely is a bit more work. Another way to look at it, I could have taken the leap of faith right away, but as a responsible IT person, I could not do that.

With every crisis there will be phases that do not work as expected, as it did for me when I could not access my backups. That is when it becomes necessary to consider solutions that are out-of-the-box or more creative. If that solution then does offer a way forward, it is then necessary to get to that point where you can return to the original path (for me that was to restore the data from backup).

I know this was a long article, but I hope it helps anyone who finds themselves in a crisis that does not seem to have an easy resolution. It may not be a failed iPhone, but the process has helped me many times, and hope it helps others too.