After upgrading from Xcode 26.5 to Xcode 26.6, I noticed that the built-in Agents section has changed. My environment Xcode 26.6 (Build 17F113) macOS 26.5.2 (Build 25F84) Installed from the Mac App Store Signed in with my Apple ID in Xcode Apple Intelligence is enabled Chat providers work normally (ChatGPT, Claude, Google) What I expected According to Apple's documentation, the Intelligence settings should display built-in Agents such as: Claude Agent Codex with a Get button to install them. Reference: https://developer.apple.com/documentation/xcode/setting-up-coding-intelligence What actually happens After upgrading to Xcode 26.6, the Agents section only contains: Allow external agents to use Xcode tools Add an Agent... The built-in Agents (Claude Agent and Codex) are completely missing. The Chat section still works normally. Comparison On the same Mac: Xcode 26.5 shows: Claude Agent Codex Get buttons Xcode 26.6 only shows MCP ("Allow external agents to use Xcode tools") and "Add an Agent...", with no built-in Agents. Things I have already tried Deleted all Xcode preferences Deleted ~/Library/Developer Deleted ~/Library/Application Support/Xcode Reinstalled Xcode 26.6 Signed out/in of Apple ID Verified Intelligence is enabled No change. Additional information The following directory is never created: ~/Library/Developer/Xcode/CodingAssistant Searching Xcode preferences also shows no Agent-related configuration. Question Is this an intentional change in Xcode 26.6, or is this a bug? If it's expected, how can I restore the built-in Agent catalog (Claude Agent / Codex)? Thanks!

Installed from the Mac App Store Signed in with my Apple ID in Xcode Apple Intelligence is enabled Chat providers work normally (ChatGPT, Claude, Google) What I expected According to Apple's documentation, the Intelligence settings should display built-in Agents such as: Claude Agent Codex with a Get button to install them. Reference: https://developer.apple.com/documentation/xcode/setting-up-coding-intelligence What actually happens After upgrading to Xcode 26.6, the Agents section only contains: Allow external agents to use Xcode tools Add an Agent... The built-in Agents (Claude Agent and Codex) are completely missing.

Dear Apple Developer Support Team, I am writing to seek clarification on the timeline behavior and app status associated with the MetricKit cpuExceptionDiagnostics payload. In a recent diagnostic log collected from production, we observed the following values: timeStampBegin: "2026-07-07 10:37:00" timeStampEnd: "2026-07-07 10:37:00" totalSampledTime: "168 sec" Since both timeStampBegin and timeStampEnd share the exact same second (10:37:00), but the totalSampledTime indicates a continuous sampling duration of 168 seconds, we are having trouble accurately correlating this incident with our internal server logs. Could you please clarify the following questions: What exactly does the timestamp "2026-07-07 10:37:00" represent? Is it the sampling start time, the sampling end time, or the moment the diagnostic log was generated/written by the system? If "2026-07-07 10:37:00" represents the log generation time (or the moment the exception was triggered), how should we determine the actual start and end times of the 168-second sampling window? For instance, does it mean the sampling occurred strictly before this timestamp (from 10:34:12 to 10:37:00), or is there a different calculation method? Does a cpuExceptionDiagnostics event imply that the app crashed or was terminated by the OS? Or is it merely a non-fatal telemetry log capturing heavy CPU usage/resource limit violations while the app remained running? Understanding the precise timeline and lifecycle impact of MetricKit diagnostics is crucial for us to correlate client-side resource issues with backend performance and user activities. Thank you for your time and guidance. Best regards

