Hello everyone, I am posting this to determine whether other iPad Pro M4 users are experiencing the same issue. Device: iPad Pro 11-inch (M4) Original Apple charger Tested on multiple iPadOS versions, stebal and beta including 26.2, 26.3, 26.4, 26.5.2 Games Tested: BGMI PUBG Mobile Global Call of Duty: Mobile Fortnite Issue: Despite using one of Apple's most powerful tablets, I continue to experience gaming performance problems. The issues include: FPS drops during long gaming sessions. Frame pacing inconsistencies. Reduced responsiveness during intense fights. Inconsistent hit registration and spray accuracy after extended play. Performance sometimes changes when gaming while charging with the original Apple charger. I have tested multiple iPadOS versions and multiple game updates over several months, but the issue has never been completely resolved. Interestingly, iPadOS feels more consistent for me than some previous versions, but the overall gaming experience is still not what I would expect from the M4 hardware. I have also noticed that many other iPad Pro M4 users have reported similar concerns on Reddit, Apple Communities, and other gaming forums. Questions: Are other iPad Pro M4 users experiencing the same FPS drops and gameplay inconsistencies? Has anyone found a reliable solution? Is Apple aware of these gaming performance issues on the M4 iPad Pro? Is this an iPadOS optimization issue, a GPU scheduling issue, or something related to game optimization? I hope Apple and game developers investigate this further because the M4 hardware should be capable of delivering a consistently excellent gaming experience. Thank you.

Title: iPad Pro M4 (11-inch) – Persistent Gaming Performance Issues Across Multiple iPadOS Versions Hello everyone, I am posting this to determine whether other iPad Pro M4 users are experiencing the same issue. Device: iPad Pro 11-inch (M4) Original Apple charger Tested on multiple iPadOS versions, stebal and beta including 26.5.2, 26.6 Beta 1, 26.6 Beta 3, and 27 Beta 1. Games Tested: BGMI PUBG Mobile Global Call of Duty: Mobile Fortnite Issue: Despite using one of Apple's most powerful tablets, I continue to experience gaming performance problems. The issues include: FPS drops during long gaming sessions. Frame pacing inconsistencies. Reduced responsiveness during intense fights. Inconsistent hit registration and spray accuracy after extended play. Performance sometimes changes when gaming while charging with the original Apple charger. I have tested multiple iPadOS versions and multiple game updates over several months, but the issue has never been completely resolved. Interestingly, iPadOS 27 Beta 1 feels more consistent for me than some previous versions, but the overall gaming experience is still not what I would expect from the M4 hardware. I have also noticed that many other iPad Pro M4 users have reported similar concerns on Reddit, Apple Communities, and other gaming forums. Questions: Are other iPad Pro M4 users experiencing the same FPS drops and gameplay inconsistencies? Has anyone found a reliable solution? Is Apple aware of these gaming performance issues on the M4 iPad Pro? Is this an iPadOS optimization issue, a GPU scheduling issue, or something related to game optimization? I hope Apple and game developers investigate this further because the M4 hardware should be capable of delivering a consistently excellent gaming experience. Thank you.

I have a function a implemented in a protocol extension that's called millions of times per second. It in turn calls a function b which is required by the protocol which does not have an implementation in the extension. According to the Time Profiler in Instruments, function a spends a lot of time in __swift_instantiateGenericMetadata. I get a big performance bump by moving a out of the extension and re-implementing it identically in each type that conforms to the protocol. Is there any way to get the compiler to do this itself? Do I need to write a macro to do it for me? There are screenshots from Instruments illustrating the issue below. Thanks! These traces are made a tiny bit more confusing because the real names of a and b are the same: read(at:). (They take different types as their parameters.) Here's the Time Profiler trace of the protocol extension implementation: And here's the trace for the duplicated-in-each-type version:

I'm joining the Ads iOS SDK team — our SDK is embedded in thousands of host apps. I want to understand the recommended approach for two performance challenges specific to embedded SDKs: what's the Instruments workflow for isolating our SDK's CPU and memory contribution from the host app's footprint, when we don't control or have access to the host app's source? are there any new APIs in iOS 27 that allow a third-party framework to declare or report its own performance budget to the host app, so developers can see SDK-level impact without custom instrumentation?

