Overview

Hello! I’m building my Swift Student Challenge project in Swift Playgrounds, and I’ve run into an issue with app orientation. Since this is a game, the layout and interactions only work correctly in landscape, but Playgrounds doesn’t offer the usual orientation settings you’d configure in Xcode. Is there a recommended way to force a landscape-only experience in Swift Playgrounds using SwiftUI? Any workarounds or guidance would be greatly appreciated! Thank you!

I got an invite to join an App Store Connect account. When trying to register, I get stuck when trying to enter the 2FA code I got to my phone number. Please have a look here: https://www.loom.com/share/6ed2d55ae05f4290a697d103081d7ade I already have this phone number registered with my work account. Not sure, if this is relevant.

My son uses an iPhone XS running iOS 18.7.2. He is able to bypass all Screen Time app limits by manually changing the date under Settings → General → Date & Time. When he sets the date/time forward or backward, the configured Screen Time restrictions no longer apply. Please make it possible on iOS 18.7.2 (and future versions) to prevent manual date and time changes when Screen Time is enabled, so that children cannot use this method to circumvent app limits.

Hi everyone — I’m implementing the new Hearing Device Support API described here: https://developer.apple.com/documentation/accessibility/hearing-device-support I have MFi hearing aids paired and visible under Settings → Accessibility → Hearing Devices, and I’ve added the com.apple.developer.hearing.aid.app entitlement (and also tested with Wireless Accessory Configuration: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.external-accessory.wireless-configuration ). com.apple.developer.hearing.aid.app xxxxx but the app won't even compile with this entitlement Problem NotificationCenter.default.addObserver(...) for pairedUUIDsDidChangeNotification never fires — not on app launch, not after pairing/unpairing, and not after reconnecting the hearing aids. Because the notification never triggers, calls like: HearingDeviceSession.shared.pairedDevices always return an empty list. What I expected According to the docs, the notification should be posted whenever paired device UUIDs change, and the session should expose those devices — but nothing happens. Questions Does the hearing.aid.app entitlement require special approval from Apple beyond adding it to the entitlements file? Is there a way to verify that iOS is actually honoring this entitlement? Has anyone successfully received this notification on a real device? Any help or confirmation would be greatly appreciated.

Stale TBD Files Cause Runtime Crash When Framework Changes from Dynamic to Static Summary When using EAGER_LINKING=YES, Xcode generates TBD files for dynamic frameworks. When a framework changes from dynamic to static, Xcode doesn't remove the stale TBD, causing dyld: Library not loaded crash at runtime. Environment Xcode 16.4 (16F6), macOS Darwin 24.6.0, iOS Simulator 18.5 Steps to Reproduce Project Structure: MainApp (EAGER_LINKING=YES) ProjectA/SharedLib (dynamic, mh_dylib) ProjectB/SharedLib (static, staticlib) Steps: Build with ProjectA (dynamic framework) → TBD created in EagerLinkingTBDs Switch workspace to ProjectB (static framework) without cleaning DerivedData Build again → BUILD SUCCEEDED Run app → CRASH: dyld: Library not loaded Root Cause Xcode adds -F EagerLinkingTBDs before -F Build/Products: -F/.../EagerLinkingTBDs/Debug-iphonesimulator ← checked FIRST -F/.../Build/Products/Debug-iphonesimulator ← checked SECOND The linker finds the stale TBD first and treats the framework as dynamic, even though the actual binary is now static. Evidence # SharedLib is static $ file SharedLib.framework/SharedLib current ar archive random library # But stale TBD still exists $ ls EagerLinkingTBDs/.../SharedLib.framework/ SharedLib.tbd ← STALE! # MainApp incorrectly references dynamic library $ otool -L MainApp.app/MainApp.debug.dylib | grep SharedLib @rpath/SharedLib.framework/SharedLib ← WRONG! Attempted Workarounds (All Failed) Workaround Result FRAMEWORK_SEARCH_PATHS = "$(BUILT_PRODUCTS_DIR)" "$(inherited)" Xcode still adds EagerLinkingTBDs first EAGER_LINKING = YES on static framework Build failure - empty TBD OTHER_LDFLAGS modifications Linker still uses TBD Expected Behavior When a framework changes from dynamic to static, Xcode should remove the stale TBD file from EagerLinkingTBDs. Suggested Fix Remove TBD files when building static library targets Track MACH_O_TYPE changes and invalidate TBD files accordingly

