Users have reported unusually high data usage with my app. So to investigate I have profiled in instruments. My app as expected in using minimal data. However in instruments I see an "Unknown" process. Which sends around 1mb of data every 2 seconds. Can anyone explain what unknown process is? Sorry my question is vague but I'm at the beginning of understanding the instruments outputs so your help is so very much appreciated.

Hi! I allready have started a product page optimization tests in the past, but now I want to test different versions of my icon. But I can't see the option to change the icons, how can I do that?

Hi, I am using xctrace to launch an app and check if the app launched successfully or crashed by reading the content of the .trace file. However if multiple devices are connected , xctrace complain No devices found matching the identifier specified. Please let me know if there is any limitations for the device to be connected.

・Xcode 15.1 ・The app is also compatible with Watch. In the privacy manifest, we defined NSPrivacyTracking to YES and NSPrivacyTrackingDomains to specific domains. Furthermore, to avoid warnings when uploading to Testflight, we have implemented a privacy manifest file in the app with the following configuration. ・Place the .xcprivacy files for the app itself and WatchExtension under their respective Target directories. ・Settings related to tracking domains are listed in .xcprivacy of the app itself. ・In .xcprivacy of WatchExtension, only describe the reason for UserDefault of NSPrivacyAccessedAPIType However, these implementations do not block network connections, "Fault" still occurs on "Point of Intereset instruments". Is there something wrong with my implementation?

Hi! I watched WWDC 2019 Optimizing App Launch video and can't see the Lifecycle phases when I Profile my App. I'm using Xcode 15.2 with Instruments 15.2, and SwiftUI as UI framework. Here is a screenshot of what I get. It's there another tool or another way to get this information? Thanks! Alfonso.

I am trying to profile my app for 'Data Persistence', but I am not getting any data in the Instruments. I tried restarting Xcode and Mac, still no progress. It is showing blank graph for faults, fetches and saves

I asked this on StackOverflow too, but did not get a response. Copying verbatim (images might not work as expected). Short question: which instructions other than floating point arithmetic instructions like fmul, fadd, fdiv etc are counted under the hardware event INST_SIMD_ALU in XCode Instruments? Alternatively, how can I count the number of floating point operations in a program using CPU counters? I want to measure/estimate the FLOPs count of my program and thought that CPU counters might be a good tool for this. The closest hardware event mnemonic that I could find is INST_SIMD_ALU, whose description reads. Retired non-load/store Advanced SIMD and FP unit instructions So, as a sanity check I wrote a tiny Swift code with ostensibly predictable FLOPs count. let iterCount = 1_000_000_000 var x = 3.1415926 let a = 2.3e1 let ainv = 1 / a // avoid inf for _ in 1...iterCount { x *= a x += 1.0 x -= 6.1 x *= ainv } So, I expect there to be around 4 * iterCount = 4e9 FLOPs. But, on running this under CPU Counters with the event INST_SIMD_ALU I get a count of 5e9, 1 extra FLOP per loop iteration than expected. See screenshot below. dumbLoop is the name of the function that I wrapped the code in. Here is the assembly for the loop +0x3c fmul d0, d0, d1 <---------------------------------- +0x40 fadd d0, d0, d2 | +0x44 fmov d4, x10 | +0x48 fadd d0, d0, d4 | +0x4c fmul d0, d0, d3 | +0x50 subs x9, x9, #0x1 | +0x54 b.ne "specialized dumbLoop(_:initialValue:)+0x3c" --- Since it's non-load/store instructions, it shouldn't be counting fmov and b.ne. That leaves subs, which is an integer subtraction instruction used for decrementing the loop counter. So, I ran two more "tests" to see if the one extra count comes from subs. On running it again with CPU Counters with the hardware event INST_INT_ALU, I found a count of one billion, which adds up with the number of loop decrements. Just to be sure, I unrolled the loop by a factor of 4, so that the number of loop decrements becomes 250 million from one billion. let iterCount = 1_000_000_000 var x = 3.1415926 let a = 2.3e1 let ainv = 1 / a // avoid inf let n = Int(iter_count / 4) for _ in 1...n { x *= a x += 1.0 x -= 6.1 x *= ainv x *= a x += 1.0 x -= 6.1 x *= ainv x *= a x += 1.0 x -= 6.1 x *= ainv x *= a x += 1.0 x -= 6.1 x *= ainv } print(x) And it adds up, around 250 million integer ALU instructions, and the total ALU instructions is 4.23 billion, somewhat short of the expected 4.25 billion. So, at the moment if I want to count the FLOPs in my program, one estimate I can use is INST_SIMD_ALU - INST_INT_ALU. But, is this description complete, or are there an other instructions that I might spuriously count as floating point operations? Is there a better way to count the number of FLOPs?

