A Summary of the WWDC25 Group Lab

Hello Apple engineering team, We are encountering a BLE connection issue on iPhone 17 series devices running iOS 26.x, while using CoreBluetooth to connect to our Bluetooth accessory in our app Aroma-Link. The problem does not occur on previous iPhone models or earlier iOS versions. Issue Summary Our BLE device uses a specific chipset batch where the 2M PHY capability is not fully supported. The expected behavior (as observed on iPhone 16 / 15 / older models) is: Connection starts on 1M PHY System attempts to upgrade to 2M PHY If 2M PHY upgrade fails → system should fallback and continue using 1M PHY Connection remains active However, on iPhone 17 series: After the system attempts to switch from 1M to 2M PHY and the upgrade fails The device disconnects immediately No fallback to the original 1M PHY occurs This results in an unintended and user-visible disconnection. Reproduction Steps Use an iPhone 17 series device running iOS 26.x Connect to the target BLE peripheral via CoreBluetooth (centralManage

In the summary documentation about the declared Age Range API:https://developer.apple.com/news/?id=2ezb6jhj It states: The API will also return a signal from the user’s device about the method of age assurance, such as credit card or government ID But if the api itself, and its documentation is examined, there is no such mechanism nor mention of it: https://developer.apple.com/documentation/declaredagerange/agerangeservice So my question is, is the first documentation incorrect, if not, then where and how to access the method of age assurance?

Hello Apple engineering team, We are encountering a BLE connection issue on iPhone 17 series devices running iOS 26.x, while using CoreBluetooth to connect to our Bluetooth accessory in our app Aroma-Link. The problem does not occur on previous iPhone models or earlier iOS versions. Issue Summary Our BLE device uses a specific chipset batch where the 2M PHY capability is not fully supported. The expected behavior (as observed on iPhone 16 / 15 / older models) is: Connection starts on 1M PHY System attempts to upgrade to 2M PHY If 2M PHY upgrade fails → system should fallback and continue using 1M PHY Connection remains active However, on iPhone 17 series: After the system attempts to switch from 1M to 2M PHY and the upgrade fails The device disconnects immediately No fallback to the original 1M PHY occurs This results in an unintended and user-visible disconnection. Reproduction Steps Use an iPhone 17 series device running iOS 26.x Connect to the target BLE peripheral via CoreBluetooth (centralManage

Summary After updating to visionOS 26, we’ve encountered severe transparency rendering issues in RealityKit that did not exist in visionOS 2.6 and earlier. These regressions affect applications that dynamically control scene opacity (via OpacityComponent). Our app renders ultra-realistic apartment environments in real time, where users can walk or teleport inside 3D spaces. When the user moves above a speed threshold, we apply a global transparency effect to prevent physical collisions with real-world objects. Everything worked perfectly in visionOS 2.6 — the problems appeared only after upgrading to 26. Scene Setup Overview The environment consists of multiple USDZ models (e.g., architecture, rooms, furniture). We manage LODs manually for performance (e.g., walls and floors always visible in full-res, while rooms swap between low/high-res versions based on user position and field of view). Transparency is achieved using OpacityComponent, applied dynamically when the user moves. Some meshes (e.g., po

In App Store Connect, I can't change Subscription Group Display Name . I get the error message There was an error editing your App Store localization. Please try again later. It doesn't change even after waiting a while. Why does this error occur? I would appreciate it if you could tell me what to do.

I'm looking for clarification on a SwiftUI performance point mentioned in the recent Optimize your app's speed and efficiency | Meet with Apple video. (YouTube link not allowed, but the video is available on the Apple Developer channel.) At the 1:48:50 mark, the presenter says: Writing a value to the Environment doesn't only affect the views that read the key you're updating. It updates any view that reads from any Environment key. [abbreviated quote] That statement seems like a big deal if your app relies heavily on Environment values. Context I'm building a macOS application with a traditional three-panel layout. At any given time, there are many views on screen, plus others that exist in the hierarchy but are currently hidden (for example, views inside tab views or collapsed splitters). Nearly every major view reads something from the environment—often an @Observable object that acts as a service or provider. However, there are a few relatively small values that are written to the environment frequently, s

Summary Several notarization submissions have remained in the In Progress state for many hours. I’d like to confirm whether this is expected behavior and what steps I can take to resolve or re-submit safely. Command used xcrun notarytool submit /Users/.../MortiseAI-arm64.dmg --keychain-profile mai_publish --wait Submission history (excerpt) createdDate: 2025-11-06T22:52:12.019Z id: 4254d623-**** name: MortiseAI-arm64.dmg status: In Progress createdDate: 2025-11-06T13:00:28.016Z id: c7397c1c-**** name: MortiseAI-arm64.dmg status: In Progress createdDate: 2025-11-06T11:24:12.624Z id: 44bcbab2-**** name: MortiseAI.zip status: In Progress (Several other submissions show the same In Progress status.) Questions Are there known reasons that could cause notarization requests to remain in In Progress for an extended time? What is the recommended method to cancel these pending submissions and safely re-submit? Are there diagnostic steps (for example, xcrun notarytool log ) that can help analyze this issue? Not

Hi there! I'm having this issue with my main windows. I'm having a big space on top of that without any logic explanation (at least for my poor knowledge). Using the code below I'm getting this Windows layout: Does anybody have any guidance on how to get out that extra space at the beginning? Thanks a lot! import SwiftUI import SwiftData #if os(macOS) import AppKit #endif // Helper to access and control NSWindow for size/position persistence #if os(macOS) struct WindowAccessor: NSViewRepresentable { let onWindow: (NSWindow) -> Void func makeNSView(context: Context) -> NSView { let view = NSView() DispatchQueue.main.async { if let window = view.window { onWindow(window) } } return view } func updateNSView(_ nsView: NSView, context: Context) { DispatchQueue.main.async { if let window = nsView.window { onWindow(window) } } } } #endif @main struct KaraoPartyApp: App { @StateObject private var songsModel = SongsModel() @Environment(.openWindow) private var openWindow var body: some Scene { Group { W