Hi Apple Developer Technical Support Team, I hope this message finds you well. I am writing to seek urgent clarification on a profiling question that is directly impacting our SDK customers. Context We provide an iOS SDK that is integrated into third-party applications. Our SDK includes a background monitoring thread created via: -[NSObject performSelectorInBackground:withObject:] As documented, threads created through this API carry a default (relatively low) scheduling priority. Inside the thread, we call sleep(1) once per second for periodic idle intervals, and we collect CPU usage metrics using kernel APIs: • task_threads() • thread_info() Both calls involve kernel-level operations and are known to trigger context switches internally. The Core Issue — Customer Misinterpretation When our customers profile their apps using Instruments with "Context Switch Sampling" enabled, they observe that our SDK thread shows a large proportion of time labeled as "Runnable" and "Blocked". A representative example: • Total (wall clock): 4.30 s — 100% • Runnable: 3.06 s — 71.4% ← customers flag this as high CPU usage • Blocked: 1.05 s — 24.5% • Running: 176 ms — 4.1% ⚠️ Our customers are interpreting the "Runnable" time (71.4%) as CPU consumption by our SDK, and are raising concerns that our SDK is degrading their app's performance. We strongly believe this interpretation is incorrect — a thread in the "Runnable" state is merely waiting in the scheduler's ready queue and has NOT been assigned to any CPU core, therefore it should NOT consume any CPU resources. However, we need an official confirmation from Apple to address our customers' concerns definitively. Our Questions Do the time values shown next to "Runnable" and "Blocked" in the Time Profiler call tree represent wall-clock waiting time (i.e., time spent in that state), or actual CPU consumption time? Does a thread in the "Runnable" state consume any CPU resources on the device? We want to confirm clearly: does Runnable time contribute to CPU load or battery drain in any way? Is it correct that the high Runnable time observed is caused by the combination of: a. The low thread scheduling priority assigned by performSelectorInBackground:withObject:, and b. Context switch overhead introduced by the task_threads() and thread_info() kernel calls? Is there any official Apple documentation that explicitly describes the semantics of "Runnable" and "Blocked" time in Instruments, which we could reference when communicating with our customers? An authoritative answer from Apple would allow us to accurately explain the profiling data to our customers and clarify that the high "Runnable" time does NOT represent CPU consumption by our SDK. Thank you very much for your time and support. Best regards

Hi Apple Developer Technical Support Team, I hope this message finds you well. I am writing to seek urgent clarification on a profiling question that is directly impacting our SDK customers. Context We provide an iOS SDK that is integrated into third-party applications. Our SDK includes a background monitoring thread created via: -[NSObject performSelectorInBackground:withObject:] As documented, threads created through this API carry a default (relatively low) scheduling priority. Inside the thread, we call sleep(1) once per second for periodic idle intervals, and we collect CPU usage metrics using kernel APIs: • task_threads() • thread_info() Both calls involve kernel-level operations and are known to trigger context switches internally. The Core Issue — Customer Misinterpretation When our customers profile their apps using Instruments with "Context Switch Sampling" enabled, they observe that our SDK thread shows a large proportion of time labeled as "Runnable" and "Blocked". A representative example: • Total (wall clock): 4.30 s — 100% • Runnable: 3.06 s — 71.4% ← customers flag this as high CPU usage • Blocked: 1.05 s — 24.5% • Running: 176 ms — 4.1% ⚠️ Our customers are interpreting the "Runnable" time (71.4%) as CPU consumption by our SDK, and are raising concerns that our SDK is degrading their app's performance. We strongly believe this interpretation is incorrect — a thread in the "Runnable" state is merely waiting in the scheduler's ready queue and has NOT been assigned to any CPU core, therefore it should NOT consume any CPU resources. However, we need an official confirmation from Apple to address our customers' concerns definitively. Our Questions Do the time values shown next to "Runnable" and "Blocked" in the Time Profiler call tree represent wall-clock waiting time (i.e., time spent in that state), or actual CPU consumption time? Does a thread in the "Runnable" state consume any CPU resources on the device? We want to confirm clearly: does Runnable time contribute to CPU load or battery drain in any way? Is it correct that the high Runnable time observed is caused by the combination of: a. The low thread scheduling priority assigned by performSelectorInBackground:withObject:, and b. Context switch overhead introduced by the task_threads() and thread_info() kernel calls? Is there any official Apple documentation that explicitly describes the semantics of "Runnable" and "Blocked" time in Instruments, which we could reference when communicating with our customers? An authoritative answer from Apple would allow us to accurately explain the profiling data to our customers and clarify that the high "Runnable" time does NOT represent CPU consumption by our SDK. Thank you very much for your time and support. Best regards

