Overview

Hello, I need guidance on App Store Connect product state vs StoreKit behavior during App Review. Stack: iOS app (Expo / React Native), subscriptions via RevenueCat + StoreKit. Bundle ID matches App Store Connect. RevenueCat API keys — what I’ve verified locally: With the production RevenueCat API key (iOS appl_..., same as the submitted build), everything works on local device but not when I download it from TestFlight. I have also tested with RevenueCat’s sandbox / test API key (the separate key intended for sandbox/testing). That setup works as well — I can load offerings and complete test purchases the same way What RevenueCat (SDK / dashboard health) reports: Product monthly is configured in RevenueCat. Warnings that products aren’t approved in App Store Connect yet and that the default offering has configuration issues. Apple’s product state: WAITING_FOR_REVIEW. The SDK still states that test purchases are possible. What App Review reports: After onboarding a new business account, “Activate subscription” leads to an error (plans don’t load / purchase path fails). Review suggested an app code issue. Why this is confusing: Locally, both RevenueCat key modes I tried (production and sandbox/test) work with Apple Sandbox on the device. The submitted build uses the production RevenueCat key. Review still sees a failure. Questions: For IAP in WAITING_FOR_REVIEW, should App Review always use an Apple Sandbox account to test subscriptions until the product is fully approved? Is it documented that StoreKit may not return products during review without Sandbox while the product remains WAITING_FOR_REVIEW? Has anyone else seen “works locally (prod + sandbox RevenueCat keys + Apple Sandbox) but Review fails” with the same WAITING_FOR_REVIEW state? Thanks for any official documentation or similar threads.

app id is 6759403692 i have been waiting to be approved my app for two months. I mailed and called several times but no response. please someone help me.

We've received several reports of a new bug while setting up our products with WAC. The Accessory Setup UI appears with a blank network selected and the message 'This accessory will be set up to join "(null)".' at top. The user can tap "Show Other Networks..." to select another network, but this experience is very confusing. Why does this UI present a choice that is known to be invalid when other valid choices exist? I've captured a screenshot and sysdiagnose from this case. In most cases this problem happens only intermittently, but I can reproduce it consistently by disconnecting my iPhone from any WiFi network (WiFi remains enabled). My suggestion for a better user experience is that this UI should select the default network according to these rules: The network to which iPhone is currently connected. Any network which is in the known/my list for this iPhone Any valid network I believe rule #1 is the existing behavior, but applying rules #2 and #3 as fallbacks would be an improvement. Is there anything I can change in my iOS code or in my accessory's WAC server to improve this experience?

In an application we are developing, we would like to show a (non-interactable) textfield when a hardware keyboard is connected to the iPad. Therefore my question: Using SwiftUI, is it possible to detect the presence of a hardware keyboard and store that state inside a boolean like isHardwareKeyboardConnected?

Hi everyone, I am hoping someone here has experienced this and can help, because we are in a really difficult position right now. We received a notice from App Review regarding Guideline 5.6.4 and have been working hard to prepare a full response with supporting evidence. The problem is that a draft response exists in App Store Connect that we cannot submit or delete. Every time we click either Submit or Delete Draft, we get the same error: "The resource cannot be found" That is it. No further explanation, no workaround, nothing. The draft is just stuck there and we cannot get past it. Because we could not submit through the normal channel, we uploaded a new build with our action plan included in the notes, hoping that would reach the review team. The build has been sitting there unreviewed. We have raised a support ticket with Apple Developer Support and have not received any response. The clock is ticking. App Review has given us a deadline to respond or face removal from the App Store. We have our response ready. We have our evidence ready. We just physically cannot submit it because of what appears to be a technical bug on Apple's side. Has anyone else hit this "resource cannot be found" error on a draft App Review response? Is there any other channel we can use to get this in front of the App Review team directly? We have tried everything we can think of. Any help would be massively appreciated. This is our livelihood and the deadline pressure combined with a broken system is genuinely distressing. Thank you

When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?

Hi, I tried to enroll since week ago, went thru the whole process, but now I'm stuck on "Enrollement not completed - You enrollment in the Apple Developper pogram could not be completed at this time." I opened a case (ID: 102869536459), but I haven’t received a response yet. What's next ?

Each time I launch a Debug version of the app on iOS Simulator, I see the Launch Screen presented and then about a 30-second delay before the app is responsive and debug output appears in the console panel. Filed FB22345091