As a developer I have a question I would like cleared up. We offer two tiers of annual subscriptions in our apps. These subscriptions are under the same subscription group in App Store connect. My question is, if a user purchases tier 1 of the annual subscription for $10.00, and uses it for 6 months; then chooses to upgrade to tier 2 which costs $20.00 per year. Would the user be pro-rated the difference in price i.e. charge only another $10.00 at the time of the upgrade., or are they charged $20.00 and then refunded the difference in their remaining lower tier subscription? I keep finding inconsistent answers across the Apple community forums on this.

Hello! I recently submitted a request for the Family Controls (Distribution) entitlement for my app, and I’m trying to understand what kind of timeline to expect. I’ve seen posts suggesting anywhere from a few days to over a month for approval. Is there a typical review window for this entitlement? And is there anything I can do on my end to help the process move more smoothly? Thanks in advance!

Hi all, I’m trying to understand what’s possible with App Store Connect when using Universal Purchase across iOS and tvOS. We currently have an app that’s set up as a universal purchase for iOS and tvOS. What we’d like to do is: Keep the iOS app fully discoverable and available to new users in the App Store. Make the tvOS app not appear for new users (e.g., not show up in search / categories / product page for users who don’t already own it). Is there a supported way to effectively “hide” or remove the tvOS app from sale for new customers only, while keeping the iOS app live and discoverable, and while existing tvOS users are unaffected? If this isn’t possible at a platform level, are there any recommended best practices for deprecating the tvOS version of a universal purchase app without impacting the iOS listing or existing tvOS users? Thanks in advance for any guidance or pointers to official docs!

Hello, I would like to report a situation that appears to be outside the normal App Review process and may indicate a system issue or an unintended internal flag on my app. My app Vocheo (Bundle ID: com.vocheo) has been stuck in “Waiting for Review” for an unusually long period — a total of ~40 days since the first 2.0 submission on October 26. Across multiple submissions, the review has never meaningfully started. Here is a summary of what happened: Timeline Overview • First 2.0 submission: Oct 26 • Most recent submission: Dec 2 (version 2.1.5) • Total time stuck: ~40 days • Longest individual “Waiting for Review” period: 18 days • Another long period: 8 days • All withdrawals were done on the same day and resubmitted immediately — they did not resolve the issue. Only two submissions ever entered “In Review”, and both resulted in very fast, template-style rejections within minutes. After those, every new submission returned to weeks of “Waiting for Review” with no progress. Attempts to Resolve I have: • Contacted App Review Support several times • Received confirmation that expedited review was approved • But the review never actually started • Support responses indicate “re-queuing due to withdrawal”, but this explanation does not match the actual prolonged delays experienced At this point, support channels have not been able to provide any actionable information or resolution. Why I’m Posting Here Given: • The prolonged review delays far beyond normal processing times • Expedited review approval without any review starting • Multiple resubmissions stuck at “Waiting for Review” for weeks • No clear reason or guidance from support I am concerned this may not be a typical review delay, but rather: • A system-level issue, or • An unintentional internal flag preventing the review from starting I am posting here in hopes that someone from Apple may be able to help escalate or verify whether the app is correctly progressing through the review queue. App Information • App Name: Vocheo • Bundle ID: com.vocheo • Latest Submission: 2.1.5 (submitted Dec 2) • Platform: iOS • Status: “Waiting for Review” consistently for ~40 days Any assistance in determining whether this is a system error, or whether the app is blocked in the queue due to an internal issue, would be greatly appreciated. Thank you very much.

