Hello, I want to use universal links in my application, for which I need to get the TeamID and BundleId, for apple-app-site-association file. Can you please tell me, do I have to buy an Apple Developer Account at the time of development to do this, or can I get it all for free at the time of development?

I think the title says it all.

What's the guidance on submitting new builds for App Review that include support for iPhone Duo/iPhone resizability? Will they work when building with Xcode 27 + if available for 27.1 or do we have to wait for new Xcode release? Any guidance from Apple and timeframe on build submission if our updates are ready and undergoing testing in simulator? Thank you.

I’m simulating an iPhone Duo using Xcode 27.1 beta, and I’m having trouble tapping buttons placed near the top of the screen. It seems that the top ~20 pixels of the screen are not responding to taps. In my ViewController, preferredScreenEdgesDeferringSystemGestures returns .all, so system gestures should require two swipes to be triggered. However, a simple tap in this area does not seem to be recognized. This appears to happen only on iPhone Duo; taps work normally on other iPhone models. Does anyone know whether this behavior is expected to occur on the actual iPhone Duo hardware as well, or is it specific to the simulator? For reference, the buttons are positioned according to LayoutMarginsGuide with Safe Area. FB24914903 I wonder if anyone knows how to get the top margin size programmatically.

"Build a great camera experience for iPhone Duo" covers the device open and the device closed, including reconfiguring the session from AVCaptureDeviceDirectionCoordinator's change handler when the forward-facing camera changes. It does not cover the partially open pose, which "Leverage multiple displays and scenes on iPhone Duo" treats as a first-class hinge state with a continuous angle. Consider a camera app that keeps a live preview on screen and adopts AVCaptureDevice.RotationCoordinator — the documented remedy for cases like the square front sensor on iPhone 17, where a hard-coded 90° leaves the preview tilted — applying videoRotationAngleForHorizonLevelPreview to both the preview and the capture connection. In the partially open pose the two halves are at different physical attitudes: one stands up, the other lies flat. Which camera does AVCaptureDeviceDirectionCoordinator report as forward-facing while the hinge status is partially open? Does the hinge angle affect that decision? RotationCoordinator derives its angle from device attitude. With the two halves at different attitudes, which one does videoRotationAngleForHorizonLevelPreview reflect — the half carrying the active camera, the half hosting the preview layer, or a single device-level reference? If an app deliberately keeps the rear camera on the scene while its preview is drawn on the half facing the user, is that a supported configuration, or is the coordinator expected to override that choice? Is any of this modelled in the iPhone Duo simulator, or does the partially open pose require real hardware to test? Question 4 matters for planning: building against a rotation value that only appears on device would be worth knowing about before the hardware ships.

What's the best practices to adopt iPhone Duo for a production UIKit app? What few things we need to consider during the development? "As long as we use auto layout, it should be fine" is this correct term for iPhone Duo? Meaning, as long as our app use proper auto layout, our app should be able to support iPhone Duo properly.

