@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?

@ShinyQuagsire

1) that seems like a bug, given that the underlying memory rebinding operations aren’t supposed to actually compile to anything. Are you able to compare the assembly of your implementations to see what’s different? (Instruments has a source/assembly view with a heatmap in the call tree)

2) Does `CMBlockBuffer.withUnsafeMutableBytes` perform well? Raw buffer pointers have a UInt8 element type so you wouldn’t need to convert to an UMBP<UInt8>. https://developer.apple.com/documentation/coremedia/cmblockbuffer/3241750-withunsafemutablebytes

We’re growing our product team!

Are you an #iOS Developer who wants to lead our official #Mastodon iOS #App?

This is a remote full-time position and requires an overlap with the CET timezone.

Ideally:

1. You are a senior iOS Developer comfortable with a mature codebase
2. Proficient in #Swift and #Apple Frameworks (UIKit, SwiftUI, Combine)
3. Prior experience with social media networks is a big plus!

For more info/to apply:
https://jobs.ashbyhq.com/mastodon/bc91c481-d30a-4e73-9eb8-ac29f4e905e2

#FediHire #GetFediHired #hiring #mastodev

@landonepps @helge Yes, iOS 18/macOS 15 and aligned releases include symbol information for SwiftUI on arm64/arm64e platforms (i.e. excluding watchOS which is arm64_32 and Intel macOS) and simulators. If you’re seeing any issues with that, please file a feedback and send me the number!

@krzyzanowskim Please file a bug report in Feedback Assistant! Attaching the file `pbxperfconfig.plist` from your temporary directory will let us look at exactly what Xcode sent over and track down what is getting messed up in transit. As a workaround, you may be able to open the target picker in Instruments and choose “Edit [name]…” and then adjust the arguments from there.

There is two more Performance Labs for #WWDC24 : tomorrow and on Friday.

We usually have enough spots to talk to anyone who signs up and has a question, so don’t hesitate to do so. If you have a performance issue, even if you don’t know where it comes from or how to even start looking into it, we are happy to look at it together with you.

Instruments is here with new features! We have many UI improvements to make features more discoverable and easier to use, and a FLAME GRAPH in Instruments. Watch the “What's New in Xcode” session to learn more!

https://developer.apple.com/wwdc24/10135?time=1122

@stroughtonsmith This is great for complex context menus, since you can break different sections up into their own views. (We’re using it for the context menus in the new call tree / flame graph in Instruments, and breaking the different parts of the menu into different files with their own independent logic makes it a lot easier to understand and update.)

@leaverou Denver airport. The sinks are on the other side of a wall from the toilets and urinals, and they’re on the opposite side from the entrance/exit so you don’t pass by them going in.

@zachwaugh @cocoafrog My understanding is that methods with same signature (ignoring types) are merged together in the autocomplete to reduce verbosity. You can press the right arrow key when an entry with a chevron is highlighted to expand it to show the other overloads with the same signature but different types

@brentsimmons I haven’t tested locally but you may be able to work around this issue by declaring a `nonisolated(unsafe) static var button2: Self { button }` getter in an extension.

@brentsimmons The problem here is that UIAccessibilityTraitButton (https://developer.apple.com/documentation/uikit/uiaccessibilitytraitbutton?language=objc) is not declared as `const`, so you could theoretically reassign it to an arbitrary different value from any thread at any time (obviously that would break a lot of things). It would need a change on the SDK side to declare it as const in objc / read-only in Swift so that it is safe to access the value from any thread.