Overview

For some reason since iOS 26.5, a ControlWidgetButton or a Button in a widget configured with an AppIntent conforming to OpenIntent fails to receive its AppEnum parameter correctly if the intent and enum are defined inside a shared Swift Package. Tapping the control widget button opens the main application, but it doesn't pass the AppEnum parameter value in, leaving the app on its default screen instead of navigating to the intended view. This was working perfectly in iOS 26.4, where the app would launch and receive the correct enum case from the intent. No code, configuration, or scheme changes were made between the two runs, only the simulator/OS version differs. Has anyone else run into what seems to be a regression on iOS 26.5? I filed feedback with a sample project: FB22848510

Hello everyone, I enrolled in the Apple Developer Program, completed payment successfully, and received confirmation, but my developer account is still not activated after 5 business days. I’m currently unable to access developer tools or continue setup. I’ve also had difficulty getting through to Apple Developer Support directly, which has made it difficult to understand whether something is wrong with my enrollment or if this is simply an unusually long processing delay. I’ve already contacted Apple Support, but I keep getting redirected between support channels. Has anyone else experienced a similar delay recently? If so: How long did activation take for you? Was there anything specific you had to do? Did your enrollment eventually activate automatically? Any advice or shared experiences would be appreciated. Thank you.

Hi, We've implemented age assurance logic in our app using the DeclaredAgeRange framework to comply with regulations in Brazil (Digital ECA, effective March 17, 2026) and Utah (App Store Accountability Act, effective May 6, 2026). Our implementation calls AgeRangeService.shared.isEligibleForAgeFeatures on app launch to determine whether the current user is subject to age assurance requirements, and proceeds to call requestAgeRange(ageGates:) accordingly. However, after monitoring in production since the Brazil enforcement date, we've consistently observed isEligibleForAgeFeatures returning false for users in regulated regions, with no age range data being returned. What we'd like to clarify: Is isEligibleForAgeFeatures currently returning true for users in Brazil in production (not sandbox)? For Utah — given that HB 498 pushed the developer compliance deadline to May 6, 2027, will isEligibleForAgeFeatures reflect the original May 6, 2026 activation date or the revised 2027 date? Is there a known rollout schedule or gradual activation plan for these regions that would explain why the flag remains false even after the legal enforcement dates have passed? We've seen similar reports from other developers on these forums, so it seems this may be a widespread issue rather than an implementation problem on our end. Any official guidance on the current status of the API in regulated regions would be greatly appreciated. Thanks.

My app has been for review for 2 months now , and the support team is ignoring my emails any reason this is my app id 6757392645

Hello App Review team, I am an iOS developer and my app (App ID: 6761247061) has been stuck in 'Waiting for Review' for nearly a week since May 15. Our previous submissions have always entered 'In Review' very quickly, so this is the first time we are experiencing such an extended delay. We have already tried the following: Opened a support case on May 18 (no response yet) Submitted a request for a call with App Review on May 21 We are sincerely hoping for any update or guidance from your team. If there is anything we have done incorrectly, we humbly ask that you let us know. We are fully prepared to make any change necessary to comply with the Review Guidelines. Any guidance or assistance would be deeply appreciated. Thank you!

