When switching a device from a Parent Apple Account to a Child Apple Account using the "Keep Data" option, the system-level Declared Age Range prompt fails to render. Instead of presenting the onboarding flow to the user, the system immediately throws AgeRangeError Code=2 (AgeRangeService.Error.notAvailable Indicates the system was unable to share the person’s age range). This causes the app to bypass the intended age verification and log the child in directly. Steps to Reproduce: Sign in to a verified Parent Apple Account on the device and log in to the PTT app. Sign out of the Parent Apple Account in device Settings, ensuring the "Keep Data" option is selected. Sign in to a Child Apple Account on the same device, selecting "Keep Data" (Sign in and Merge data). Open the existing PTT app. Expected Behavior: The OS should present the system-level Age Range onboarding prompt to the new child user so the age range can be properly verified or shared.

Please contact me. Critical design issue affecting Duo. Time sensitive.

I’m testing a SwiftUI app on the iPhone Duo simulator running iOS 27\.1 and have noticed some unexpected behaviour when using pinned Picture in Picture\. When the device is unfolded in portrait and a PiP video is pinned to the top of the display, the available app height drops significantly, but `verticalSizeClass` remains `.regular`\. For comparison, these are the values reported by `GeometryReader`: |Configuration |Available size (pt)|Horizontal|Vertical | |------------------------------|-------------------|----------|----------| |Unfolded landscape |867 × 611 |`.regular`|`.regular`| |Unfolded portrait |669 × 786 |`.regular`|`.regular`| |Unfolded portrait + pinned PiP|669 × 348 |`.regular`|`.regular`| I’d expected the vertical size class to become `.compact` when pinned PiP reduces the available height to approximately 348 points\. Is this intentional behaviour, with size classes remaining tied to the unfolded display configuration rather than the available app window dimensions, or is it potentially a bug in iOS 27\.1? I’m currently working around it by checking the available geometry directly, but I’d be interested to know what the recommended approach is for adapting SwiftUI layouts in this configuration\.

I have a free Apple Developer account and am evaluating an iPhone app that listens for LLDP frames from a USB Ethernet adapter using NWEthernetChannel. Apple’s documentation says this API requires com.apple.developer.networking.custom-protocol. Can this entitlement be used for development on a physical iPhone with free provisioning, or do I need paid Apple Developer Program membership? Does the entitlement require Apple’s approval or a capability request? Can an app with this entitlement be distributed through the App Store? I’m targeting iOS 25 and later. I can provide the adapter and iPhone models if useful. F

I have a shortcut that should repeat on the 1st Saturday of every month at 8 am. However, it doesn't trigger. If I set it to trigger daily, it works; if I set it to repeat weekly, it works. But if I set it to repeat on the first Saturday, it doesn't. The option to select the first Saturday is native in the Shortcuts app. Select time of day -> Repeat -> Frequency Monthly -> Change "each" to "on the"

I recently updated to a new Mac using Migration Assistant. Xcode said it was damaged and wouldn't launch but it reinstalled fine. SF Symbols has the same problem, but reinstalling results in the same damaged message. I've deleted SF Symbol related stuff from Library > Application Support and Library > Preferences but no luck. Anyone have a suggestion on how to get it to work again?

I noticed in the PNG export of my icon in icon composer that there is a border around a layer of my icon. This doesn’t show up in the in app preview, but only when exported. My icon composer file is here: https://github.com/user-attachments/files/28973433/rootshell.27.zip This is the 1024@2x exported image https://private-user-images.githubusercontent.com/65378120/608158382-7b2a8e59-9822-465b-95d0-1dc624d6a617.png

Hello Apple Design Team, I’m an independent AI engineer with a strong background in product design, preparing to bring a new AI-powered application to market alongside a major iOS update featuring native support for iPhone Duo. With launch approaching, I’m looking for guidance on how developers should visually communicate Duo-specific experiences, particularly when preparing App Store screenshots, promotional assets, and featuring nominations. Specifically, are there examples, templates, or recommended approaches for presenting: Multitasking: Two* applications working side by side. Paired apps: Demonstrating workflows between complementary applications. Folded states: Communicating how an application adapts to different device configurations. Screenshot composition: Are larger developers using headlines, explanatory text, and custom layouts within their Duo screenshots, or are they primarily submitting unmodified simulator captures and device renders? App Store featuring: What types of visual assets best communicate Duo-specific functionality in featuring nominations? As an independent developer, I have very few public references for how larger development teams are preparing their launch materials. I’m particularly interested in understanding what Apple Design considers a strong visual demonstration of Duo integration, beyond simply showing an application running on the device. For example, should screenshots emphasize the actual interface and system multitasking experience, or is it appropriate to incorporate marketing headlines and supporting visual elements to explain the workflow? Are there recommended assets, design guidelines, templates, or examples that independent developers can reference before submitting their updates and featuring nominations? This is time-sensitive given the upcoming launch and associated submission deadlines. Any guidance would be greatly appreciated. Thank you for supporting the independent developer community.

With Apple HomeView announced today, is there any developer guidance on designing and optimizing existing iOS applications for the new platform? Very cool product!

Hello. Do you know how to make full screen on SwiftUI? Not like when you tap on green circle placed top-left side in any MacOS app, now my app opens on small window but I need to this app was stretched for horizontal and vertical sides