Hello, I'm the developer of RPGPlayer, a game emulator for RPG Maker games that has been live on the App Store since 2025. I'm writing here out of frustration and desperation after 2+ months of trying to publish a critical bug fix update. The Situation I submitted v2.4 on February 21, 2026. Since then, I have received 9+ rejections under Guidelines 4.7 and 2.5.2. Every single rejection message is word-for-word identical — the same copy-pasted text, every time. None of my detailed technical responses have ever been acknowledged or addressed. I have submitted appeals twice through the App Review Board. Both times I received the same automated response: "The App Review Board will contact you directly once they've completed their investigation." The first appeal went unanswered for over 30 days. At this point, I genuinely do not believe a human being has opened my app during any of these reviews. The Technical Reality RPGPlayer is a game emulator, explicitly permitted under Guideline 4.7. The rejection under 4.7 states that "HTML5-based games appear to be an incidental feature." This is incorrect. RPG Maker MV/MZ games are built on HTML5/JavaScript by design — that is the engine's native architecture on all platforms including PC and consoles. The WKWebView is the emulation layer, not a web browser or game portal. There are zero bundled games. The rejection under 2.5.2 states the app "installed or launched executable code." The app does not download anything from the internet. It includes a bundled, statically-linked runtime (MKXP-Z) that interprets local game scripts from user-imported files — identical to how Delta Emulator interprets ROM instructions. The Double Standard Other apps on the App Store use the exact same architecture as RPGPlayer: Delta Emulator — approved under Guideline 4.7, interprets user-provided ROM files Quest Play — RPG Maker MV/MZ player, uses the same WebView approach, currently receiving updates ArkRPG — same engine, same architecture, also on the App Store and getting updates. These apps are approved and actively updated. RPGPlayer is being rejected with automated messages for doing the exact same thing. What I've Tried Detailed technical responses in Resolution Center — ignored Two App Review Board appeals — no meaningful response Contact Us support requests — automated replies Provided ROM files, video walkthroughs, and thorough App Review Notes — none of it acknowledged The Impact My users have been waiting 50+ days for a critical bug fix. Some have left negative reviews calling me a scammer because they think I abandoned the app. I haven't. I've been fighting this review process every single day. I have a Meet with Apple appointment scheduled. But I wanted to share this here as well — both to ask if anyone has faced a similar situation with emulator apps, and to document what is happening in case it helps other developers. Has anyone successfully resolved a 4.7 + 2.5.2 rejection for a legitimate emulator app? Any advice is welcome.

We have tried using background tasks for file saving via (UIBackgroundTaskIdentifier) beginBackgroundTaskWithName:(NSString *) taskName expirationHandler:(void (^)(void)) handler; when our app goes into the background and/or is closed by the user. But we cannot make it work the way the documentation tells us it should. While task creation never reports an issue (in fact it never calls our expiration handler at all) and the returned task id is always valid, when we ask for how much time we have left via backgroundTimeRemaining we always get 6s instead of the specified 30s. We tried to create the task when the app state goes to inactive or when our delegate is called via applicationDidEnterBackground but it makes no difference, besides the fact that the remaining time reported is basically max double, when the app is not in background yet which is by design as far we understand. But we don't even get the 6s for saving when a user closes the app. Because almost immediately after applicationDidEnterBackground our delegate is called via applicationWillTerminate which will then again almost immediately end in the app receiving a SIGKILL. So we must be doing something wrong. Why would applicationWillTerminate be called at all when we have a valid background task that reports we have 6s left? We tried blocking the thread in both background and terminate to at least give us the 5s the spec says we have before we get the SIGKILL. That works in general but doesn't feel like the correct approach and we do need more time than the 5s or 6s we get this way. Are we supposed to add something to our plist in order for these background tasks to work correctly? It is very confusing that there is a second mechanism that's also called background tasks for running apps in the background in general, which is not applicable to us. Are we supposed to block somewhere when we create the task? Or even spin up an extra thread for the task? Why is our expirationHandler never called? The spec says that our handler should be called if it was unable to "grant the ask assertion" so it seems like we do not have that problem. But it's also supposed to be called just before we are running out of time but by that time the app is already dead. This was all tested on iOS 26.3 and it is probably worth mentioning that our app is Qt-based.