Hello everyone, We are experiencing a serious issue with consumable In-App Purchase products in App Store Connect and could not find a clear solution. Our app previously had approved In-App Purchase products. Later, we removed the old products from sale, deleted them, and created new consumable IAP products with new product identifiers. The new products are: Points_50 Points_100 Points_250 Points_500 Points_1000 Points_2500 These products are used in the live app’s Points Store. The problem is that the live production app now depends on these new product IDs, but the products have not been approved yet. Because of this, prices are not displayed correctly in production and users cannot complete purchases. The IAP products have now been stuck In Review for about one week. Here is the timeline: We created the new consumable IAP products and submitted them for review. They were rejected under Guideline 3.1.1 with the following message: “We have begun the review of your In-App Purchase products but are not able to continue because you have submitted In-App Purchase products for the Consumable type, but you have not yet submitted an updated binary for review. To resolve this issue, please upload a new binary and resubmit the In-App Purchase products for review.” We followed this instruction. We uploaded a new binary and submitted a new app version for review. In the App Review Notes, we clearly explained that the new version was submitted because App Review requested an updated binary for the pending consumable IAP products. The new app version was approved. However, the six IAP products are still stuck In Review and have not been approved. The confusing part is that the In-App Purchases page still shows the following general message: “Your first in-app purchase must be submitted with a new app version. Create your in-app purchase, then select it from the app’s In-App Purchases and Subscriptions section on the version page before submitting the version to App Review. Once your binary has been uploaded and your first-in app purchase has been submitted for review, additional in-app purchases can be submitted from the In-App Purchases section.” However, these are not the first In-App Purchases ever created for this app. The app previously had approved IAP products. The old products were removed from sale and deleted, and the app now uses the new product identifiers listed above. Because these are not the app’s first-ever IAP products, when we uploaded the new binary and submitted the new app version, App Store Connect did not show an “In-App Purchases and Subscriptions” section where we could manually attach or select these pending IAP products. This makes the request to “upload a new binary and resubmit the IAP products” confusing in our case. We did upload a new binary, the app version was approved, but there was no way to manually select the IAP products on the version page, and the IAPs are still stuck In Review. We have already contacted support several times, but the issue is still unresolved. Has anyone experienced a similar situation? What is the correct workflow when: an app previously had approved IAPs, those old IAPs were deleted, new consumable IAPs were created, App Review requested a new binary, the new binary was uploaded and approved, but App Store Connect did not show any IAP selection section on the app version page, and the IAP products remain stuck In Review for about one week? Is there any way to manually associate these pending IAP products with the approved app version, or is this something that only App Review / Developer Support can resolve? Any guidance would be appreciated.

App review reviewed one app then rejected another

Hello Apple Developer Support, I am posting here as a third attempt to get assistance with an App Review issue that has now been ongoing for more than one month and is causing significant harm to our business. Our app has been going through a prolonged back-and-forth review process for over a month. The issues raised during review have been relatively minor and administrative in nature. For example, one review asked us to confirm subscription pricing, and another asked us to make subscription names more unique, even though those same names had not previously been flagged as problematic. Each time we address the requested changes and resubmit, we wait again, only to receive another simple clarification request weeks later. As a result, we have been unable to launch our product despite making every effort to respond quickly and comply with all review requirements. This situation has become extremely critical for us. We already have a marketing team and launch activities prepared around this product, and the inability to obtain a basic approval after more than a month is causing substantial business damage. I have also attempted to contact Apple Developer Support by phone today. I requested a callback and received one, but I was unable to proceed because the automated phone system did not recognize my keypad responses. Additionally, when requesting support callbacks, the website frequently displays an error message stating that there was a problem processing the request, despite callbacks sometimes still being generated. We have already posted in the Developer Forums twice regarding this matter and were informed that the issue was being looked into. Unfortunately, the situation has never been resolved, which is why I am posting again. I would greatly appreciate if someone could: Escalate the review of our submission. Investigate why this review process has been stalled for over a month. Contact me directly via email or phone regarding this case. This matter is now highly time-sensitive and has a direct impact on our business operations. Thank you for your time and assistance. Best regards, Jevgenij App ID: 6765609730 Current Status: Waiting for Review Case ID: 102905910960