Is anyone else getting new warning about menu items with submenus when running on Tahoe? I'm getting big performance problems using my menu as well as seeing these messages and I'm wondering if there's a connection. My app is faceless with a NSStatusItem with an NSMenu. Specifically it's my own subclass of NSMenu where I have a lot of code to manage the menu's dynamic behavior. This code is directly in the menu subclass instead of in a controller because the app I forked had it this way, a little wacky but I don't see it being a problem. A nib defines the contents of the menu, and it's instantiated manually with code like: var nibObjects: NSArray? = [] guard let nib = NSNib(nibNamed: "AppMenu", bundle: nil) else { ... } guard nib.instantiate(withOwner: owner, topLevelObjects: &nibObjects) else { ... } guard let menu = nibObjects?.compactMap({ $0 as? Self }).first else { ... } Within that nib.instantiate call I see a warning logged that seems new to Tahoe, before the menu's awakeFromNib is called, that says (edited): Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> as a supermenu, but the supermenu does not seem to have any item with that submenu My_StatusItem_App.AppMenu: 0x7f9570c1a440 is my menu belonging to the NSStatusItem, NSMenu: 0x6000034e5340 is the submenu of one of its menu items. At a breakpoint in the NSMenu subclass's awakeFromNib I print self and see clear evidence of the warning's incorrectness. Below is a snippet of the console including the full warning, only edited for clarity and brevity. It shows on line 32 menu item with placeholder title "prototype batch item" that indeed has that submenu. Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> Title: Supermenu: 0x7f9570c1a440 (My StatusItem App), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010e4fa0 Do The Thing Again, ke mask='<none>'>", "<NSMenuItem: 0x6000010e5040 Customize\U2026, ke mask='<none>'>", "<NSMenuItem: 0x6000010e50e0, ke mask='<none>'>" ) believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu (lldb) po self <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010fd7c0 About My StatusItem App\U2026, ke mask='<none>', action: showAbout:, action image: info.circle>", "<NSMenuItem: 0x6000010fd860 Show Onboarding Window\U2026, ke mask='Shift', action: showIntro:>", "<NSMenuItem: 0x6000010fd900 Update Available\U2026, ke mask='<none>', action: installUpdate:, standard image: icloud.and.arrow.down, hidden>", "<NSMenuItem: 0x6000010e46e0, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4780 Start The Thing, ke mask='<none>', action: startTheThing:>", "<NSMenuItem: 0x6000010e4dc0 \U2318-\U232b key detector item, ke mask='<none>', view: <My_StatusItem_App.KeyDetectorView: 0x7f9570c1a010>>", "<NSMenuItem: 0x6000010e4e60, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4f00 saved batches heading item, ke mask='<none>', view: <NSView: 0x7f9570b4be10>, hidden>", "<My_StatusItem_App.BatchMenuItem: 0x6000016e02c0 prototype batch item, ke mask='<none>', action: replaySavedBatch:, submenu: 0x6000034e5340 ()>", "<NSMenuItem: 0x6000010f7d40, ke mask='<none>'>", "<My_StatusItem_App.ClipMenuItem: 0x7f956ef14fd0 prototype copy clip item, ke mask='<none>', action: copyClip:>", "<NSMenuItem: 0x6000010fa620 Settings\U2026, ke='Command-,', action: showSettings:>", "<NSMenuItem: 0x6000010fa6c0, ke mask='<none>'>", "<NSMenuItem: 0x6000010fa760 Quit My StatusItem App, ke='Command-Q', action: quit:>" ) Is this seemingly incorrect inconsistency message harmless? Am I only grasping at straws to think it has some connection to the performance issues with this menu?

