A Summary of the WWDC25 Group Lab

Hello Apple Developer Support Team, I am writing to request assistance with an issue preventing me from distributing my iOS app to the App Store. I am able to successfully build and archive my app in Xcode without errors. However, after archiving, Xcode only shows the option “Distribute Content” instead of “Distribute App”. Because of this, I am unable to upload the app to App Store Connect. App & Account Details • App Bundle Identifier: com.yesbuy.yesbuyapp • Team Name: Fathima Sayed Mohamed • Team ID: Z327MG963D • Xcode Version: 26.2 • macOS Version: macOS 15.6.1 Signing & Certificates • Signing Method: Automatically manage signing (enabled) • Signing Certificate (Release): Apple Distribution: Fathima Sayed Mohamed • Provisioning Profile: Xcode Managed / App Store Distribution • Archive Status: Build succeeded What I’ve Already Verified • The archive is created using Release configuration • Skip Install is set to No for the main app target (Runner) • The app target is selected correctly during Archi

Project Background： I am developing a third-party custom keyboard for iOS whose primary feature is real-time voice input. In my current design, responsibilities are split as follows: 1. The container (main) app is responsible for: Audio recording Speech recognition (ASR) 2. The keyboard extension is responsible for: Providing the keyboard UI Initiating the voice input workflow Receiving transcription results via an App Group Inserting recognized text into the active text field using textDocumentProxy.insertText(_:) Intended User Flow The intended workflow is: The user is typing in a third-party app (for example, WeChat) using my custom keyboard. The user taps a “Voice Input” button in the keyboard extension. The keyboard extension activates the container app so that audio recording and ASR can begin. After recording has started, control returns to the original app where the user was typing. The container app continues running in the background, maintaining active audio recording and ASR. Recognized t

The documentation of the NSPopover property hasFullSizeContent says that when it's true, you should Use the safeAreaLayoutGuide of the contentViewController view to ensure that your content is fully visible and doesn’t become clipped when displayed. I can do that by adding auto-layout constraints programmatically, but is there a way to do it in the xib? When I googled it, the AI summary begins To use safe areas in a Mac XIB (Interface Builder), enable the Use Safe Area Layout Guides checkbox in the File Inspector for your view but I have not found any non-AI indications that such a checkbox exists for macOS. (I'm using Xcode 26.2.)

So I’m stuck on an App Store Connect subscription issue and could use help. My app was rejected under Guideline 2.1 because in-app purchases couldn’t complete during review. I’ve since accepted the Paid Apps Agreement, completed tax/banking, fixed all UI issues, and re-submitted the subscriptions (monthly & yearly). Current status: • Subscriptions show “Developer Action Needed” • Subscription group shows Rejected • In TestFlight, the app loads but shows “Subscription temporarily unavailable / unable to load subscription options” • I am logged in with a Sandbox tester and using StoreKit Sandbox. I’m new to all this so how can I proceed going forward?

iOS Intermittent Bug: UserDefaults Preferences Loading Issue Problem Summary We're experiencing an intermittent issue where UserPreferences.shared.preferences returns inconsistent values even after calling getPreferences(). The behavior is unpredictable and affects critical functionality. Environment iOS Version: 15+ Language: Objective-C with Swift interop Storage: UserDefaults with App Group (group.com.jci.tyco.glss) Architecture: Singleton pattern for UserPreferences (Swift class) The Issue When a push notification arrives and triggers the showEvent: method, user preferences are sometimes loaded correctly and sometimes return nil or default values: Scenario A (Works - ~60% of time): Scenario B (Fails - ~40% of time): Observed Pattern From extensive logging over multiple test runs: Key Observation: At app launch: Preferences often load successfully Seconds later when push arrives: Same preferences become unavailable User navigates to another screen and back: Preferences suddenly work again