According to Apple's press release (https://www.apple.com/pt/newsroom/2026/09/apple-debuts-iphone-18-pro-and-iphone-18-pro-max/): Variable aperture also provides more control for creative pros by giving them the ability to manually adjust any of the four aperture settings in the Camera app, and an API is available to developers for even more control across the aperture range in their apps. Can a DTS engineer specify the quoted API please? I can't see it anywhere in the documentation yet. What does it mean "even more control across the aperture range"? Will it be possible to set the aperture in a 0.0-1.0 range?

Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the iPhone Duo Group Labs: How should apps preserve navigation and UI state when switching between the inner and outer displays? Treat display transitions as size-class and trait changes, not a scene disconnect or app termination; your process stays alive. For more information, see Prepare your app for iPhone Duo. For state that must survive a scene disconnect/reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. Do multiple instances of the same app on iPhone Duo share UserDefaults/@AppStorage state? Multiple instances of your app's UI on iPhone Duo behave similarly to multi-window support on iPadOS. To learn more, see Leverage multiple displays and scenes on iPhone Duo. Both UserDefaults and AppStorage are app-wide, not per-window, stores. If a full-screen app on the inner display is closed, does it move to the outer display or get backgrounded? iPhone Duo honors UIRequiresFullScreen and apps adapt in place as the device opens and closes rather than backgrounding. To learn more, watch Prepare your app for iPhone Duo. How should apps preserve state — text input, scroll position, video playback, camera sessions — during hinge angle transitions? For example, when a LazyVGrid's column count changes because the device folds, does SwiftUI preserve scroll position automatically, or should you use scrollPosition(id:)? The system generally preserves text input and scroll position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. This applies even to cases like a LazyVGrid column-count change triggered by opening or closing the device — apps typically don't need to manually manage scroll position with scrollPosition(id:anchor:) for this transition. For more info, see Prepare your app for iPhone Duo. How can apps preserve what someone is doing when switching displays or folding/unfolding? Treat this as a resize/trait-change event, not app teardown — your process keeps running as size classes change. See Prepare your app for iPhone Duo to learn more. For scenes that actually disconnect and reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. How does actively playing video behave through the hinge angle animation? The system generally preserves video playback and player position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. AVKit will scale and resize the video automatically. If a user folds or unfolds the device mid-checkout, what does the system preserve automatically, and what should the app manage itself to avoid lost input or duplicate requests? When someone opens or closes an iPhone Duo, the system represents this as a size-class and trait collection change, not a scene disconnect or app teardown, so in-memory state like input fields typically persists automatically since the app’s process keeps running. For more info, see Prepare your app for iPhone Duo. How should apps handle the keyboard and text input when the device folds or unfolds while typing? As iPhone Duo folds or unfolds, the available screen geometry and framing change. Ensure your app adopts standard layout controls, containers, and size classes to handle resizability gracefully across all poses. When a text field becomes first responder, the system automatically shows the keyboard and binds its input to the text field. Because the appearance of the keyboard has the potential to obscure portions of your user interface, you should update your interface as needed to ensure that the text field being edited remains visible. Use keyboard notifications such as keyboardWillShowNotification, keyboardWillHideNotification, and keyboardWillChangeFrameNotification to detect the appearance and disappearance of the keyboard and to make necessary changes to your interface layout. To learn more, see UITextField. If someone is typing and closes iPhone Duo, does the keyboard/editing session survive the hinge transition, or does it get a new scene? When a user types and closes iPhone Duo, the active editing session and keyboard do not get a completely new scene. Instead, the app undergoes a dynamic resizing and transitions from the inner display to the compact outer display, maintaining the existing scene and application state. For more info, watch Prepare your app for iPhone Duo.

Hi, I was testing my app on iPhone Duo simulator and couldn't understand why even though I am using native navigation stack and toolbars, the toolbar items are not placed on the vertical space. With some debugging I found that it's due to the Group {} I am using Group - because I have a switch inside it where I switch between different types of views, and I insert an environment object only once in the Group {}.environment... I recreated the issue in a clean project, here is full source code: SourceCode.swift And the result when nesting the NavigationStack inside a Group {}. If I remove the Group, toolbar items are pushed to the vertical space as needed

I’m adapting a UIKit app for iPhone Duo and noticed that UITableViewController separators extend underneath the navigation and tab bar controls when those controls move to the side. The cell content appears to respect the safe area, but the separators continue to the screen edge. When using a UITableView inside a regular UIViewController, constraining its horizontal edges to the parent’s safeAreaLayoutGuide prevents this. With UITableViewController, however, the table view is the controller’s root view. The attached screenshots show the difference: Screenshot 1: Separators extend underneath the side controls. Screenshot 2: Separators stop at the safe area boundary. Should UITableViewController respect these safe area boundaries out of the box, including for separators, when system controls move to the side? Or is drawing separators underneath those controls the intended behavior? If automatic adaptation is expected, could this be a UIKit issue?