I am interested in adding signposts to an existing large application that was written in .NET compiled in VisualStudio for MacOS so that I can isolate portions of the application in instruments. It seems like it's straightforward to do this in C++ but I couldn't figure out how to do it, perhaps there is a way via dll invoke? Appreciate any suggestions.

Hello everyone, Our iOS app is taking too long to launch. On checking the launch profile, we are seeing that most of the launch time is being spent in applying fixups which is taking more than a second and at times even more to complete. Our deployment target is iOS 15+. We have checked using dyld_info that our binary uses chained fixups. Since chained fixups are enabled, page-in linking should also be enabled for our app as per this WWDC session. Can someone please help us understand why the fixups application is taking this long and how can we improve it? Thanks.

As title, i tried to get tracking domain by Network instruments, but it shows Call os_log APIs on a logging handle network instruments. Anyone know how can i log the domain. Thanks

I am using the Leaks instrument, and it has identified a bunch of 32 and 48 byte "Malloc" leaks. I would like to see a hex dump of some (or all) of those areas. I think if I can see what is in them I can get a better idea about what is triggering the leak. I'm pretty sure it is a real leak. What is the easy way to do this? Can it be done inside instruments, or do I need to run my app under instruments and also attach via lldb and hexdump from lldb? (can I attach lldb and instruments at the same time?) If it matters I'm debugging an iPadOS app, and it is written in Swift plus ObjC, plus ObjC++, oh, and some straight C++.

Hello, This relates to NSTrackingDomains for Privacy Manifest. Following doc here https://developer.apple.com/documentation/xcode/detecting-when-your-app-contacts-domains-that-may-be-profiling-users. (Also, I'm quite new to using the Network Instrument). I'm not seeing any "Points of Interest" but I know my app has domains that should be shown as "Faults". Do I need to os_log to my Objective-C codebase. I don't have access to the code of various 3rd party SDKs. The doc mentioned above made it sound like these domains should automagically appear. Thanks!

I'm introducing some SwiftUI into a primarily UIKit app and have noticed that, as soon as a SwiftUI view is presented / pushed to the nav stack in its hosting view controller, the memory graph shows a number of Swift closure context (unknown layout) entries under an <unknown> header. These entries persist after the SwiftUI view has been popped from the navigation stack. Is this cause for concern? I don't think it represents a memory leak within my app, because the entries are grouped under <unknown> as opposed to my app name. But I'm not entirely sure why they exist (and crucially, why they persist). It's possible to observe this behaviour with a really simple demo app. Just push the following view: struct ViewController02: View { var body: some View { Text("Hello, world!") } } onto a navigation stack: self.navigationController?.pushViewController(UIHostingController(rootView: ViewController02()), animated: true) Any advice / guidance / reassurance would be much appreciated. There can be a considerable number of these entries but I can't see how I could be causing a retain cycle.

