On watchOS, the Developer Mode entry under Settings -> Privacy & Security is hidden by default and only appears after Xcode has attempted to connect to the watch as a development device. In my case, once Xcode triggers that surfacing, opening Settings -> Privacy & Security on the watch prompts for a 4-digit Screen Time passcode before granting access. No Screen Time passcode I set on the paired iPhone is accepted at this prompt, which prevents me from reaching the Developer Mode toggle to enable it. The passcode prompt only appears in this specific state. With no Xcode connection attempt (and therefore no Developer Mode entry surfaced in the menu), Settings → Privacy & Security opens normally on the watch with no prompt at all. Environment macOS: Tahoe 26.4.1 (Build 25E253) Xcode: 26.4.1 (24909.0.3) (Build 17E202) iPhone: iOS 26.4.2 Apple Watch: Ultra 3 running watchOS 26.4 All devices on release software (no betas). Xcode error Developer Mode disabled Domain: com.apple.dt.deviceprep Code: -28 Recovery Suggestion: To use [Watch Name] for development, enable Developer Mode in Settings → Privacy & Security. User Info: { DVTErrorCreationDateKey = "2026-04-30 09:38:57 +0000"; "com.apple.dt.DVTCoreDevice.operationName" = checkDeveloperMode; } Reproduction Pair Apple Watch to iPhone (paired fresh, set up as new, not restored from backup). Connect iPhone to Mac running Xcode 26.4.1. Before any Xcode connection attempt, open Settings -> Privacy & Security on the watch. The menu opens normally with no passcode prompt. There is no Developer Mode entry visible. In Xcode, attempt to use the Apple Watch as a run destination. Xcode returns the -28 / Developer Mode disabled error above and instructs me to enable Developer Mode in Settings -> Privacy & Security on the watch. After this attempt, the Developer Mode entry is surfaced in Settings -> Privacy & Security on the watch. Open Settings -> Privacy & Security on the watch in this surfaced state. The menu now prompts for a 4-digit Screen Time passcode before allowing access. The passcodes I have set on the paired iPhone are rejected. The passcode prompt is therefore conditional on the Developer Mode entry having been surfaced by a recent Xcode connection attempt. In step 3 (no surfacing) the menu opens freely; in step 6 (surfacing in effect) the menu is gated. What I have already tried Confirmed Screen Time is disabled on the paired iPhone. Confirmed Share Across Devices is enabled. Confirmed Content & Privacy Restrictions is off on the iPhone. Confirmed I am an adult in my Family Sharing group (not a managed/child account). Confirmed there are no configuration profiles installed (Settings -> General -> VPN & Device Management is empty). Set a fresh Screen Time passcode on the iPhone. Not accepted by the watch prompt. Used Forgot Passcode? → Apple ID authentication to reset the Screen Time passcode and set a new one. Not accepted by the watch prompt. Turned the Screen Time passcode off entirely on the iPhone. The watch still prompts for one when Xcode is connecting. Unpaired the Apple Watch and re-paired as new (not restored from backup). Issue persists. Tried entering the watch's own device passcode at the prompt. Not accepted. Question What credential is the watch's Privacy & Security menu actually checking against once the Developer Mode entry has been surfaced, and how can it be reset or cleared from a paired iPhone? Is anyone else seeing this conditional gating where the menu is only locked in the post-surfacing state? Any pointers from the Xcode / watchOS tools team would be appreciated. Happy to provide sysdiagnose or further details on request.

Hi, I can sign in to my Apple ID, but my Apple Developer account shows a “closed” status and I’m unable to access App Store Connect features. My app is currently showing “Ready for Distribution,” so the account appears active, but developer access is restricted. I’ve already contacted Apple Developer Support and am waiting for their response. Also, I temporarily can’t access my primary email due to a verification issue, so I’ve provided an alternate contact email and phone number in my support request. Has anyone experienced a similar situation or knows possible reasons for a “closed” developer status while the app remains approved? Thanks.

