Some instruments in the Instruments application can be used on arbitrary processes, so you could use them to analyze even production builds.
However, other instruments give you very detailed insights into the execution of a process (e.g. its memory layout) and making this kind of data available is a security risk.
Therefore, this kind of access to a process' internals is only possible for processes launched from a "debuggable" executable, whereas "debuggable" means the executable has theget-task-allow entitlement.
Executables built and installed by Xcode directly will have this entitlement and thus be "debuggable".
Note that this is independent of the "Build Configuration" you use. You can make a "Release"-build in Xcode and it will still have that entitlement and thus be "debuggable" and fully analyzable in Instruments. In fact, that's what happens when you use the Product -> Profile action in Xcode: Xcode build in the "Release" build configuration to get the most performant version of your application and then hands the resulting binary over to Instruments for analysis.
The "Archive" action in Xcode doesn't add the get-task-allow entitlement as an "archived" executable is meant for distribution not for analysis and debugging.
You can check the entitlements of a binary using
codesign -dvvv --entitlements=- <path-to-target-binary>
Then in the output look for com.apple.security.get-task-allow. If it's there it is "debuggable", otherwise it's not.
If being able to create a "debuggable" binary via the Archive action for distribution would be useful for you, please file a feedback describing your use-case.
tl;dr: Only binaries installed (and potentially signed) by Xcode are "debuggable" for the purpose of this question. Simply run your app from Xcode and profile that instead of targeting the TestFlight build.
