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?

tl;dr: On iPhone Duo with connected WiFi it is not possible to fully verify/scan a NFC ePassport. On iPhone Duo (iPhone19,4, iOS 27.2), reading ePassports via NFCTagReaderSession / NFCISO7816Tag fails reproducibly while the device is connected to Wi-Fi. Access control (PACE) succeeds. During the following file reads (EF.SOD, DG2), one sendCommand call gets no response for about 2 seconds and then fails with NFCReaderError code 102 ("Tag response error / no response"). The failing command varies from run to run. After disconnecting from Wi-Fi in Control Center, the same passport reads immediately. Disconnecting is enough; Wi-Fi does not need to be turned off. The device lies still on the document in all attempts. ReadID Me, Regula Document Reader and our own app (KINEGRAM Digital Seal) all fail the same way. Filed as FB25502333 with sysdiagnose and video. This looks similar to the 2024 issue on iPhone 15 Pro / 16 Pro, where turning off Wi-Fi also helped: https://developer.apple.com/forums/thread/765855 If you see this on an iPhone Duo too, please file a Feedback and reference FB25502333.

I've been getting some unexpected behavior when using TabView as the root view in SwiftUI, which I believe to be a bug. I created a barebones app to isolate the bug and will paste the code at the end for anyone who wants to try to reproduce it if you have a physical Duo device. Details below copied from my Feedback ticket FB25490881. Xcode 27.1. What's the bug? When you have a TabView as the root view inside the ContentView.swift and you open the app on the outer screen, then swipe it to the background, unfold the phone and tap the app to bring it to the foreground, any UI element without a fixed frame size gets moved off screen. And any UI element with a fixed frame size gets moved to the very top of the screen. See my two screenshots of outer vs inner display. How to reproduce: 1- Unzip the project folder and open it in Xcode. 2- With a physical Duo on hand, run the app on the Duo. 3- On the outer screen, launch the app. 4- Swipe the app to the background (Do not swipe completely to close the app, just swipe it to the background so it is still running) 5- Unfold the iPhone Duo completely open. 6- Tap the app icon to bring it to the foreground. 7- Look at the broken UI. Also note even the side tab bar itself is broken, it has no padding with the edge of the screen. This is managed by the system. The workaround to fix it: 1- Go to the ContentView.Swift in Xcode. 2- Uncomment "NavigationStack {" on line 13. 3- Uncomment the closing bracket "}" on line 2. 4- Repeat the previous from how to reproduce the bug. My hypothesis: The system reports 0 height for the inner screen in that moment you bring the app to the foreground. Anything with a fixed frame will move to the top, anything with flexible height will not be visible. This only happens when TabView is the root of the scene. Other Useful Information: I hit a very similar bug to this in my main app that I'm still developing, unfortunately I was not able to reproduce it in a sandbox simple app. The bug was: 1- Open the app on outer screen 2- While the app is open, tilt the Duo to the back at a certain angle 3- Unfold the Duo 4- You get this exact same bug where everything with a flexible height disappears off screen or collapses to zero if it's in between UI elements with fixed heights. And everything moves to the top of the screen. I'm not sure why I wasn't able to reproduce it on a sandbox app, but the fix was the same, either remove the TabView completely or put it inside a NavigationStack. I want to stress that this one had to do with the backwards tilt of the phone itself while unfolding it, very weird I know. ContentView.swift: import SwiftUI @available(iOS 27.1, *) struct ContentView: View { var body: some View { // NavigationStack { TabView { HomeTabView() .tabItem { Label("Home", systemImage: "house") } StoreView() .tabItem { Label("Store", systemImage: "bag") } } .tint(Color.black) // } } } HomeTabView.swift: import SwiftUI @available(iOS 27.1, *) struct HomeTabView: View { var body: some View { VStack { Text("Jenny") .font(.largeTitle) .fontWeight(.bold) .padding() .frame(maxWidth: .infinity) .frame(height: 200) .background(Color.gray, in: .rect(cornerRadius: 28)) Spacer() Circle() .fill(Color.blue) .frame(width: 100, height: 100) .padding(.bottom, 50) } .contentMargins(for: .container, edges: .horizontal) } } StoreView.swift is just an default empty swiftUI file with the default Text("Hello, World!")

Hello, I think this might be a bug, but I'm not sure (see the code below). FB25486625 On iPhone, when the inspector is presented as a SHEET, swiping down to dismiss it (instead of tapping the close button inside the inspector) causes the navigation toolbar toggle to stop working properly: tapping it once won't reopen the inspector. You have to tap it twice (turning it on and off again) to make the inspector appear again. This doesn't happen when the inspector is presented as a SIDEBAR on iPad or macOS. import SwiftUI struct ContentView: View { @State private var showInspector = false var body: some View { NavigationStack{ Text("Hello, world!") .padding() .inspector(isPresented: $showInspector) { Button("Close Inspector", role: .cancel) { showInspector.toggle() } Text("On iPhone, with inspector as SHEET, if you swipe to close (instead of tap the close button), the toggle in the navigation toolbar won't open the inspector next time (half the time). It doesn't affect inspector as SIDEBAR on iPad") .padding() Spacer() } .toolbar { Toggle(isOn: $showInspector) { Label("Open", systemImage: "sidebar.trailing") } } } } } #Preview { ContentView() }

Apple thought it was impossible. I made it possible. No server. Just an iPhone. LUMEN-JEV OS v3.0 — On-device OS using Pyto + iCloud Drive + Obsidian Architecture: Pyto runtime = server: Persistent loop, 922 tickers scanned, 502.6 ev/s, 12ms latency, sub-2ms cache iCloud Drive = bus: Writes JEV-BUS.md every 15s, shared working directory Obsidian = OS window manager: 00-JEV-DASHBOARD-main 48 nodes live Vault: 11/11 LOCKED, Factory Complete Anchor: 572b9df5e8e1f101365f8316ba7b34da4aa54ff89a2dcdb68ed20b126e8cabed Chain: REAL-EXCHANGE-PUBLIC-WS -> 8-MODULE-DEMO -> DEMO-TERMINATED -> NO EXECUTION Feed: real-public-readonly / public_ticker_only Modules (8-MODULE-v1px): WARREN-WATCHDOG, KEEPER-BOX, NODE-MODE-SYNC, VAULT-MULT, SCOUT-SCAN, SIREN-FILTER, FOCUS-SIGNAL-20K, ORACLE-PRICE-FEED, RELAY-ROUTER, AKE-ARBITRAGE, YIELD-BACK-4, MEDUSAs: 03 DYNAMIC OBSERVER-SPACE Context: Built in 33hrs over 11 nights, day job, single dad, solo dev, on iPhone only. Pyto working directory set to iCloud Drive. No Mac backend, no CloudKit function, no external server. Why this matters for iOS: Apple's sandbox says you can't run a persistent OS-like loop with live file sync on iOS. Pyto + iCloud Drive persistence proves you can. iPhone becomes the server. Proof: 48 NODES LIVE canvas PROOF CHAIN 11/11 FLAT VIEW VAULT LOCKED Jev.py V2.6 CLEAN BUS log (checked 50/100/150/200 -> 922/922 passes) Anchor hash matches zip JEV-OS-v3.0-572b9df5-40files.zip Requesting: Guidance on showcasing this as an iOS innovation + Ask Apple office hours. X proof pinned: @Activepython007

Issue: Screen rotation becomes locked when updating the status bar on an iPhone Duo. This does not appear to be a device-specific hardware issue; however, it occurs specifically on the iPhone Duo. In my app, if I change the status bar visibility (using prefersStatusBarHidden) while on the iPhone Duo’s external screen, and then immediately unfold the device to reveal the internal screen, the app’s rotation state becomes locked. Although I use prefersInterfaceOrientationLocked to manage rotation, the app remains locked even when this property returns false. The issue persists even when prefersInterfaceOrientationLocked is commented out or removed entirely. Returning to the device’s home screen, rotating the device, and then re-entering the app resolves the lock. Has anyone encountered or resolved a similar issue?

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?

How can I test tent mode and other poses with iPhone Duo in Device Hub?

Hello Apple AVFoundation team, Could you clarify the supported iPhone models and OS versions for standalone locked video frame duration using AVCaptureDeviceInput.activeLockedVideoFrameDuration? The API is documented as available from iOS 26.0, but I understand that OS availability alone does not mean every camera device/configuration supports it. I have read the API documentation and the DTS reply in iPhone 17 Pro's Genlock feature, but could not find a model compatibility list for the standalone locked-duration API. Scope: I am investigating actual capture timing for multi-iPhone motion capture. This question is about locking each camera's frame period using its internal timing, without an external genlock accessory. I am not asking about encoding a constant-frame-rate file, ordinary equal min/max frame durations, timecode metadata, or synchronizing the first exposure across phones. Physical-device test iPhone 16 Pro, iOS 26.2 (23C55). Built with Xcode 26.3 and the iOS 26.2 SDK. One AVCaptureSession, one physical rear .builtInWideAngleCamera input, and one AVCaptureVideoDataOutput. 8-bit SDR 420v formats, tested at 1920 x 1080 and 3840 x 2160, each at 30 and 60 fps. Auto video frame rate disabled; no spatial video capture or multicam session. Manual exposure approximately 2 ms, shorter than half a frame at both tested rates. The session is running and delivering frames. Two separate probe runs produced the same results, including capability readbacks after a settling period. For all four tested configurations: input.isLockedVideoFrameDurationSupported = false device.minSupportedLockedVideoFrameDuration = kCMTimeInvalid input.activeLockedVideoFrameDuration = kCMTimeInvalid device.isVideoFrameDurationLocked = falseOrdinary activeVideoMinFrameDuration and activeVideoMaxFrameDuration can both be set to the requested CMTime(value: 1, timescale: 30) or CMTime(value: 1, timescale: 60), and frames are delivered. This is only a configuration readback, not a claim of exact capture timing in the ordinary mode. The app directly queries the public support properties; it has no model whitelist. It does not attempt to set a valid locked duration when support is false, as the documented setter contract would reject that. These tests cover the selected formats, not every camera/format on this phone. Questions Which iPhone models support this standalone API? In particular, is false expected on iPhone 16 Pro? Is there an official compatibility list covering iPhone 13/14/15/16 and iPhone 17 models? Is the iPhone 16 Pro result a hardware capability restriction, an iOS 26.2 limitation/known issue, or a configuration requirement? Is there a released iOS version that enables this on iPhone 16 Pro, or is newer hardware required? What is the minimum supported capture configuration and correct time to query support? Are there restrictions involving the physical versus virtual camera input, pixel format, SDR/HDR, or exposure mode that could explain this result? If so, which configuration should be tested before concluding that the device does not support it? On supported hardware, can this standalone lock be enabled without an external accessory or a special entitlement, independently of follow(_:videoFrameDuration:delegate:)? Relevant documentation: activeLockedVideoFrameDuration isLockedVideoFrameDurationSupported minSupportedLockedVideoFrameDuration I can provide a focused reproducer if needed. Thank you for clarifying the device requirements and whether an OS upgrade can change the result.

hey Apple Community! i love every Apple product and i even have an iphone my dream is to get a macbook one day. i read that the $99.00 fee can be waived so I'm trying to do that because i have 4 children and a wife all at home and I'm the sole provider. it's tough times right now and I'm broke every pay day please i beg you waive my fee and let my dream come true and i offer a lot. jeremyharris1117@icloud.com

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 posted my App Store URL as a link inside our Instagram profile (https://instagram.com/identafly). When I press the link, the in-app-browser loads the link which tries to open the App Store link, but it just stalls. Visible issue on all devices I am told. If I re-open the link in the external browser from Instagram it loads fine. Edit to add, this happens on Facebook too, from the profile page What can I do so I can have my app store link open correctly? Here is a video of what is happening: link to video

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.

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?

Updated my iOS apps for the Duo, partially rewriting the interface to better match the Duo and I am a bit puzzled - lets say it this way - that AppStore doesn't show the submitted Duo Screenshots nor the announced ">ready for Duo" badge. Am i the only one - or did I miss something or is it still not rolled out?

Hey Apple Developer Relations, App Review Team, and anyone else reading this,I wanted to share what’s been going on with my app because I’m honestly stuck and not sure what else to do.I’m an indie developer working on Marque: Car Collection — my first iOS app. I paid for the Developer Program, spent a lot of time getting everything ready, fixed the issues from the previous rejection, and submitted a new build.It’s been over a week now and I still have no idea what’s happening with it.Quick timeline: Oct 6: My previous submission got rejected under Guideline 5.1.2(i) (App Tracking Transparency). Oct 14: I submitted a fixed build, version 1.1.0 (24), with an updated ATT implementation, revised App Privacy details, and detailed notes explaining the changes. Since then (11 days as of Oct 25): It’s been sitting in “Waiting for Review” and hasn’t even moved to “In Review.” I’ve contacted Developer Support and asked on the forums, but I haven’t gotten any real answers. No one has asked for more information, explained what’s going on, or given me any idea when the review might actually start.I get that reviews can take longer sometimes, especially with a first app, subscriptions, or privacy-related stuff. I’m not asking anyone to just approve it without looking at it.What bothers me is the complete lack of communication. Right now I have no way of knowing: whether my build is just waiting in the normal queue or if something’s wrong with it when I can realistically plan a launch if there’s any point in contacting support again since I haven’t gotten a useful response so far I’m still paying for the Developer Program, but I have zero visibility into what’s happening with my submission.Apple holds developers to high standards. It would be nice to get at least basic transparency in return.So I have a few straightforward questions: Why has my corrected build been stuck in “Waiting for Review” for 11 days? Is there any way to confirm it’s properly in the queue and not stuck because of some technical or admin issue? Why hasn’t my support request gotten a real response? Is there an escalation path for indie developers when a submission just sits there with no explanation? If Apple can’t provide a status update, what options do developers have when they’re paying for the program but can’t get any information about their release? I’d really appreciate it if someone from Developer Relations or App Review could take a look and give me some kind of explanation (or point me to someone who can).I’d also be interested to hear from other developers who’ve dealt with similar long waits in “Waiting for Review,” especially with first apps.The issue isn’t just that the review is taking longer than expected. It’s that when something seems off, there’s almost no way to figure out what’s actually going on.Indie developers put a lot of time, money, and effort into building for Apple’s ecosystem. Clear communication shouldn’t be this hard.Thanks for reading. Marque Development Team

Let's say we start with a fully open iPhone Duo. We then present a view controller as a form sheet or page sheet. If the device is then rotated between landscape and portrait, the view controller's viewWillTransition(to:with:) is called to reflect the change in size between orientations. So far so good. Now put the fully open Duo in landscape. Then partially close the Duo. The presented view controller will automatically move off to the left half of the screen to avoid the fold. That's expected. However, the view controller's viewWillTransition(to:with:) is NOT called in this case even though its size has changed. Does this seem like a bug or is this somehow expected? I have a particular view controller that needs to know its size has changed so it can make some adjustments. Other lifecycle methods such as viewDidLayoutSubviews are called but I'd prefer to have viewWillTransition(to:with:) called.

I've looked at the UIKit docs for UIView reservedRegions(kind:options:). I've watched the video "Strike a pose with adaptive layouts on iPhone Duo". So I know how to get the current reserved regions. But I can't find the APIs to know when the reserved regions change. This means I can setup my custom view controller with the reserved regions that exist when the view controller is first displayed. But if the user changes the Duo, say from fully open to partially open, what API is triggered that lets me know that I need to call reservedRegions(kind:options:) and update the layout as needed? I played around with UIHingeInteraction but that isn't the right approach. In most cases I tried calling reservedRegions(kind:options:) on each call to the interaction handler but I almost always got the wrong results (maybe a simulator issue?). And of course that interactiion handler will be called a lot just to report the new fold angle. I also tried various UIViewController methods for size changes and registered for size class changes. None of these were appropriate. I just need a single notification that the Duo went from fully open to partially open, partially open to fully open, and partially open between landscape/portrait so that I can call reservedRegions(kind:options:) and get the correct, current divider info. What am I missing? My use case is for a custom fullscreen view controller that needs to layout a few items based on whether the Duo is fully open or partially open and whether the fold is horizontal or vertical. Unless I'm mistaken this precludes the use of UIArrangementViewController since I only have one view controller with one set of content to display. Showing the view controller as a form sheet, page sheet, or popover won't work since I need this to be fullscreen. I just need the fullscreen content to adjust for any fold (reserved region).

Is Apple still processing and accepting feature nominations for Duo support/major updates? Thank you. I think I have a meaninful capability with my new build which includes dramatic iPhone Duo use case. Since I cannot record on iPhone duo does editorial have ability to install and use the apps when they right up a feature?

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.

The waiting for the app to be reviewed has just been ridiculous on Apple, last year things were still okay you would submit your new app and get approved within 24 hours. But now that's no longer the case. I understand that review times vary and that Apple cannot guarantee a specific timeline. I'm not expecting special treatment; I would just appreciate some clarity on what might be happening and what the best next step would be. Even when you submit expedited review no response, and I don't know how many times I tried to email them, nothing. I cannot even call because I am in South Africa, calls are not available here. This is too much! I've put a lot of work into getting my app ready for release, and the uncertainty after waiting so long has been quite stressful.