Skip to content
FLAVIO COPES
flaviocopes.com
2026

How I investigated why my iPhone was running hot

By Flavio Copes

I used USB diagnostics, crash reports, and Xcode Instruments to investigate a hot iPhone, but the evidence did not reveal one clear cause.

~~~

My iPhone started running hot, even after I closed every app.

Closing apps did not help. That alone told me very little, because iOS system services continue working in the background.

I connected the iPhone to my Mac with USB and investigated.

Here is what I found.

A quick warning

The tools in this post can do much more than read diagnostics.

Some commands can restart the phone, change settings, or interact with running processes. I only used read-only commands.

Do not copy commands you do not understand. Back up your iPhone first.

Check that the Mac can see the iPhone

First, connect the iPhone with USB.

Unlock it and tap Trust This Computer if asked.

You can check the USB connection with:

system_profiler SPUSBDataType

Look for an iPhone entry in the output.

This only confirms the physical connection. It does not mean the diagnostic channel is ready.

Install pymobiledevice3

I used pymobiledevice3, an open source tool for communicating with iOS devices.

My advice is to install it in a virtual environment. This keeps it isolated from the rest of the system.

python3 -m venv iphone-tools
iphone-tools/bin/pip install pymobiledevice3

Now list the connected devices:

iphone-tools/bin/pymobiledevice3 usbmux list

The command should print the iPhone model and iOS version.

Be careful with this output. It can include device identifiers. Do not paste the full result in public.

Read the battery diagnostics

The simplest way to get a battery snapshot is:

iphone-tools/bin/pymobiledevice3 diagnostics battery single

The output is large. These were the values I cared about:

My battery was around 46.6°C while connected.

It was charging at roughly 11W, which could contribute to the heat. The battery had 426 cycles and about 94% of its original capacity.

I found no battery safety fault or charging fault.

This was useful. The battery looked healthy, but something was keeping the phone busy.

Look at historical resource reports

iOS creates diagnostic reports when a process uses too much CPU, memory, or disk.

You can list them with:

iphone-tools/bin/pymobiledevice3 crash ls \
  --remote-file / \
  --depth 3

Despite the crash name, this also lists resource-limit reports.

I found several reports named like this:

photoanalysisd.cpu_resource-2026-07-11-091228.ips

photoanalysisd is an Apple system service. It analyzes the Photos library for people, objects, scenes, and relationships.

Closing the Photos app does not stop it.

I copied only the matching reports to the Mac:

iphone-tools/bin/pymobiledevice3 crash pull reports \
  --match '^photoanalysisd.*cpu_resource.*\.ips$'

Do not pass the --erase option. That would remove reports from the phone.

The newest report showed the important line:

CPU: 90 seconds cpu time over 134 seconds (67% cpu average)

Now I had a strong lead.

Photos analysis had repeatedly exceeded the iOS CPU limit during the previous month.

Test Low Power Mode

iOS does not provide a switch for photoanalysisd.

Low Power Mode can defer background work, so I enabled it as a test.

I waited, then recorded the phone again. This time photoanalysisd averaged around 0.01% CPU.

The service was practically idle.

This did not prove that Low Power Mode always stops Photos analysis. It showed that Photos analysis stopped during my test.

Enable Developer Mode

Historical reports are useful, but I also wanted live process data.

For that, the iPhone needs Developer Mode.

The option might not appear immediately. First, pair the iPhone with Xcode:

  1. Open Xcode.
  2. Choose Xcode → Open Developer Tool → Device Hub.
  3. Select the connected iPhone.
  4. Follow the pairing instructions.

Then open Settings → Privacy & Security → Developer Mode on the iPhone.

Enabling it restarts the phone. After the restart, unlock it and confirm Developer Mode again.

Developer Mode exposes additional debugging services. Turn it off when you finish if you do not normally develop iOS apps.

Record all processes with Instruments

Xcode includes Instruments, which can record CPU and memory activity from the iPhone.

Open it from Xcode → Open Developer Tool → Instruments.

Choose the Activity Monitor template and select the iPhone as the target.

I first recorded for two minutes using Immediate mode. Instruments warned that the data volume was too high and dropped some data.

I saved the trace anyway, then repeated the test using Deferred mode.

Deferred mode produced a cleaner recording.

Export an Instruments trace

You can inspect a saved .trace bundle inside Instruments.

You can also export its tables with xctrace.

First, list the available tables:

xcrun xctrace export \
  --input 'run 2.trace' \
  --toc \
  --output trace-toc.xml

The Activity Monitor trace contained a table named activity-monitor-process-live.

I exported the second run with:

xcrun xctrace export \
  --input 'run 2.trace' \
  --xpath '/trace-toc/run[@number="2"]/data/table[@schema="activity-monitor-process-live"]' \
  --output processes.xml

The result is XML containing samples for every process.

Notice that Instruments adds its own overhead. Processes such as DTServiceHub, ptpd, and sysmond become busier while recording.

Do not mistake that activity for normal idle usage.

What the live trace showed

The deferred recording confirmed that Photos analysis was idle:

But other processes were busy:

fseventsd tracks filesystem changes. fileproviderd handles iCloud Drive and other providers connected to the Files app.

This showed that file and cloud synchronization were active during the recording.

Twitter was also surprisingly busy. It peaked above 300% CPU, which means it used more than three CPU cores at that moment.

Did I find the cause?

No.

I found several processes doing a lot of work. I also found historical reports showing that Photos analysis had previously exceeded its CPU limit.

But none of this proved what made the iPhone hot.

The live recording happened after I enabled Low Power Mode. The phone was connected to USB, charging, running Developer Mode, and being monitored by Instruments.

Every one of those details changed the conditions of the test.

The trace showed what the phone did during those few minutes. It could not tell me whether the same work caused the heat I noticed earlier.

What I learned

Closing apps is not a reliable way to diagnose a hot iPhone.

System services continue working after every visible app disappears.

In my case, the investigation showed two different periods of activity:

  1. Photos analysis had previously exceeded its CPU limit.
  2. Low Power Mode deferred that work, but file and cloud synchronization remained busy.

The battery itself looked healthy.

That narrowed the possibilities, but it did not give me a definitive answer.

My advice is to start with the safe checks:

If the heat continues, use Instruments to record a short deferred Activity Monitor trace.

That gives you evidence about what happened during the recording. It might reveal the cause, or it might only rule out a few possibilities.

Tagged: Mac · All topics
~~~

Related posts about mac: