Using Xcode 27.1 RC, the iPhone Duo simulator (Device Hub) only comes with the Settings and Safari apps. Am I missing something? Are there plans to have the usual simulator apps such as Photos, Calendar, Reminders, Maps, etc.? In these early stages it would be really nice to have some real apps to look at for examples of how some things should work/appear on the Duo in different layouts.

Since upgrading my free Apple Developer account to the paid Apple Developer Program (Individual) on September 21, 2026, every app signed with my paid team fails to install on my devices. TestFlight builds work. Error (Xcode Run, devicectl, Ad Hoc export): MIInstallerErrorDomain Code 13 / 0xe8008018 "The identity used to sign the executable is no longer valid." +[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:] LibMISErrorNumber = -402620392 What I've established: A brand-new Hello World app with no capabilities fails the same way, so it is not my project, entitlements or widget. The same Hello World signed by a free Personal Team installs on the same iPad (after trusting the developer in Settings). So the device, OS, Xcode and Mac are fine. Fails on iPad Pro 13" M4 (iPadOS 27.0.1 and 27.2), iPhone Air (iOS 27.0.1) and iPhone 15 Pro Max (iOS 26.0.1), with Xcode 27.0, 27.1 and 27.2. Fails with Apple Development signing (Xcode Run) and with an Ad Hoc export signed with an Apple Distribution certificate. codesign verifies the app, the embedded profile contains the signing certificate and the device UDIDs, and the chain (WWDR G3 to Apple Root CA) is valid and not expired. Regenerated the Development and Distribution certificates, cleaned expired WWDR certificates from the keychain, removed profiles on the device, re-paired and toggled Developer Mode. No change. Only apps re-signed by Apple (TestFlight) install. This looks like stale signing state for the team on Apple's side after the free-to-paid conversion. I have an open request with Apple Developer Support (Case-ID 22506476) and Feedback Assistant report FB24912726, but have had no reply in two weeks. Has anyone seen 0xe8008018 on a team that was recently upgraded or converted, and is there anything I can do on my side beyond asking Apple to reset the team's signing identity?

