[CRITICAL] Metal API Memory Leak - Heap Memory Never Released to OS (CWE-400) Security Classification This issue constitutes a resource exhaustion vulnerability (CWE-400): Aspect Details Type Uncontrolled Resource Consumption CWE CWE-400 Vector Local (any Metal application) Impact System instability, denial of service User Control None - no mitigation available Recovery Requires application restart Summary Metal heap allocations are never released back to macOS, even when the memory is entirely unused. This causes continuous, unbounded memory growth until system instability or crash. The issue affects any application using Metal API heap allocation. This was discovered in Unreal Engine 5, but reproduces in a completely blank UE5 project with zero application code - confirming this is Metal framework behavior, not application-level. Environment OS: macOS Tahoe 26.2 Hardware: Apple Silicon M4 Max (also reproduced on M1, M2, M3) API: Metal Reproduction Steps Run any Metal application that allocates and deallocat
Search results for
SwiftUI List performance
50,609 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Thanks for your reply. The feedback ID is FB21579636 Yes, I've tried overriding hitTest and in fact noticed that the mouse events simply pass through some swiftUI controls like swiftUI buttons. Using AppKit controls instead fixes the issue, but is not convenient.
Topic:
UI Frameworks
SubTopic:
SwiftUI
Tags:
Thanks for the replies. You are both quite right that I should have provided more information. When I say that notarization succeeds, I mean that I submit the dmg file produced by the build to the Apple notarization service and receive a status of 'Accepted'. I take this to mean all is well. When I say that notarization fails, I mean that the notarization step produces a status of 'Invalid'. Retrieving the notarization log indicates that the binaries were not signed. I've just gone through this again with my two machines. The build here is performed by scripts that are maintained in source code control and forced to be identical in both setups. The build infrastructure is also the same for both. Before beginning, both machines were powered off for a period of time. Power up one machine. Ensure the source tree is up-to-date. Run the build to produce a signed dmg. Submit it for notarization. The submission produces a status of Accepted. Power down the first machine. Power up the second machine. Again e
Topic:
Code Signing
SubTopic:
Notarization
Reply to
Best practice for centralizing SwiftData query logic and actions in an @Observable manager?
A SwiftData query (@Query) is currently tied to a SwiftUI view and relies on the modelContext environment value of the view. There is currently no way to use @Query outside of a SwiftUI view. To implement the query logics in a controller class, you basically need to to do the following with your own code: Fetch data using FetchDescriptor + ModelContext.fetch. Update the result set when relevant changes happen. To do step 2, assuming you are using the SwiftData default store, which is based on Core Data, you need to observe the notifications triggered by a store change (basically NSManagedObjectContextObjectsDidChange and .NSPersistentStoreRemoteChange), check if the change is relevant, and re-fetch the data set as needed. All these will be a bit involved, and yet have already implemented (as Query) on the framework side. I'd hence suggest that you file a feedback report to request an API that does what Query does but doesn't rely on SwiftUI – If you do so, please share your report I
Topic:
App & System Services
SubTopic:
iCloud & Data
Tags:
Posting this here in case this information is helpful to other developers: As of visionOS 26.3 beta 1, onWorldRecenter has two significant issues: (FB21557639) Memory Leak: When onWorldRecenter is assigned to a RealityView within an ImmersiveSpace, it appears to retain a strong reference to the view's internal SwiftUI context. When the immersive space is dismissed, the view's @State objects will not be deallocated. Also, each time the immersive space view's body is executed, additional state storage will be allocated and leaked. Multiple Callbacks: When the user long-presses the Digital Crown, the onWorldRecenter closure will be called multiple times, once for each past view body execution, including those of immersive space views that have been previously dismissed. Although these issues seem to be most prevalent when onWorldRecenter is used with an ImmersiveSpace, they may also occur in the context of a WindowGroup under certain circumstances. It's possible to work around this problem by moving onW
I try to update remoteHandle using CXCallUpdate for outgoing calls, but this works only on iOS 15 but not on 17 or 18 (16 didn't test). What's actually not working here? Are you looking at what the lock screen UI shows or what you see in other locations (particularly in the Recent call list)? There is a longstanding issue (r.126348631) where call updates aren't being displayed on the lock screen interface; however, this is purely about UI showing old data, not about the update itself completely failing. Notably: I use this handle value to implement recall by tapping on a call in the Recents tab of the system address book. But since my calls can transform from p2p to group calls, I need to update the handle value or find some other way to pass call identification info. ...I'd expect this sort of thing to work exactly the way you need/expect, regardless of what the lock screen UI shows. __ Kevin Elliott DTS Engineer, CoreOS/Hardware
Topic:
App & System Services
SubTopic:
General
Tags:
On MacBook Pro M3 14 I can profile the Metal App performance by running it, then clicking on the M icon and choosing profile after replay. On Mac Studio M2 Ultra I cannot: the profiler starts and crashes. I have tried everything including reinstalling the OS, Xcode, the Metal SDK, you name it. The app uses the Metal 4 API. The content of the replayer errorinfo report is shown at the end. Any ideas what is going on here and/or what else I can do do root cause this and fix it? FWIW, it was worse on 26.1 (Xcode just reported Metal 4 profiling not available). In 26.2 Xcode attempts to profile and invariably crashes. === Error summary: === 1x DYErrorDomain (512) - guest app crashed (512) 1x com.apple.gputools.MTLReplayer (100) - Abort trap: 6 === First Error === Domain: DYErrorDomain Error code: 512 Description: guest app crashed (512) GTErrorKeyPID: 26913 GTErrorKeyProcessName: GPUToolsReplayService GTErrorKeyCrashDate: 2026-01-09 19:22:52 +0000 === Underlying Error #1 === Domain: com.apple.gputools.MTLR
Topic:
Graphics & Games
SubTopic:
Metal
Hello, I have an iOS camera app that captures exposure brackets and performs custom HDR processing. On iOS 26, I’m observing a visual difference between: a single photo captured at –2 EV, and the –2 EV frame from an exposure bracket (–2 / 0 / +2 EV). On iOS 26: The single –2 EV image looks natural and consistent. The –2 EV image from the bracket appears clamped / distorted, most noticeably in high dynamic range scenes (highlight compression and loss of detail). On iOS 18, both approaches produce visually identical and correct –2 EV images. The issue only appears for bracketed captures on iOS 26. Attachments (examples) iOS 26 Single capture –2 EV (JPEG): /Users/danilobudimir/Downloads/ios26SingleImage/JPEG image-4006-8B77-51-0.jpeg Single capture –2 EV — Capture report (dumped settings): /Users/danilobudimir/Downloads/ios26SingleImage/UnderExposureDebug_CaptureReport_2026-01-09T15-59-20Z.md Bracket capture –2 EV frame (JPEG): /Users/danilobudimir/Downloads/bracket_iOS26/JPEG image-45CE-9793-A5-0.jpeg
Hi! I've been scratching my brain for a few days now to no avail. I have a Perl project that I need to embed within my app. Perl includes a pp command (https://metacpan.org/pod/pp) which takes the runtime binary and then slaps the Perl code at the end of the binary itself which in brings some woes in a sense that the binary then needs to be fixed (https://github.com/rschupp/PAR-Packer/tree/master/contrib/pp_osx_codesign_fix) by removing the linker-provided signature and fixing LINKEDIT and LC_SYMTAB header sections of the binary. Nevertheless, I've successfully gotten the binary built, fixed up and codesigned it via codesign -s '$CS' mytool (where $CS is the codesigning identity). I can verify the signature as valid using codesign -v --display mytool: Identifier=mytool Format=Mach-O thin (arm64) CodeDirectory v=20400 size=24396 flags=0x0(none) hashes=757+2 location=embedded Signature size=4820 Signed Time=5. 1. 2026 at 8:54:53 PM Info.plist=not bound TeamIdentifier=XXXXXXX Sealed Resources=none Internal requi
In general, the notary service should include all Mach-O images in your submission in the ticket that it issues. Thus, you shouldn’t have to notarise helper independently, or Application Bundle.app for that matter [1]. However, I recommend that you check this, just to be sure. To do that: Submit your package for notarisation. On successful notarisation, fetch the notary log. See if it lists the cdhash values for helper. IMPORTANT If your helper has multiple architectures, check that both cdhash values are present. For more on cdhash values, see TN3126 Inside Code Signing: Hashes. For more background on how this stuff works, see Notarisation Fundamentals. For links to lots of other notarisation info, see Notarisation Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Although it’s fine to do that if, for example, you also distribute the app via some other channel that doesn’t involve this installer package.
Topic:
Code Signing
SubTopic:
Notarization
Tags:
Hello, I am building an iOS-only, commercial app that uses AVSpeechSynthesizer with system voices, strictly using the APIs provided by Apple. Before distributing the app, I want to ensure that my current implementation does not conflict with the iOS Software License Agreement (SLA) and is aligned with Apple’s intended usage. For a better playback experience (more accurate estimation of utterance duration and smoother skip forward/backward during playback), I currently synthesize speech using: AVSpeechSynthesizer.write(_:toBufferCallback:) Converting the received AVAudioPCMBuffer buffers into audio data Storing the audio inside the app sandbox Playing it back using AVAudioPlayer / AVAudioEngine The cached audio is: Generated fully on-device using system voices Stored only inside the app’s private container Used only for internal playback controls (timeline, seek, skip ±5 seconds) Never shared, exported, uploaded, or exposed outside the app The alternative approaches would be: Keeping the generated audio entire
So one of the following must be true: You want to use the Background Tasks framework to run long-running tasks via BGProcessingTask. Or you don’t. If you do, add the BGTaskSchedulerPermittedIdentifiers property to your Info.plist and populate it with the list of background task identifiers you use. If you don’t: Remove the processing value from the UIBackgroundModes property in your Info.plist. Remove any code that uses BGProcessingTask. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect
Tags:
We're updating a FileProvider-based app which was written for Big Sur to recent macOS. The system requires that the extension be manually enabled by the user in System Preferences -- either under Extensions > Added Extensions, Privacy & Security > Extensions > Added Extensions, or in newer versions General > Login Items & Extensions. Is there a programmatic (preferably Swift) or installer-based way to enable this checkbox-- or at least to detect if it has been enabled for a particular app, and if not bring up the appropriate pane of Preferences? (For which I'd need a complete OS-version-specific list of which pane to bring up.) (I can detect whether our particular NSFileProviderDomain has its userEnabled flag set after it's defined during the mounting process, but I'd rather be able to detect / set it during initial setup.)
Issue When an Entity with a ViewAttachmentComponent is: disabled using isEnabled = false removed using removeFromParent() and then enabled or added back again, the attached SwiftUI view is rendered correctly, but tap interactions stop working. Specifically: Button actions inside the attached view do not fire TapGesture closures on child views do not respond Expected Behavior Tap interactions inside the attached view should continue to work after the Entity is re-enabled or re-added. Actual Behavior After being disabled or removed once, all tap interactions stop responding. Comparison When displaying the same SwiftUI view using RealityViewAttachments, this issue does not occur. Removing and re-displaying the attachment still allows taps to work correctly. Reproduction Attached sample code reproduces the issue: A RealityView with an Entity that has a ViewAttachmentComponent The attached SwiftUI view contains a Toggle The toggle updates isEnabled on the Entity After toggling off and on
I do not see how this even the structure is intellectual property. Design does appear to use SwiftUI which is recommended by Apple. Congrats on the approval.