Overview

I've basically run the entire Apple website and couldn't find this information.

Summary We have identified a reproducible world tracking drift regression in ARKit on LiDAR-equipped iOS devices running iOS 26.4 and later. A static virtual node anchored at the world origin visually drifts from its initial position as the user moves around a real-world scene, despite the scene remaining physically static. The same code produces stable, drift-free results on non-LiDAR devices running identical OS versions. Device & OS Observations Testing was performed across four devices on iOS 26.4 using the same application build and ARWorldTrackingConfiguration settings. Non-LiDAR devices — iPhone 14 and iPhone 15 — produced stable, drift-free tracking in all test runs. No world origin displacement was observed regardless of how long or how far the user walked. LiDAR-equipped devices — iPhone 14 Pro and iPhone 16 Pro — exhibited consistent, reproducible drift. A static node placed at the world origin visually shifted from its initial position as the user moved through the scene. The same devices were stable on earlier iOS versions, confirming this is a regression introduced in iOS 26.4. Technical Observations Nature of drift: A SCNNode placed statically at the ARKit world origin (SCNVector3(0, 0, 0)) visually displaces from its original position as the user walks around a static real-world scene. The displacement is not random — it accumulates directionally as the user moves, consistent with a sensor fusion or coordinate anchoring error. Trigger condition: The drift occurs during normal walking motion around a fixed point of interest, such as circling a parked vehicle. It does not appear when the device is held still. LiDAR specificity: The drift is exclusive to devices with a LiDAR scanner. Identical hardware configurations — same iOS build, same ARWorldTrackingConfiguration settings — on non-LiDAR devices produce no drift whatsoever. This isolates the regression to the LiDAR sensor's contribution to ARKit's internal Visual-Inertial Odometry (VIO) fusion pipeline. No API-level workaround found: There is currently no public ARKit API to selectively disable the LiDAR scanner's contribution to VIO. All available configuration-level options have been evaluated without resolving the drift. ARWorldTrackingConfiguration Options Evaluated The following configuration changes were applied individually and in combination. None resolved the drift on LiDAR devices: isAutoFocusEnabled = false — No improvement videoHDRAllowed = false (disabled) — No improvement planeDetection = [] (disabled) — No improvement sceneReconstruction = .mesh — No improvement worldAlignment: .gravity vs .gravityAndHeading — No improvement Minimal Reproduction Case The drift can be reproduced with a minimal ARKit scene: Create an ARSCNView with ARWorldTrackingConfiguration using default settings. Add a single static SCNNode (e.g., a small sphere or axes geometry) at SCNVector3(0, 0, 0) when the session starts. Run the app on a LiDAR-equipped device (iPhone Pro, iPad Pro with LiDAR) on iOS 26.4 or later. Walk in a circle around the node's approximate real-world position. Expected: The node remains visually fixed at its world position throughout the walkthrough. Actual: The node drifts from its initial position, increasingly displaced from its world origin anchor as walking continues. We want to know if Apple has made any internal updates to ARKit, particularly after the OS 26.4 upgrade. Thanks!