I'm seeing a critical issue where a custom CKRecordZone is consistently deleted server-side when a second iCloud account interacts with a zone-wide CKShare. I've reproduced this 20+ times across two days and have exhausted every client-side fix I can think of. Looking for guidance on what might be going wrong. Setup Container: iCloud.com.cohencooks (production app on App Store) Custom CKRecordZone in owner's private database Zone-wide CKShare(recordZoneID:) (iOS 15+ zone sharing) SwiftData with ModelConfiguration(cloudKitDatabase: .none) — no automatic CloudKit mirroring Acceptance via CKFetchShareMetadataOperation → CKContainer.accept(metadata) (no UICloudSharingController) Minimal reproduction // 1. Owner creates zone + share let zone = CKRecordZone(zoneName: "MyZone") try await privateDB.save(zone) let share = CKShare(recordZoneID: zone.zoneID) share[CKShare.SystemFieldKey.title] = "My Share" as CKRecordValue share.publicPermission = .readWrite let (results, _) = try await privateDB.modifyRecords(saving: [share], deleting: []) // 2. Owner pushes ~500 records to zone — all succeed // 3. Second user (different iCloud account) accepts share let metadata = try await container.shareMetadata(for: shareURL) try await container.accept(metadata) // 4. Owner's next CKFetchRecordZoneChangesOperation → zoneNotFound (code 26) // Zone is permanently gone. allRecordZones() confirms deletion. What I observe Three distinct failure patterns depending on configuration: Pattern 1 — publicPermission = .readWrite, no addParticipant: Zone dies instantly after acceptance. First push notification shows cloudkit.share changed (zone alive), second push notification returns zoneNotFound. The non-owner never successfully wrote anything. Pattern 2 — publicPermission = .none with explicit addParticipant: Zone survives acceptance and 2-3 minutes of bidirectional sync (non-owner pulls 578 records, pushes meal plans back). Then a push notification arrives and the zone is gone. This is dramatically better than Pattern 1 but still fails. Pattern 3 — Container destabilization after repeated testing: After 20+ create/delete cycles in one day, zones die from the owner's own push notifications — no second device involved at all. The container appears to enter an unstable state. What I've ruled out Hypothesis Test Result publicPermission = .readWrite Changed to .none + explicit addParticipant Zone survived longer but still eventually deleted Zone name tombstoning Tested 6 fresh names never used in this container All eventually deleted Non-owner writes causing deletion Gated ALL non-owner push methods (recipe, meal plan, grocery, photo, event) Zone still deleted database.save(share) vs modifyRecords Switched to modifyRecords(saving:deleting:) Zone still deleted NSPersistentCloudKitContainer interference Removed all Core Data CloudKit code Zone still deleted Double share acceptance Fresh app install, single acceptance only Zone still deleted Advanced Data Protection Neither account has ADP enabled Not the cause Programmatic vs system acceptance Tested both container.accept() and tapping share link Zone still deleted CloudKit Dashboard No ZoneDelete operation is visible in the logs. All operations are ZoneFetch, ZoneChanges, RecordQuery, RecordFetch. I do see EphemeralGroup operations targeting the custom zone — not sure what generates those. Comparison with working apps I compared my implementation with another app (Spotbook) that uses the exact same zone-wide CKShare(recordZoneID:) pattern with publicPermission = .readWrite and programmatic acceptance — and it works. The main difference is that app uses CKSyncEngine (iOS 17+) rather than raw CKFetchRecordZoneChangesOperation / CKModifyRecordsOperation. Could CKSyncEngine be handling something internally that prevents this issue? Questions Is there a known interaction between zone-wide CKShare(recordZoneID:) acceptance and zone lifecycle that could cause zone deletion? Does CKSyncEngine handle zone-wide sharing differently than manual CKFetchRecordZoneChangesOperation + CKModifyRecordsOperation? What generates EphemeralGroup operations in CloudKit Dashboard? Could these trigger a zone delete? After 20+ zone create/delete cycles in a container, is there a server-side rate limit or tombstone mechanism that would destabilize new zones? Is the custom programmatic acceptance flow (CKFetchShareMetadataOperation → container.accept()) fully supported for zone-wide shares, or does it require UICloudSharingController? Any guidance would be greatly appreciated. This is blocking multi-user functionality for our app (mesa, a meal planning app on the App Store). Single-user sync works perfectly — the issue only manifests when a second iCloud account is involved. Environment: iOS 18.4.1, Xcode 16+, Swift, SwiftUI