crash stack: Crashed: com.apple.main-thread 0 libsystem_pthread.dylib 0x90c thread_chkstk_darwin + 60 1 libsystem_pthread.dylib 0x90c ___chkstk_darwin + 60 2 CoreAutoLayout 0x14c4 -[NSISEngine _flushPendingRemovals] + 56 3 CoreAutoLayout 0x2de08 -[NSISEngine _coreReplaceMarker:withMarkerPlusDelta:].cold.1 + 64 4 CoreAutoLayout 0x15d78 -[NSISEngine _coreReplaceMarker:withMarkerPlusDelta:] + 204 5 CoreAutoLayout 0x2ce38 -[NSISEngine constraintDidChangeSuchThatMarker:shouldBeReplacedByMarkerPlusDelta:] + 108 6 CoreAutoLayout 0x15f1c -[NSISEngine tryToChangeConstraintSuchThatMarker:isReplacedByMarkerPlusDelta:undoHandler:] + 100 7 CoreAutoLayout 0x2fdbc -[NSLayoutConstraint _tryToChangeContainerGeometryWithUndoHandler:] + 252 8 CoreAutoLayout 0x3020c -[NSLayoutConstraint _setSymbolicConstant:constant:symbolicConstantMultiplier:] + 452 9 CoreAutoLayout 0x30378 -[NSLayoutConstraint setConstant:] + 84 10 UIKitCore 0x51c3c __74-[UIView(UIConstraintBasedLayout) _autoresizingConstraints_frameDidChange]_block_invoke + 140 11 UIKitCore 0x1841174 -[UIView(AdditionalLayoutSupport) _withUnsatisfiableConstraintsLoggingSuspendedIfEngineDelegateExists:] + 112 12 UIKitCore 0x51b28 -[UIView(UIConstraintBasedLayout) _autoresizingConstraints_frameDidChange] + 452 13 UIKitCore 0x2c894 -[UIView _constraints_frameDidChange] + 100 14 UIKitCore 0x18fac08 -[UIView(Geometry) setFrame:] + 576 15 UIKitCore 0x96712c -[UITabBar setFrame:] + 128 16 UIKitCore 0x1666f4 -[_UITabBarControllerVisualStyle updateTabBarLayout] + 360 17 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 18 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 19 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 20 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 21 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 22 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 23 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 24 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 25 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 26 UIKitCore 0x16671c -[_UITabBarControllerVisualStyle updateTabBarLayout] + 400 27 UIKitCore 0x16642c -[UITabBarController _prepareTabBar] + 128 28 UIKitCore 0x166a10 -[UITabBarController _layoutContainerView] + 376 29 UIKitCore 0x1677a8 -[UITabBarController __viewWillLayoutSubviews] + 28 30 UIKitCore 0x147078 -[UILayoutContainerView layoutSubviews] + 176 31 UIKit 0xb14a0 -[UILayoutContainerViewAccessibility layoutSubviews] + 60 for a more detail crash stack, can see attach file: crash.txt crash probabilistic happed after app enter background, and our app support landscape, when crash appear, the system method: /* This method is called when the view controller's view's size is changed by its parent (i.e. for the root view controller when its window rotates or is resized). If you override this method, you should either call super to propagate the change to children or manually forward the change to children. */ - (void)viewWillTransitionToSize:(CGSize)size withTransitionCoordinator:(id <UIViewControllerTransitionCoordinator>)coordinator API_AVAILABLE(ios(8.0)); is called; but for a normal not crash case, when enter background and rotate device, the viewWillTransitionToSize method is not called until app enter foreground; Are there any suggestions that can help solve this problem, thank you.

I'm getting the following error when I try to make a dev build for iOS even though I am an admin: ✖ Failed to register bundle identifier Apple 403 detected - Access forbidden. This request is forbidden for security reasons - You currently don't have access to this membership resource. Not certain how to proceed from here

I created my app with the wrong name and deleted it 3 days ago. When I want to create a new app, I can't use the old app's bundle id, even though I removed it. I opened a support case 2 days ago, but so far nothing changed.