The CGSetDisplayTransferByTable() is not working on the latest round of Mac hardware, namely the MacBook Neo (external display), MacBook M5 Pro (both built-in and external display) and possibly the M5 Max. All tested apps (BetterDisplay, MonitorControl, f.lux, Lunar) exhibit the very issue both in macOS Tahoe 26.3 and macOS Tahoe 26.4 RC. Tested on multiple Macs and installations on the MacBook Neo and MacBook M5 Pro. This issue breaks several display related macOS apps. Way to reproduce the issue using an affected app: Install the app BetterDisplay (https://betterdisplay.pro) Launch the app, open the app menu, choose Image Adjustments and try to adjust colors. Adjustments take no effect Way to reproduce the issue programmatically: Attempt to use the affected macOS API feature: https://developer.apple.com/documentation/coregraphics/cgsetdisplaytransferbytable(::::_:) Here are the FB numbers: FB22273730 (Filed this one as a developer on an unaffected MBP M3 Max) FB22273782 (Filed from an affected MBP M5 Pro running 26.4 RC, with debug info attached)

I see many others have been stuck for way longer than the 24-48 hours. I am wondering if there is a bug with their submission queue. I am hoping my post will be seen by apple and someone can reply with an update. I believe my APP ID is 6795997159 Thanks in advance

Hello Apple, I'm hoping someone can clarify the expected behaviour here, as I'm not sure whether I've missed a step. Timeline for my first submission (iOS 1.0, new organisation account): 21 July — reviewed 22 July — App Review opened a Guideline 2.1 information request, asking the standard set of questions about third-party analytics, third-party advertising, data sharing and any other data collection 23 July — I replied in the App Store Connect message thread with complete answers to all four questions Since then — status has remained In Review, with no further response That's now 18 days. The submission page shows all 19 items as In Review with no warnings, there are no unread messages in the thread, and the version page has no incomplete metadata flags. My questions: When you reply to a 2.1 information request, does the submission automatically return to the review queue, or does replying alone sometimes leave it in a state where it isn't picked back up? Is a reply in the App Store Connect message thread sufficient, or should the response also be entered in the App Review Notes field on the version? Is there anything that would cause a reply to be recorded but not surfaced to the reviewer? I'd rather understand the mechanism than resubmit blindly and lose my place in the queue. Submission ID: 4cd83c15-8977-4545-a1c4-d4e666d769fc App: 6762837701 (com.travellingintime.TravellingInTime) Thanks.

Good morning, We are experiencing issues with timeouts during the certificate handshake. We have checked the certificates and they are valid. Please could you assist us? Details are as follows: 2026-08-25T06:32:08.163472945Z – first error 2026-08-25T06:42:42.649765367Z 2026-08-25T15:53:01.713486959Z 26 August 2026 14:54:20.693697592Z 26 August 2026 15:09:43.343099296Z 26 August 2026 15:42:55.565622994Z An SSLHandshakeException has occurred. The certificates provided may not be valid {message={I/O error on POST request for ‘https://apple-pay-gateway.apple.com/paymentservices/paymentSession’: Remote host terminated the handshake}}} After one minute, we observe an error: 2026-08-25T15:56:35.280529678Z Calling Apple {url=https://apple-pay-gateway.apple.com/paymentservices/paymentSession} Then: 25 August 2026 15:57:35.504558588Z An SSLHandshakeException has occurred. The certificates provided may not be valid {message={I/O error on POST request for ‘https://apple-pay-gateway.apple.com/paymentservices/paymentSession’: Remote host terminated the handshake

On every iOS 27.0 beta, setExposureModeCustom(duration:iso:completionHandler:) on the front TrueDepth camera (.builtInTrueDepthCamera, position .front) no longer has any observable effect on the video stream. Frame brightness continues to track continuous auto exposure. The same code applies exposure correctly on iOS 26.x and iOS 18.x on the same devices. Reproduced on iPhone 14 Pro Max, iPhone 16, iPhone 16 Pro Max, and iPhone 17 Pro Max running iOS 27.0 betas. Not reproducible on any earlier iOS on the same hardware. Configuration: AVCaptureSession with the TrueDepth device as video input AVCaptureVideoDataOutput (BGRA) plus AVCaptureDepthDataOutput connected Session running, auto exposure settled Repro: Start the session above and wait ~2 s for AE to settle. Apply a custom exposure that should visibly overexpose the image: try device.lockForConfiguration() let format = device.activeFormat device.setExposureModeCustom( duration: CMTime(value: 1, timescale: 15), iso: format.maxISO, // device reports ISO ran completionHandler: nil ) device.unlockForConfiguration() Observe mean luma of delivered frames. Expected: frames become heavily overexposed (max ISO at 1/15 s). Actual: frame brightness is unchanged and keeps adapting with call never happened. No error is thrown, lockForConfiguration succeeds, and isExposureModeSupported(.custom) returns true. The device als custom range (ISO 20...1920, duration up to 1/15 s), so there is no API-visible signal that the command was not applied. [READBACK RESULT: state her device.exposureMode / device.iso / device.exposureDuration reflect the requested values after the call.] Possibly related: on earlier releases the completionHandler f fired on builtInTrueDepthCamera (https://developer.apple.com/forums/thread/770566), while the exposure values themselves were still applied. On i longer applied either. Questions: Is this an intentional change (for example, the system ret while the TrueDepth/depth pipeline is active), or a regression? If intentional, what is the supported way for an app to de refused, and is custom exposure still possible while an AVCaptureDepthDataOutput is connected?

I'm a sole proprietor, tax resident in Spain — not a U.S. person or U.S. tax resident. I'm trying to complete the tax form step of the Paid Applications Agreement in App Store Connect so I can offer in-app purchases. Going to Business → Agreements, Tax, and Banking → Agreements tab → Tax Forms → "Add Tax Info" (also tried the (+) → "Paid Apps" path) takes me directly to an electronic Form W-9: "Identification of Beneficial Owner," a "Type of Beneficial Owner" dropdown with only U.S.-specific categories (Individual/Sole proprietor, C Corporation, S Corporation, Partnership, Trust/estate...), and Part I asking for a U.S. SSN or EIN. There is no field, checkbox, or preliminary question anywhere in this flow that lets me indicate foreign status. I don't have a U.S. SSN/EIN and don't qualify for one. Per the IRS's own instructions for this exact form: "Foreign person. If you are a foreign person [...], do not use Form W-9. Instead, use the appropriate Form W-8." Part II of the form also requires certifying "I am a U.S. citizen or other U.S. person," which would be false for me to sign. Apple's own help docs say non-U.S. individuals should be routed through a questionnaire to Form W-8BEN instead of seeing W-9 directly — that questionnaire never appears for my account. I've already contacted Developer Support and submitted a case through the Tax/Financial Information contact form, but haven't gotten a resolution yet (over 20 days now). Has anyone else run into this and found a way to actually reach W-8BEN in App Store Connect? Or is this a known account-level issue that needs to be fixed on Apple's side? Any pointers — including from anyone at Apple who monitors these forums — would be much appreciated.

I'm trying to understand why would a single button appear twice in the toolbar, like so: Do you see the eclipsed button peeking from underneath the top button? It's the same button, somehow doubled or cloned, or replicated. To reproduce it, I only needed to create a fresh iOS project in Xcode and apply this code change: diff --git a/BugRepro20260409/ContentView.swift b/BugRepro20260409/ContentView.swift index 426b298..d22433f 100644 --- a/BugRepro20260409/ContentView.swift +++ b/BugRepro20260409/ContentView.swift @@ -28,7 +28,7 @@ struct ContentView: View { ToolbarItem(placement: .navigationBarTrailing) { EditButton() } - ToolbarItem { + ToolbarItem(placement: .bottomBar) { Button(action: addItem) { Label("Add Item", systemImage: "plus") } This is all I needed to do for the double-vision button. Why would this button appear twice when moved to .bottomBar? By the way, when moved to the side and displayed on a smaller device like iPhone SE, the duplication is quite jarring: Interestingly, both buttons are active, and both trigger the same code path. Any ideas what's going on? ContentView.swift

I've asked this before — and I still don’t get it. Do Apple Web Developers even read this forum? I’ve been a developer my whole life, and Apple’s review process makes no sense. What actually happens when you submit an update? Code review: clearly not done by humans — AI or automated checks. App Store metadata: trivial to scan — if nothing changed, why delay? Security checks: automated, not human-led. So why do review times vary wildly — 1 day, 3 days, 7+ days — with no explanation? For a trillion-dollar company with advanced tech, this is baffling. Examples: Firefox update: released in ~30 minutes, always predictable. Chrome update: released within ~12 hours, consistent. Apple update: unpredictable and inconsistent. Support is equally frustrating. You open a ticket, go back-and-forth for a weeks, provide the same info repeatedly, then the ticket is closed with no resolution. They ask for a screen shot to give developers. Then they ghost you for weeks. Developers or AI couldn't figure out the issue on their end? It's not rocket science. I'm not being rude - I'm genuinely trying to understand why Apple's App Review is entirely different than how streamlined and easy Firefox and Google are. I uploaded two identical builds, one for web and one for iPad (same binary, different scheme). Web was live in 2 days; the iPad build is still “Waiting for Review.” Can anyone explain how Apple’s review actually works? This level of randomness makes no business sense. I go through this entire forum and it's post after post with zero replies, maybe 1 reply on some - but for the most part, nothing even really gets answered in this forum. Makes no sense.

I’m seeing a repeatable first-party cameracaptured crash on an iPhone 14 Pro (iPhone15,2) running iOS 27 beta 5 (24A5424a). The single-camera AVCaptureSession configuration is: Front wide camera 3840×2160 at 30 fps, SDR/420f Two AVCaptureVideoDataOutput connections: Main recording output: 3840×2160 Auxiliary preview output: approximately 2096×1178 Both connections request and activate .standard video stabilization Within roughly two minutes, cameracaptured crashed three times—once during recording and twice during idle preview. The application receives AVErrorMediaServicesWereReset (-11819) after each crash. All three reports have the same faulting queue and underlying stack: com.apple.coremedia.capture.videodata-stabilization.front FigCFDictionaryGetCGRectIfPresent -[BWVISNode _transformRectanglesInMetadata:pts:] -[BWVISNode _stabilizeMetadataForSampleBuffer:] -[BWVISNode _tallyAndEmitSampleBuffer:] VideoStabilizationV2 The first two crashes are: EXC_BAD_ACCESS / EXC_ARM_PAC_FAIL address: 0x00000000dac11a30 termination: PAC_EXCEPTION, code 261 The third reaches the same stabilization stack but terminates with: EXC_BAD_ACCESS / SIGSEGV KERN_INVALID_ADDRESS at 0x30 App-side frame analytics were disabled, system pressure remained nominal, and neither audiomxd nor bluetoothd restarted. The first crash report also shows two front- stabilization worker threads, consistent with the two stabilized video outputs. I have filed Feedback Assistant report FB24553011 with the complete log archive and all three cameracaptured reports. With the iOS 27 public release approaching, waiting for an OS-side fix is not a viable shipping strategy; an app-side workaround is effectively the only option available for our release. Is this a known issue? In particular: Is it safe to leave .standard stabilization on the main recording connection while forcing the auxiliary preview connection to .off? Would disabling/removing the auxiliary AVCaptureVideoDataOutput reliably reduce this to one stabilization pipeline? If a single stabilized front output remains affected, is disabling front-camera stabilization entirely the only supported containment? Is there any public API for disabling the rectangle-metadata processing performed by BWVISNode? The current field workaround is to use the front camera with stabilization Off, or use a rear camera when stabilization is required.

https://feedbackassistant.apple.com/feedback/24553094 Security.framework returns NULL from SecPolicyCreateSSL when the directory containing the running executable no longer exists. That commonly happens with "go run" after the go command deletes its temporary build directory while a child process is still running. More details on how to reproduce: https://github.com/golang/go/issues/68557 Golang team rejected my workaround https://github.com/golang/go/pull/80471/changes so we're relying on the macOS team to allow this, unless of course there is a great reason not too. This is problematic when developing applications in golang, especially daemons.

Hello everyone, I am currently running the macOS Golden Gate 27 Developer Beta and am experiencing an issue with external displays. I am only able to connect one external display successfully. Any additional external displays I try to plug in do not work or are not recognized by the system. Here are the details of my setup: Mac Model: 16-inch MacBook Pro (Apple M4 Pro, 24 GB Memory) macOS Version: macOS 27 Version 27.0 Beta (Build 26A5353q) Displays: Two LG UltraFine 5K Thunderbolt displays Connection Type: Connected directly using two separate Apple Thunderbolt 4 cables Troubleshooting steps already taken: Restarted the Mac Tested different cables and ports Verified both displays work individually (only fails when both are connected) Has anyone else encountered this issue on this specific beta build? If so, have you found any temporary workarounds? Side note: Feedback Assistant was not working for me. I tried it in the Web, and the native App, neither of them would work. I am posting here because there was nowhere else to submit this bug report.

In WWDC20 it was mentioned that missing compileTime/renderTime (or no intermediate image with the dump-intermediates option) can indicate a cached intermediate. I have also seen renderTime=cacheHit on passes that are clearly rendering intermediates, and an actual renderTime is only properly shown on the final pass which always seems to equal the final time render time. In compileTime it says cacheMiss. Which fields should be considered authoritative for tracking intermediate cache hits versus actual rendering? Thanks!

Hello, my app (6802356260) has been pending review for quite some time. This is impacting my product launch and availability to users. I tried requesting an expedited app review, but was unable to reach anyone on the phone after being on hold for a long time. Case # 20000143670576. I haven't received any response.

Hello, I am building an iOS app that uses NSPersistentCloudKitContainer with a two-store configuration (.private + .shared), following the "Sharing Core Data objects between iCloud users" sample. Sharing works in one direction only: the owner's records reach the participant, but nothing the participant writes is ever exported. I have spent a full day isolating this and have ruled out every cause I can think of. I would appreciate guidance on what else to check, or confirmation that this is a limitation I have misunderstood. I have deliberately kept the details below complete, because the interesting part of this report is not the failure itself but everything that has already been eliminated. Environment Xcode 26.6 (17F113) Owner device: iPhone 15 Pro, iOS 26.5.2 Participant device: iPhone 13 mini, iOS 26.0.1 Two devices, two different iCloud accounts CloudKit container: iCloud.com.onton.quipuledger, Development environment NSPersistentCloudKitContainer with two stores: private.sqlite — databaseScope = .private shared.sqlite — databaseScope = .shared Both created exactly as in the sample (the shared description is a copy() of the private one, with a new NSPersistentCloudKitContainerOptions whose scope is .shared) Both stores have NSPersistentHistoryTrackingKey and NSPersistentStoreRemoteChangeNotificationPostOptionKey set viewContext has transactionAuthor, mergePolicy (NSMergeByPropertyObjectTrumpMergePolicy) and automaticallyMergesChangesFromParent = true What works The owner calls share(_:to:) with a set of objects and gets a CKShare. The owner sets publicPermission = .readWrite, saves the share via CKDatabase.modifyRecords, then calls persistUpdatedShare(_:in:). The participant accepts the invitation link. All shared records arrive correctly in the participant's shared.sqlite (164 objects), and subsequent owner-side changes continue to arrive. Import events succeed. What fails Every export from the participant's .shared store fails, regardless of what is written. On the participant device: New object assigned to the shared store via context.assign(_:to:) → never exported Update to an existing record that arrived from the owner → never exported Both are saved successfully to the local store (verified by reading the sqlite file) and appear in the persistent history The corresponding NSPersistentCloudKitContainer.Event reports: type: .export succeeded: false error: NSCocoaErrorDomain Code=134060 userInfo: [:] // completely empty — no underlying error countAffectedObjects: 0 Reading the store's internal metadata tables shows the export never begins: ANSCKEXPORTMETADATA — empty (no history token was ever recorded) ANSCKEXPORTEDOBJECT — 0 rows ANSCKEXPORTOPERATION — 0 rows Meanwhile the same device's .private store exports successfully, and the owner device's .private store (which holds the shared zone) exports successfully as well. What I have ruled out Permissions. On the participant, share.currentUserParticipant reports permission == .readWrite, role == .publicUser, acceptanceStatus == .accepted. Record types. All types exist in the Development schema (verified in CloudKit Console). I also ran initializeCloudKitSchema() to be certain. Server-side rejection. The CloudKit Console Logs show no errors at all — the request never reaches the server. The records themselves. Failure is independent of content: a single entity with no relationships fails exactly like a multi-object graph. Association with the share. fetchShares(matching:) on the participant returns the correct share for the record, with the correct zone name and owner name. Core Data does know the object belongs to the shared zone. Corrupted mirroring metadata. Deleting and reinstalling the app on the participant device reproduces the problem from a clean state. CloudKit itself refusing participant writes. Using the raw CloudKit API on the same device, I saved a CKRecord directly into the same shared zone — this succeeded, and the owner device received a push notification for it. So the account, the zone, the permissions and the record type are all fine; only the Core Data mirroring path fails. Question Given that Core Data correctly associates the object with the share, and that the same device can write to the same zone through the raw CloudKit API, why would the mirroring delegate never schedule an export for the .shared store? Specifically: Is exporting participant-side changes from a .shared store supported by NSPersistentCloudKitContainer? The sample project demonstrates share management and owner-side writes, but I could not find an example of a participant creating or modifying objects in the shared store. If it is supported, what would cause NSCocoaErrorDomain 134060 with an empty userInfo and zero affected objects? Is there a way to obtain the underlying reason? (-com.apple.CoreData.CloudKitDebug 1 produced no additional output for me when the app was launched via devicectl.) Is there any additional setup required on the participant side beyond accepting the share — for example, does a newly created object need to be related to an object that is already part of the share in order to be exported? Thank you very much for your help.

Hi, Overview I have an app for which I have created a sandbox account. When I try to clear purchase history it doesn't work, it still shows the in-app purchase items (non-consumable in-app purchases) as purchased. I have tied tried the following ways, but none of them work. Any help on this would be much appreciated! Attempt 1: Go to https://appstoreconnect.apple.com/ Users and Access > Sandbox Check sandbox account > Tap Clear Purchase History button Attempt 2: Go to the iPhone > Settings > Developer > Sandbox Apple Account Tap on account > Manage > Clear Purchase History Attempt 3: Sign out of Sandbox account and sign back in Attempt 4: Delete app and re-run app from Xcode

I'm testing iAP in a sandbox account (as configured in App Store Connect under 'Sandbox Testers'). So the in app purchase works. Cool. But I wanted to retry it. So I cleared the purchase history (both in App Store Connect and on my iPad in the 'Developer' section in Settings). But when I relaunch my app the purchase still validates and my app displays the item as 'unlocked'. Figure the receipt must still be cached so I nuke the app and completely reinstall it but it appears StoreKit is still getting the receipt and it isn't being cleared because my app is displaying it as 'purchased.' Also tried rebooting the iPad. But the sandbox purchase doesn't clear. I just did a sandbox test since it is closer to real life than StoreKit Configuration so I just wanted to do it a few times to make sure all is good but making a burner test account for every purchase is kind of tiresome. Anyone know of a workaround? I might just declare victory and go back to StoreKit Configuration.

While developing a gallery app, I noticed that the iCloudId can change between devices Phone1 and Phone2, on which iCloud is active. First, I know the assetId is unstable, but the iCloud ID ( How it can be? I thought it was stable and I could use it for sending, for example as a UUID for a items on BE to prevent duplication. Could you please explain to me in which cases the iCloudId can change, and what I can use for stable UUID for my internal item to prevent duplication on the BE side? Additional info: Phone1: - assetId part = B01B27D9-10BE-4C95-BE35-C9A03DBA4006 - iCloudId part = 39E0E3A6-6A37-4E8E-83E9-C1B837E2E973 - iCloudId full = 39E0E3A6-6A37-4E8E-83E9-C1B837E2E973:001:ARUcJ2AQQ/nM6BIRu2dq/NSPi61u Phone2: - assetId part = F51B272C-1BE6-41B3-AB54-39E6BDE1C984 - iCloudId part = F51B272C-1BE6-41B3-AB54-39E6BDE1C984 - iCloudId full = F51B272C-1 BE6-41B3-AB54-39E6BDE1C984:001:ARUcJ2AQQ/mM6BIRu2dq/NSPi61u

My first app "Remote for Roku TV: RokuMote" (Apple ID 6795405234, iOS) was submitted for review on July 31, 2026. It has been in "Waiting for Review" ever since — 6+ days — and has never entered "In Review". No messages in App Store Connect, nothing in Resolution Center. What I've already done: Expedited review request on August 4 — no response. Email to App Review — no response. Developer Support case "App Review Status" on August 5 (Case ID 20000128844197) — pending. All metadata, review notes and a demo video were attached at submission. The account is new (created July 28, 2026) — if new accounts are queued differently, I'd appreciate knowing that. Is anyone from Apple able to look into this? Is there a known backlog right now for first submissions?