When Instruments cannot see your iPhone or fails to attach to your app, profiling stalls before it starts. Here is how to fix device detection and attachment problems.
You open Instruments, go to choose a target, and your device is missing from the list. Or it appears, but the session fails to attach to your app.
This is frustrating because it blocks profiling before any measurement begins. The tool is ready, but it cannot reach the device or process.
These problems are almost always about connectivity, trust, or process state. They rarely indicate a real fault in your app.
The fixes are methodical. Work through connection, trust, and selection in order, and the device usually returns.
Start with the physical and trust basics. Make sure the device is connected with a known-good cable and is unlocked.
The first time you connect a device to a Mac, iOS asks whether to trust this computer. If you never tapped Trust, the Mac cannot fully communicate with the device.
Unlock the device, watch for the Trust prompt, and confirm it. If you previously tapped do not trust, you may need to reconnect to get the prompt again.
A flaky cable or hub is a surprisingly common culprit. Try a direct, reliable connection before assuming a software problem.
Xcode prepares a device for development the first time it sees it, and Instruments relies on that preparation. If the device is not ready, profiling will not work.
Open Xcode and check the Devices window to confirm the device is recognized and finished preparing. This step can take a little time after a connection or an OS update.
If the device shows a busy or preparing state, wait for it to complete. Attempting to profile mid-preparation leads to attach failures.
An OS update on the device often triggers a fresh preparation cycle. Let Xcode finish before you return to Instruments.
Attaching to an already-running process is more fragile than launching the app fresh. If attach keeps failing, let Xcode launch the app for you.
From Xcode choose Product, then Profile. This builds, installs, launches, and attaches in one coordinated step, which avoids most attach errors.
Launching fresh ensures the process exists and is in a clean state when Instruments connects. It removes timing problems where you try to attach before the process is ready.
Reserve manual attaching for cases where you specifically need to profile an already-running session. For everyday profiling, the Profile action is more reliable.
A device running a newer OS than your Xcode supports can fail to be profiled. Xcode needs the matching support components for that OS version.
Keep Xcode reasonably current relative to your device's OS. If you recently updated the device, you may need an Xcode update to match.
Wireless pairing can also drop. If you rely on profiling over the network, reconnect with a cable to re-establish a solid pairing, then try wireless again.
When in doubt, fall back to a wired connection. It is the most dependable path while you sort out version alignment.
First, connect the device directly with a good cable, unlock it, and accept any Trust prompt. Confirm it appears in Xcode's Devices window and has finished preparing.
Second, instead of attaching manually, choose Product, then Profile, in Xcode. Let the toolchain launch and attach for you.
Third, if the device is still missing, unplug and reconnect, then restart Xcode and Instruments. A clean reconnect clears many transient states.
Fourth, if it persists, restart both the Mac and the device, and verify your Xcode version supports the device's OS. A reboot resolves a surprising number of pairing glitches.
Standardize on a reliable cable and a known-good port for profiling sessions. Eliminating flaky hardware removes a whole class of failures.
Keep Xcode updated alongside your test devices so version support stays aligned. Mismatches are easiest to avoid before they happen.
Let Xcode finish preparing a device after any OS update before you try to profile. Patience here saves repeated attach failures.
And remember the native context. Instruments attaches to compiled native app processes, so if your product is web output from an app builder rather than native Swift, you would first build and install a real native app from Xcode before profiling is possible.
Before assuming a deep tooling problem, run through the mundane explanations, because they account for most attach and detection failures.
A locked device is a frequent one. Many connection and trust steps simply will not complete while the screen is locked, so keep the device awake and unlocked while you set up.
A low-quality or damaged cable is another. Data and charge-only cables can look identical, and a charge-only cable will power the device without ever exposing it for development.
An overloaded hub or adapter can also interfere. Connecting the device directly to the Mac removes a layer that sometimes drops the data connection.
Finally, a half-finished trust relationship is common after wiping or restoring a device. Reconnecting and re-accepting the Trust prompt re-establishes the pairing. Working through these first often saves you from chasing a problem that was never really about Instruments or Xcode at all.
It is also worth confirming there is no second Mac or app already holding the device. A device that is busy being prepared, syncing, or actively used by another tool can refuse to appear for profiling. Giving it a moment to settle, or quitting whatever else is talking to it, frequently clears the issue without any deeper troubleshooting.
When none of the simple checks help, a deliberate clean reconnect is the next move. Unlock the device, unplug it, plug it back in directly, watch carefully for the Trust prompt, and confirm it shows as ready in Xcode before you switch back to Instruments. Doing these steps slowly and in order tends to work better than retrying the same failing attach over and over.
If you are blocked on device issues and only need a rough look, the simulator is always available as a target. It does not require pairing or trust.
The simulator is fine for catching gross problems and for some memory and CPU investigation. It is convenient when hardware is being uncooperative.
Remember its limits, though. Simulator performance and energy numbers do not reflect real hardware, so confirm important findings on a device once it is back online.
Use the simulator to keep moving, then validate on real hardware before you trust any performance conclusion. That balance keeps you productive without misleading yourself.
Most often the device is locked, not trusted, or still being prepared by Xcode. Unlock it, accept the Trust prompt, and confirm it is recognized in Xcode's Devices window.
Attaching to a running process is timing-sensitive and can fail if the process is not ready. Use Product, then Profile, so Xcode launches and attaches the app for you in one step.
A newer device OS can require a matching Xcode update for support components. Update Xcode and let the device finish preparing before profiling again.
Yes, the simulator is always available and needs no pairing. Just remember its performance and energy numbers do not reflect real hardware, so validate important findings on a device later.