“A Summary of the WWDC25 Group Lab”

Hello, I’m developing a third-party VoIP app called Heyno and trying to support Siri-initiated calls so they behave like WhatsApp / FaceTime, especially from the lock screen. Target behavior From the locked device, the user says: “Hey Siri, call using Heyno” Expected result: • System CallKit audio-call UI appears. • No “continue in ” sheet, no forced unlock or foregrounding. • Our app handles the VoIP leg in the background via CXProviderDelegate. WhatsApp already does this with: “Hey Siri, call on WhatsApp” I’m trying to reproduce that behavior for Heyno using public APIs. I have followed the SiriKit + CallKit VoIP docs but cannot get a clean Siri → CallKit → app flow from the lock screen without either: Being forced into .continueInApp (unlock + foreground), or Hitting CallKit transaction errors when starting the call from the app in response to the intent. Current implementation Intents extension (INStartCallIntentHandling) • resolveContacts(for:with:) normalizes to E.164 and returns INPersonResolutionRes

I've been writing about the DeclaredAgeRange a bit on LinkedIn and now it is time to take to the developer forums. In my efforts to prepare my apps for new local requirements, I've run across some rough edges. The DeclaredAgeRange API is missing on several platforms, and extension types. First and foremost, watchOS. An Apple Watch is a clear single user platform and for standalone apps, the DeclaredAgeRange being absent is felt by developers. FB20954931 - DeclaredAgeRange: Framework not available on watchOS making compliance a challenge for watchOS standalone apps In the same vein of thinking, while users on Apple Vision Pro are far fewer numbers than Apple Watch, it is also a miss. The tricky part would be testing on the simulator. So far I haven't gotten the simulator and sandbox testing to work and give real values across any platform. I don't think an Apple Store will let me try my app out via TestFlight on their devices and they're still too expensive to reasonably buy for most developers. Too bad Feedba

Device: iPhone 11 iOS Version: 17.2.1 Frameworks: UIKit, Auto Layout App Behavior: App supports Arabic (RTL). User can switch language in-app. When language is switched, the app sets UIView.appearance().semanticContentAttribute and fully rebuilds the window’s rootViewController. Problem Summary I update the global semantic direction only when the user explicitly switches language inside the app — e.g.: // Only run when user switches language inside the app UIView.appearance().semanticContentAttribute = .forceRightToLeft // or .forceLeftToRight // then rebuild the window's rootViewController I do not change UIView.appearance().semanticContentAttribute during navigation transitions. Despite that, after switching the language (and rebuilding the root), the app sometimes crashes during a subsequent UINavigationController push/pop animation. The crash appears to be caused by UIKit’s Auto Layout engine removing or updating directional constraints while a navigation transition is running. Crash Log (most re

Hi everyone, We’re experiencing a persistent issue with an App Clip Experience that continues to load on iOS devices even after being deactivated in App Store Connect more than 48 hours ago. Issue Summary An App Clip Experience tied to the URL pattern https://srgplus.com/u/... keeps appearing when scanning NFC tags or QR codes, despite being removed from App Store Connect. Key Details The App Clip Experience was deactivated over 48 hours ago. iOS still launches the App Clip when scanning NFC tags or QR codes that match the URL structure. The specific token-based App Clip Experience (for example: https://srgplus.com/u/iohgqa) was removed, but iOS still loads an App Clip as if the Experience exists. It seems like iOS is falling back to a previously registered base URL Pattern such as: https://srgplus.com/u or possibly even https://srgplus.com The problem: This fallback App Clip is not visible anywhere in App Store Connect → Advanced App Clip Experiences. So we cannot delete or modify it. The behavior p

XCode version = 26 && macOS version = 26 Running the app from XCode (not in release mode) I want to implement in app purchases for my macOS application, for that i want to first test it locally through StoreKit config file. Steps i have done uptill now: Added the capability in target-> Signing & Capabilities -> In_App Purchase(while adding this i had got the popup: Make changes to In-App Purchase by changing all configurations - i have no idea about it, Researched on it - didnt got something) Added the storekit config file -> added Group for autorenewable subscription -> reference name & product ID (i have used same Bundle ID and product ID, also i have used different both but still the same issue in both case) - also added it to scheme Added the storeManager implementation that is: import StoreKit class IAPManager { // Shared instance (optional singleton pattern) static let shared = IAPManager() private init() { } // Array to store fetched products var products: [Product]

Hi, I am building an iOS app that uses FamilyControls / ManagedSettings to restrict apps. Flow of my app: In my main app, the user chooses which apps to restrict using FamilyActivityPicker (for example, they select Instagram). I save the selection in an App Group. I then use ManagedSettingsStore in the main app to add those app tokens into store.shield.applications, so a Screen Time shield appears when the user opens Instagram. In my ShieldConfigurationExtension, I show a shield UI with a primary button called “Access App”. In my ShieldActionExtension, when the user taps “Access App”, I want to immediately hide the shield and allow Instagram. To hide the shield, I am using this code in my ShieldActionExtension: final class ShieldActionExtension: ShieldActionDelegate { // ... override func handle( action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void ) { switch action { case .primaryButtonPressed: handlePrimaryButton(for: application, c

Issue Summary: On iOS 26.0.1 to 26.3, apps using multiple UITextFields for OTP input face a critical issue where the system autofill pastes the entire OTP string into a single text field, usually the focused one, rather than splitting digits across fields. Delegate events like textDidChange: do not trigger consistently on autofill, breaking existing input handling logic. Expected Behavior: OTP autofill should distribute each digit correctly across all OTP UITextFields. Delegate or control events should fire on autofill to enable manual handling. (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if (string.length > 1) { // Autofill detected - distribute OTP manually for (int i = 0; i < string.length && i < self.arrayOTPText.count; i++) { UITextField *field = self.arrayOTPText[i]; field.text = [NSString stringWithFormat:@%c, [string characterAtIndex:i]]; } UITextField *lastField = self.arrayOTPText[string.length

Summary I am investigating a change in macOS 26.1 (Tahoe) where plain (non-bundled) executables that request screen recording access no longer appear under: System Settings → Privacy & Security → Screen & System Audio Recording This behavior differs from macOS Sequoia, where these executables did appear in the list and could be managed through the UI. Tahoe still prompts for permission and still allows the executable to capture the screen once permission is granted, but the executable never shows up in the UI list. This breaks user expectations and removes UI-based permission management. To confirm the behavior, I created a small reproduction project with both: a plain executable, and an identical executable packaged inside an .app bundle. Only the bundled version appears in System Settings. Observed Behaviour 1. Plain Executable (from my reproduction project) When running a plain executable that captures the screen: macOS displays the normal screen-recording permission prompt. Before grantin