Environment App: Web app (Sign in with Apple JS / redirect flow) Hosted over HTTPS (valid TLS cert via AWS ALB) Tested on latest Chrome, Safari, and Firefox Reproducible in normal + incognito/private windows Expected behavior When clicking "Sign in with Apple", the popup should render the Apple login form and then redirect to our configured callback endpoint Actual behavior Apple Sign-In popup opens successfully Page loads only the Apple header shell: • Apple logo • "Apple Account" • Collapsed "Sign in" section The actual login form (email/password entry) never renders No visible error shown to the user No requests ever reach our backend callback endpoint Configuration status Services ID created and enabled for Sign in with Apple Domain verified and added to Services ID: Return URL configured exactly: Primary App ID has Sign in with Apple capability enabled Key created and associated with the App ID CSP allows What we have already tried Re-saving Services ID configuration multiple times Regenerating Key and re-binding to App ID Verifying client_id matches Services ID identifier exactly Waiting >24 hours for propagation Testing across multiple browsers and devices Key observation The flow appears to stop before authentication UI renders fully, and no redirect/callback is ever triggered, suggesting the issue occurs within Apple’s authorization session before completion. Question Is there any known requirement or verification step for Services IDs using a domain-style identifier, or any additional Apple-side configuration/activation step that could prevent the login form from rendering even though the initial authorize page loads?

I have encountered the following issue on iPadOS. Has anyone experienced this issue or reported it before? Steps to Reproduce Enable Windowed Apps mode in Settings. Launch the Settings app and another app (App X), and display both in windowed mode. Use the Settings app to completely cover App X (App X becomes inactive at this point). From the Settings app, enable Full Screen Apps mode. Bring App X to the foreground. Expected Result App X becomes active when brought to the foreground. Actual Result Even after bringing App X to the foreground, it immediately becomes inactive. The issue persists even if App X is restarted. To resolve the issue, it is necessary to either restart the iPad or switch back to Windowed Apps mode. Verified OS Versions iPadOS 26.5: Reproducible iPadOS 26.4.2: Reproducible iPadOS 26.2: Not reproducible iPadOS 26.0.1: Not reproducible Additional Information According to the console logs, App X appears to remain inactive because the deactivation reason "sceneOverlap" persists.

Metal GPU Driver Crash on M5 Pro + macOS 26.5 — kIOGPUCommandBufferCallbackErrorOutOfMemory with <2GB working sets Summary The Metal driver AGXMetalG17X 351.2 on macOS 26.5 (25F71) for the M5 Pro chip crashes with kIOGPUCommandBufferCallbackErrorOutOfMemory (00000008) when running LLM inference workloads with working sets as small as ~1.5GB, despite 24GB of unified memory being available and Apple Diagnostics confirming the hardware is fully functional. This affects multiple tools: MLX, llama.cpp (Metal backend), and native apps using Metal for inference. System Component Value Model MacBook Pro (Mac17,9) Chip Apple M5 Pro (applegpu_g17s) GPU Cores 16 RAM 24 GB LPDDR5 macOS 26.5 (25F71) Metal Metal 4 GPU Driver AGXMetalG17X 351.2 Xcode 26.5 (17F42) Reproduction MLX (Python) pip install mlx mlx-lm python -m mlx_lm.generate \ --model mlx-community/Qwen2.5-3B-Instruct-4bit \ --max-tokens 10 \ --prompt "Hello" Expected: Normal text generation Actual: Crash with: libc++abi: terminating due to uncaught exception of type std::runtime_error: [METAL] Command buffer execution failed: Insufficient Memory (00000008:kIOGPUCommandBufferCallbackErrorOutOfMemory) llama.cpp brew install llama.cpp llama-cli --model model.gguf --prompt "Hello" --n-predict 20 --n-gpu-layers 99 Expected: Fast GPU generation Actual: Process hangs indefinitely Test Results Tool Model Peak Memory Result MLX Qwen2.5-0.5B-4bit 0.36 GB ✅ Works MLX Qwen2.5-1.5B-4bit 0.98 GB ✅ Works MLX Qwen3-1.7B-4bit 1.01 GB ✅ Works MLX Qwen2.5-3B-4bit ~1.5 GB ❌ Metal OOM crash MLX Qwen3-4B-4bit ~2.1 GB ❌ Metal OOM crash MLX Qwen3-8B-4bit ~4.5 GB ❌ Metal OOM crash llama.cpp Qwen2.5-0.5B GGUF ~0.5 GB ❌ Hangs with GPU llama.cpp Qwen2.5-0.5B GGUF ~0.5 GB ✅ Works with CPU only Key Evidence Hardware is healthy — Apple Diagnostics passed all tests Basic Metal works — matmul, array ops work fine CPU inference works — llama.cpp with -ngl 0 runs correctly The error is NOT about actual memory exhaustion — kIOGPUCommandBufferCallbackErrorOutOfMemory means the kernel rejects the Metal memory commit, not that physical memory is full. The system reports 17.76GB available for Metal working set. Crash Log Extract Thread 31 Crashed: 0 libsystem_kernel.dylib __pthread_kill + 8 1 libsystem_pthread.dylib pthread_kill + 296 2 libsystem_c.dylib abort + 148 3 Metal MTLReportFailure.cold.1 + 48 4 Metal MTLReportFailure + 576 5 Metal -[_MTLCommandBuffer addCompletedHandler:] + 104 ... Exception Type: EXC_CRASH (SIGABRT) Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6 Related Issues ml-explore/mlx#3586 — Metal compiler regression on macOS 26.5 ml-explore/mlx#3534 — M5 float32 precision issue ml-explore/mlx#3568 — M5 random divergence ml-explore/mlx#3539 — Metal residency OOM (M4 Max) Request Please investigate the AGXMetalG17X driver for M5 Pro on macOS 26.5. The driver appears to incorrectly reject Metal memory commits for LLM inference workloads, even when the working set is well within the system's reported limits (1.5GB requested vs 17.76GB available). Happy to provide full crash logs, sysdiagnose archives, or run additional tests.