Subject: [SDK / Instruments] Clarification on Runnable & Blocked Time Semantics — Customers Misinterpreting as CPU Usage Hi Apple Developer Technical Support Team, I hope this message finds you well. I am writing to seek urgent clarification on a profiling question that is directly impacting our SDK customers. Context We provide an iOS SDK that is integrated into third-party applications. Our SDK includes a background monitoring thread created via: -[NSObject performSelectorInBackground:withObject:] As documented, threads created through this API carry a default (relatively low) scheduling priority. Inside the thread, we call sleep(1) once per second for periodic idle intervals, and we collect CPU usage metrics using kernel APIs: • task_threads() • thread_info() Both calls involve kernel-level operations and are known to trigger context switches internally. The Core Issue — Customer Misinterpretation When our customers profile their apps using Instruments with "Context Switch Sampling" enabled, they observe that our SDK thread shows a large proportion of time labeled as "Runnable" and "Blocked". A representative example: • Total (wall clock): 4.30 s — 100% • Runnable: 3.06 s — 71.4% ← customers flag this as high CPU usage • Blocked: 1.05 s — 24.5% • Running: 176 ms — 4.1% ⚠️ Our customers are interpreting the "Runnable" time (71.4%) as CPU consumption by our SDK, and are raising concerns that our SDK is degrading their app's performance. We strongly believe this interpretation is incorrect — a thread in the "Runnable" state is merely waiting in the scheduler's ready queue and has NOT been assigned to any CPU core, therefore it should NOT consume any CPU resources. However, we need an official confirmation from Apple to address our customers' concerns definitively. Our Questions Do the time values shown next to "Runnable" and "Blocked" in the Time Profiler call tree represent wall-clock waiting time (i.e., time spent in that state), or actual CPU consumption time? Does a thread in the "Runnable" state consume any CPU resources on the device? We want to confirm clearly: does Runnable time contribute to CPU load or battery drain in any way? Is it correct that the high Runnable time observed is caused by the combination of: a. The low thread scheduling priority assigned by performSelectorInBackground:withObject:, and b. Context switch overhead introduced by the task_threads() and thread_info() kernel calls? Is there any official Apple documentation that explicitly describes the semantics of "Runnable" and "Blocked" time in Instruments, which we could reference when communicating with our customers? An authoritative answer from Apple would allow us to accurately explain the profiling data to our customers and clarify that the high "Runnable" time does NOT represent CPU consumption by our SDK. Thank you very much for your time and support. Best regards

When I set the option parameter to OSLogEnumeratorReverse, the iteration order of OSLogEnumerator is still from front to back in time When I set the options parameter to 0 and the position parameter to the first 5 seconds of the current time, OSLogEnumerator can still iterate over the previous 5 seconds #import "ViewController.h" #import <OSLog/OSLog.h> @interface ViewController () @property(strong, nonatomic)OSLogStore *logStore; @property(strong, nonatomic)NSDateFormatter *formatter; @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; NSError *err = nil; self.logStore = [OSLogStore storeWithScope:OSLogStoreCurrentProcessIdentifier error:&err]; if (!self.logStore || err) { NSLog(@"error: %@", err); NSAssert(0, @""); } self.formatter = [[NSDateFormatter alloc] init]; [self.formatter setDateFormat:@"[yyyy-MM-dd HH:mm:ss:SSS]"]; } - (IBAction)addLog:(id)sender { static int i = 0; NSLog(@"[test] %@ this is a log with index:%d", [self.formatter stringFromDate:[NSDate date]], i++); } - (IBAction)printLogWithReverse:(id)sender { NSError *err = nil; NSPredicate *preeicate = [NSPredicate predicateWithFormat:@"composedMessage contains %@" argumentArray:@[@"[test]"]]; OSLogEnumerator *enumer = [self.logStore entriesEnumeratorWithOptions:OSLogEnumeratorReverse position:nil predicate:preeicate error:&err]; if (err) { NSLog(@"enumer error:%@", err); NSAssert(0, @""); } OSLogEntryLog *entry = nil; while (entry = [enumer nextObject]) { NSString *message = [entry composedMessage]; printf("log: %s\n", message.UTF8String); } } - (IBAction)printLogWithPosition:(id)sender { NSError *err = nil; NSPredicate *preeicate = [NSPredicate predicateWithFormat:@"composedMessage contains %@" argumentArray:@[@"[test]"]]; NSDate *posDate = [NSDate dateWithTimeIntervalSinceNow:-5]; OSLogPosition *pos = [self.logStore positionWithDate:posDate]; OSLogEnumerator *enumer = [self.logStore entriesEnumeratorWithOptions:0 position:pos predicate:preeicate error:&err]; if (err) { NSLog(@"enumer error:%@", err); NSAssert(0, @""); } const char *now = [self.formatter stringFromDate:[NSDate date]].UTF8String; const char *posStart = [self.formatter stringFromDate:posDate].UTF8String; OSLogEntryLog *entry = nil; while (entry = [enumer nextObject]) { NSString *message = [entry composedMessage]; printf("log(now:%s, pos:%s): %s\n", now, posStart, message.UTF8String); } } @end The method of - (IBAction)printLogWithReverse:(id)sender print result not reversed by time. log: [test] [2025-02-18 17:35:50:175] this is a log with index:0 log: [test] [2025-02-18 17:35:51:040] this is a log with index:1 log: [test] [2025-02-18 17:35:51:174] this is a log with index:2 log: [test] [2025-02-18 17:35:51:323] this is a log with index:3 log: [test] [2025-02-18 17:35:51:473] this is a log with index:4 log: [test] [2025-02-18 17:35:51:640] this is a log with index:5 log: [test] [2025-02-18 17:35:51:773] this is a log with index:6 log: [test] [2025-02-18 17:35:51:923] this is a log with index:7 The method of - (IBAction)printLogWithPosition:(id) print result should not contain the log from 5 seconds ago because I set the start time position in the position argument [test] [2025-02-18 17:43:58:741] this is a log with index:0 [test] [2025-02-18 17:43:58:940] this is a log with index:1 [test] [2025-02-18 17:43:59:458] this is a log with index:2 [test] [2025-02-18 17:43:59:923] this is a log with index:3 log(now:[2025-02-18 17:44:51:132], pos:[2025-02-18 17:44:46:032]): [test] [2025-02-18 17:43:58:741] this is a log with index:0 log(now:[2025-02-18 17:44:51:132], pos:[2025-02-18 17:44:46:032]): [test] [2025-02-18 17:43:58:940] this is a log with index:1 log(now:[2025-02-18 17:44:51:132], pos:[2025-02-18 17:44:46:032]): [test] [2025-02-18 17:43:59:458] this is a log with index:2 log(now:[2025-02-18 17:44:51:132], pos:[2025-02-18 17:44:46:032]): [test] [2025-02-18 17:43:59:923] this is a log with index:3