Hello, My app Wecheerup 360 Booth (App ID: 676214516, bundle ID: com.wecheerup.wecheerup360booth.ios) has been stuck in the App Review process for longer than expected. Version 1.0.3 was submitted on April 13, 2026 and has been in “In Review” status for over 15 days. There are no messages in the Resolution Center and all metadata appears to be complete on my side.

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

Is there any way to activate Storekit External Purchase Entitlements in Russian region currently? External Purchase documentation's form link for this specific region is not working. Is there a workaround to register for it?

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

I am developing an iOS app using Capacitor and Xcode. The app installs on my device but fails to launch with the error: “Quarantined due to high logging volume.” I have already: Configured signing correctly Enabled Developer Mode Disabled excessive logging in the app code Cleaned build and re-synced Capacitor The app still fails to run on a physical device (My iPhone 17Pro Max). Please advise on how to resolve this issue or whether this is related to a system-level logging limit or WebView restriction. Please suggest a reliable solution to the issue.

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

Our Account Holder has requested transfer of Account Holder to me. This transfer needs me to verify my account on the developer app. I am based in South Africa, its only giving me drivers license option to verify, but it keeps failing, no matter what i do. I urgently need help with this, my apps are not being able to be updated or anything. Please can anyone help and guide me. I have created numerous support requests and call back, without success.

I’m seeing a regression in Xcode 26.4 where Interface Builder will not allow connecting IBOutlets or IBActions. Symptoms: The usual gutter circle/dot does not appear next to IBOutlet / IBAction in the code editor Because of this, I cannot: drag from storyboard → code drag from code → storyboard The class is valid and already connected to the storyboard (existing outlets work) Assistant Editor opens the correct view controller file Important: The exact same project, unchanged, works perfectly in Xcode 26.3. I can create and connect outlets/actions normally there. ⸻ Environment Xcode: 26.4 macOS: 26.4 Mac Mini M4 Pro 64G Ram Project: Objective-C UIKit app using Storyboards This is a long-running, ObjC, project (not newly created) ⸻ What I’ve already tried To rule out the usual suspects: Verified View Controller Custom Class is correctly set in Identity Inspector Verified files are in the correct Target Membership Verified outlets are declared correctly in the .h file: @property (weak, nonatomic) IBOutlet UILabel *exampleLabel; Opened correct file manually (not relying on Automatic Assistant) Tried both: storyboard → code drag code → storyboard drag Tried using Connections Inspector Clean Build Folder Deleted entire DerivedData Restarted Xcode Updated macOS to 26.4 Ran: sudo xcodebuild -runFirstLaunch Confirmed required platform components installed Reopened project fresh ⸻ Observations In Xcode 26.4 the outlet “connection circles” are completely missing In Xcode 26.3 they appear immediately for the same code Existing connections still function at runtime — this is purely an Interface Builder issue ⸻ Question The gutter circles appearance has always been flaky in Xcode over the 13+ years I've been using it but now with 26.4 they have completely disappeared. Has anyone else seen this in Xcode 26.4, or found a workaround? At this point it looks like a regression in Interface Builder, but I haven’t found any mention of it yet.

Hello, I requested to change my Apple Developer account from Individual to Organization, but I haven’t received any feedback for several weeks now. I also don’t see any indication in the UI that the request is still pending, which makes me unsure whether it was processed at all. Additionally, I created a support ticket regarding this issue, but I have not received any response there either. Could someone please help me check the status of my request or advise me on what I should do next? Thank you.

I cannot distribute an app on xcode becouse he cannot find a certificate valid for my personal or business team. Need to address XCODE to access to my business account and not personal

Individual enrollment stuck after identity document upload, no response after days Order W1683765476 Enrollment ID 4Q6XCD5F3Z Case 102879350376

I have raised multiple tickets for the same on developer enrollment. There's no one to get back on the status. I have submitted all documents as requested, and was acknowledged of the same. Yet it's been more than a week, and I have no status update and no email from the developer enrollment team. My enrollment ID is M5B36N5PJ9. Kindly look into this at the earliest. This is not the experience I expected from Apple. Best