Hi everyone, I submitted this feature request through Apple’s Feedback Assistant and wanted to share it here, because many families run into the same issue and Apple prioritizes features based on the number of reports they receive. Current limitation: Screen Time only allows one single Downtime period per day for child accounts. For families with separate school hours and bedtime, this is very impractical. My real-world use case: • Downtime 1: 08:00–13:00 (school) • Downtime 2: 20:00–06:00 (bedtime) Both serve completely different purposes, but are not possible to combine with the current system. My suggestions to Apple: Support multiple Downtime periods per day for child accounts. Allow custom exceptions per Downtime block (e.g., allow Phone app). Provide more flexibility overall for families using Screen Time. If you would benefit from this too, it would be great if you could submit the same request via the Feedback app – the more reports Apple receives, the higher the chance for implementation. My Feedback ID: FB21265678 Thank you! 🙏 Hallo zusammen, ich habe über die Feedback-App einen Vorschlag an Apple eingereicht und wollte ihn hier teilen, weil viele Familien dasselbe Problem haben und Apple mehr Rückmeldungen braucht, um das Thema zu priorisieren. Aktuelles Problem: In Bildschirmzeit kann für Kinder aktuell nur eine einzige Auszeit pro Tag eingerichtet werden. Für Familien mit getrennten Schul- und Schlafenszeiten ist das extrem unpraktisch. Mein Anwendungsfall: • Auszeit 1: 08:00–13:00 (Schule) • Auszeit 2: 20:00–06:00 (Schlafenszeit) Beides erfüllt unterschiedliche Zwecke, ist aber nicht kombinierbar. Mein Vorschlag an Apple: Mehrere Auszeiten pro Tag für Kinderaccounts. Pro Auszeit eigene Ausnahmen festlegen (z. B. Telefon erlauben). Allgemein mehr Flexibilität im Screen-Time-System für Familien. Wenn ihr das ebenfalls hilfreich findet, wäre es super, wenn ihr es auch über die Feedback-App meldet – je mehr, desto besser. Feedback-ID meines Vorschlags: FB21265678 Danke euch! 🙏

I've adopted the new BGContinuedProcessingTask in iOS 26, and it has mostly been working well in internal testing. However, in production I'm getting reports of the tasks failing when the app is put into the background. A bit of info on what I'm doing: I need to download a large amount of data (around 250 files) and process these files as they come down. The size of the files can vary: for some tasks each file might be around 10MB. For other tasks, the files might be 40MB. The processing is relatively lightweight, but the volume of data means the task can potentially take over an hour on slower internet connections (up to 10GB of data). I set the totalUnitCount based on the number of files to be downloaded, and I increment completedUnitCount each time a file is completed. After some experimentation, I've found that smaller tasks (e.g. 3GB, 10MB per file) seem to be okay, but larger tasks (e.g. 10GB, 40MB per file) seem to fail, usually just a few seconds after the task is backgrounded (and without even opening any other apps). I think I've even observed a case where the task expired while the app was foregrounded! I'm trying to understand what the rules are with BGContinuedProcessingTask and I can see at least four possibilities that might be relevant: Is it necessary to provide progress updates at some minimum rate? For my larger tasks, where each file is ~40MB, there might be 20 or 30 seconds between progress updates. Does this make it more likely that the task will be expired? For larger tasks, the total time to complete can be 60–90 mins on slower internet connections. Is there some maximum amount of time the task can run for? Does the system attempt some kind of estimate of the overall time to complete and expire the task on that basis? The processing on each file is relatively lightweight, so most of the time the async stream is awaiting the next file to come down. Does the OS monitor the intensity of workload and suspend the task if it appears to be idle? I've noticed that the task UI sometimes displays a message, something along the lines of "Do you want to continue this task?" with a "Continue" and "Stop" option. What happens if the user simply ignores or doesn't see this message? Even if I tap "Continue" the task still seems to fail sometimes. I've read the docs and watched the WWDC video, but there's not a whole lot of information on the specific issues I mention above. It would be great to get some clarity on this, and I'd also appreciate any advice on alternative ways I could approach my specific use case.