Hi all, I've hit a reproducible issue where the presence of the SwiftUI instrument in a template prevents any data from being recorded, including from the other instruments in the same template. Removing the SwiftUI instrument immediately restores normal recording. Environment Host: macOS 26.4.1 (25E253), Mac mini Xcode / Instruments 26.4.1 (17E202) Device: iPhone 17, iOS 26.4.2 (23E261) (physical device, USB-attached) Symptom Recording the same app, same device, same session, only varying the template contents: SwiftUI template (as-is) => All lanes empty across the entire recording Same template with the SwiftUI instrument removed => Data collected normally (Time Profiler samples, Hangs, etc.) So it seems not an issue with the SwiftUI lanes specifically being empty — including the SwiftUI instrument appears to silence the entire recording. Steps to reproduce Open Instruments → pick the SwiftUI template (or build a custom template that includes the SwiftUI instrument alongside, e.g., Time Profiler). Target the device, attach to the running app. Record for ~10s, interact with the app. Stop. Result: every lane is empty. Edit the template, remove the SwiftUI instrument, re-record with no other changes. Result: normal data appears in the remaining instruments. Questions Is this a known regression in Instruments 26.4.1 on iOS 26.4.x? Is there a workaround to use the SwiftUI instrument on this OS combo (different Xcode build, runtime flag, entitlement)? Does it work for anyone on iOS 26.4.x + Xcode 26.4.1, or is everyone seeing this? I can file a Feedback if confirmed as a bug — wanted to check here first in case I'm missing a setup step. Thanks!

