“A Summary of the WWDC25 Group Lab”

I'm experiencing an issue where monthly and family monthly subscriptions fail immediately with purchase cancelled in TestFlight, while yearly and family yearly subscriptions work correctly. Setup: All 4 products in same subscription group All show Ready to Submit status Using react-native-iap with StoreKit 2 Testing in TestFlight sandbox The Problem: Yearly subscriptions work fine Monthly subscriptions fail immediately with E_USER_CANCELLED (no dialog appears, user didn't cancel) What I've verified: No active subscriptions (getAvailablePurchases() returns empty) No pending transactions Same subscription group for all products Product IDs match App Store Connect Code is identical for all products Error: E_USER_CANCELLED fires immediately when calling requestPurchase() for monthly products, but yearly products proceed normally. Questions: Why would monthly fail while yearly works (same group, same config)? Could this be sandbox state corruption for monthly products? Should I delete/re

I am an open source developer, who just switched to macOS a few weeks ago. I am basically looking for an alternative to Linux' /etc/nsswitch.conf. Not for custom DNS resolution, that's an easy problem to solve, but for users / groups / hosts resolution via custom network modules. Basically looking for a way how I can hook up into the OS in kind of the same way as an LDAP client would do, and provide my own NSS modules. Just for reference, I am developing rauthy which can do PAM authn / authz in combination with rauthy-pam-nss. It works perfectly fine on Linux systems, and I now want to make it work on macOS as well. I already know that macOS is running its mDNSResponder for DNS instead of having the nsswitch.conf, but I have not found an answer for users, groups and hosts.

As of iOS 26.1, Safari and WebKit views have an issue when rendering the html tag. The disclosure-closed icon / character appears as an emoji arrow ▶️ instead of the unicode character ▸ (U+25B8 - Black Right-Pointing Small Triangle) For example: Summary Additional details.... This wasn't the case in iOS 26.0 / iOS 18. From what I can observe it seems ▶ (U+25B6 - Black Right-Pointing Triangle) may be used in iOS 26.1 which renders as the emoji ▶️ on iOS (at least as far back as iOS 18). The only workaround I found for the moment is to specify explicit CSS to revert back to using the ▸ (U+25B8 - Black Right-Pointing Small Triangle) details > summary { list-style-type: ▸ ; } details[open] > summary { list-style-type: ▾ ; } Is this expected? I've filed a feedback for this FB20997955. Thanks!

Summary App Store Connect validation (Transporter) is rejecting a build that includes a ReplayKit Broadcast Upload extension. The validator reports that RPBroadcastProcessMode is “not specified”, but the shipped IPA’s Upload appex Info.plist has the key at the documented nested path, and Apple’s own analyser (swinfo) shows the same key/value. Error (Transporter 409) “Invalid Info.plist value. The value for the key 'RPBroadcastProcessMode' in bundle BeamRoomHost.app/PlugIns/BeamRoomUpload2.appex is invalid. RPBroadcastProcessMode value must be 'RPBroadcastProcessModeSampleBuffer' or 'RPBroadcastProcessModeMP4Clip'. The key was not specified.” Example error ID seen: 94ec8b42-ef1b-44e8-9d70-2c76458e1bb3 Environment • Xcode 26.0.1 (17A400) • macOS 15.6 (24G84) • Transporter 1.3.4 (13410) • App Apple ID: 6752822011 • Host bundle: com.conornolan.BeamRoomHost • Upload appex bundle: com.conornolan.BeamRoomHost.BeamRoomUpload2 • Version/Build: 0.9.4 (14) Most recent reproduction: 2025-10-02 ~09:00 GMT+1 Proof

