A Summary of the WWDC25 Group Lab

Summary On iOS 26, the navigation bar unexpectedly switches to a Light appearance during/after a view transition while the device/app is in Dark Mode. This seems correlated with applying listStyle(.plain) to a List. Removing .plain prevents the issue, but my app’s layout requires it. Sample code: import SwiftUI @main struct iOS26NavigationTitleSampleApp: App { var body: some Scene { WindowGroup { NavigationStack { ContentView() .navigationTitle(Root) .navigationBarTitleDisplayMode(.inline) } } } } struct ContentView: View { var body: some View { VStack { NavigationLink { ListView() } label: { VStack { Image(systemName: globe) .imageScale(.large) .foregroundStyle(.tint) Text(Hello, world!) } } } .padding() .toolbar { ToolbarItemGroup(placement: .navigation) { Button(Test) { } Button(Test2) { } } } } } struct ListView: View { var items: [Int] = Array(0..<100) var body: some View { List { ForEach(items.indices, id: .self) { idx in cell(items[idx]) } } .listStyle(.plain) .toolbar { ToolbarItemGroup(pl

My Mac Catalyst app fails with a MissingEntitlement error when accessing keychain/secure storage, while the same code works perfectly on iOS. I have tested this extensively on macOS using Visual Studio Code on a MacBook, trying both automatic and manual provisioning approaches - both result in the same MissingEntitlement error during keychain operations. Error Message: An error occurred during OTP verification: Error adding record: MissingEntitlement Environment : Platform: Mac Catalyst (.NET 9.0) Issue: Keychain access fails on macOS, works on iOS Development: Using .NET MAUI What I've Tried : Entitlements Configuration Added keychain-access-groups to Entitlements.plist: xml keychain-access-groups $(AppIdentifierPrefix)com.example.myapp Project Signing Setup (.csproj configuration) : true manual TEAM_ID Apple Development: Name (XXXXXXXXXX) PROVISIONING_PROFILE_UUID Platforms/MacCatalyst/Entitlements.plist true Has anyone encountered similar issues with Mac Catalyst keychain access? Any

Hi! I wrote an internal used backup command line tool which is in use since several years. Today I got an error while sending an email: “Failed: ioOnClosedChannel”. I assume that the latest macOS updates did break my app. On the server I use macOS 15.7 and on my development machine macOS 26. Here is the related code: private func sendMail() { var a : [Email.Attachment] = [] if self.imageData != nil { switch self.imageType { case .tiff: a.append(Email.Attachment(name: Statistics.tif, contentType: #image/tiff#, contents: ByteBuffer(bytes: self.imageData!))) case .pdf: a.append(Email.Attachment(name: Statistics.pdf, contentType: #application/pdf#, contents: ByteBuffer(bytes: self.imageData!))) case .unknown: fatalError(Unimplemented attachment type!) } } mailHtml = mailHtml.replacingOccurrences(of: , with: n) let email = Email(sender: .init(name: Backup, emailAddress: SENDER@MYDOMAIN), replyTo: nil, recipients: recipients, cc: [], bcc: [], subject: self.subject, body: .universal(plain: self.mailText, html: mailH

Builds rejected with generic ContentDelivery 409 “corrupted binaries” (no email, no Activity entry) App ID: 6752832930 Bundle ID: com.taleway.tw Toolchain: Xcode 16.0 (build 24319) on macOS 15.6.1 (24G90) What happens Archiving (Release, manual signing) succeeds. Upload/validation via Xcode Organizer or xcrun altool immediately fails with: Validation failed (409) The app contains one or more corrupted binaries. Rebuild the app and resubmit. (ID: ef414ced-bf4e-40a6-8f5f-d4ba744c9433) altool also reports a preceding 500 “internal server error” (L4JS7YJVZYJMHBI4ISC4L3UQBM) before the 409. No system-generated email ever arrives (nothing under App Store Connect → Activity). We therefore have no specific error message or file name to fix. What we’ve checked Archive entitlements and embedded provisioning profiles match: App entitlements: CarPlay audio, App Group group.com.taleway.tw, get-task-allow=false. Intents extension entitlements: com.taleway.tw.TWIntents, get-task-allow=false. Profiles decoded via op

Summary: On iOS 26.0, iPad apps ignore standard interface orientation controls (shouldAutorotate, supportedInterfaceOrientations, Info.plist settings) and rotate to landscape despite being configured for portrait-only. Steps to Reproduce: Create iPad app with portrait-only configuration Implement shouldAutorotate returning NO Implement supportedInterfaceOrientations returning UIInterfaceOrientationMaskPortrait Set Info.plist UISupportedInterfaceOrientations~ipad to UIInterfaceOrientationPortrait only Run on iPad with iOS 26.0 Rotate device physically Expected Result: App should remain locked in portrait orientation Actual Result: Entire app interface rotates to landscape, ignoring all orientation controls Additional Information: Same code works correctly on iOS 18.4 (stays portrait-only) Problem affects entire UI including status bar and all view controllers All standard orientation control methods are implemented correctly Issue occurs on both simulator and physical devices Code Sample: objc -(BOOL)

Hello, I would like to ask for your opinion on whether the following in-app purchase (IAP) specifications would comply with the App Store Review Guidelines. ■ App Overview ・The app allows users to create a “Family Group” by inviting other family members to join. ・The app provides brain-training games. The game itself is displayed via WebView. ・All purchases use in-app purchase (IAP) only. No external payments or links are provided. ■ Purchase Types (2 models) ① Group Unlimited Plan ・If one member of a family group purchases this plan, all members of the same group can play the games without limits for a certain period. ・This is based on the app’s own group-sharing mechanism, not Apple’s “Family Sharing.” We will clearly state this in the UI to avoid confusion. ② Ticket System (Consumable) ・One user in the group purchases game-play tickets. ・Other members of the same group can also consume those tickets to play. ・Tickets are only shared and consume

Hello, I would like to ask for your opinion on whether the following in-app purchase (IAP) specifications would comply with the App Store Review Guidelines. ■ App Overview ・The app allows users to create a “Family Group” by inviting other family members to join. ・The app provides brain-training games. The game itself is displayed via WebView. ・All purchases use in-app purchase (IAP) only. No external payments or links are provided. ■ Purchase Types (2 models) ① Group Unlimited Plan ・If one member of a family group purchases this plan, all members of the same group can play the games without limits for a certain period. ・This is based on the app’s own group-sharing mechanism, not Apple’s “Family Sharing.” We will clearly state this in the UI to avoid confusion. ② Ticket System (Consumable) ・One user in the group purchases game-play tickets. ・Other members of the same group can also consume those tickets to play. ・Tickets are only shared and consume

Hello, As previous reports have already shown, there seems to be a few issues on the latest version of Safari, mainly around: Modals taking up the full viewport Elements positioned at the bottom of the screen This also seems to affect the modals on apple.com/iphone. I've recently done an analysis of what can and can't be done in code to work with the new liquid glass UI and thought I'd share my findings here. The full write up, along with screenshots and the demos I used are available in this repository: https://github.com/stevenocchipinti/liquid-glass-spike A brief summary of the findings: The conditions for a fullscreen modal overlay element to cover the entire screen with a position: fixed; seems to be: The background must be semi-transparent Solid colours, linear-gradients, etc. don't work The container must be empty This also means the standard and ::backdrop don't seem to work. The conditions for a bottom sheet to cover the entire screen, including the area around the Safari toolbar seems to be