Has anyone else run into this issue? If you present a view controller and set its isModalInPresentation property to true, then when you try to drag down the view controller (which can't be dismissed), the view controller's content on the side of the vertical toolbar is shifted inward. This happens on a closed iPhone Duo. Even the title shifts if the vertical toolbar is on the left side. To replicate, create a Swift/UIKit project. Edit the main storyboard by deleting the default view controller scene and add a navigation controller (and its default root view controller). Set the class for the root view controller to ViewController. Then replace the default ViewController.swift code with the following: import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let modal = UIBarButtonItem(systemItem: .add, primaryAction: .init(handler: { _ in let vc = ViewController() vc.title = "Some Modal" // If the following is true, dragging the modal view controller // down results in the table margins being shifted on whichever // side has a vertical toolbar. This happens on the iPhone Duo // when closed in either portrait or landscape. Whichever side // has the vertical toolbar gets shifted. // When the iPhone Duo is open the modal appears in a form sheet // and it does not demonstrate the issue. // The navigation title is also affected when the iPhone Duo is // closed and in landscape with the vertical toolbar on the left. // If the following is false, dismissing the modal by dragging it // down does NOT result in any change in the table's margins. vc.isModalInPresentation = true // false let nc = UINavigationController(rootViewController: vc) self.present(nc, animated: true) })) navigationItem.rightBarButtonItem = modal } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { 2 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { 4 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { // Some simple table cells to demonstrate the margin shift let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .value1, reuseIdentifier: "cell") cell.textLabel?.text = "Some Text" cell.detailTextLabel?.text = "Value" cell.accessoryType = .disclosureIndicator return cell } } Build and run the app with Xcode 27.1 and run it on an iPhone Duo (simulated or real). Tap the + icon to display the modal view controller (just another instance of ViewController). Now try to drag down the modal view controller. Notice the margin shift if the Duo is closed. There is no margin shift is the Duo is open or if isModalInPresentation is set to false. This has been reported as FB25221160.

We're adding an option to our Unity SDK that gives a game a native launch screen: a launch storyboard (set through UILaunchStoryboardName) showing a full-screen image from an asset catalog. What we see On a clean install, the new launch screen shows as expected. When the same device installs an update over the existing app (tested through TestFlight), the previous launch screen keeps showing. Launching the app several times does not change it. Deleting the app, restarting the device and reinstalling shows the new launch screen straight away. We checked the build itself: the compiled storyboard, the image in Assets.car and the Info.plist keys are all correct, so this looks like the system's launch screen snapshot cache. We assume App Store updates behave the same way. What we're considering On the first launch after an update, the app would delete the cached launch screen snapshots in its own container (Library/SplashBoard), so the system regenerates them and the new launch screen shows on the next launch. This only uses public file APIs inside the app's own sandbox. But Library/SplashBoard is not documented anywhere, so we'd rather ask before shipping it. Questions Is deleting Library/SplashBoard from the app's own container a supported or acceptable practice, or could it cause problems (with the system, or in a future iOS version)? Is there a supported way to make iOS refresh a cached launch screen after an app update? If not, is the expected behaviour simply that the system refreshes the snapshot at some point? Is it documented when that happens (for example after a reboot, or after a certain time)? If clearing the folder isn't recommended, we won't ship it. Updating players would just keep the old launch screen until iOS refreshes it. Thanks!

On iPhone 14 Pro and later, the system flashlight in Control Center can adjust beam width (narrow ↔ wide). As far as I can tell, AVCaptureDevice only exposes torchMode, torchLevel and setTorchModeOn(level:) I found nothing related to beam width Is there any supported way for a third-party app to control the torch beam width? If not, is this on the roadmap?

We build a medical scanning app. A practitioner walks a slow orbit (~1 m radius, two laps, 25–35 s) around a standing subject while an ARSession runs, and we capture ~50 high-resolution stills with captureHighResolutionFrame. The ARKit camera poses for those frames are later used to set the metric scale of a photogrammetry reconstruction. We need the resulting scale to be within about 2 % of true. What we observe, measured against a printed A4 sheet on the floor in every scan: Devices with LiDAR (iPhone 16 Pro Max, iPad Pro), using the sceneDepth frame semantic as a check: scale within ±0.8 % across 11 sessions. Devices without LiDAR (iPhone 13, iPad 9th and 11th gen, plus non-LiDAR runs on the Pro devices): the world-frame metre is on average 2–3 % short of true, and varies by a further ±2 % from one session to the next, across 24 sessions in four rooms. Within a session the scale is stable: lap-to-lap variation is under 0.4 %. The error appears to be set during initialisation and held. Nothing we record about capture correlates with the error: time spent before capture, distance walked, vertical camera movement, orbit radius, rotation speed, tracking state, or the residual of our pose fit. Questions: Is there any session setup, initialisation practice, or motion during the first seconds of tracking that is known to improve the metric scale estimate on devices without LiDAR? Does the choice of video format, resolution or frame rate affect scale estimation? Is there any signal, beyond ARCamera.trackingState, that indicates how well scale has been determined for a session, so we could flag sessions rather than accept them? Does anything in the configuration above, in particular locking exposure on the capture device or using the high-resolution video format, work against tracking quality or scale?

We are implementing StoreKit External Purchase Link for an iOS app distributed in the European Union and are trying to determine whether we are missing a configuration step or encountering a StoreKit server-side eligibility issue. The failure is reproducible in a focused native Swift Xcode project that directly calls StoreKit: let eligible = await ExternalPurchaseCustomLink.isEligible The sample contains no Flutter code, PayPal SDK, networking, or application business logic. Configuration we have verified: The Account Holder accepted the StoreKit External Purchase Link Entitlement Addendum for EU Apps. StoreKit External Purchase Link is enabled and shown as Assigned for the App ID. The regenerated Development provisioning profile contains com.apple.developer.storekit.external-purchase-link = true. The installed app's signed entitlements contain the same value. The application-identifier and team-identifier match the intended App ID and team. The compiled Info.plist contains SKExternalPurchaseCustomLinkRegions with all 27 lowercase EU region codes, including "de". Germany is available for the app in App Store Connect. No local StoreKit Configuration file is enabled. Test environment: Physical iPhone running iOS 26.5.2 (23F84) Xcode 26.6 (17F113) Real German Media & Purchases Apple Account German Sandbox Apple Account StoreKit 2 storefront ID 143443, country code DEU StoreKit 1 also reports country code DEU AppStore.canMakePayments = true AppTransaction verifies in the Sandbox environment Clean build and reinstall using the regenerated Development profile Observed result: ExternalPurchaseCustomLink.isEligible = false For diagnostic purposes only, after observing false eligibility, we also requested both token types: ACQUISITION: StoreKitError.notAvailableInStorefront SERVICES: StoreKitError.notAvailableInStorefront A delayed recheck still reports storefront DEU and isEligible=false. Our production flow does not request tokens unless eligibility is true. We found the similar thread "Unable to enable eligibility for External Purchase Link APIs" (https://developer.apple.com/forums/thread/808349). In that case, the production Media & Purchases account had an unsupported storefront. In our case, both the real Media & Purchases account and the Sandbox account are German, and StoreKit itself reports DEU. We also found "External Purchase in Japan" (https://developer.apple.com/forums/thread/822618), where an Apple App Store Commerce Engineer requested a Feedback Assistant report with a sysdiagnose and screen recording for isEligible=false. Questions: Should ExternalPurchaseCustomLink.isEligible return true in a developer-signed Sandbox build when the entitlement, compiled Info.plist, German storefront, and account conditions are all satisfied, or is TestFlight/App Store approval required? Is there any additional App Store Connect storefront election, entitlement approval, or server-side activation step required beyond the EU addendum, Assigned capability, signed entitlement, and SKExternalPurchaseCustomLinkRegions? If this configuration is complete, could Apple verify whether eligibility has not propagated correctly for the German Development/StoreKit Sandbox environment, and which diagnostics should be included in a Feedback Assistant report? We have also opened a code-level support request and prepared a minimal native Swift reproduction project. Any guidance from StoreKit engineering would be appreciated.

I'm trying to test the new “Describe a Shortcut” feature in iOS 27 using an iPhone 17 Simulator. When I open Shortcuts and tap “Describe a Shortcut”, it stays on: “Preparing support for describe a shortcut” and the text field remains disabled. I cannot enter anything or create the shortcut. My setup: Mac: MacBook Pro macOS: 27 Xcode: 26.5 (17F42) Simulator: iPhone 17 iOS: 27 I also have a physical iPhone 14 Pro, but I understand that it doesn't support Apple Intelligence, so I'm trying to test this using the iPhone 17 Simulator. Do I need to enable/download anything for Apple Intelligence on the Mac or Simulator? Or is “Describe a Shortcut” currently unsupported/not working in the iOS 27 Simulator? Any guidance on the correct setup would be appreciated.

Hello, Our app, InReality (iOS version 0.1.4, build 20), has been in “Waiting for Review” since October 26, 2026. This is a new version of an existing app, using the same bundle ID, io.inreality.app. The previous version has been off the App Store for an extended period, and we are now preparing to bring InReality back. Timeline: October 26: Submitted version 0.1.4 for App Review. October 29: Requested expedited review and received confirmation: “We’ll expedite review for InReality.” October 30: Contacted App Review Support (Case #103013501314). November 1: Still “Waiting for Review,” with no visible review activity or requests for additional information. We understand that review times vary, but we are concerned that the submission has not entered review despite the accepted expedited request. Could an Apple representative help verify whether our submission is correctly queued for expedited review, check for any administrative or technical blocker, and escalate our existing support case if appropriate? If this cannot be checked through the forums, guidance on the appropriate escalation route would be appreciated. Our team is available to respond immediately to any requests for additional information. Thank you for your assistance.

It would be great for accessibility and productivity for hardware like iPhone Duo that do not have an action button to include a setting to enable a "VIRTUAL" action button that can appear on screen with the same capability. And connecting it to Siri setting control to "TURN ON ACTION BUTTON" or "SHOW VIRTUAL ACTION BUTTON". FOR ACCESSIBILITY and for feature parity for newer devices where physical button is not present. Thank you

Environment Xcode 27.1 iOS 27.1 iPhone Duo simulator UIKit app built with the iOS 27.1 SDK Issue On iPhone Duo, the background of a system-managed UINavigationBar does not extend completely to the top edge of the window. The navigation bar is configured using UINavigationBarAppearance with an opaque blue background. However, a horizontal white strip remains above the blue navigation bar. I also post a feedback: FB24859353 Questions Is this expected behavior on iPhone Duo? What is the recommended way to style this top region? Should apps add a custom background underlay outside the UINavigationBar bounds? Could this be an iOS 27.1 or iPhone Duo simulator issue? Minimal reproduction code: import UIKit final class DemoTabBarController: UITabBarController { override func viewDidLoad() { super.viewDidLoad() viewControllers = NavigationBarStyle.allCases.map { style in let content = DiagnosticsViewController(style: style) let navigationController = UINavigationController(rootViewController: content) navigationController.tabBarItem = UITabBarItem( title: style.title, image: UIImage(systemName: style.symbolName), selectedImage: nil ) style.apply(to: navigationController.navigationBar) return navigationController } } } enum NavigationBarStyle: CaseIterable { case systemDefault case appearance case legacy var title: String { switch self { case .systemDefault: return "Default" case .appearance: return "Appearance" case .legacy: return "Legacy" } } var symbolName: String { switch self { case .systemDefault: return "iphone" case .appearance: return "paintbrush" case .legacy: return "clock.arrow.circlepath" } } func apply(to navigationBar: UINavigationBar) { switch self { case .systemDefault: break case .appearance: let appearance = UINavigationBarAppearance() appearance.configureWithOpaqueBackground() appearance.backgroundColor = .demoBlue appearance.shadowColor = nil appearance.titleTextAttributes = [.foregroundColor: UIColor.white] navigationBar.tintColor = .white navigationBar.standardAppearance = appearance navigationBar.compactAppearance = appearance navigationBar.scrollEdgeAppearance = appearance case .legacy: navigationBar.tintColor = .white navigationBar.barTintColor = .demoBlue navigationBar.backgroundColor = .demoBlue navigationBar.setBackgroundImage(Self.solidImage(color: .demoBlue), for: .default) navigationBar.shadowImage = UIImage() navigationBar.isTranslucent = false navigationBar.titleTextAttributes = [.foregroundColor: UIColor.white] } } private static func solidImage(color: UIColor) -> UIImage { return UIGraphicsImageRenderer(size: CGSize(width: 1, height: 1)).image { context in color.setFill() context.fill(CGRect(x: 0, y: 0, width: 1, height: 1)) } } } private extension UIColor { static let demoBlue = UIColor(red: 0.0, green: 0.46, blue: 0.70, alpha: 1.0) }

I am looking for guidance from Apple or other developers who have experienced a similar Guideline 4.3(a) rejection. I submitted an independently developed iPhone/iPad application, Canvasz AI: Passport ID Photo, for App Review. On September 30, 2026, the app was rejected under Guideline 4.3(a) – Design – Spam, with a general statement that the app appeared to share a similar binary, metadata, and/or concept with apps submitted by other developers. The problem is that I have not been able to determine what Apple actually considers similar. Canvasz AI was developed independently and was not created from a purchased template, white-label application, cloned application, or repackaged source code. The application includes product-specific functionality such as: Real-time face-position and distance guidance before taking a photo On-device face detection and format-aware automatic framing Passport/document head-size framing logic On-device background segmentation, matting, and replacement without uploading the user's photo to a processing server One source photo converted into multiple destination classes, including passport/visa/ID photos, profile images, social-media formats, and banners Batch generation/export of supported formats from one source photo An enhancement pipeline intended to preserve facial detail rather than apply a generic beauty filter Seven localized languages iPhone and iPad layouts Portrait and landscape support No account or signup requirement Core photo processing that works locally/on-device Following the rejection, I replied through App Store Connect asking whether the concern related specifically to: Binary/source-code similarity Metadata Visual assets/UI The application concept itself I also performed an additional source-provenance and similarity audit. The audit documented progressive source-control history and compared Canvasz AI against my other independently developed applications. It found no byte-identical application-specific source/assets across the compared applications, the common files identified were normal Flutter/iOS/Android generated framework/scaffolding files. I attached the forensic technical clarification report to App Review and offered to provide source-control history, architecture information, screenshots, development evidence, or additional technical information if required. I first replied on September 30 and followed up again on October 5. I still did not receive clarification identifying the actual similarity concern. I subsequently resubmitted the application on October 12, 2026, with detailed App Review notes and the forensic report attached. As of October 25, 2026, both the app and its in-app purchase remain Waiting for Review. I understand that App Review may require additional time, especially after a previous Guideline 4.3 rejection. I am not asking for special treatment or asking Apple to disclose another developer's confidential application or internal detection systems. What I need is enough actionable information to understand how to comply. Apple's published Guideline 4.3 states that apps in established categories may be accepted when they provide a meaningfully different or improved experience. I therefore have three specific questions: If an independently developed application receives a 4.3(a) rejection referring to "binary, metadata, and/or concept," how can the developer determine which of those dimensions actually caused the rejection? If source provenance and independent development evidence are provided, but no clarification is received, what additional evidence is normally useful for demonstrating that an application is not a template, clone, or repackaged application? For the "meaningfully different or improved experience" standard, should differentiation be evaluated on the complete user workflow and experience, or is overlap in individual features sufficient to trigger Guideline 4.3? I have invested significant development, testing, localization, and product-design effort into building a genuine application intended to provide useful functionality to users. I fully respect Apple's need to prevent spam, cloned apps, white-label applications, and low-effort template submissions. I support that objective. However, without knowing whether the concern is source code, metadata, UI/assets, or the concept itself, it is extremely difficult for an independent developer to make a meaningful correction instead of making speculative changes. I would appreciate guidance from Apple or developers who have encountered this situation and successfully obtained actionable clarification. Thank you.

Sometime pre-iOS 26 it was possible to use a SplitViewController so that on iPhone you saw the master as a side menu (e.g. hamburger), and the detail full screen. While on iPad you would see the master displayed in a sidebar that could be closed, with the detail fullscreen. This has changed, using a SplitViewController on iPhone now forces you into having 2 fullscreen screens, with a push/pop layout and a back button. In situations where you want the detail screen to open first, this results in users opening the app to find a back button already presented, despite having not navigated anywhere. They must "return" to a screen they never saw. I really despise this layout and find it to be quite a UX issue. But given the new iPhone Duo, using the SplitViewController is now one of the easiest ways to maintain the necessary responsiveness needed, forcing us to accept this behaviour on regular iPhones. Can we PLEASE get the old functionality back, where we can explicitly state on iPhone that the master will always be displayed as a menu?

I submitted enhancement request FB24804559 for a system-wide scrolling screenshot feature in iOS. The idea is a “Capture More” option after taking a screenshot, similar to Android. iOS would continue capturing while scrolling, and the user could choose the exact endpoint. Ideally, this should work in any scrollable app where technically possible and save the result as one long image. This would be especially useful for Messages, Mail, Settings, social media, lists and other scrollable content.

Hello Apple Developer Community, We are developing a hardware diagnostic solution consisting of a macOS desktop application and a companion iOS application. Our iOS application is currently distributed through Apple TestFlight for testing purposes. The application installs and functions correctly when users download it manually through TestFlight. However, we are facing an issue when attempting to automatically install the same iOS application onto iPhones connected to our macOS application via USB. Our Intended Workflow A user connects one or multiple iPhones to a Mac using USB cables. Our macOS application automatically detects the connected devices. The macOS application initiates installation of our iOS diagnostic application onto the connected iPhones. The iOS application performs hardware diagnostic tests. Test results are transferred back to the macOS application. Once testing is completed, the iOS application can be removed from the connected devices. Current Issue When installing the iOS application manually through TestFlight, everything works correctly. However, when attempting to install the application programmatically from our macOS application over USB, we encounter a developer recognition or trust-related error. Our objective is to support commercial hardware diagnostic testing on customer-owned iPhones without requiring users to manually install the application, enable Developer Mode, trust developer certificates, or register individual device UDIDs. Questions Is there an officially supported Apple API, framework, or method that allows a macOS application to programmatically install an iOS application onto USB-connected iPhones? Is this functionality available for applications distributed through TestFlight, or does it require an App Store production release? Can installation be initiated on customer-owned, unmanaged iPhones without requiring Developer Mode, manual certificate trust, or device registration? Are there specific code-signing, provisioning profile, or distribution requirements for installing an iOS application through USB? Does Apple provide a supported solution for deploying diagnostic applications to multiple USB-connected iPhones simultaneously? If direct USB installation is restricted, what alternative Apple-supported workflow would be recommended for commercial device diagnostic and refurbishment applications? Additional Information Our iOS diagnostic application and macOS desktop application have already been developed, and the core diagnostic functionality is working. The remaining challenge is determining the correct Apple-supported method for installing the iOS companion application automatically onto connected devices. We would appreciate guidance from Apple engineers or developers who have experience with USB-based iOS application deployment, device management, or commercial diagnostic solutions. Thank you for your assistance.

Hello Apple App Review Team, I would appreciate your assistance with the review of my app, Trepho (App ID: 6816292923). My app has been awaiting approval since October 22, 2026, and it has now been seven days. I understand that review times can vary, but I would be grateful for an update on the status of my submission. For reference: App name: Trepho App ID: 6816292923 Pending approval since: October 22, 2026 Support Case ID: 103011066693 Could someone from the App Review Team please look into my submission and confirm whether any additional information or action is required from my side? As an independent developer preparing to launch my app, an update would help me plan the next steps. Thank you for your time and assistance. Best regards, David

I've been trying to sign up to the developer program and the response I've gotten is weird. "For one or more reasons, your enrollment in the Apple Developer Program couldn't be completed. We can't continue with your enrollment at this time." Is there absolutely nothing I can do to fix this? I can't even get a reason for why my enrolment has been blocked. I've tried signing up on 3 different devices and they all have different reasons for why I can't continue. iPhone: "Unable to Continue. Contact support" iPad: ID Verification Rejected MacBook: Unable to Verify (Tried driver's licence and passport, passport matches my Apple ID name exactly.

My latest app communicates, via TCP, with an embedded device. The embedded device is programmed in C and sends my Swift app data encapsulated in "messages" which are actually structures defined like this: { uint16_t sig; uint16_t len; // Total length of message, include header and playload; uint16_t type; uint32_t data; // 32 Bits of data. } MSG_t; In my Swit app they arrive via NWConnection, and are sent to my controller delegate as Data (That's the swift type called Data, not just the general term 'data') So me question for you harties is this: How can I unpack this 'Data' into something resembling my C struct - and acess it's members by name. In Pseudo code I'd like to do something like: if let myData = data { myStruct = <cast myData.bytes onto a struct > if myStruct.sig == CORRECT_MSG_SIG { // do soemthig with the message... } } So is this possible? Is it the wrong approach? Is there a better approach?

I'm trying to prepare my app for the iPhone Duo release. I'm now producing the screenshots for the Duo. Apple's guidance gives dimensions for folded and unfolded, but these dimensions are both different in height, so they would make them visually uneven on the App Store, which would undoubtedly be refused. My screenshots show the device on a coloured background. I have shots for both open landscape and closed portrait, but I'm unsure how to properly format them. Are there any examples that Apple have released for me to review?

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\.