Hi, I want to recreate a chart from Apple Health and I have code like this. When I scroll - especially the week and month charts, there are performance issues. If I remove .chartScrollPosition(x: $scrollChartPosition), it runs smoothly, but I need to know which part of the chart is currently displayed. Can you help me? import Charts import SwiftUI struct MacroChartView: View { var selectedRange: ChartRange var binnedPoints: [MacroBinPoint] @State private var scrollChartPosition: Date = .now var body: some View { VStack { Text("\(selectedRange.rangeLabel(for: scrollChartPosition))") Chart(binnedPoints) { point in BarMark( x: .value("Date", point.date, unit: selectedRange.binComponent), y: .value("Calories", point.calories) ) } .frame(height: 324) .chartXVisibleDomain(length: selectedRange.visibleDomainLength()) .chartScrollableAxes(.horizontal) .chartScrollPosition(x: $scrollChartPosition) .chartScrollTargetBehavior(.valueAligned(matching: selectedRange.scrollAlignmentComponents)) .chartXAxis { switch selectedRange { case .week: AxisMarks(values: .stride(by: .day)) { date in AxisGridLine() AxisTick() AxisValueLabel(format: .dateTime.weekday(.abbreviated)) } case .month: AxisMarks(values: .stride(by: .weekOfYear)) { date in AxisGridLine() AxisTick() AxisValueLabel(format: .dateTime.day()) } case .halfYear: AxisMarks(values: .stride(by: .month)) { date in AxisGridLine() AxisTick() AxisValueLabel(format: .dateTime.month(.abbreviated)) } case .year: AxisMarks(values: .stride(by: .month)) { date in AxisGridLine() AxisTick() AxisValueLabel(format: .dateTime.month(.abbreviated)) } } } } } } enum MeasurementHistoryMode { case macros case comparisons } enum MacroKindToDisplay { case protein, fat, carbs } enum MacrosDisplayMode: Equatable { case all case single(MacroKindToDisplay) } enum ChartRange: String, CaseIterable { case week = "T" case month = "M" case halfYear = "6M" case year = "R" var binComponent: Calendar.Component { switch self { case .week, .month: return .day case .halfYear: return .weekOfYear case .year: return .month } } var scrollAlignmentComponents: DateComponents { switch self { case .week: return DateComponents(hour: 0, minute: 0, second: 0) case .month: return DateComponents(hour: 0) case .halfYear: return DateComponents(weekday: 1) case .year: return DateComponents(day: 1) } } func visibleDomainLength() -> Int { switch self { case .week: return 7 * 24 * 60 * 60 case .month: return 31 * 24 * 60 * 60 case .halfYear: return 6 * 31 * 24 * 60 * 60 case .year: return 12 * 31 * 24 * 60 * 60 } } func start(for date: Date) -> Date { let cal = Calendar.current switch self { case .week, .month: return cal.startOfDay(for: date) case .halfYear: return cal.dateInterval(of: .weekOfYear, for: date)?.start ?? cal.startOfDay(for: date) case .year: return cal.dateInterval(of: .month, for: date)?.start ?? cal.startOfDay(for: date) } } func rangeLabel(for start: Date) -> String { let end = start.addingTimeInterval(TimeInterval(visibleDomainLength())) let f = DateFormatter() f.dateFormat = Calendar.current.isDate(start, inSameDayAs: end) ? "MMM d" : "MMM d" return Calendar.current.isDate(start, inSameDayAs: end) ? f.string(from: start) : "\(f.string(from: start)) – \(f.string(from: end))" } } struct MacrosPoint: Identifiable { var id: Date { date } let date: Date let calories: Double let proteinInGrams: Double let carbsInGrams: Double let fatInGrams: Double } struct MacroBinPoint: Identifiable { var id: Date { date } let date: Date let calories: Double let proteinKcal: Double let carbsKcal: Double let fatKcal: Double } func bin(points: [MacrosPoint], for period: ChartRange) -> [MacroBinPoint] { let grouped = Dictionary(grouping: points) { point in period.start(for: point.date) } let bins = grouped.map { (start, items) -> MacroBinPoint in var calories = items.reduce(0) { $0 + $1.calories } var proteinKcal = items.reduce(0) { $0 + $1.proteinInGrams * 4 } var carbsKcal = items.reduce(0) { $0 + $1.carbsInGrams * 4 } var fatKcal = items.reduce(0) { $0 + $1.fatInGrams * 9 } calories /= Double(items.count) proteinKcal /= Double(items.count) carbsKcal /= Double(items.count) fatKcal /= Double(items.count) return MacroBinPoint(date: start, calories: calories, proteinKcal: proteinKcal, carbsKcal: carbsKcal, fatKcal: fatKcal) } .sorted { $0.date < $1.date } return bins } struct ExampleData { static let macrosPoints: [MacrosPoint] = [ MacrosPoint(date: Date(timeIntervalSince1970: 1687949774), calories: 1895, proteinInGrams: 115, carbsInGrams: 192, fatInGrams: 72),... ]

I've been testing Apple Silicon devices in their desktop configurations on the Mac Studio and now retired Mac Pro and it seems like they're greatly bottlenecked by their clock speeds. For reference here's my testing results. Testing Results: Mac Studio M2 Max • 32GBs RAM • 30 core GPU • 1TB Storage CPU Utilization • 60% • 20W CPU Temperature • 47ºC GPU Utilization • 100% • 20W GPU Temperature • 55ºC Fan Speed • 50% Workload Duration • 2hrs Another point is that the clock speed on the M2 Max's CPU is 3.5 GHz and on the GPU it is 1.44 GHz at max performance. Which the Mac Studio has no trouble pushing. My question is how do I push those clock speeds higher? Cause 1.44 GHz at 55ºC is evidence for extensive headroom. I'm sure there are tools internally for testing the upper limits of the silicon, but it makes no sense why it would be set so low the Mac Studio is at no worries of melting. Is there any way to push the performance of my Mac Studio? FB22713867 - Possibilities of Overclocking Apple Silicon

I am experiencing a UI issue after migrating my app from Xcode 16 to Xcode 26. In my implementation, I have a toolbar that contains multiple buttons along with a dropdown menu. The hierarchy for dropdown is as follows: **Toolbar → ToolbarItem → View → Menu → Picker ** Prior to Xcode 26, this setup worked smoothly in production builds. The dropdown (Menu + Picker) behaves as expected, and selecting a value triggers loading a dataset containing thousands of records on the screen. However, after upgrading to Xcode 26, I am observing an animation glitch when dismissing the dropdown after a selection is made. Specifically, the dropdown briefly shows a “capsule-like” animation artifact during dismissal, which persists for a few seconds. This visual issue is noticeable and negatively impacts the perceived performance and user experience of the app. This issue is occurring in an already released app built with Xcode 26. Questions: Is this a known issue or regression in Xcode 26 / SwiftUI Menu or Picker components? If yes, are there any known fixes or upcoming Xcode versions where this is resolved? If not, what would be the recommended approach to eliminate or minimize this animation glitch when dismissing the dropdown? Additional Context: The issue appears only after migration to Xcode 26. The dataset loaded after selection is large (thousands of records). The glitch specifically occurs during the dismissal animation of the Menu/Picker. Any guidance or workarounds would be greatly appreciated.

Hello, I’m experiencing a severe performance degradation when running CoreML models on a live AVFoundation video feed compared to offline or synthetic inference. This happens across multiple models I've converted (including SCI, RTMPose, and RTMW) and affects multiple devices. The Environment OS: macOS 26.3, iOS 26.3, iPadOS 26.3 Hardware: Mac14,6 (M2 Max), iPad Pro 11 M1, iPhone 13 mini Compute Units: cpuAndNeuralEngine The Numbers When testing my SCI_output_image_int8.mlpackage model, the inference timings are drastically different: Synthetic/Offline Inference: ~1.34 ms Live Camera Inference: ~15.96 ms Preprocessing is completely ruled out as the bottleneck. My profiling shows total preprocessing (nearest-neighbor resize + feature provider creation) takes only ~0.4 ms in camera mode. Furthermore, no frames are being dropped. What I've Tried I am building a latency-critical app and have implemented almost every recommended optimization to try and fix this, but the camera-feed penalty remains: Matched the AVFoundation camera output format exactly to the model input (640x480 at 30/60fps). Used IOSurface-backed pixel buffers for everything (camera output, synthetic buffer, and resize buffer). Enabled outputBackings. Loaded the model once and reused it for all predictions. Configured MLModelConfiguration with reshapeFrequency = .frequent and specializationStrategy = .fastPrediction. Wrapped inference in ProcessInfo.processInfo.beginActivity(options: .latencyCritical, reason: "CoreML_Inference"). Set DispatchQueue to qos: .userInteractive. Disabled the idle timer and enabled iOS Game Mode. Exported models using coremltools 9.0 (deployment target iOS 26) with ImageType inputs/outputs and INT8 quantization. Reproduction To completely rule out UI or rendering overhead, I wrote a standalone Swift CLI script that isolates the AVFoundation and CoreML pipeline. The script clearly demonstrates the ~15ms latency on live camera frames versus the ~1ms latency on synthetic buffers. (I have attached camera_coreml_benchmark.swift and coreml model (very light low light enghancement model) to this repo on github https://github.com/pzoltowski/apple-coreml-camera-latency-repro). My Question: Is this massive overhead expected behavior for AVFoundation + Core ML on live feeds, or is this a framework/runtime bug? If expected, what is the Apple-recommended pattern to bypass this camera-only inference slowdown? One think found interesting when running in debug model was faster (not as fast as in performance benchmark but faster than 16ms. Also somehow if I did some dummy calculation on on different DispatchQueue also seems like model got slightly faster. So maybe its related to ANE Power State issues (Jitter/SoC Wake) and going to fast to sleep and taking a long time to wakeup? Doing dummy calculation in background thought is probably not a solution. Thanks in advance for any insights!

I have two apps; one is a subset of functionality of the other. The smaller app has about 170 Swift files. The larger app has these files plus about 120 more. So I would expect the larger app to take around twice as long to build. Instead, the smaller app takes less than a minute to build while the larger app takes over 13 minutes to build; to be exact, it takes 15.3 times longer. While reviewing the build report, I noticed that the smaller app compiles the Swift files in batches, with each batch taking around 10 seconds, but with up to 17 batches running at once. In contrast, the larger app compiles all 290 Swift files in one giant batch, so apparently there is no multithreading of the Swift compilation (see screen shots below). The difference in the number of batches the smaller app compiles at once roughly corresponds to the difference in overall build time. Is there a build setting I can change to make the larger app compile Swift files in multiple smaller batches as the smaller app is doing? I checked SWIFT_COMPILATION_MODE and it's the same in both apps (Incremental for debugging and Whole Module for release) but I don't know what other settings I should check.

On and off I've been trying to figure out how to do hang detection in-application (at least from the user's point of view). Qualitatively what I'd like to do is have a process which runs sample(1) on the application after it's been unresponsive for more than a second or so. Basically, an in-app replacement for Spin Control. The problem I've been stuck on is: how do I tell? There used to be Core Graphics SPI (CGSRegisterNotifyProc with a value of kCGSEventNotificationAppIsUnresponsive) for doing this, but it doesn't work anymore (either due to sandboxing or system-wide security changes, I can't tell which but it doesn't matter). One thought I had was to have an XPC service which would expect to receive a checkin once per second from the host (via a timer set up by the host). If it didn't, it would start sample(1). This seems pretty heavyweight to me, since it means that once per second, I'm going to be consuming cycles to check in with the service. But I haven't been able to come up with a scheme that doesn't include some kind of check-in by the target process. Are there any APIs or strategies that I could use to accomplish this? Or is there some entitlement which would allow the application to request "application became unresponsive"/"application became responsive" notifications from the window server?

Context: I am building a macOS file (currently image only) browser using SwiftUI. The core view is a ScrollView containing a LazyVGrid. The layout is dynamic: as the window resizes, I calculate the optimal number of columns and spacing using a GeometryReader. The Issue: While scrolling is pretty smooth (thanks to custom image caching and prefetching), window resizing is significantly laggy. After having scrolled the UI stutters and drops frames heavily while dragging the window edge. The Code: https://github.com/MorusPatre/Binder

Background: During daily usage of iOS devices, devices experience noticeable thermal issues. This heating not only affects user experience, but may also lead to device performance throttling, shortened battery life, and other problems. We need better understanding and monitoring of device thermal states to optimize application performance and user experience. Issues Encountered: Insufficient thermal monitoring capabilities: Unable to obtain real-time accurate temperature data from devices Difficult power consumption analysis: Hard to determine which specific modules or threads cause high power consumption and heating Requested Solutions: Temperature Monitoring API: Provide accessible device temperature reading interfaces Thermal Attribution Analysis Capability: During heating events, we expect to receive more detailed power consumption monitoring data, such as CPU, GPU, network, location services, display, high power consumption thread stacks and other information to help developers identify high energy consumption operations

Hi Apple Developer Forums, I’m developing an iOS camera app that processes RAW captures using Core Image. I’m seeing a large “first use” performance penalty specifically when creating the CIImage from CIRAWFilter.outputImage. What’s slow (important detail) I’m measuring the time for: let rawFilter = CIRAWFilter(imageData: rawData, identifierHint: hint) let ciImage = rawFilter.outputImage This is not CIContext.render(...) / createCGImage(...). It’s just the time to access outputImage (i.e., building the Core Image graph / RAW pipeline setup). Observed behavior First time accessing CIRAWFilter.outputImage: ~3 seconds Second time (same app session, similar RAW): ~3 milliseconds So something heavy is happening only on first use (decoder initialization, pipeline setup, shader/library compilation, caching, etc.). Using Metal System Trace, I also noticed that during the slow first call there are many “Create MTLLibrary” events, while the second call doesn’t show this pattern. Warm-up attempts using bundled DNG I tried to “warm up” early (e.g., on camera screen entry) by loading a bundled DNG and then accessing CIRAWFilter.outputImage by taking a photo: Warm-up with a ~247 KB DNG → first real RAW outputImage cost drops to ~1.42s Warm-up with a ~25 MB DNG → first real RAW outputImage cost drops to ~843ms This helps, but it’s still far from the steady-state ~3ms. Warm-up by capturing a real RAW (works, but concerns) The only method that fully eliminates the delay is to trigger a real RAW capture programmatically before the user’s first photo, then use that captured rawData to warm up the CIRAWFilter.outputImage path. This brings the first user-facing capture close to the steady-state timing. However: In some regions, the camera shutter sound cannot be suppressed, so “hidden warm-up capture” is unacceptable UX. I’m also unsure whether triggering a real capture without an explicit user action could raise compliance/privacy concerns, even if the image is immediately discarded and never saved/uploaded. Questions Is the large first-time cost of CIRAWFilter.outputImage expected (RAW pipeline initialization / shader compilation)? Is there an Apple-recommended way to pre-initialize the Core Image RAW pipeline / Metal resources so the first outputImage is fast, without taking a real photo? Are there any best practices (e.g. CIContext creation timing, prepareRender(...), specific options) that reliably reduce this first-use overhead for CIRAWFilter? Attachments Figure 1: First RAW capture with no warm-up (~3s outputImage time) Figure 2: First RAW capture after warm-up with bundled DNG (improved but still hundreds of ms) Thanks for any guidance or experience sharing!

I’m trying to understand how SwiftUI List handles row lifecycle and reuse during scrolling. I have a list with around 60 card views; on initial load, only about 7 rows are created, but after scrolling to the bottom all rows appear to be created, and when scrolling back to the top I again observe multiple updates and apparent re-creation of rows. I confirmed this behavior using Instruments by profiling my app. Even though each row has a stable identifier, the row views still seem to be destroyed and recreated, which doesn’t resemble UIKit’s cell reuse model. I’d like clarity on how List uses identifiers internally, what actually gets reused versus recreated, and how developers should reason about performance and view lifetime in this case.

This is a screenshot from the Swift Task track in Xcode. I made these tasks with public actor ResourceManager { func foo() { for observer in observers { Task(name: "ResourceManager notify observers") { await notification(observer) } } } } I am confused why each of the task is showing as a separate task in the task lifetime summary. Is there a way to queue the trace in Instruments into the fact that these are indeed the same task?

Hello there! I wanted to give a native scrolling mechanism for the Swift Charts Graph a try and experiment a bit if the scenario that we try to achieve might be possible, but it seems that the Swift Charts scrolling performance is very poor. The graph was created as follows: X-axis is created based on a date range, Y-axis is created based on an integer values between moreless 0-320 value. the graph is scrollable horizontally only (x-axis), The time range (x-axis) for the scrolling content was set to one year from now date (so the user can scroll one year into the past as a minimum visible date (.chartXScale). The X-axis shows 3 hours of data per screen width (.chartXVisibleDomain). The data points for the graph are generated once when screen is about to appear so that the Charts engine can use it (no lazy loading implemented yet). The line data points (LineMark views) consist of 2880 data points distributed every 5 minutes which simulates - two days of continuous data stream that we want to present. The rest of the graph displays no data at all. The performance result: The graph on the initial loading phase is frozen for about 10-15 seconds until the data appears on the graph. Scrolling is very laggy - the CPU usage is 100% and is unacceptable for the end users. If we show no data at all on the graph (so no LineMark views are created at all) - the result is similar - the empty graph scrolling is also very laggy. Below I am sharing a test code: @main struct ChartsTestApp: App { var body: some Scene { WindowGroup { ContentView() Spacer() } } } struct LineDataPoint: Identifiable, Equatable { var id: Int let date: Date let value: Int } actor TestData { func generate(startDate: Date) async -> [LineDataPoint] { var values: [LineDataPoint] = [] for i in 0..<(1440 * 2) { values.append( LineDataPoint( id: i, date: startDate.addingTimeInterval( TimeInterval(60 * 5 * i) // Every 5 minutes ), value: Int.random(in: 1...100) ) ) } return values } } struct ContentView: View { var startDate: Date { return endDate.addingTimeInterval(-3600*24*30*12) // one year into the past from now } let endDate = Date() @State var dataPoints: [LineDataPoint] = [] var body: some View { Chart { ForEach(dataPoints) { item in LineMark( x: .value("Date", item.date), y: .value("Value", item.value), series: .value("Series", "Test") ) } } .frame(height: 200) .chartScrollableAxes(.horizontal) .chartYAxis(.hidden) .chartXScale(domain: startDate...endDate) // one year possibility to scroll back .chartXVisibleDomain(length: 3600 * 3) // 3 hours visible on screen .onAppear { Task { dataPoints = await TestData().generate(startDate: startDate) } } } } I would be grateful for any insights or suggestions on how to improve it or if it's planned to be improved in the future. Currently, I use UIKit CollectionView where we split the graph into smaller chunks of the graph and we present the SwiftUI Chart content in the cells, so we use the scrolling offered there. I wonder if it's possible to use native SwiftUI for such a scenario so that later on we could also implement some kind of lazy loading of the data as the user scrolls into the past.

I would like to inquire about Apple's recommended best practices for iPhone thermal management. Specifically, what actions are developers expected to take to prevent the device from overheating? I am aware that we should subscribe to Thermal State Notifications and throttle performance accordingly—such as by reducing streaming quality or temporarily disabling active features. Beyond these measures, are there any other strategies you recommend to mitigate thermal issues and help the device cool down?

I would like to inquire about Apple's recommended best practices for iPhone thermal management. Specifically, what actions are developers expected to take to prevent the device from overheating? I am aware that we should subscribe to Thermal State Notifications and throttle performance accordingly—such as by reducing streaming quality or temporarily disabling active features. Beyond these measures, are there any other strategies you recommend to mitigate thermal issues and help the device cool down?