I'm in the unenviable position of needing the current UIViewController to keep an external library happy. Essentially, I need to do this in SwiftUI: import LibraryOutOfMyControl ViewControllerReader { viewController in Button("Action") { LibraryOutOfMyControl.action(with: viewController) } } My simple attempt below functions correctly but I'm relying on makeUIViewController always being immediately followed by updateUIViewController. Is the a reasonable assumption or should I set everything up assuming updateUIViewController might never be called? struct ViewControllerReader<Content>: UIViewControllerRepresentable where Content: View { @ViewBuilder var content: (UIViewController) -> Content func makeUIViewController(context: Context) -> UIHostingController<Content> { UIHostingController(rootView: content(UIViewController())) } func updateUIViewController(_ uiViewController: UIHostingController<Content>, context: Context) { uiViewController.rootView = content(uiViewController) uiViewController.view.isUserInteractionEnabled = context.environment.isEnabled } func sizeThatFits(_ proposal: ProposedViewSize, uiViewController: UIHostingController<Content>, context: Context) -> CGSize? { uiViewController.sizeThatFits(in: proposal.replacingUnspecifiedDimensions()) } }

I'm trying to use SwiftUI views inside an NSToolbarItem, and I feel like I'm fighting the system. The goal is to create custom toolbar controls. I don't want AppKit or SwiftUI to recognize that there's a SwiftUI view in the toolbar and then try to style it automatically, which is what I think is happening. Consider this hierarchy: - NSToolbar - NSToolbarItem - view -> MyCustomNSView - addSubview(NSHostingView<CustomView>) So CustomView is inside an NSHostingView, which is inside an NSView, which is assigned to the .view property of an NSToolbarItem. For a while, I struggled to get this working at all because SwiftUI's layout metrics appeared to be affected by safe area insets. SwiftUI's ignoresSafeArea() only seemed to move the problem around. For now, I've disabled full-size content view, which I don't really need anyway. However, a SwiftUI Button or Menu still doesn't behave or style the way I would expect when placed inside an NSToolbarItem. They don't seem to honor many of the styling attributes or view modifiers that work elsewhere. Is there a way to tell AppKit to "ignore" the children of my NSToolbarItem and not apply toolbar-specific styling to them? Am I even correct in thinking that AppKit is recognizing a Button or Menu in the toolbar and forcibly applying styling to it? Previously, I tried implementing my "custom toolbar" entirely outside of NSToolbar, but then SwiftUI struggled with placing views under the transparent, non-existent toolbar. I'd appreciate any direction or hints here. It would be really nice to use SwiftUI for the controls I have in mind, but at the moment I can't get close to the result I'm aiming for.

