In my case, when I try to block calls on iOS 26, the blocking doesn't occur; the scenarios seem intermittent. If I create two CallDirectory extensions, the first blocks the numbers, but the second doesn't. Interestingly, the extension marks the number as suspicious. There's also a case where, on iOS 26 on an iPhone 16 Pro, the functionality doesn't work at all. I'd like to know if there have been any changes to the use of CallKit in iOS 26, because users of my app on iOS 18 and below report successful blocking.

Rejecting a Cellular Call Also Rejects Application Video Call Steps: 1.When a user receives a cellular call and it is in the "ringing" state and application receives a video call which is reported to CallKit 2.User rejects the Cellular call from Callkit UI, Video call is also getting rejected. 3.Application is receiving performEndCallAction when user is rejecting the Cellular call As a part of CXcallobserver Application is receiving call connected then disconnected for the cellular call Irrespective of OS, the issue only reproduces on cellular calls if Live Voicemail is enabled. Issue is not reproduced when Live Voicemail is disabled for cellular calls, and it is not reproducing on FaceTime calls, regardless of the Live Voicemail setting. This results in a poor user experience because: The recipient unintentionally misses the CallKit-reported call. The initiator receives confusing and inaccurate status information, believing the recipient is busy rather than having chosen to decline the pending video call.

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 <contact> 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 <contact> 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 INPersonResolutionResult.success. • resolveDestinationType → .success(.normal). • resolveCallCapability → .success(.audioCall). Confirm / handle currently: func confirm(intent: INStartCallIntent, completion: @escaping (INStartCallIntentResponse) -> Void) { completion(INStartCallIntentResponse(code: .ready, userActivity: nil)) } func handle(intent: INStartCallIntent, completion: @escaping (INStartCallIntentResponse) -> Void) { completion(INStartCallIntentResponse(code: .ready, userActivity: nil)) } Earlier, I used .continueInApp with an NSUserActivity carrying the normalized number and metadata, but that always produced a “Continue in Heyno” sheet that requires unlock and foreground, which breaks the lock-screen Siri flow. App target – CallKit provider In the app I have CXProvider + CXProviderDelegate, which work correctly when calls are initiated from inside the app: func provider(_ provider: CXProvider, perform action: CXStartCallAction) { let handle = action.handle.value // Start VoIP / WebRTC / LiveKit / Asterisk call here provider.reportOutgoingCall(with: action.callUUID, startedConnectingAt: Date()) provider.reportOutgoingCall(with: action.callUUID, connectedAt: Date()) action.fulfill() } If I construct a CXStartCallAction and submit it via CXCallController.request(...) from the app, CallKit UI appears and our pipeline runs correctly. What I tried and what fails Starting CallKit from the Intents extension Calling CXCallController.request(...) directly from handle(intent:completion:) in the extension always yields: com.apple.CallKit.error.requesttransaction error 1 (unentitled) The extension does not have the CallKit entitlement, and the docs say not to initiate calls from the extension, so this path seems unsupported. Using .continueInApp + NSUserActivity Pattern: • handle(intent:) builds NSUserActivity (activityType = NSStringFromClass(INStartCallIntent.self), title = "Heyno Start Call", userInfo with E.164 handle, etc.). • Returns INStartCallIntentResponse(code: .continueInApp, userActivity: activity). • App receives the activity, then starts CallKit + VoIP. Functionally this works, but iOS always requires unlock + foreground (“Continue in Heyno”), which is not acceptable for a Siri lock-screen call. App group + Darwin notification (extension → app → CallKit) Experiment: • Extension writes the normalized number into an app-group UserDefaults. • Extension posts a Darwin notification. • App (if running) listens, reads the number, and initiates CXStartCallAction + VoIP. Observed: • Works only when the app is already running in the background; a killed app is not woken. • In some states I see CXErrorCodeRequestTransactionError.invalidAction (error 6) if I try to issue a CXStartCallAction while CallKit is already doing something as part of the Siri flow. • Siri sometimes replies “There was a problem with the app,” likely because CallKit rejects the transaction or sees duplicate/conflicting actions. My understanding so far • The Intents extension should resolve/confirm the intent but not start the call. • The source of truth for starting a call should be: Siri → CallKit → app’s CXProviderDelegate.provider(_:perform: CXStartCallAction) • The app then starts the VoIP leg, reports started/connected, and fulfills. Where I am stuck What is not clear is how Siri is supposed to route an INStartCallIntent into CallKit for a third-party VoIP app on a locked device without using .continueInApp. If my extension simply: • resolves the contact, • confirm → .ready, • handle → .ready (no NSUserActivity, no CallKit), I do not see a documented mechanism that causes: “Hey Siri, call <contact> using Heyno” on the lock screen to: • Present a CallKit audio call bound to Heyno, and • Deliver CXStartCallAction to my CXProviderDelegate while the app stays in the background. Questions For third-party VoIP apps today, is it recommended to implement INStartCallIntentHandling at all, or should we rely only on CallKit registration and Siri’s built-in support for “Call with ” (no SiriKit extension)? If an INStartCallIntentHandling extension is still the intended pattern: • Should confirm/handle simply return .ready and never start CallKit or set NSUserActivity? • In that case, is Siri expected to invoke CallKit on our behalf and create a CXStartCallAction targeting our provider, even when the device is locked and the app is not foreground? Is there any supported way for a Siri-triggered third-party VoIP call to start from the lock screen via CallKit without: • using .continueInApp (unlock + foreground), and • starting CallKit directly from the Intents extension (unentitled)? Is there any additional configuration, entitlement, provisioning profile flag, or Info.plist key required so that Siri can map “Call using Heyno” directly to our CallKit provider and background VoIP implementation? Current options: • .continueInApp + NSUserActivity → works, but always requires unlock + app UI. • Start CallKit from the extension → fails with “unentitled” and appears unsupported. • Extension → app-group + notification → app → CallKit → VoIP → fragile, with intermittent CXErrorCodeRequestTransactionError.invalidAction. • Remove the extension and hope Siri/CallKit auto-routes to our provider → unclear if this is supported for third-party VoIP apps or reserved for privileged apps. I would appreciate guidance on the intended architecture for this scenario, and whether the “Siri from lock screen → CallKit UI → background VoIP call” flow is achievable for an App Store VoIP app like Heyno using public APIs only.

Hello! Thank you for bringing the new iPhone experience with the PushToTalk framework. I have a working walkie talkie app based on the PushToTalk framework. Everything works fine except for an intermittent bug that I face from time to time on different devices with different iOS versions, from iOS 18 to iOS 26.2 Beta. Sometimes the app goes into a state where the AVAudioInputNode input node tap returns buffers with a constant size that contain only silence. Leaving and rejoining a channel helps, but relaunching or reinstalling (from Xcode) the app does not. Rebooting the device or deleting and reinstalling the app also helps. I do not activate the audio session in my app. I only configure it on launch using setCategory(.playAndRecord, options: [.defaultToSpeaker, .allowBluetooth]) So the flow is: channelManager?.requestBeginTransmitting(channelUUID: globalChannelUUID) func channelManager( _ channelManager: PTChannelManager, channelUUID: UUID, didBeginTransmittingFrom source: PTChannelTransmitRequestSource ) func channelManager( _ channelManager: PTChannelManager, didActivate audioSession: AVAudioSession ) { /// ... installTapAndStart() } private func installTapAndStart() { let inputNode = audioEngine.inputNode let hardwareFormat = inputNode.outputFormat(forBus: 0) guard let targetFormat = AVAudioFormat( commonFormat: .pcmFormatFloat32, sampleRate: configuration.audioSampleRate, channels: configuration.audioChannelsCount, interleaved: true ) else { handleError(RecorderError.invalidAudioFormat) return } let converter = AVAudioConverter(from: hardwareFormat, to: targetFormat)! print("[QUICOpusRecorder]: installTap") inputNode.installTap(onBus: 0, bufferSize: tapBufferSize, format: hardwareFormat) { [weak self] buffer, _ in guard let self else { return } // Here I handle audio data and sometimes get silence } //... do { audioEngine.prepare() try audioEngine.start() } catch { print(" ⚠️ Audio engine start error: \(error)") handleError(error) } } Moreover, if the app is in the foreground and PushToTalk gets stuck in this “silence bug”, I can avoid relying on the PushToTalk flow and simulate audio session activation manually in code. In this case I do not request a transmission and do not use any PushToTalk related code, and the app captures audio data perfectly. Once I leave the channel and rejoin it again, the issue is fixed and I start to receive non silent buffers of varying size, as expected. It works for a while. It can work fine for a day or more, communicating without launching the app, or with the app in the foreground. But it can also go into the “silence” state 30 minutes after working normally. I have no clue why this happens. The only thing I notice is that when the app is in this “stuck silence bug” state, iOS does not play its “chirp” system sound when audio recording starts. P.S. Channel descriptor restoration code: extension PushToTalkEngine: PTChannelRestorationDelegate { public func channelDescriptor(restoredChannelUUID channelUUID: UUID) -> PTChannelDescriptor { print("☀️ \(#function) channelUUID: \(channelUUID)") Task { @MainActor in // Here I fetch more detailed channel data asynchronously do { await initChannelManagerIfNeeded(channelUUID: channelUUID) let channelDescriptor = currentChannelDescriptor() lastChannelDescriptorName = channelDescriptor.name try await channelManager?.setChannelDescriptor( channelDescriptor, channelUUID: channelUUID ) } catch { handleError(error) } } return PTChannelDescriptor(name: "Loading...", image: nil) } } private func initChannelManagerIfNeeded(channelUUID: UUID? = nil) async { guard let channelUUID = channelUUID ?? currentUser?.globalChannelUUID else { print("❌ No global channel uuid found") return } do { guard channelManager == nil else { try await channelManager?.setTransmissionMode(.halfDuplex, channelUUID: channelUUID) return } channelManager = try await PTChannelManager.channelManager( delegate: self, restorationDelegate: self ) try await channelManager?.setTransmissionMode(.halfDuplex, channelUUID: channelUUID) } catch { handleError(error) } }

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 persists across: Multiple devices Different networks After clearing device caches After reinstalling our app Even after scanning using devices that never used this App Clip before This makes us believe that the App Clip Experience may be: Cached on Apple’s servers Or orphaned/hidden in App Store Connect Or not properly removed from the URL pattern registry Steps to Reproduce Deactivate an App Clip Experience in App Store Connect. Wait 48 hours or more. Scan an NFC tag or QR code pointing to a previously used URL pattern. App Clip still appears, even though no active Experience exists. Expected Behavior App Clip should stop appearing once the Experience is deactivated and removed. Actual Behavior App Clip continues to load indefinitely, suggesting a cached or orphaned configuration. Question Has anyone encountered similar behavior? Is there a way to request a manual purge of App Clip URL patterns or cached Experiences from Apple’s side? Any guidance or insights would be greatly appreciated. Thank you!

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, completionHandler: completionHandler) case .secondaryButtonPressed: completionHandler(.close) @unknown default: completionHandler(.defer) } } private func handlePrimaryButton( for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void ) { // (I update some app-group state here, lives, history, etc.) // This is the important part: I try to unshield the app let store = ManagedSettingsStore() var apps = store.shield.applications ?? Set<ApplicationToken>() apps.remove(application) store.shield.applications = apps // I then tell the system to re-evaluate completionHandler(.defer) } } (When testing another approach, I also tried completionHandler(.close) after removing the app from the shield applications.) Behavior I see: Local / Xcode debug build (installed by cable): Open Instagram → Slofy shield appears. Tap “Access App” → the above code runs. Shield disappears immediately and Instagram is usable. ✅ TestFlight build: Open Instagram → Slofy shield appears. Tap “Access App” → the above code runs, and I see in logs: Removed app from shield set (apps now: 0) But the shield does not hide. It stays on the screen. ❌ Only if I then open my main app (Slofy) and close it again, and then return to Instagram, the shield disappears and Instagram is unlocked. So the same code works as expected in local debug builds, but in TestFlight builds the Screen Time shield does not refresh / disappear immediately after I remove the app from store.shield.applications inside the ShieldActionExtension. My questions: Is it supported to unshield an app directly from inside a ShieldActionExtension (by removing it from ManagedSettingsStore().shield.applications) and expect the shield to disappear immediately? Is there any difference in how ManagedSettingsStore changes are applied between debug and TestFlight / release builds for Screen Time shields? Is the main app required to be in the foreground for the shield to update, or is there a recommended pattern to make the shield hide right after the user taps the primary button in the shield? I would like the behavior to be: User opens restricted app → shield shows → taps “Access App” → shield hides immediately and the app becomes usable, without needing to open the main app. Any guidance on the correct way to implement this with Screen Time extensions would be greatly appreciated. Thank you.

As per the US state law including SB2420 in Texas. We are suppose to meet their compliance. We have following queries Could you please confirm whether the provided Declared Age Range API framework is available for sandbox testing How does the API respond for a region other than Texas

Hello, I would like to clarify how link association and app-opening preferences work in iOS, specifically when a user opens a URL in a browser that can be handled by an installed application. I have noticed the following behavior: When a user taps a URL that can be opened by an app, iOS sometimes asks whether to open the link in the app or continue in the browser. After choosing an option once (for example, "Open in App" or "Stay in Browser"), it seems that this preference becomes persistent. Even after deleting the application and reinstalling it, the browser (Safari or third-party browsers) sometimes continues to open the link directly in the browser without asking the user again. In some cases, it appears impossible to reset or clear this association, and the user is not prompted again to choose how the link should be opened. My questions are: How exactly does iOS store link-handling preferences between apps and browsers? Are these preferences saved on the system level, inside Safari, or associated with the app installation itself? Is there a way for a user to manually reset or clear these link-opening associations? Should deleting and reinstalling the app reset these preferences, or is the behavior expected to persist? Is this behavior different for Universal Links, App Clips, or for regular URL scheme associations? This situation is important for us because it affects user experience, and at the moment it is difficult to understand or reproduce the internal logic behind these link associations. Thank you in advance for your clarification.

系统闹钟APP响铃响起时，点击电源键可以小睡功能。AlarmKit能否有办法判断是电源键和其他物理按键关闭了闹钟，而非点击或滑动关闭按钮。这样第三方闹钟也可以增加小睡功能。目前是直接关闭了闹钟。

We are integrating Apple’s DeclaredAgeRange SDK. To comply with relevant regulatory requirements, our understanding is as follows: The app is only required to obtain the declared age range for users located in Texas. For users outside of Texas, we should not proactively request age range information. Accordingly, we would like to confirm the following: Are we required to present the age range request prompt to all users in the United States? If yes, we are concerned that this may significantly impact the overall user experience. If it is permissible to request age range only for Texas users, how can we reliably determine whether a user is located in Texas on the client side? For example, does Apple provide an API or recommended method for accurately identifying a user’s region (specifically Texas)?

Q4: When an alarm is dismissed (either by swiping or pressing the power button), can an app detect this action and execute code in response? What about force closed apps? When an alarm is dismissed, the stopIntent set in the AlarmConfiguration is called. Any code in the perform method of this AppIntent would execute. 我看到这样的描述，但是测试发现锁屏状态下闹钟响起时按下电源键不走AlarmConfiguration的stopIntent。设计确实是这样吗？

General: Forums topic: Family Controls Forums tag: Family Controls Configuring Family Controls documentation Screen Time Technology Frameworks documentation FamilyControls documentation What's new in Screen Time API video Meet the Screen Time API video

Subject: iOS Fails to Fetch AASA File for Internationalized Domain Names (IDN) in Unicode or Punycode Format Dear Apple Developer Relations Team And Community Members, We are reporting a critical bug in the iOS Associated Domains feature that prevents Universal Links from working for apps using Internationalized Domain Names (IDN). Problem Description: The iOS operating system does not attempt to download the apple-app-site-association (AASA) file for domains containing non-ASCII characters (e.g., diacritics, Cyrillic). This failure occurs regardless of whether the domain is specified in the app's entitlements in its human-readable Unicode format (e.g., montréal.ca) or its encoded Punycode format (e.g., xn--montral-fya.ca, xn--e1afka0abm4b.xn--p1ai). Without fetching and validating this file, Universal Links are not activated, and the system fails to establish a connection between the website and our app. Steps to Reproduce: Create an app with the Associated Domains entitlement enabled. Add an IDN to the entitlement. We tested both formats: Format A (Unicode): applinks://montréal.ca Format B (Punycode): applinks://xn--montral-fya.ca Host a valid AASA file on our server at the correct, accessible well-known URLs for both domain representations: For montréal.ca: https://montréal.ca/.well-known/apple-app-site-association and https://xn--montral-fya.ca/.well-known/apple-app-site-association Install the app on a device running the latest iOS version. Monitor network traffic using a tool like Charles Proxy. Observed Result: No HTTP GET request is made to any of the AASA URLs for the domains montréal.ca (in either Unicode or Punycode format) upon app installation. The system does not initiate the domain validation process. In contrast, for a standard ASCII domain (e.g., applinks://example.com), the AASA fetch is triggered immediately and is observed in the network log. Expected Result: iOS should correctly resolve the Internationalized Domain Name (whether specified in Unicode or Punycode format in the entitlement) and perform an HTTP GET request to fetch the AASA file from the /.well-known path, identical to its behavior for ASCII domains. Evidence & Configuration: Our server is configured correctly: SSL certificates are valid, the AASA file is served with the correct application/json MIME type, and is directly accessible via a browser or curl. The AASA file's syntax has been validated and is correct. The issue is reproducible on the latest versions of iOS. Impact: This bug blocks a core platform feature for millions of users in regions that use non-Latin scripts (e.g., France, Russia, China, Arab states). It makes it impossible to use Universal Links with our primary domains, severely degrading the user experience and forcing us to seek suboptimal workarounds like registering separate ASCII domains. Request: We kindly request that you investigate and log this issue as a bug in iOS and forward it to the appropriate engineering team for a fix in an upcoming update. We are prepared to provide any additional information, demo projects, or server access to assist in diagnostics. Thank you for your attention to this serious matter.

I am requesting assistance with an issue involving my Advanced App Clip Experience, which has remained in the “Received” state for more than few months, preventing the App Clip from becoming available when invoked via QR code. App Details App Name: Yellow Label Verification App Store Bundle ID: com.acviss.demoindia App Clip Bundle ID: com.acviss.demoindia.Clip Team ID: F2RLQ4VV59 App Version (Live): 1.4 Domain: acviss.com Issue Summary My Advanced App Clip Experience is stuck in the “Received” status. The “Publish” and “Build Assignment” options never appear, even though: The updated AASA file is correctly published at: https://acviss.com/.well-known/apple-app-site-association It contains the correct appclips → appID and paths entries It is served with the correct application/json content type Domain validation in App Store Connect shows Validated The App Clip build is already approved and live on the App Store Safari-based App Clip invocation works as expected Despite this, the Advanced App Clip Experience has not transitioned from “Received” to “Processing” or “Published.” Because of this, QR-based invocation consistently shows “App Clip Unavailable”, indicating that the App Clip Experience has not yet been activated on Apple’s backend. Reproduction Steps Publish correct AASA file with appclips array and paths Validate domain (shows green “Validated” in App Store Connect) Open the Advanced App Clip Experience in App Store Connect Status stays as Received “Build Assignment” or “Publish” buttons never appear QR scanning of the App Clip URL continues to show App Clip Unavailable Request Could you please check the backend processing of my App Clip Experience and manually trigger the sync or processing It appears that the App Clip Experience is not being processed even though all configuration, AASA, and domain validations are correct. I would greatly appreciate your assistance in resolving this so the App Clip can be invoked successfully via QR. Thank you very much for your help and support.

According to Apple's documentation at https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox?language=objc, the testing steps and expected responses are outlined as follows: ​Test app consent revocation​ To test the notification when a parent or guardian revokes access to your app on behalf of their child, follow these steps: Start with a Sandbox account. From the Age Assurance settings, tap ​Revoke App Consent. Enter your app’s Bundle ID (for example, com.example.bundle). Tap ​Revoke Consent​ to simulate the revocation. Confirm that the system displays ​​“Notification Triggered”​​ with the message ​​“A notification will be sent to the developer server soon.”​ I followed the steps exactly as described above, but during the fifth step, instead of seeing the prompt ​​"A notification will be sent to the developer server soon,"​​ a pop-up dialog with only a confirmation button appeared. After clicking it, there was no further response, and our server did not receive any notification (neither from the Sandbox nor the Production environment).

Hello Apple Developer Support Team, I am the Account Holder of my Apple Developer Program team (Team ID: T2BKUF6E93). My iOS app is using Swift WeatherKit (WeatherService) on device. Although my environment is completely configured, the system WeatherDaemon consistently fails to generate the WeatherKit JWT token. My environment: Team type: Apple Developer Program (paid) Team ID: T2BKUF6E93 Account role: Account Holder Xcode: latest version Device: iPhone (real device) Provisioning Profile: iOS Team Provisioning Profile (auto-managed) Entitlement: com.apple.developer.weatherkit included WeatherKit Key: created successfully (.p8 downloaded) Bundle ID: correct and WeatherKit capability enabled App reinstalled after each configuration change Device rebooted Even after enabling WeatherKit capability and generating a WeatherKit Key, the system still fails to generate JWT: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" The error persists across: multiple device restarts full clean/rebuild in Xcode deleting and reinstalling the app pulling the latest provisioning profiles waiting more than several hours for backend propagation What I suspect My WeatherKit entitlement and/or WeatherKit Key may not be fully propagated to the provisioning server or WeatherDaemon backend, even though everything appears correctly configured on the Developer Center. I kindly request the support team to: Verify whether the WeatherKit Entitlement is correctly attached to my app ID and provisioning profile. Verify whether my WeatherKit Key is properly registered and propagated for my team. Check if there are any backend propagation delays or stuck states for my Team ID (T2BKUF6E93). Confirm whether WeatherDaemon has permission to generate JWT for my app. Thank you Please let me know if any logs, screenshots, or provisioning profile identifiers are needed. Thank you for your help! Best regards, Jiangyang

I created in my Objective-c project the AgeRange check for a special function. It is working well on an iPhone. Now I used my Mac and added my app to the TestFlight on my macOS Tahoe 26.1 Here it is directly crashing. But how can I debug an Application which is created for iPhone and iPad with Xcode? I cannot use the target myMac when running a debugging mode. So how is the debugging working for such Apps?

Are we planning to have some APIs or methods to know that status of Call blocking extension and message filter extension in future releases as currently it is not available.

Hi everyone, I’ve been stuck on an issue with iOS Universal Links for about a week and could really use some help. The problem When tapping a Universal Link on iOS, my Flutter app opens correctly (desired behavior) — but immediately afterward, Safari opens the same link in the browser. So both the app and the browser open. This only happens on iOS. On Android everything works as expected. What works If the link is simply the domain, like: https://mydomain.com …then the app opens without triggering the browser afterward. This is the correct behavior. What doesn’t work If the link includes a path or parameters, like: https://mydomain.com/path https://mydomain.com/path?param=value …then the app opens, and then the browser opens immediately after. What I’ve tried Verified my AASA file using Branch’s validator: https://branch.io/resources/aasa-validator/ → The AASA file is valid. Universal Links do open the correct screen inside the app — the issue is the unwanted second step (Safari opening). Behavior is consistent across different iOS devices. Extra details Using Flutter. Universal Links set up with the standard configuration (associatedDomains, AASA hosted at /.well-known/apple-app-site-association, etc.). Question Has anyone encountered this issue where Universal Links with paths/params open the app and then open Safari? What could cause iOS to trigger the browser fallback even when the AASA file is valid and the app handles the link correctly? Any insights, debugging tips, or known edge cases would be incredibly appreciated!

Hello, I have a question about the default UI in an App Clip. I know that when App Clip launches, a system banner appears at the top for a few seconds, prompting the user to download the full app from the App Store. I'd like to confirm if this is the standard, default behavior for all App Clips. More importantly, is there any way to disable or hide this banner? We would prefer to manage the prompt to download the full app within our own UI. Thanks in advance for your help!