How do we post app icons using Windows. We're trying to submit our app for review and we've learned how to submit the screenshots for preview but we're having trouble uploading our logo/app icon. Can anyone help pleeeeeeaaaaasssseee?

Hi This is probably not for this particular forum but I wanted to know how I can go about adding assets, logos and images that are compatible with with iphone. I’m so new to this whole thing and I would totally use some guidance. I’m enjoying the conversations and the Q&A thanks! Isaac

Area: iPadOS / UIKit / Accessibility Summary: In iPadOS 27, the floating shortcut bar above the software keyboard (Undo, Redo, Copy, AutoFill) and the bottom keyboard toggle buttons (Globe, Microphone, Handwriting) suffer from severely reduced touch targets. This makes them difficult to tap accurately, leading to frequent mis-taps and a degraded text input experience. Steps to Reproduce: Open any app with a text input field (e.g., Safari, Notes) on an iPad running iPadOS 27. Bring up the software keyboard. Observe the floating shortcut bar and the bottom row of keyboard toggles. Attempt to tap "Undo", "Redo", or the handwriting/globe buttons. Expected Behavior: The UI elements should meet Apple's Human Interface Guidelines for minimum touch target size (44x44 pt). Alternatively, enabling "Larger Text" or "Display Zoom" in Accessibility settings should appropriately scale these system UI components. Actual Behavior: The buttons are visually cramped and their touch targets are tiny. Increasing system text size has no effect on these UI elements. It is extremely difficult to hit the correct button, and users frequently trigger the wrong action. Environment: Device: A16 iPad OS Version: iPadOS 27.0 (Build: [IpadOS27) App: System-wide (Safari, Notes, etc.) Impact: This affects accessibility and basic usability. Users with larger fingers, motor impairments, or those relying on Accessibility features are significantly impacted. The UI feels overly compressed and unintuitive.

IOS27 force the developer to apply the new look and feel. My project set the Navigation View background to red and there is a search bar on the section which background is set to white. It work well under IOS25 and IOS26 by using UIDesignRequiresCompatibility It won't work any more under IOS27 and result a ugly background color on the searchbar, the goal is do the same in IOS27.

When previewing the new header asset, I noticed a peculiarity with the iPad in landscape mode. See the reflected objects at the top of the image; those reflections are at the bottom of my header asset. Is there a bug in  connect that displays the header with a vertical wrap, or will the wrap be present in the distributed build? For reference, none of the other iOS devices have this in either dark/light and portrait/landscape modes. Hope someone sees this and catches the bug.

What is the recommended position of the "X" button dismissing a modal sheet on iOS? When we have "X" and "✓" the case is easy, but what if we just have "X" button? For example, on a "What's New" screen. I found guidelines here: https://developer.apple.com/design/human-interface-guidelines/sheets Based on resizable sheets presented there, the "X" button should be on leading edge. However, iOS is inconsistent and sometimes it presents the button on the leading edge and sometimes on the trailing edge. How do you approach it? Do you prefer having it on the leading or trailing edge? SwiftUI provides ToolbarItem(placement: .cancellationAction) , but it doesn't feel like the right placement. cancellationAction sounds like something for actionable sheets when we have something to be cancelled. I'm missing placement: .dismiss :).

I'm developing an PWA app which really needs the whole screen real estate in focus... Any idea if Apple will make the status bar blur a choice for the developer, not something that is forced? It drives me nuts!

I’m preparing my existing App Store app for iOS 27 and want to test interface resizability on iPhone Duo. I cannot find the iPhone Duo simulator in Device Hub. Is it currently available? If so, what Xcode version/runtime is required and how do I add it? Thanks! I have the latest Xcode 27 from downloads section and Device Hub 27. Where is 27.1 download?

Hello Apple Design and macOS Engineering Teams, With macOS 27 Golden Gate, the introduction of custom color tinting, dark, and clear icon styles has significantly modernized the desktop and application experience. However, there is a noticeable inconsistency in this design language that directly impacts the overall user experience. While all application icons on the left side of the Dock immediately adapt to the selected icon style (Dark, Clear, Tinted), the folder shortcuts, Downloads, Applications directories, and the Trash on the right side of the Dock remain entirely excluded from this visual transformation. As a user who values visual symmetry, color harmony, and attention to detail, having default bright yellow folders and legacy icons sitting right next to dark/clear-themed app icons completely breaks the interface's consistency. The dynamic GPU-layer style transformation applied to the left side should naturally extend to the folder and directory shortcuts on the right side of the Dock as a system standard. In an effort to resolve this locally via scripts or automation, I found that these icon style preferences are not written to any user-accessible system parameters (plist) nor exposed via APIs. Consequently, users have no means to manually or automatically align these visual styles. I have attached screenshots that clearly demonstrate this visual discrepancy. I would like to inquire whether this design gap will be addressed in upcoming macOS updates and if dynamic theme support is planned for the right side of the Dock. I look forward to your feedback on this matter. Sincerely,

Among the major user problems on iPhone that still remain unsolved, which ones do you think an independent developer outside Apple could realistically start tackling today? And if I built a prototype to solve one of them, what would you look for to decide, “This is something real”?