I have an App where I use the UISheetPresentationController to present a menu as a "drawer" (like the "FindMy" or "Maps") App. Because the sheet is presented over a map, I made the sheet semi-transparent/blurry, so the Map shines through, which looks nice. The sheet is using a UITableView with the "insetGroup" style, so the table cells have the nice rounded borders and there are margins to the sheet borders. When running the App on the iPhone Duo (Simulator) on the outer display, the tableView does no longer respect the "insetGroup" style, it is rendered like it would have the "plain" style, which destroys everything that look good. No rounded borders, no margins. However if I opt-out of the automatic "vertical toolbar behavior" (overriding preferredVerticalBarBehavior so it returns "disabled"), then everything looks great again, however then the sheet content might overlap with the sidebar icons and camera because it now covers the whole area up to the right screen border. Is this supposed to be this way (if yes, why?), is there a way to fix this, or do we have to wait for a bugfix within iOS 27.1? The tableview still claims to have the "insetGrouped" style, just it does not render this way. I did not see any similar issues under other circumstances. Only UISheetPresentationController seems to be affected by this. Is there a way to correctly detect if the App is running on an iPhone Duo, so we could use this detection to add workarounds for such issues?

Hello everyone, This is my first ever game submission to the App Store, so I’m honestly very excited to finally be at this stage. I’ve spent a lot of time working on the game, and seeing it reach the review process for the first time is a really exciting moment for me. The app has now been in “Waiting for Review” for around 5 days. I completely understand that the review process takes time and that Apple’s review team has many submissions to handle. At the same time, since this is my first game and I’m really looking forward to launching it, I’m starting to get a little concerned about the waiting time. I wanted to kindly ask if there is anything I can do from my side to help move the review forward, or if there is any possibility of requesting an expedited review in this situation. I absolutely understand that the normal review process needs to be followed, and I’m not expecting any special treatment. I would just be very grateful if there is anything I can do, or if someone could let me know whether a faster review might be possible. Thank you very much for taking the time to read this, and thank you to everyone who can share their experience or advice. It’s my first game, so I’m both excited and a little nervous about seeing it finally go live. :)

On iPhone 18 Pro, the Now Playing panel and bottom Lock Screen controls can use different material opacity and foreground colors for the same wallpaper and settings. The final appearance depends on the preceding wallpaper-editing sequence. Environment Device: iPhone 18 Pro iOS: 27.2 beta (24B5084k) Liquid Glass: Clear / most transparent setting Wallpaper: Built-in iPhone 18 Pro wallpaper collection Variants tested: Silver and Black within the same saved wallpaper configuration Feedback Assistant: FB24866793 Two observed appearance states For clarity, I use the following labels: Higher-opacity state (S_s): The Now Playing panel and bottom buttons have a light or gray, relatively solid fill with dark foreground icons. Translucent state (S_t): The same elements are more transparent and use light foreground icons. In Sleep mode, they darken and blend into the background more naturally. No Liquid Glass setting is changed during the following sequence. Shortest reproduction sequence 1. Change Silver to Black Start with the Silver variant displaying the higher-opacity state (Silver S_s). Open the Lock Screen wallpaper carousel, tap Customize, change Silver to Black within the same iPhone 18 Pro wallpaper configuration, tap Done, and exit the carousel. Observed result: Black retains the higher-opacity state (Black S_s). 2. Save Black without changing it Reopen the same Black wallpaper in Customize, make no changes, tap Done, and exit. Observed result: Black changes to the translucent state (Black S_t). 3. Change Black back to Silver Reopen Customize, change Black back to Silver, tap Done, and exit. Observed result: Silver retains the translucent state (Silver S_t). 4. Save Silver without changing it Reopen the same Silver wallpaper in Customize, make no changes, tap Done, and exit. Observed result: Silver changes back to the higher-opacity state (Silver S_s). The complete sequence is therefore: Silver S_s → Black S_s → Black S_t → Silver S_t → Silver S_s The two actual appearance changes occur after reopening Customize and saving without changing the selected wallpaper. Actual result When switching between Silver and Black inside the same saved wallpaper configuration, the existing material state can be preserved even though the new wallpaper has a different brightness. Reopening the configuration and saving it without making a change can then alter: Now Playing panel opacity Notification material appearance Bottom shortcut-button opacity Foreground or icon colors As a result, the exact same Silver or Black wallpaper can appear in either state solely because of the preceding editing history. Expected result The material opacity and foreground colors should be determined consistently from the currently selected wallpaper and the Liquid Glass setting. Switching between Silver and Black should update the appearance immediately if different treatments are intended for them. Saving an unchanged wallpaper should not alter the Lock Screen appearance. Sleep mode impact The issue is especially noticeable in Sleep mode. In the higher-opacity state, the Now Playing panel and bottom buttons remain conspicuous gray elements against the darkened Lock Screen. In the translucent state, the same controls darken and integrate with the background. Supporting evidence The corresponding Feedback Assistant report, FB24866793, includes: A screen recording of the complete sequence in normal mode A screen recording of the same sequence in Sleep mode A detailed PDF report containing screenshots, terminology, additional observations, and reproduction paths Both recordings show the following sequence: Silver S_s → Black S_s → Black S_t → Silver S_t → Silver S_s The recordings and PDF cannot be attached directly to this Developer Forums post, but they are available to Apple through the Feedback Assistant report. Request for confirmation Could anyone else with an iPhone 18 Pro test this sequence on the same iOS build? If you can reproduce it, please consider filing a separate Feedback Assistant report and referencing FB24866793.

