Because this affects every app and no agreement is pending, it sounds account-side rather than build-specific. Have the Account Holder check App Store Connect → Business → Agreements, Tax, and Banking. If nothing is available to accept, update your existing Support case with the Team ID, exact error, timestamps, and ask Apple to verify the TestFlight Beta contract is attached to the team and re-provision it if needed. There may be no self-service fix when the contract is missing from the account.

A possible trigger is recipes.removeAll() before the ModelActor call. While the fetch is suspended, the selected row vanishes from List(selection:); NavigationSplitView may then restore a stale selection when rows return. Try keeping the old rows visible, build the fetched results locally, and assign the array once on the main actor. Also check that row values use stable, unique IDs matching the selection type.

Using SubscriptionStoreView doesn't guarantee review approval by itself. Guideline 3.1.2(c) applies to what the screen tells people before they subscribe: what they get and what it costs. StoreKit's view shows localized subscription names, descriptions and prices, and you can add custom marketing content above the choices. If the default product text doesn't explain the actual benefit, spell it out on the paywall, for example which features unlock or what usage limit changes. Make the subscription period and renewal price easy to see too. I can't say whether Paywall 1 or 2 will pass without seeing the full screens and the product metadata. Apple's docs: SubscriptionStoreView and Guideline 3.1.2(c).

Thanks for the detailed repro, especially confirming it with the ARIA APG Feed example. Since document.activeElement and the visible focus ring move but VoiceOver's cursor doesn't, this looks like a mismatch between web focus and VoiceOver's reading cursor. I don't know of a supported web API to move VoiceOver's cursor, so I wouldn't try to force it from page script. A minimal HTML repro from the APG example, including the parent markup and whether Quick Nav changes the result, would be useful alongside FB25212861. That can help show whether this is tied to one focus pattern or reproduces more generally.

There isn't a spacing parameter on ArrangementView itself. Since the gap needs to follow whichever axis the system chooses, padding both children can add unwanted space at the outside edges too. If you need a precise gap in both orientations, a custom ArrangementViewStyle is the cleaner option: build the split layout with an HStack(spacing:) or VStack(spacing:) based on the axis, and use the style's primary and secondary content. If you want to keep the built-in split style, the splitArrangementAxis environment value can help each child apply padding on the active axis, but you may need to balance the outer padding as well. ArrangementViewStyle · SwiftUI updates

Since you can reproduce this in multiple Apple apps, it sounds like a system keyboard issue rather than something an individual app can fix. I don't know of a setting that lets users enlarge the keyboard shortcut bar's hit areas. I'd send it through Feedback Assistant on the iPad and include a short screen recording, the exact iPadOS build, the iPad model, and the steps that reproduce it. Filing from Feedback Assistant on the device also attaches a sysdiagnose automatically. The 44 pt touch target guidance is useful context, but it applies to app interface controls and doesn't by itself confirm that the keyboard is violating that guidance. Apple Feedback Assistant · Apple button guidance

WeatherKit already includes haze as a WeatherCondition, so you can check weather.currentWeather.condition for .haze. CurrentWeather also has visibility, which gives you the visibility distance. Those tell you the reported condition, but they are not a particulate reading like PM2.5 or an AQI value. If you need that, you will need a separate air-quality data provider. WeatherCondition · CurrentWeather

For the app itself, I would put .modelContainer(for: Valeur.self) after WindowGroup. That is Apple’s documented setup and gives all windows in the group the same container and model context. A preview can use its own in-memory container for testing. For example, attach .modelContainer(for: Valeur.self, inMemory: true) to the preview’s ContentView. Changes in that preview are temporary. Putting the modifier on ContentView() in the app also works, but scopes that container to that view subtree instead of the whole window group. If the WindowGroup version is read-only in your Playgrounds preview, could you share the small app declaration and how the preview is configured? The preview may be using a different model context. Apple’s ModelContainer documentation includes the WindowGroup pattern and a link to its preview example.

You don’t need to rewrite the whole app at once. Xcode supports Swift and Objective-C in the same app target, so a practical approach is to move one class or module at a time and keep the rest working through the bridging header. Apple’s migration guide walks through that process. A coding agent can help with the mechanical first pass, but I’d review each change, build, and run the existing tests before moving on. Objective-C nullability, memory ownership, and APIs that don’t map directly to Swift can need hand fixes. Importing Objective-C into Swift · Migrating your Objective-C code to Swift