Hello Apple Developer Relations Team, I am seeking urgent assistance regarding my Apple Developer Program enrollment. On April 23, 2026, I submitted the requested verification documents and received a confirmation email stating that they would be reviewed and I would get a follow-up within two business days. However, today is April 29, 2026. Excluding the weekend (Saturday and Sunday), it has been 4 full business days since my submission, and I still haven't received any response or update regarding my account status. My project timeline is currently blocked by this delay, and I urgently need this account to be activated. Reference details: Invoice Number: MC66649793 Document Submission Date: April 23, 2026 Could an Apple staff member please look into my case and provide an update? Thank you in advance for your help.

Hello, I am writing to express my frustration regarding my Apple Developer Program enrollment, which has now been ongoing for over 3 months without resolution. Since my initial application, I have been asked to provide more than 20 different documents in multiple stages. I have promptly submitted every single document requested, without delay, each time. Despite this, my enrollment status is still showing as “In Progress,” and I have not received any clear timeline or final decision. This process has become extremely exhausting and inefficient. Continuously requesting additional documents over such a long period, without concluding the review, is not a reasonable experience. At this point, I kindly but firmly request that: My application be reviewed in full without further unnecessary delays A final decision be made as soon as possible Any remaining requirements (if truly necessary) be clearly communicated all at once I have done everything required on my end, and I expect the same level of efficiency and clarity from Apple. Please prioritize this case and provide a resolution at the earliest. Enrollment id: 37RX4442RK Thank you.

Hello Seniors, this would be my first time in here and i would need help on how to get duns number cos am a new dev from Nigeria looking to push my app to app store but i need my account verified first

Any idea why this might happen and how to stop it? I try to run a simple iOS app from Xcode, in the iOS Simulator, and it takes a very long time to start. I see "mediaanalysisd" in the Activity Monitor, taking a lot of CPU, fans are blowing. When I quit the simulator, the mediaanalysisd process goes away and the fans stop. Maybe related: I have a 2020 MacBook Pro with Intel chips, and general it's been having more bogged down performance and fans blowing that in years past. My suspicion is the latest macOS updates are not caring much about Intel CPUs...

Description Xcode 26.4.1 crashes immediately on launch with a code signature error. The issue exists on macOS 26.4.1 and persists after upgrading to macOS 26.5 (25F5058e) and attempting 26.6 beta. Crash Details: Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) Termination Reason: Namespace CODESIGNING, Code 2, Invalid Page Key symbols: dyld3::MachOFile::trieWalk, dyld4::JustInTimeLoader::applyFixups, dyld4::Loader::forEachBindTarget All Steps Tried (All Failed): Fresh reinstall from Mac App Store and .xip from Developer website Multiple sudo xattr -cr + sudo codesign --force --deep --strict --options=runtime --sign - Deleted all Xcode caches, DerivedData, and preferences Tested in a brand new user account (same crash) Downgraded Xcode to older versions macOS remains on 26.4.1 (issue existed here) and upgraded to 26.5 / attempted 26.6 beta — still same crash Refreshed Apple Worldwide Developer Relations certificates Multiple restarts The crash report is identical every time. System Information Model: MacBook Pro (M1 Pro, MacBookPro18,1) macOS: 26.5 (25F5058e) — issue started after upgrade from 26.4.1 Xcode: 26.4.1 (24909.0.3) SIP: Enabled Developer Mode: Enabled Additional Notes Other applications launch normally. This appears to be a system-level compatibility issue introduced in macOS 26.5's stricter code signing validation on mapped files / chained fixups. Request Is there a known workaround? Is Apple preparing a fix in a future macOS 26.5 patch or Xcode update? What additional information would help? Thank you!

Hi everyone, I’m encountering an issue with Xcode Cloud when trying to notarize my macOS app. As shown in the screenshot, there are no errors in the logs, but the process gets stuck indefinitely. The message says: The post-action could not be completed because the build was canceled. No artifacts are generated at all. This problem started recently. Notarization works perfectly when I submit from my local Xcode, so it seems to be specific to Xcode Cloud. Has anyone else experienced this?