On iPhone Duo in the folded state, the outer screen displays a vertical bar on the right edge with view contents inset. I noticed Form displays an appropriate amount of leading padding but 0 padding on the trailing edge, since the vertical bar provides some padding already, so it looks nice. I have a view that looks kind of like a form, multiple stacked text fields, that should align the same way. I used scenePadding to achieve this and it looks correct on iPhone 18 Pro perfectly aligning with Form. Unfortunately on iPhone Duo there is extra trailing padding such that it doesn't align with the edit button that remains in the horizontal axis navigation bar (and it is not inset enough on the leading edge, off by a few pixels, interestingly). Note when you unfold it and add the app on the left side in Split View, the vertical bar is on the leading edge, in which case there's too much padding on the leading edge. How can I achieve the correct padding? My actual app: struct ContentView: View { var body: some View { TabView { NavigationStack { SystemFormView() .navigationTitle("System Form") } .tabItem { Label("System Form", systemImage: "list.bullet.rectangle") } NavigationStack { CustomFormView() .navigationTitle("Custom Form") } .tabItem { Label("Custom Form", systemImage: "rectangle.3.group") } } } } private struct SystemFormView: View { var body: some View { Form { Text("Row 1") Text("Row 2") Text("Row 3") } } } private struct CustomFormView: View { var body: some View { ScrollView { VStack(spacing: 0) { customRow("Row 1") Divider() .padding(.leading) customRow("Row 2") Divider() .padding(.leading) customRow("Row 3") } .background(.background) .scenePadding(.horizontal) } .background(Color(uiColor: .systemGroupedBackground)) } private func customRow(_ title: LocalizedStringKey) -> some View { Text(title) .frame(maxWidth: .infinity, minHeight: 44, alignment: .leading) .padding(.horizontal) } }

Why doesn't iPhone 13 Pro Max and Watch Series 11 not connect to Xcode 27.0? Something is wrong and I cannot vet the application before submitting for App Store.

On the iPhone Duo the standard "Edit" button for navigation bars is a text-based button, and text-based buttons are not pushed to the vertical toolbars on the Duo. This looks sometimes silly, if it is the only remaining button that can not be placed in the vertical toolbar and which has the result that an almost empty horizontal navigation bar must be kept visible as well. So I guess it would be good idea to have an icon-based replacement for the Editor button to avoid having two toolbars on the Duo. Is there a best practice for the icon to pick for such an edit button? Would be "square.and.pencil" (SF Symbols) a good choice? Or better the "pencil .circle", because the "square" one is often used for text-based input? Anything better?

Hello, I am investigating call behaviour on a dual SIM iPhone. Observed behavior: A specific line is selected in Settings > Cellular > Default Voice Line. Our app initiates the native call flow by opening a phone-number URL scheme with the destination number. The native Phone app does not always place the call using the selected default line. Expected behaviour: The native Phone app should place the call using the line selected in Settings > Cellular > Default Voice Line Questions: In this flow, is line selection fully controlled by iOS? Is there any supported way for an app to ensure the native Phone app respects the selected default line? Is this a known limitation or known issue on dual SIM devices? Any clarification on expected iOS behaviour would be appreciated.