Hi! Is there a reason why trace's *-profile tables (time-profile, cpu-profile, counters-profile) always use an instruction pointer value that is 1 byte larger than what should be a true instruction pointer value? Odd valued IPs on Apple M2 are definitely incorrect as instructions have to be word-aligned. It's also worth mentioning that addresses in "source" tables ("time-sample" for "time-profile", "kdebug-counters-with-pmi-sample" for "cpu-profile" and "counters-profile") are correct (or, at least, are correctly aligned aligned). Here's an example: % xctrace version xctrace version 15.2 (15C500b) # run recording % xctrace record --template "Time Profile" --output TP.trace --launch /bin/dd if=/dev/random of=/dev/null bs=1024 count=1048576 # extract "source" table % xctrace export --input TP.trace --xpath='/trace-toc/run[1]/data/table[@schema="time-sample"]' > tp.time-sample.xml # extract "derived" table % xctrace export --input TP.trace --xpath='/trace-toc/run[1]/data/table[@schema="time-profile"]' > tp.time-profile.xml % xmllint --xpath '//row[1]' tp.time-sample.xml <row><sample-time id="1" fmt="00:00.040.502">40502000</sample-time><thread id="2" fmt="Main Thread 0x37c2d0a (dd, pid: 32471)"><tid id="3" fmt="0x37c2d0a">58469642</tid><process id="4" fmt="dd (32471)"><pid id="5" fmt="32471">32471</pid><device-session id="6" fmt="TODO">TODO</device-session></process></thread><core id="7" fmt="CPU 4 (P Core)">4</core><thread-state id="8" fmt="Running">Running</thread-state><sentinel/><kperf-bt id="9" fmt="PC:0x1863149fc, 3 frames, 1 regs, pid: 32471"><text-addresses id="10" fmt="frag 1717">6546645708 6546360308 0</text-addresses><text-address id="11" fmt="0x1863149fc">6546344444</text-address><process ref="4"/><register-content id="12" fmt="0x2e4c00018635e2cc">3336041430521340620</register-content></kperf-bt><time-sample-kind id="13" fmt="Timer Fired">0</time-sample-kind></row> % xmllint --xpath '//row[1]' tp.time-profile.xml <row><sample-time id="1" fmt="00:00.040.502">40502000</sample-time><thread id="2" fmt="Main Thread 0x37c2d0a (dd, pid: 32471)"><tid id="3" fmt="0x37c2d0a">58469642</tid><process id="4" fmt="dd (32471)"><pid id="5" fmt="32471">32471</pid><device-session id="6" fmt="TODO">TODO</device-session></process></thread><process ref="4"/><core id="7" fmt="CPU 4 (P Core)">4</core><thread-state id="8" fmt="Running">Running</thread-state><weight id="9" fmt="1.00 ms">1000000</weight><backtrace id="10"><frame id="11" name="0x1863149fd" addr="0x1863149fd"><binary id="12" name="dyld" UUID="324E4AD9-E01F-3183-B09F-3E20B326643A" arch="arm64e" load-addr="0x186313000" path="/usr/lib/dyld"/></frame><frame id="13" name="0x18635e2cc" addr="0x18635e2cc"><binary ref="12"/></frame><frame id="14" name="start" addr="0x1863187f4"><binary ref="12"/></frame></backtrace></row> As you can see, <kperf-bt id="9" fmt="PC:0x1863149fc, 3 frames, 1 regs, pid: 32471"> refers to a properly aligned address, but the address from <backtrace id="10"><frame id="11" name="0x1863149fd" addr="0x1863149fd">... is off by one. It seems like only an address from the top frame is incorrect, as others are aligned properly. The same issue exists for "CPU Profile" and "CPU Counters" instruments and could be reproduced on macOs running on both x86-64 and Apple-Silicon CPUs.

I have an iOS app that uses os_signpost API for instrumentation. When I profile it from Xcode on real iOS device, it works as expected. When I profile its macCatalyst variant (using the identical code) on the same Mac where Xcode is running, the os_signpost Instrument does not show anything, not even the Apple provided signposts that are otherwise visible on the iOS. How do I make it work?

When using Instruments in Xcode 15.3 on macOS Sonoma 14.3.1 symbols from system frameworks are not displaying. I've tried creating a template "App" project and running it on the iOS 17.4 simulator without any code changes and still am not seeing symbols so I can be sure it's not unique to my real-world project build settings. If I install Xcode 15.0 and run the same build in the same 17.4 simulator using Instruments 15.0 it shows thread names and symbols for UIKit and other frameworks but is still missing SwiftUI symbols. Instruments 15.3 Instruments 15.0 I've spent 2 days trying to narrow down why I couldn't debug my app and even deleted all my partitions and reinstalled macOS which didn't fix the issue.

What's the best way in Instruments, to measure the amount of time spent on large memory copies? For a very simple example, when directly calling memcpy? Memory copying does not show up in the time profiler, it's not a VM cache miss or zeroing event, etc so it doesn't show there, it doesn't (as far as I can tell) show up in the system trace, and there aren't any other choices.