anyone else have this gltich? my app seems to be in stuck state and has not been reviewed for a week now. help?

Hello, I have an app for a research study that has been approved and authorized to use SensorKit. All my permissions, entitlements and authorizations are in order, but I still can't get any data. The didFetchResult is not being called even though didCompleteFetch is called. I have waited for over 24 hours, but it still returns no samples. Please, I would appreciate any help on this issue. Thank you func sensorReader( _ reader: SRSensorReader, fetchingRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject> ) { receivedResultsInCurrentFetch = true print("✅ SensorKit fetch result received for: \(sensorKey)") AppLogger.shared.log("SensorKit fetch result received for \(sensorKey)") if let sample = result.sample as? T { print("✅ SensorKit sample matched expected type for \(sensorKey): \(T.self)") AppLogger.shared.log("SensorKit sample matched expected type for \(sensorKey): \(T.self)") processSample(sample) } else { print("❌ SensorKit sample did not match expected type for \(sensorKey): \(T.self)") AppLogger.shared.log("SensorKit sample did not match expected type for \(sensorKey): \(T.self)") } } func sensorReader(_ reader: SRSensorReader, didCompleteFetch request: SRFetchRequest) { if receivedResultsInCurrentFetch, let lastRequestedUpperBound { session.setSensorKitLastFetchTime(lastRequestedUpperBound, for: sensorKey) print("✅ SensorKit fetch completed with samples for \(sensorKey). Checkpoint updated.") } else { print("⚠️ SensorKit fetch completed for \(sensorKey) with no samples.") AppLogger.shared.log("SensorKit fetch completed for \(sensorKey) with no samples. Keeping previous checkpoint so delayed SensorKit data is not skipped.") } isFetchInFlight = false completePendingFetches(success: true) print("✅ SensorKit fetch completed for: \(sensorKey)") AppLogger.shared.log("Fetch request completed for sensor type: \(T.self)") }

Providing a response and feedback to this: https://origin-devforums.apple.com/forums/thread/827311 and https://developer.apple.com/forums/thread/827043?page=1#889020022 I have a created a feedback/bug report with ID FB22823733 Feedback Report: I have created a feedback report as well like recommended with this ID: FB22823733, with more elaborate images of my implementation, also see here More clarity: Yes, this is for an iOS app(iOS 18+) but testing and debugging on Xcode(MacOS 15.7.7, M4 24GB), which traps or hangs on getting to [PhotogrammetrySample] even while using the lazy sequence and the contentsOf as specified in your docs. I also tried using the PhotogrammetrySession folder run but its still failed with : CoreOC.PhotogrammetrySession.Error 6 and I understand to mean alignment failed. What can be done or do you guys expose any functions that can be used to aid, or handle these internally, can't find any internally. The ObjectMasks are actually segmentation masks from an ML algorithm . To replicate try calling PhotogrammetrySession(input: [PhotogrammetrySample]) with contentsOf as captured on your documentation, even with like 30 image set or is there something I'm missing.

Hi everyone, This is my first app submission to the App Store, and I'm curious about current review timelines. My app has been sitting in "Waiting for Review" and I'm trying to get a better idea of what others are experiencing right now. I know review times can vary depending on the app and workload, but I'd love to hear some recent experiences. For those who have submitted apps recently: • How long did it take to move from Waiting for Review to In Review? • How long did the full review process take? • Did you receive approval over the weekend, or mostly during weekdays? I'm not having any issues with the submission itself and haven't received any messages from Apple. Just trying to gauge what the current wait times look like. Thanks in advance! 😊📱🍎