Auto Layout is a good baseline, but there are a few Duo-specific things to check too. Avoid fixed widths and layout assumptions tied to one screen size, and make sure your content respects both safe areas and the reserved regions around the hinge and cameras. UIKit’s standard containers, such as UISplitViewController and UITabBarController, adapt to the different poses. For custom layouts, UIView can report division and occlusion regions so you can position content around them. I’d test the app on both the outer and inner displays, in portrait and landscape, and with the device opened and closed. Apple’s iPhone Duo design guidance and UIKit reserved region API are good places to start.

Yes, that explains why it disappeared. Xcode 27.1 supports device debugging on iOS 17 and later, so it will not debug an iPhone X on iOS 16.7.16. Apple lists Xcode 26.6 as supporting iOS 15 and later. You can keep both Xcode versions installed and use 26.6 for this phone, as long as your Mac meets its macOS 26.2 requirement. For the app data, Xcode does not provide a way to copy a single app’s private data folder to another phone. Check whether the app has its own export or sync feature. A Finder backup and full restore may carry the data over, but it restores the device as a whole. Xcode 27.1 release notes · Xcode 26.6 release notes · Back up iPhone with Mac

If you mean the SwiftUI Preview canvas, it has its own device setting. Choosing a simulator from the Run Destination menu doesn't necessarily change the preview. In the canvas, open the Preview Device menu in the lower-right and select the iPhone model you want. Also check the Display override, since Xcode 27.1 can preview an alternative display on iPhone Duo. Apple's guide: https://developer.apple.com/documentation/xcode/interacting-with-previews-in-the-canvas The Run Destination controls which simulator launches when you press Run. If you mean that the running Simulator shows Duo too, could you share the exact simulator name selected in the Run Destination menu? That will help tell whether this is a preview setting or a simulator selection issue.

You may not need to rewrite all your Swift code. Swift 6.3 added an official SDK for Android, so platform-independent Swift packages can be built for Android if their dependencies support it too: https://www.swift.org/blog/swift-6.3-released/ The iOS screens won't carry over directly. SwiftUI is for Apple's platforms, so expect to build Android screens and device integrations separately, commonly with Kotlin and Jetpack Compose. A practical approach is to share the business logic and networking code that can build on both platforms, then write a native UI for each.

If you use a regular SwiftUI TabView, the system handles the tab bar's position and adapts it across iPhone Duo's different poses. A custom bar doesn't automatically turn into the system's side tab bar when the device folds. safeAreaInset helps keep your content clear of the usual safe areas, but the fold is a separate reserved region. For a custom bar, check the reserved regions that intersect its layout and move the bar or its buttons when they would land under the hinge or camera. In SwiftUI, Apple shows querying these with GeometryProxy.reservedRegions(kind:), including .division for the fold. You may also need to check .occlusion for areas covered by hardware. The system's standard components already handle these areas. Apple's guide: https://developer.apple.com/design/human-interface-guidelines/designing-for-iphone-duo SwiftUI reserved region API: https://developer.apple.com/documentation/swiftui/geometryproxy

Your versions should be compatible: Xcode 27.1 supports running apps on iOS 17 and later, so iOS 27.0.1 is within range. Seeing the phone in devicectl list devices doesn't necessarily mean Xcode has finished pairing it for development. Open Device Hub from Xcode > Open Developer Tool > Device Hub. Select Physical Devices, choose the iPhone, and follow the pairing steps shown there. Keep it connected by cable and tap Trust if the phone asks. If it already appears as paired, Control-click it in the sidebar, choose Unpair, then pair it again. Apple's guide: https://developer.apple.com/documentation/xcode/managing-your-simulated-and-physical-devices-in-device-hub If Device Hub still reports an error, could you share the exact message shown when you select the phone there, plus the iOS build number from Settings > General > About? That should help narrow down whether this is a pairing issue or an Xcode bug. Xcode 27.1 release notes: https://developer.apple.com/documentation/xcode-release-notes/xcode-27_1-release-notes