Hi all, We are migrating a SCSI HBA driver from KEXT to DriverKit (DEXT), with our DEXT inheriting from IOUserSCSIParallelInterfaceController. We've encountered a data corruption issue that is reliably reproducible under specific conditions and are hoping for some assistance from the community. Hardware and Driver Configuration: Controller: LSI 3108 DEXT Configuration: We are reporting our hardware limitations to the framework via the UserReportHBAConstraints function, with the following key settings: // UserReportHBAConstraints... addConstraint(kIOMaximumSegmentAddressableBitCountKey, 0x20); // 32-bit addConstraint(kIOMaximumSegmentCountWriteKey, 129); addConstraint(kIOMaximumByteCountWriteKey, 0x80000); // 512KB Observed Behavior: Direct I/O vs. Buffered I/O We've observed that the I/O behavior differs drastically depending on whether it goes through the system file cache: 1. Direct I/O (Bypassing System Cache) -> 100% Successful When we use fio with the direct=1 flag, our read/write and data verificatio

I noticed that I cannot even tell that an NSBox is being used on macOS Tahoe when the system is in light mode. The 'box' background can't be seen so it makes it appear that the subviews in the box aren't positioned correctly (because they are inset from the subview outside the box). There is no visual indicator that that subviews inside this box are grouped together because well, you can't see the box at all. In Interface Builder the box looks fine at Design Time in Light Mode. In Dark Mode the box looks fine at design time and at run time. Just figured I'd throw that out there.

Hello, I would like to report a situation that appears to be outside the normal App Review process and may indicate a system issue or an unintended internal flag on my app. My app Vocheo (Bundle ID: com.vocheo) has been stuck in “Waiting for Review” for an unusually long period — a total of ~40 days since the first 2.0 submission on October 26. Across multiple submissions, the review has never meaningfully started. Here is a summary of what happened: Timeline Overview • First 2.0 submission: Oct 26 • Most recent submission: Dec 2 (version 2.1.5) • Total time stuck: ~40 days • Longest individual “Waiting for Review” period: 18 days • Another long period: 8 days • All withdrawals were done on the same day and resubmitted immediately — they did not resolve the issue. Only two submissions ever entered “In Review”, and both resulted in very fast, template-style rejections within minutes. After those, every new submission returned to weeks of “Waiting for Review” with no progress. Attempts to Resolve I hav

As a developer I have a question I would like cleared up. We offer two tiers of annual subscriptions in our apps. These subscriptions are under the same subscription group in App Store connect. My question is, if a user purchases tier 1 of the annual subscription for $10.00, and uses it for 6 months; then chooses to upgrade to tier 2 which costs $20.00 per year. Would the user be pro-rated the difference in price i.e. charge only another $10.00 at the time of the upgrade., or are they charged $20.00 and then refunded the difference in their remaining lower tier subscription? I keep finding inconsistent answers across the Apple community forums on this.

Hi, We are trying to use Apple Security API for KeyChain Services. Using the common App Group : Specifying the common app group in the kSecAttrAccessGroup field of the KeyChain query, allowed us to have a shared keychains for different apps (targets) in the app group, but this did not work for extensions. Enabling the KeyChain Sharing capability : We enabled the KeyChain Sharing Ability in the extensions and the app target as well, giving a common KeyChain Access group. Specifying this in the kSecAttrAccessGroup field also did not work. This was done in XCode as we were unable to locate it in the Developer portal in Indentifiers. We tried specifying $AppIdentifier.KeyChainSharingGroup in the kSecAttrAccessGroup field , but this did not work as well The error code which we get in all these 3 cases when trying to access the Keychain from the extension is error code 25291 (errSecNotAvailable). The Documentation says this error comes when No Trust Results are available and prin

I'm working on a multi-process macOS application (based on Chromium/Electron) that uses Mach ports for inter-process communication between the main app and its helper processes. Background I have an MAS build working successfully via TestFlight for internal testing. However, public TestFlight testing requires Apple review, and while waiting for that review, I wanted to provide a directly distributable build for external testers. I attempted to create a Developer ID signed build with App Sandbox enabled, expecting it to behave similarly to the MAS build. The Problem With App Sandbox enabled (com.apple.security.app-sandbox) and identical entitlements, I observe different behavior depending on the signing certificate: Apple Distribution certificate: App launches successfully, mach-register and mach-lookup work Developer ID certificate: App crashes at launch, mach-register is denied by sandbox The Console shows this sandbox violation for the Developer ID build: Sandbox: MyApp(13605) deny(1) mach-register XXXXXXXX