We are currently adapting our app to Liquid Glass. It's mainly written with UIKit. One of the questions is about the tab bar. We advocate the business to go with Apple's recommendation to display it at the top with only labels on iPad. The question now is this: on iPhone Duo, in the inner screen, in Portrait mode, where is the tab bar displayed ? We know from the Tech Talks and Human Interface Guidelines that is is the only pose when it's horizontal (as opposed to vertical on the side). But is it displayed at the top like on iPad (with only labels) or at the bottom like on iPhone (with icons and / or labels) ?

Device: iPhone 17 Pro 256GB Affected builds: • iOS 27 RC — 24A435 • iOS 27 public release — 24A437 Known working version: • iOS 26.7 DESCRIPTION I am seeing a reproducible total loss of touchscreen input on this specific iPhone 17 Pro when running iOS 27. Before today's test, the device was running iOS 26.7 and the touchscreen was working normally. On September 14, I updated through the official OTA Software Update to iOS 27.0 public release, build 24A437. Beta Updates were disabled. After the update completed, the iPhone booted normally and reached the Hello screen. The display renders normally. Physical buttons respond normally. However, all touchscreen input is completely unavailable. No taps or swipes are recognized anywhere on the display, so it is not possible to proceed past the Hello screen. REPRODUCIBLE ON IOS 27 RC The exact same behavior previously occurred on iOS 27 RC build 24A435. To eliminate backup corruption, user data, apps and settings as possible variables, I performed a complete clean restore of 24A435 using Apple Configurator. No backup was restored. No apps were installed. No user data was restored. No previous settings were restored. Immediately after the clean restore, at the initial Hello screen, touchscreen input was still completely unavailable. Restoring the same device back to iOS 26 immediately restored touchscreen functionality. REPRODUCTION HISTORY iOS 26.7 → Touchscreen works normally iOS 27 RC 24A435 → Touchscreen completely unresponsive after boot Clean restore of 24A435 → Touchscreen still completely unresponsive at the initial Hello screen Restore back to iOS 26 → Touchscreen functionality returns iOS 27 public 24A437 → Touchscreen completely unresponsive again after boot DIAGNOSTICS Apple has already performed: • Remote diagnostics — passed • MRI — passed • Multi-Touch diagnostic — passed None of these diagnostics detected a hardware failure. The issue was reported through Feedback Assistant before the public release: Feedback ID: FB24728805 I also have an active Apple Support case, and the device is being evaluated by an Apple Authorized Service Provider. QUESTION / TECHNICAL OBSERVATION The particularly unusual aspect is the repeatability across OS versions on the same physical device: iOS 26 → touch works iOS 27 → touch does not work iOS 26 → touch works again iOS 27 → touch does not work again I am not assuming that the root cause is purely software or purely hardware. I am interested in whether this could involve touchscreen/HID initialization, digitizer-related firmware, or an interaction between iOS 27 and a particular hardware/display/controller revision. Has anyone observed a similar condition where: • the display continues rendering normally; • physical buttons continue working; • all touchscreen input is lost immediately after booting iOS 27; • a clean restore of iOS 27 does not resolve it; and • restoring the same device to iOS 26 restores touchscreen functionality? If anyone has reproduced this on another iPhone 17 Pro or 17 Pro Max, the exact model and iOS build would be particularly useful. RELATED PUBLIC DISCUSSIONS Apple Support Community: https://discussions.apple.com/thread/256356702 MacRumors: https://forums.macrumors.com/threads/iphone-17-pro-touchscreen-completely-dead-on-ios-27-public-24a437-same-issue-on-rc-24a435.2489323/

Hi All, My app was approved last month around 27 August and the email stated indexing would take 24 to 48 hours. However it is now almost close to a week and I am still not abe to see the app in App store. The app is limited to UK destination only. In the app store connect, the initial link is marked as US and when I changed it to GB, I can see the app store link showing up the app. But not in the App store search. It is displaying several other apps but not mine. Is there anything I should fix? If the users does not have geographical in Media & Purchase, will it cause an issue. How can I ensure all UK users even if they dont have the geeographical location added to their profile see the app.

I want to obtain the precise temperature of the CPU core of the iPhone. What should I do?