View Layout Add the following views in a view controller: Label View A, with a subview of the same size: MTKView A View B, with a subview of the same size: MTKView B Refresh Rates of Each View The label view refreshes at 60fps (driven by CADisplayLink). MTKView A and B refresh at 15fps. MTKView Implementation Details The corresponding CAMetalLayer's maximumDrawableCount is set to 2, changed to double buffering. The scheduling mechanism is modified; drawing is not driven by the internal loop but is done manually. The draw call is triggered immediately upon receiving a frame. self.metalView.enableSetNeedsDisplay = NO; self.metalView.paused = YES; A new high-priority queue is created for drawing, instead of handling it on the main queue. MTKView Latency Tracking The GPU completion time T1 is observed through the addCompletedHandler callback of the CommandBuffer. The presentation time T2 of the frame is observed through the addPresentedHandler callback of the currentDrawable in MTKView. Testing shows that T2 - T1 > 16.6ms (the Vsync period at 60Hz). This means that after the GPU rendering in MTLView is finished, the frame is not actually displayed at the next Vsync instruction but only at the Vsync instruction after that. I believe there is an extra 16.6ms of latency here, which I want to eliminate by adjusting the rendering mechanism. Observation from Instruments From Instruments, the Surface presentation aligns with the above test results. After the Metal encoder finishes, the Surface in Display switches only after the next-next Vsync instruction. See the image in the link for details. Questions According to a beginner's understanding, after MTKView's GPU rendering is finished, the next Vsync instruction should officially display (make it visible). However, this is not what is observed. Does the subview MTKView need to wait for another Vsync cycle to be drawn to the actual display buffer? The label updates its text at 60fps, so the entire interface should be displayed at 60fps. Is the content of MTKView not synchronized when the display happens? Explanation of the Reasoning Behind Some MTKView Code Details Changing from the default triple buffering to double buffering helps reduce the latency introduced by rendering. Not using MTKView's own scheduling mechanism but using manual triggering of the draw method is because MTKView's own scheduling mechanism is driven by CADisplayLink. Therefore, if a frame falls within a Vsync window, it needs to wait for the next Vsync window to trigger the draw operation, which introduces waiting latency.

I noticed that I cannot even tell that an NSBox is being used on macOS Tahoe when the system is in light mode. The 'box' background can't be seen so it makes it appear that the subviews in the box aren't positioned correctly (because they are inset from the subview outside the box). There is no visual indicator that that subviews inside this box are grouped together because well, you can't see the box at all. In Interface Builder the box looks fine at Design Time in "Light Mode". In Dark Mode the box looks fine at design time and at run time. Just figured I'd throw that out there.

I don't know what happened I try to fix and resolve issues and no feedback or anything back

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

Hello Apple Dev Support, Our company is preparing to submit an iOS and iPadOS application. When development commenced nine months ago, the application name was available. However, during the submission process for internal and external testing via TestFlight, we discovered that the name is already in use. We are seeking a solution to secure our application name, ensuring its exclusive use for our purposes. We anticipate approximately four to five months of development before the application's release. If we submit our application for Apple review and receive approval but refrain from releasing it, would this action reserve or register the name for our exclusive use, preventing others from utilizing it? Thank you

My team has a robust digital accessibility program and processes for WCAG conformance in our apps. Because of this, there are definitely accessibility defects that get caught and addressed in order of impact and business priority like any other bug. Obviously we want to aim for 100% accessibility for our users, but it's a continual work in progress as new enhancements or changes are released. I'm stuck on the appropriate measurement to indicate support. If we have 50 common tasks and the most central 10 tasks are solid but some supporting (but also common) tasks have a contrast fail or accessibleLabel missing, does that make the whole app not supporting the feature? If "completing the task" is the rubric there are a whole range of interpretations for that. In a complex app, I anticipate that a group like ours will have strong support for many of the Accessibility Nutrition Labels accessibility features across tasks and devices, but realistically never be 100% free of defects for a given Apple Accessibility feature, even among core tasks. As I consider the next steps for Nutrition Labels, I do not see anything in the documentation that gives a sort of baseline or measurement for inclusion. We plan to test all steps to complete a task, and log defects accordingly with an assigned timeline for fixing them (as would be true for functional defects).