@manuel @jsq If you still want that (such as to make a condition more legible when doing on-line code review) you can click on the annotation and choose the option to convert it to a comment which will also hide it to avoid duplication :)

@fsousa Did you get a chance to submit a report about this in Feedback Assistant? I want to make sure this bug doesn’t slip through the cracks :)

@cocoafrog As I understand it, Xcode 26 sets a build setting in new projects that enables the 2 “approachable concurrency” features. I imagine they will also be included in the next language mode, whenever that happens. Separately, new *app* projects get the MainActor-by-default language feature/mode enabled which I don’t believe is on track to be enabled by default for all projects ever.

Swift SDKs for WebAssembly are now available on swift.org for 6.2 and `main` development snapshots!

Huge announcement for me personally, this is something I could only dream of when almost 7 years ago I joined a few volunteers maintaining a patchset trying to add support for Wasm to Swift. A tremendous amount of effort from many people was put into polishing, upstreaming, and testing these changes. I'm grateful to everyone who helped and provided feedback 🙇

https://forums.swift.org/t/swift-sdks-for-webassembly-now-available-on-swift-org/80405

It's that time of year, WWDC labs! I highly recommend folks to sign up for labs. I will be in the Performance, Power, and stability labs through the entire week. Sign up for a session, whether you have a specific performance issue you want to work through together or just have questions about our existing & new tools. https://developer.apple.com/wwdc25/sessions-and-labs/one-on-one-labs

This year we have a brand new CPU counters instrument that reimagines what profiling CPU counters looks like, rather than manually configuring HW counters you will be given a guided approach with understandable metrics & documentation in guiding micro-optimizations. We hope that this new tool makes understanding & optimizing your code using CPU counters much more approachable for developers of all experience levels.

Watch this Optimize CPU performance with Instruments talk. This talk covers CPU profiling from the ground up, covering CPU profiler, Processor Trace, and CPU Counters. This is a fantastic talk I would recommend to every developer, especially those new to profiling & performance work.
https://developer.apple.com/videos/play/wwdc2025/308

@fsousa No, you shouldn’t need to do that. Can you file a bug report on Feedback Assistant? Please go to Settings → General → “Attach supporting files” in Instruments and try to record again. Then attach the recorded trace file and a sysdiagnose from both the Mac and your Watch. If you send the number here I’ll take a look!

@fsousa It’s definitely supposed to work on watchOS 26. What error message are you getting?

@cocoafrog since it’s source breaking and there’s no new language mode this year you have to opt in and migrate your codebase: https://github.com/swiftlang/swift/blob/ba715db935aaaf16d4ae221df81424b7b9ad27ab/userdocs/diagnostics/nonisolated-nonsending-by-default.md

My work project this year (with help from folks across Apple who built out the data source, taught me how various bits of SwiftUI work, and made the UI in Instruments much more informative): a new SwiftUI instrument that can finally tell you why your views are updating! It also gives you a peek into the soup of attributes under the hood :) Grab one of the 26.0 betas for your device of choice and give it a try: https://developer.apple.com/videos/play/wwdc2025/306/

@cocoafrog SE-0461: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0461-async-function-isolation.md

@simonbs ok! A workaround that you could try until this gets fixed at the SwiftUI/Observation level is to move all the accesses to Observable class properties to a super view that does not update frequently, then take the values of those properties in as plain properties on your view that updates frequently.

@simonbs If you click “mark generation” in Instruments with the timeline cursor after app startup and partway into the memory increase, it should hide all the things that were created before then so you can focus on the part of the memory that’s growing. What types do you see there?

My suspicion is that Observation creates some sort of tracking object so it can remember which view to update when you set the property, but if you never do that the trackers don’t get deduped and just pile up.

@zachleat 🫣

fine print: this position currently requires that you be in person in an office in Cupertino 3 days a week.

If you have questions about the role, feel free to reply or DM!

My team at Apple is hiring! We work on all parts of Instruments — from interacting with OS-level data sources to building the UI components that present that information in an understandable and actionable manner. I really love this job because there are so many different kinds of problem to solve, and we sit at the confluence of a wide variety of other teams’ work. It’s also a rare opportunity to work on a native Mac app :)

If this sounds interesting to you, apply here: https://jobs.apple.com/en-us/details/200577790/developer-tools-performance-tools-engineer

@compilz
With regard to the export functionality: you can also select all in the call tree, then right-click and choose “Deep Copy with Header” which will copy a tabular version of the whole call tree which you can process as you’d like. We do recognize that neither this nor the xctrace exports are ideal, and we’d love to hear about how what kind of information you’d like to export (either here or via https://feedbackassistant.apple.com so it gets tracked in our official system)! (3/3)

@compilz You can also right-click on a row in the call tree and choose “Show Calls Made by ‘[library name]’” which also trims any frames above those calls. I’d recommend checking out the filtering options here — they apply to both the call tree and flame graph, and you can do a lot with them! (2/)

@compilz Thanks for the feedback! We don’t have anything like that call graph at the moment (although it is a cool idea), but Instruments 16 (part of Xcode 16, currently available as a release candidate) does add a flame graph representation for almost all of the places you can see a call tree. You can filter the call tree or flame graph using the search box (type the library name, press return, and then click on “Any Contains” to change it to “Library Contains.” (1/)

@compilz Out of curiosity, what’s missing for you from Instruments?