From https://developer.apple.com/forums/thread/803945?answerId=862153022#862153022, the testing of Age Range API was not available through xcode simulator back in Oct 2025. Is this available now? In particular: Is requestAgeRange testing available through simulator? Is requestAgeRange testing with sandbox account available through simulator? Is isEligibleForAgeFeatures available through simulator? Is isEligibleForAgeFeatures testing with sandbox account available through simulator? If the answer is "yes" to any of the above, which version of the xcode and ios version should I use? So far I didn't get any of the above working on the simulator, and I can't find any documentation on the answers above. Thank you!

Our app receives a CallKit VoIP call. When the user taps “Answer”, the app launches and automatically connects to a real-time audio session using WebRTC or MobileRTC. We would like to confirm whether the following flow (“CallKit Answer → app opens → automatic WebRTC or MobileRTC audio session connection”) complies with Apple’s VoIP Push / CallKit policy. In addition, our service also provides real-time video-class functionality using the Zoom Meeting SDK (MobileRTC). When an incoming CallKit VoIP call is answered, the app launches and the user is automatically taken to the Zoom-based video lesson flow: the app opens → the user is landed on the Zoom Meeting pre-meeting room → MobileRTC initializes immediately. In the pre-meeting room, audio and video streams can already be active and MobileRTC establishes a connection, but the actual meeting screen is not joined until the user explicitly taps “Join”. We would like to confirm whether this flow for video lessons (“CallKit Answer → app opens → pre-meeting room (audio/video active) → user taps ‘Join’ → enter actual meeting”) is also compliant with Apple’s VoIP Push and CallKit policy.

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 XXXXXXXXXX.com.mycompany.myapp.MachPortRendezvousServer.13605 The crash occurs when the app calls bootstrap_check_in() to register a Mach service for child process communication. What I've tried Adding com.apple.security.temporary-exception.mach-register.global-name with wildcard pattern XXXXXXXXXX.com.mycompany.myapp.MachPortRendezvousServer.* to the main app's entitlements - this resolved the mach-register denial. However, helper processes then fail with mach-lookup denial. Adding com.apple.security.temporary-exception.mach-lookup.global-name with the same wildcard pattern to the main app's entitlements (for inheritance) does not work. Analysis of /System/Library/Sandbox/Profiles/application.sb I examined macOS's App Sandbox profile and found that mach-register.global-name supports wildcard patterns via select-mach-filter: (sandbox-array-entitlement "com.apple.security.temporary-exception.mach-register.global-name" (lambda (name) ... (let ((mach-filter (select-mach-filter name global-name-prefix global-name))) (allow mach-register mach-filter)))) But mach-lookup.global-name does not - it only accepts exact names: (sandbox-array-entitlement "com.apple.security.temporary-exception.mach-lookup.global-name" (lambda (name) (allow mach-lookup (global-name name)))) Since the Mach service name includes the PID (e.g., ...MachPortRendezvousServer.13605), it's impossible to specify exact names in entitlements. I also verified that com.apple.security.application-groups grants mach-register and mach-lookup only for service names prefixed with the group ID (e.g., group.com.mycompany.myapp.), which doesn't match the TEAMID.bundleid. prefix used by Chromium's MachPortRendezvousServer. My questions What mechanism allows Apple Distribution signed apps to use mach-register and mach-lookup for these service names without temporary exceptions? I don't see any certificate-based logic in application.sb. Is there a way to achieve the same behavior with Developer ID signing for testing purposes? Related threads https://developer.apple.com/forums/thread/747005 https://developer.apple.com/forums/thread/685601 https://developer.apple.com/forums/thread/128714 (confirms temporary-exception can be used freely for Developer ID apps) Environment macOS 15.6 (Sequoia) Xcode 16.4 Both certificates from the same Apple Developer account

Hi We have an AppleTV app that is used to continuously display information (digital signage). One of our clients reports that their AppleTV returns to the homescreen by morning. While our recommendation is to setup Mobile Device Management to lock the AppleTV into running only our app, not every client will have the IT knowledge to set this up. So we're trying to figure out possible causes for the app getting closed. We've not received any crash reports, nor does the device give any indication the app crashed. The energy saving settings are set to run continuously without sleep. The client is reporting this happens every night, so it seems unlikely to be caused by tvOS updates. Are there other things I could rule out to find the cause of this issue? Any ideas are welcome, thanks!

Hello, Regarding EKEventStore, the WWDC session mentions that “you should only have one of these for your application.” In my app, I need to use the instance on both the main thread and a background thread, and I would like to share a single instance across them. However, EKEventStore is a non-sendable type, so it cannot be shared across different isolation domains. I would like to know what the recommended best practice is for this situation. Also, do I need to protect the instance from data races by using a lock? Thank you.

I encountered a concurrency compilation warning when calling the TranslationSession.translations(from: [TranslationSession.Request]) API, and I'm don't know how to resolve it. I reviewed the official demo, but it appears identical.

We have a login flow where the user authenticates in Safari, and at the end of the process the authentication server redirects back to our app using a Universal Link. On most devices, the app opens automatically without any confirmation banner. However, on several iPads, Safari always shows the “Open App A?” banner after the redirect. The user must tap Open every time. Other devices running the same iOS version do not show this issue. Expected Flow (working devices): Start authentication Safari login Authentication server redirects using a Universal Link App A opens automatically Problematic Flow (several iPads): Start authentication Safari login Authentication server redirects using a Universal Link Safari shows “Open App A?” confirmation banner User must tap Open App A starts Questions: Is this a known issue in iOS? Or is this expected behavior under certain conditions (i.e., is there a specific Safari/iOS specification that causes this banner to appear)? Is there any way to prevent Safari from showing the “Open App A?” banner and allow automatic redirection? ＊This issue did not occur on iOS 16, but it started appearing after updating to iOS 17. Devices : iPad 9th Gen/iPad 10th Gen

Is there any way to use blockedApplications to hide all apps in a category? Currently, I use blockedApplications to hide individual apps, but it doesn’t work when I select an entire category. I thought the only solution would be to use shield, which doesn’t hide the apps but creates a blocking shield. However, I found an app on the App Store called Fokus, and it’s able to select a category and block all the apps in it. Does anyone know how this could be possible?

The published "Next steps for apps distributed in Texas" says "A parent or guardian in Texas can withdraw consent for any app, which will block launching of the app on the child or teen’s device." My question is: will this also block notifications sent to that app from showing up on that device? Or will notifications still be delivered to the notification center, even though the app can't be launched? (Specifically, notifications sent from a server via Firebase topic/token). If notifications are not blocked automatically, what is the expected flow for this scenario? My app sends notifications from a server like this. I could implement client-side code to say "if consent is revoked, unsubscribe from notifications", but if the OS blocks launching of the app, this client-side code would never run. Similarly, I could subscribe to the server notifications for when consent is revoked, but my app is free & accountless, so I'm not aware of any information in the server notification that I could use to identify the specific user whose notifications should be stopped. (For example my users won't have an appAccountToken because they never made a purchase). Guidance would be much appreciated. I'm trying to comply with the law but I don't know how.

The API we used: NSURL *url = [NSURL URLWithString:@"App-Prefs:INTERNET_TETHERING"]; The link provided by Apple engineer: https://developer.apple.com/forums/thread/761314 I did not find any URL in the link that leads to the secondary menu of system settings. Does this suggest that iOS 26 does not support this functionality? Moreover, is it possible that versions of iOS 18 and earlier may also not support this behavior in the future?

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)?