EASession(accessory:forProtocol:) always returns nil — MFI accessory iAP2 Platform: iOS 17+ | Hardware: Custom MFI-certified accessory (USB-C, iAP2) | Language: Swift Problem We have a custom MFI-certified accessory communicating over USB-C using ExternalAccessory. The app calls EASession(accessory:forProtocol:) after receiving EAAccessoryDidConnect but it always returns nil. We never get past session creation. What we have verified We captured a sysdiagnose on-device and analysed the accessoryd-packets log. The full iAP2 handshake completes successfully at the OS level: USB attach succeeds MFI auth certificate is present and Apple-issued Auth challenge and response complete successfully IdentificationInformation is accepted by iOS — protocol string and Team ID are correct EAAccessoryDidConnect fires as expected iOS sends StartExternalAccessoryProtocolSession — the OS-level session is established So the hardware, MFI auth, protocol string, and Team ID are all correct. Despite this, EASession(accessory:forProtocol:) returns nil in the app. We also confirmed: Protocol string in UISupportedExternalAccessoryProtocols in Info.plist matches the accessory exactly Protocol string in code matches Info.plist App entitlements are correctly configured EAAccessoryManager.shared().registerForLocalNotifications() is called before connection Current connection code @objc private func accessoryDidConnect(_ notification: Notification) { guard let accessory = notification.userInfo?[EAAccessoryKey] as? EAAccessory else { return } DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { self.tryConnectToAccessory() } } private func tryConnectToAccessory() { DispatchQueue.main.asyncAfter(deadline: .now() + 3.0) { for accessory in EAAccessoryManager.shared().connectedAccessories { let session = EASession(accessory: accessory, forProtocol: "") // session is always nil here } } } Questions The packet log shows a ~4 second gap between EAAccessoryDidConnect firing and iOS internally completing session readiness (StartExternalAccessoryProtocolSession). Is there a reliable way to know when iOS Is it actually ready to grant an EASession, rather than using a fixed delay? Is there a delegate callback or notification that fires when the accessory protocol session is ready to be opened, rather than relying on EAAccessoryDidConnect + an arbitrary delay? Are there any known conditions on iOS 17+ under which EASession returns nil even though the iAP2 handshake completed successfully at the OS level? Is retrying EASession after a nil result a supported pattern, or does a nil result mean the session will never succeed for that connection? Any guidance appreciated.

I have a collection view that covers all the screen and it is scrolling behavior is paging. This collection view is embedded in a UIViewRepresentable and used in a SwiftUI app. The issue is that when users rotate the devices, sometimes the CollectionView.contentOffset get miscalculated and shows 2 pages. This is the code that I'm using for the collectionView and collectionViewLayout: class PageFlowLayout: UICollectionViewFlowLayout { override class var layoutAttributesClass: AnyClass { UICollectionViewLayoutAttributes.self } private var calculatedAttributes: [UICollectionViewLayoutAttributes] = [] private var calculatedContentWidth: CGFloat = 0 private var calculatedContentHeight: CGFloat = 0 public weak var delegate: PageFlowLayoutDelegate? override var collectionViewContentSize: CGSize { return CGSize(width: self.calculatedContentWidth, height: self.calculatedContentHeight) } override init() { super.init() self.estimatedItemSize = .zero self.scrollDirection = .horizontal self.minimumLineSpacing = 0 self.minimumInteritemSpacing = 0 self.sectionInset = .zero } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func prepare() { guard let collectionView = collectionView, collectionView.numberOfSections > 0, calculatedAttributes.isEmpty else { return } estimatedItemSize = collectionView.bounds.size for item in 0..<collectionView.numberOfItems(inSection: 0) { let indexPath = IndexPath(item: item, section: 0) let attributes = UICollectionViewLayoutAttributes(forCellWith: indexPath) let itemOrigin = CGPoint(x: CGFloat(item) * collectionView.frame.width, y: 0) attributes.frame = .init(origin: itemOrigin, size: collectionView.frame.size) calculatedAttributes.append(attributes) } calculatedContentWidth = collectionView.bounds.width * CGFloat(calculatedAttributes.count) calculatedContentHeight = collectionView.bounds.size.height } override func layoutAttributesForElements(in rect: CGRect) -> [UICollectionViewLayoutAttributes]? { return calculatedAttributes.compactMap { return $0.frame.intersects(rect) ? $0 : nil } } override func layoutAttributesForItem(at indexPath: IndexPath) -> UICollectionViewLayoutAttributes? { return calculatedAttributes[indexPath.item] } override func shouldInvalidateLayout(forBoundsChange newBounds: CGRect) -> Bool { guard let collectionView else { return false } if newBounds.size != collectionView.bounds.size { return true } if newBounds.size.width > 0 { let pages = calculatedContentWidth / newBounds.size.width // If the contentWidth matches the number of pages, // if not it requires to layout the cells let arePagesExact = pages.truncatingRemainder(dividingBy: 1) == 0 return !arePagesExact } return false } override func invalidateLayout() { calculatedAttributes = [] super.invalidateLayout() } override func shouldInvalidateLayout(forPreferredLayoutAttributes preferredAttributes: UICollectionViewLayoutAttributes, withOriginalAttributes originalAttributes: UICollectionViewLayoutAttributes) -> Bool { guard let collectionView, #available(iOS 18.0, *) else { return false } return preferredAttributes.size != collectionView.bounds.size } override func invalidateLayout(with context: UICollectionViewLayoutInvalidationContext) { guard let customContext = context as? UICollectionViewFlowLayoutInvalidationContext else { return } if let collectionView, let currentPage = delegate?.currentPage() { let delta = (CGFloat(currentPage) * collectionView.bounds.width) - collectionView.contentOffset.x customContext.contentOffsetAdjustment.x += delta } calculatedAttributes = [] super.invalidateLayout(with: customContext) } override func prepare(forAnimatedBoundsChange oldBounds: CGRect) { super.prepare(forAnimatedBoundsChange: oldBounds) guard let collectionView else { return } if oldBounds.width != collectionView.bounds.width { invalidateLayout() } } override func targetContentOffset(forProposedContentOffset proposedContentOffset: CGPoint) -> CGPoint { guard let collectionView, let currentPage = delegate?.currentPage() else { return .zero } let targetContentOffset = super.targetContentOffset(forProposedContentOffset: proposedContentOffset) let targetPage = targetContentOffset.x / collectionView.frame.width if targetPage != CGFloat(currentPage) { let xPosition = CGFloat(currentPage) * collectionView.frame.width return CGPoint(x: xPosition, y: 0) } return targetContentOffset } // This function updates the contentOffset in case is wrong override func finalizeCollectionViewUpdates() { guard let collectionView, let currentPage = delegate?.currentPage() else { return } let xPosition = CGFloat(currentPage) * collectionView.bounds.width if xPosition != collectionView.contentOffset.x { let offset = CGPoint(x: xPosition, y: 0) collectionView.setContentOffset(offset, animated: false) } } } The full implementation is attached in the .txt file: RotationTestView.txt

Hi, I’m looking for clarification from folks familiar with CoreHID rather than App Review, as the guys there have not responded to my post (https://developer.apple.com/forums/thread/820676) We have a sandboxed macOS app that creates a virtual HID device (HIDVirtualDevice) as described in Creating virtual devices https://developer.apple.com/documentation/corehid/creatingvirtualdevices To work at all, the app requires the entitlement: com.apple.developer.hid.virtual.device With this entitlement present, macOS shows the system prompt requesting Accessibility permission App would like to control this computer using accessibility features. Grant access to this application in Security and Privacy preferences located in System Preferences. when HIDVirtualDevice(properties:) is called. There is no mention of Accessibility in the HIDVirtualDevice documentation, but the behavior is reproducible and seems unavoidable. My question is therefore: Is creating a virtual HID device from userspace via HIDVirtualDevice considered inherently incompatible with Mac App Store distribution? In other words: Is the Accessibility prompt an expected side‑effect of this API? And if so, does that mean using HIDVirtualDevice is only practical for direct (non–App Store) distribution unless the app is explicitly an accessibility tool? I’m not asking about review policy details—just whether, from a technical/system point of view, HIDVirtualDevice is actually intended to be usable by App Store apps. For context, there seem to be public, non‑accessibility uses of Apple’s virtual HID infrastructure, like this recent post: https://developer.apple.com/forums/thread/820708 and corresponding Github repo this project. I don't know if these intend to use the App Store, but they might end up in the same situation. Any insights from people who’ve worked with CoreHID would be greatly appreciated. Thanks, Magnus

审核回复：Issue Description The app uses public APIs in an unapproved manner, which does not comply with guideline 2.5.1. Specifically, the app still uses the ScreenTime API to hide apps. Since there is no accurate way of predicting how an API may be modified and what effects those modifications may have, unapproved uses of public APIs in apps is not allowed. 代码我都没有怎么改，然后之前2025年都上架成功了的，现在更新一个版本后，就不让上架了，是怎么回事？

I am writing to share my frustration regarding the app review process for my application. My current submission has been stuck in "Waiting for Review" for nearly 7 weeks, starting from February 5th. Although I have attempted to cancel and resubmit periodically, there were significant gaps of 10 and 21 days between submissions where no action was taken. Currently, I am stuck again. The situation is critical for the following reasons: Critical Bug: The update includes a necessary fix for an In-App Purchase bug that is preventing users from accessing paid features. No Communication: I have sent four inquiries regarding this delay. I received only one generic response asking me to wait, and my subsequent follow-ups have been completely ignored. Expedited Review Request: My requests for an Expedited Review have also gone unanswered. Apple’s standard review time is typically 24-48 hours, but my experience is far from that. I am not asking for special treatment; I am asking for basic transparency regarding why my app has been stalled for nearly two months. Could anyone from the review team please look into this or provide an explanation? This prolonged silence is causing significant issues for my service and its users. Apple ID: 6752595582 First Submission Date: Feb 5th

Hi team: I recently update to Xcode 26.4, and I encountered crash when running to < iOS 26.4 both for physical device and Simulator with this log: dyld[1257]: Symbol not found: _$s9MetricKit10mxSignpost_3dso3log4name10signpostID__ySo03os_H7_type_ta_SVSo03OS_j1_F0Cs12StaticStringV0J0010OSSignpostI0VALSays7CVarArg_pGtF Referenced from: <164CCEB0-E1F8-3CE2-A934-2096C19C0A9A> /private/var/containers/Bundle/Application/EA709A68-F76F-4D97-85C6-B71D61D68389/xxx.app/xxx.debug.dylib Expected in: <9E5EC9BB-5828-329C-A2BC-038B67060298> /System/Library/Frameworks/MetricKit.framework/MetricKit Symbol not found: _$s9MetricKit10mxSignpost_3dso3log4name10signpostID__ySo03os_H7_type_ta_SVSo03OS_j1_F0Cs12StaticStringV0J0010OSSignpostI0VALSays7CVarArg_pGtF Referenced from: <164CCEB0-E1F8-3CE2-A934-2096C19C0A9A>x /private/var/containers/Bundle/Application/EA709A68-F76F-4D97-85C6-B71D61D68389/xxx.app/xxx.debug.dylib Expected in: <9E5EC9BB-5828-329C-A2BC-038B67060298> /System/Library/Frameworks/MetricKit.framework/MetricKit dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/usr/lib/libViewDebuggerSupport.dylib but iOS 26.4 works well. Env: Xcode: 26.4 Simulator/Physical Device: < 26.4 macOS: 26.3 Thanks for giving any help.

I'm using Xcode 26.4 for Swift development on macOS 26.4.1. It seems that the documentation for the "Foundation" framework has disappeared, possibly after an Xcode update (not the latest one). "Foundation" does not appear in the left-side list in the developer documentation window, and searching for "URLSession", "UndoManager" finds no result. Autocomplete for these classes works. Quick help on URLSession shows just "inherits from" and "conforms to", but no description and no link to a help page. I've tried deleting files in ~/Library/Developer so that it rebuilds the index, and also fully removing and reinstalling Xcode and rebooting, but nothing seems to solve it. Is there any way to get the full documentation back in Xcode.

When I use Xcode 26 (0.1, 1) for debugging and hit a breakpoint, using "step over" causes the debugger to freeze at a random line of code. Clicking "Pause program execution" indicates that the line is being executed, but the breakpoint never exits, seemingly causing a freeze. The application on the simulator also becomes unresponsive. However, when I do not use breakpoints, my program runs smoothly, and debugging on a physical device does not cause any freezes. This issue only occurs with the simulator. I am using Xcode on Apple Silicon, and due to some third-party SDKs that depend on Rosetta, our app can only run on the Rosetta simulator. We did not encounter this issue when using Xcode 16.x for simulator debugging. The current situation with Xcode 26.x significantly reduces our development efficiency. What could be causing this, and is there a solution?

I am currently developing an app for MacOS that needs to control HomeKit devices like lights. However, it seems like MacOS is supported on the official documentation, but not when I try to create an app ID on developer.apple.com. On the link https://developer.apple.com/apple-home/, MacOS is clearly showed as supported for MacOS. But when I try to create an app ID, it shows that it is only compatible for iOS, VisionOS and WatchOS. Could this be clarified? Best regards, orangeidle25