Xcode Version 15.2 (15C500b) After upgrading Xcode from 14 to 15.2 I am not able to attach system extension (packettunnel) process to Instruments tools for memory debugging. Same is working fine with Xcode 14. Error displayed: "Process No Longer Exists". But the service is running and is listed in process list. % ps -ax | grep -i pkttunnel | grep -v grep 61910 ?? 0:01.04 /Library/SystemExtensions/5F4AF6EF-****-****-****-F11****9CE78/com.******.client.*****-Client.***ui.***pkttunnel.systemextension/Contents/MacOS/com.******.client.*****-Client.***ui.***pkttunnel.systemextension Note: I am able to attach a normal program to Instruments tool for memory debugging, I have noticed this issue with system extension processes only.

If I try to run Instrument's logger for an app downloaded from TestFlight it says "Permission to debug app name was denied". "Recover Suggestion: The app must be debuggable and signed with 'get-task-allow'. How do you make the app debuggable? (I tried creating an archive with the scheme set to Debug, but after uploading that to TestFlight, it doesn't appear. So presumably its not possible to upload an app built with debug scheme builds to TF?). Therefore how can I make a TF build debuggable?, and how to sign it with get-task-allow? Does it have to be a developer distribution .ipa rather than a TestFlight build to enable Instruments/Logger to run it?

Hi everyone, I have an AR app that allows for collaborative sessions and synchronizes model state (e.g. rotation, can be changed via slider) using Multipeer Connectivity. The receiving peer parses the data and then uses DispatchQueue.main.async to update the UI (SwiftUI) and the model in SceneKit. Lately I have noticed that this synchronization seems to lag periodically. To analyze the issue better I compiled this minimal reproducible example: https://github.com/MrMuetze/MCSyncTest The repository includes a boiled down "Multipeer Connectivity" project that should make this issue reproducible on local devices (maybe even between one device and the simulator). I have also added a readme with a gif that shows the issue. The synchronization between devices worked like a treat for a long time but recently I have noticed that e.g. a rotation is not as smooth as before on the receiving device. A bit of debugging revealed that the messages are received quickly but then the work that needs to happen on the main thread is periodically delayed. In the example project the relevant code bit that should be executed on the main thread looks like this: func session(_: MCSession, didReceive data: Data, fromPeer _: MCPeerID) { print("received data") DispatchQueue.main.async { print("doing stuff") let doubleVal = data.to(type: Double.self) ?? 0.0 self.internalSliderValue = doubleVal self.sliderValue = doubleVal } } It updates a published variable sliderValue that is connected to a Slider and a Text UI element. Regularly (like every 500ms or so) the execution of work on the main thread seems to be delayed. After a short while all outstanding UI updates are executed at once which leads to visual stuttering. This can be observed by looking at the printed messages: ... received data &lt;-- normal behavior doing stuff received data doing stuff received data doing stuff received data &lt;-- hiccup starts received data received data received data doing stuff doing stuff doing stuff doing stuff received data &lt;-- returns to normal behavior doing stuff received data doing stuff ... I have tried to change the "Quality of Service" to .userInteractive as well as limiting the number of messages that are sent in a certain timeframe (I tried one message every 100ms). Both changes have not helped and even with a much lower number of messages the periodic stuttering remains. Using DispatchQueue.main.sync is also not a solution right now. It does bring the sequence back into original order but the periodic "freeze" of the queue is prevalent there as well. This then leads to a "laggy" execution of what happened on the sending peer device. I am not very familiar with Profiling an app and using Instruments, but I have captured some timings in regards to the usage of the main thread and some backtraces. From what I can understand the workload of the written code should not be the issue, but rather an underlying system function or library. I can provide more information in regards to the backtraces if needed. Right now I can't really say what would be useful. Below is an image that shows the main thread usage at the very top. This happens when the slider lags as shown in the gif. I am working with Xcode 15.2 and run the app on iOS 17.3. For devices I use an iPad Pro (2nd gen.) and an iPhone 15 Pro. The issue happens in Debug as well as in Release mode. I can't quite say when the stuttering appeared initially. I wonder if anyone is aware of any changes to iOS or underlying frameworks that could have caused this issue. I am interested in any information about this, if the issue can be resolved or if I have to look for alternative workarounds. Let me know if I can add any additional information. Best regards! Bjoern