ENVIRONMENT Device : MacBook Pro 16,1 CPU : 6-Core Intel Core i7, 2.6 GHz RAM : 16 GB DDR4 GPU : AMD Radeon Pro 5300M + Intel UHD 630 macOS : 26.5 (Build: 25F71) Xcode : 26 (also tried Xcode 16 — same issue) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ISSUE SUMMARY Xcode crashes immediately on launch after updating to macOS 26.5. The issue started right after the macOS update — Xcode was working perfectly before. Both Xcode 26 and Xcode 16 are affected. Fresh reinstall does not help. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ERROR — xcodebuild -version output dyld: Library not loaded: @rpath/DVTSystemPrerequisites.framework/ Versions/A/DVTSystemPrerequisites Reason: code signature in DVTSystemPrerequisites.framework not valid for use in process — mapping process is a platform binary, but mapped file is not. zsh: abort xcodebuild -version ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CRASH REPORT DETAILS Incident ID : 370D1162-4CA5-4FFE-9193-45EBD350BF85 Exception : EXC_BAD_ACCESS (SIGKILL — Code Signature Invalid) Termination : CODESIGNING, Code 2, Invalid Page Crash Date : 2026-05-14 Failing Frameworks: DVTSystemPrerequisites.framework MobileDevice.framework (/Library/Apple/System/Library/ PrivateFrameworks/MobileDevice.framework) Crashed Thread 7 Stack: dyld3::MachOFile::trieWalk dyld4::Loader::hasExportedSymbol dyld4::JustInTimeLoader::applyFixups _CFBundleLoadExecutableAndReturnError -[NSBundle loadAndReturnError:] __watchForSims_block_invoke -[OSActivityStream setDeviceDelegate:] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ WHAT I HAVE ALREADY TRIED sudo xattr -cr /Applications/Xcode.app sudo codesign --force --deep --sign - /Applications/Xcode.app sudo codesign --force --deep --preserve-metadata=identifier,entitlements --sign - /Applications/Xcode.app Re-signed DVTSystemPrerequisites.framework individually Deleted DerivedData, Xcode caches, preferences Fresh reinstall of Xcode (multiple times) Tried installing Xcode 16 — same crash Raised Apple Support Ticket: 102889658162 — no resolution received Nothing has worked. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ROOT CAUSE ANALYSIS macOS 26.5 introduced stricter platform binary validation in dyld. On Intel Mac (x86_64), this validation is rejecting Xcode's own frameworks at runtime — even after re-signing. This does not appear to be a user-fixable issue. This seems to be a macOS 26.5 regression specifically affecting Intel Mac users. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ REQUEST Is anyone else experiencing this on Intel Mac? Has anyone found a working workaround? Can Apple Engineering please investigate this as a macOS 26.5 regression for Intel Macs? My entire development workflow is blocked. Any help is greatly appreciated. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

I recently released an iOS app that includes banner ads through Google AdMob, and an in-app purchase to remove those ads. I created 500 offer codes in App Store Connect to be able to give out to people to get the in-app purchase for free. And I of course tried using one myself. However, it didn't work. At first, clicking on the offer code link failed to redeem anything. Eventually I was able to enter an offer code manually by going to App Store > My Photo > Redeem Code. But even after doing so, the ads weren't actually removed from my app. Now when I click the "Restore Purchases" link in my app, it says, "No Purchases Found. No previous ad removal purchase was found." But when I click the button to remove ads it says "Purchase Failed. The purchase could not be completed. Please try again." And if I try and redeem another code, it says, "Your code limit has been reached. You have already redeemed the maximum number of these codes per Apple Account." As the developer of this app, is there any way for me to make a in-app purchase (either with money or with an offer code) of my own app? Claude Code told me this: Apple prevents the developer Apple ID (the one that owns the app in App Store Connect) from purchasing or redeeming in-app purchases and offer codes for their own apps. But that response is AI and I always take its responses with a grain of salt. I asked it to cite its source, and it couldn't. Can anyone else who's developed iOS confirm or deny that this is true?

Im getting this error, when i tried to put my last build into public group