In statistical objects In MXMetricPayload histogrammedTimeToFirstDrawKey start times not equal applicationExitMetrics exit： case1: "applicationExitMetrics": { "backgroundExitData": { "cumulativeNormalAppExitCount": 3, "cumulativeMemoryPressureExitCount": 4 }, "foregroundExitData": { "cumulativeMemoryResourceLimitExitCount": 3 } }, "applicationLaunchMetrics": { "histogrammedTimeToFirstDrawKey": { "histogramNumBuckets": 14, "histogramValue": { "10": { "bucketCount": 1, "bucketStart": "1740 ms", "bucketEnd": "1749 ms" }, "2": { "bucketCount": 1, "bucketStart": "1440 ms", "bucketEnd": "1449 ms" }, "3": { "bucketCount": 2, "bucketStart": "1490 ms", "bucketEnd": "1499 ms" }, "11": { "bucketCount": 1, "bucketStart": "1780 ms", "bucketEnd": "1789 ms" }, "4": { "bucketCount": 1, "bucketStart": "1500 ms", "bucketEnd": "1509 ms" }, "5": { "bucketCount": 1, "bucketStart": "1580 ms", "bucketEnd": "1589 ms" }, "12": { "bucketCount": 1, "bucketStart": "1860 ms", "bucketEnd": "1869 ms" }, "6": { "bucketCount": 1, "bucketStart": "1620 ms", "bucketEnd": "1629 ms" }, "13": { "bucketCount": 1, "bucketStart": "1990 ms", "bucketEnd": "1999 ms" }, "7": { "bucketCount": 1, "bucketStart": "1650 ms", "bucketEnd": "1659 ms" }, "0": { "bucketCount": 1, "bucketStart": "1400 ms", "bucketEnd": "1409 ms" }, "8": { "bucketCount": 1, "bucketStart": "1660 ms", "bucketEnd": "1669 ms" }, "1": { "bucketCount": 1, "bucketStart": "1430 ms", "bucketEnd": "1439 ms" }, "9": { "bucketCount": 1, "bucketStart": "1730 ms", "bucketEnd": "1739 ms" } } }, In this Case the app cold started 15 times, but quit only 10 times， why？？ case2: "applicationExitMetrics": { "backgroundExitData": { "cumulativeMemoryPressureExitCount": 1 }, "foregroundExitData": { "cumulativeMemoryResourceLimitExitCount": 3, "cumulativeNormalAppExitCount": 1 } }, "applicationLaunchMetrics": { "histogrammedTimeToFirstDrawKey": { "histogramNumBuckets": 3, "histogramValue": { "0": { "bucketCount": 1, "bucketStart": "1490 ms", "bucketEnd": "1499 ms" }, "1": { "bucketCount": 1, "bucketStart": "1680 ms", "bucketEnd": "1689 ms" }, "2": { "bucketCount": 1, "bucketStart": "1880 ms", "bucketEnd": "1889 ms" } } }, The app cold started 3 times, but quit unexpectedly reached 5 times， why？？？