Code signing uses various different identifier types, and I’ve seen a lot of folks confused as to which is which. This post is my attempt to clear up that confusion. If you have questions or comments, put them in a new thread, using the same topic area and tags as this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com Code Signing Identifiers Explained An identifier is a short string that uniquely identifies a resource. Apple’s code-signing infrastructure uses identifiers for various different resource types. These identifiers typically use one of a small selection of formats, so it’s not always clear what type of identifier you’re looking at. This post lists the common identifiers used by code signing, shows the expected format, and gives references to further reading. Unless otherwise noted, any information about iOS applies to iOS, iPadOS, tvOS, visionOS, and watchOS. Formats The code-signing identifiers discussed here use one of two

We have 2 monthly subscription tiers that are part of a subscription group, and always have been part of this group. Both are configured with a 1 month trial introductory offer. According to the documentation for auto-renewable subscriptions,: Users can subscribe to one subscription product per group at a time. And yet several users have managed to start trials of both products in this group simultaneously, which converted to paid subscriptions after the expiration of the trials, and now are being concurrently billed by Apple for both. How do we completely prevent this from happening?

Hi everyone, In the simple app below, I have a QueryView that has LazyVStack containing 100k TextField's that edit the item's content. The items are fetched with a @Query. On launch, the app will generate 100k items. Once created, when I press any of the TextField's , a severe hang happens, and every time I type a single character, it will cause another hang over and over again. I looked at it in Instruments and it shows that the main thread is busy during the duration of the hang (2.31 seconds) updating QueryView. From the cause and effect graph, the update is caused by @Observable QueryController .(Bool). Why does it take too long to recalculate the view, given that it's in a LazyVStack? (In other words, why is the hang duration directly proportional to the number of items?) How to fix the performance of this app? I thought adding LazyVStack was all I need to handle the large dataset, but maybe I need to add a custom pagination with .fetchLimit on top of that? (I understand that ModelActor would be an alter

Hi, We are facing the issue of commissioning our Matter device to google home through iOS device will be 100% failed. Here is our test summary regarding the issue: TestCase1 [OK]: Commissioning our Matter 1.4.0 device to Google Nest Hub 2 by Android device (see log DoorWindow_2.0.1_Google_Success.txt ) TestCase2 [NG]: Commissioning Matter 1.4.0 device to Google Nest Hub 2 by iPhone13 or iPhone16 (see log DoorWindow_2.0.1_Google_by_iOS_NG.txt ) TestCase3 [OK]: Commissioning our Matter 1.3.0 device to Google Nest Hub 2 by iPhone13 In TestCase2, we noticed that device was first commissioned to iOS(Apple keychain) then iOS opened a commissioning window again to commission it in Google’s ecosystem, and the device was failed at above step 2, so we also tried: Commissioning the device to Apple Home works as expected, next share the device to Google Home app on iOS, this also fails. Commissioning the device to Apple Home works as expected, next share the device to Google Home app on Android, this works as ex

Hi, We are facing the issue of commissioning our Matter device to google home through iOS device will be 100% failed. Here is our test summary regarding the issue: TestCase1 [OK]: Commissioning our Matter 1.4.0 device to Google Nest Hub 2 by Android device (see log DoorWindow_2.0.1_Google_Success.txt ) TestCase2 [NG]: Commissioning Matter 1.4.0 device to Google Nest Hub 2 by iPhone13 or iPhone16 (see log DoorWindow_2.0.1_Google_by_iOS_NG.txt ) TestCase3 [OK]: Commissioning our Matter 1.3.0 device to Google Nest Hub 2 by iPhone13 In TestCase2, we noticed that device was first commissioned to iOS(Apple keychain) then iOS opened a commissioning window again to commission it in Google’s ecosystem, and the device was failed at above step 2, so we also tried: Commissioning the device to Apple Home works as expected, next share the device to Google Home app on iOS, this also fails. Commissioning the device to Apple Home works as expected, next share the device to Google Home app on Android, this works as ex