Hi, In the calendar app I created an event called E1 on an iCloud calendar and noticed 2 entries, so I suspect EKEventStore.events(matching:) returned it. Note: I am not referring to recurring events. Used an iCloud calendar Question Is it possible EKEventStore.events(matching:) to return duplicate events? When I did search the following was reported by AI, but I am not very sure, so hence the question. The EKEventStore.events(matching:) method returning duplicate events is a well-known, expected behavior in EventKit. It typically happens because a single event exists across multiple calendars, has multiple participants/invitees, or EventKit is fetching the event from different sync sources (like iCloud and a local cache) simultaneously.

Summary: When our VoIP app attempts to reject/end an incoming call, CXCallController.request(_:completion:) fails with: Error Domain=com.apple.CallKit.error.requesttransaction Code=4 "(null)" CXErrorCodeRequestTransactionError, Code 4 = unknownCallUUID — the call UUID did not match a call known to the call kit. As a result, the Incoming call screen continue to displayed and leaving a stale/ghost call in CallKit. Environment: iOS version: 26 / 18 Device model: iPhone 14 Steps to Reproduce: Receive an incoming VoIP call (reported to CallKit via CXProvider.reportNewIncomingCall). Reject the call programmatically OR manual end call Observe: app-side call state transitions to ended/rejected, but the native CallKit call UI/state does not clear — CXEndCallAction request fails with unknownCallUUID. [fill in: reproduction rate — always / intermittent / specific timing window] Full error log: 2026-08-13T13:41:16:902+0530 Thread 915 — [CallKitManager requestTransaction:]_block_invoke: Error requesting transaction: [<CXTransaction 0x14f1eb060 UUID=E1785E55-24CF-49E6-8225-372E7F5F0F9D isComplete=0 actions=( "<CXEndCallAction 0x141d18190 UUID=BBE9EB13-EFF5-49F1-99DC-96A6218C9031 state=0 commitDate=(null) callUUID=7C8A16B2-4CF4-4F66-A588-5A663A6D52D4 dateEnded=(null)>" )>] Error Domain=com.apple.CallKit.error.requesttransaction Code=4 "(null)" Questions : Can CXCallController.request(_:completion:) legitimately fail with unknownCallUUID if CXEndCallAction is issued before the reportNewIncomingCall completion handler has returned — i.e., is there a required ordering/synchronization guarantee we're missing? Are there known conditions (OS version-specific behavior, app suspension/background state, Do Not Disturb / Focus interaction, multiple concurrent CXProviders) under which CallKit's internal call controller can "lose" a UUID that was previously reported, causing a subsequent valid action to be rejected as unknown? Is there a supported way to query CXCallController/CXProvider for the current set of UUIDs it considers "known" at a given time, to diagnose this class of mismatch before issuing an action? Once unknownCallUUID occurs, is there a recommended recovery path to force-clear a stale call from CallKit's UI/state from the app side, short of ending all calls?

We adopted the "com.apple.developer.family-controls.app-and-website-usage entitlement" to read usage through "DeviceActivityData.activityData(filteredBy:using:)" after "approvedWithDataAccess". It works as documented. We want to clarify the exclusivity issues. The consent sheet says, under "Limited Access", that Screen Time "will lose access to this data as only one app or service can access it at a time." On our test devices that is exactly what happens: after allowing, the Screen Time pane in Settings shows no new usage until the app is toggled off under Apps with Screen Time Access. Is this intended as permanent design, and is there any supported way for a third-party app and Apple's Screen Time to hold the data simultaneously?

Hi Apple Developer Support, I’m developing an iOS app that uses FamilyControls, ManagedSettings, and DeviceActivity. My app requests Screen Time authorization with: try await AuthorizationCenter.shared.requestAuthorization(for: .individual) Issue: On my development-installed build, AuthorizationCenter.shared.authorizationStatus becomes .approvedWithDataAccess, and the app can display usage data. However, after installing the App Store / App Store Connect distribution build, the same device and same flow returns .approved instead of .approvedWithDataAccess. As a result, the app only treats the authorization as management access, not usage-data access. App details: App name: App时记 Main bundle ID: com.qteqpid.appstop Device Activity Monitor extension: com.qteqpid.appstop.AppStopMonitorExtension Device Activity Report extension: com.qteqpid.appstop.AppStopReportExtension Version/build tested: 2.0 (4) Team ID: 5N6B48T57B What I verified: I exported an App Store Connect IPA from Xcode Organizer on September 3, 2026 and inspected the actual signed entitlements with codesign. The main app and both Screen Time extensions all include: com.apple.developer.family-controls = true com.apple.developer.family-controls.app-and-website-usage = true com.apple.security.application-groups = group.com.qteqpid.appstop get-task-allow = false The DistributionSummary.plist also shows Apple Distribution signing and App Store provisioning profiles for the main app and both extensions. Question: Given that the App Store Connect distribution IPA appears to contain the app-and-website-usage entitlement on the main app and both extensions, what conditions would cause AuthorizationCenter.shared.authorizationStatus to return .approved instead of .approvedWithDataAccess for an .individual authorization? Is there an additional distribution-side approval, App ID setting, provisioning support setting, device state, or Screen Time privacy limitation that can prevent .approvedWithDataAccess even when the signed entitlements are present? I would appreciate guidance on how to verify why data access is not granted in the App Store/TestFlight environment. Thank you.

Hi team, We're experiencing two issues with our App Clip invocation via appclip.apple.com links. Setup: App Clip URL: https://appclip.apple.com/id?p=com.x.AppClip The App Clip card and experience work correctly when the full app is NOT installed ✅ Issue 1: App Clip card shown even when the full app is installed When the full app is already installed on the device, tapping the App Clip link shows the App Clip card instead of directly opening the full app. After tapping "Open" on the card, the full app launches — but then the App Clip card appears again on top of the app, requiring the user to dismiss it a second time. Expected behavior: If the full app is installed, tapping the App Clip link should bypass the App Clip card entirely and open the full app directly, routing to the correct screen using the URL parameters. Actual behavior: User taps App Clip link → App Clip card appears (should not appear if app is installed) User taps "Open" on the card → Full app launches App Clip card appears again on top of the full app → User has to dismiss it manually This results in unnecessary friction — two extra taps just to get into the app. Issue 2: Full app does not route to the correct screen When the full app eventually opens (after dismissing the cards), it opens to the default home screen rather than routing to the screen specified by the parameter in the URL. Expected behavior: The full app should handle the URL parameters and navigate to the appropriate screen. Actual behavior: The full app opens to its default/home screen, ignoring the url parameter. Questions: Is this expected behavior that appclip.apple.com links always show the App Clip card even when the full app is installed? If so, is there a recommended approach to bypass the card and open the app directly? What is causing the duplicate App Clip card after tapping "Open"? Is this a known issue, or is there something in our configuration that could be triggering it? For the full-app-installed case, what is the recommended way to handle deep linking from an appclip.apple.com URL into a specific screen in the full app? Should we be handling this via NSUserActivity, UIApplicationDelegate, or a Universal Link handler? Environment: iOS 26.x Xcode 26.x App Clip configured with appclips associated domain Full app and App Clip share the same App ID prefix Any guidance would be greatly appreciated. Thanks!

We have a Live Caller ID Lookup deployment that has been blocked for weeks, and the core difficulty is not technical. It is that we cannot find out anything about the state of our onboarding submission. Here is where we stand. We submitted the onboarding form and our configuration was approved on 8 August. That approval email is the only communication we have ever received about this feature. Our service is deployed and verified: the OHTTP gateway negotiates HTTP/2, serves a valid key configuration, the issuer directory returns 200 and Apple polls it continuously, the DNS TXT record is in place, and the validation identity is in our corpus. Development builds work end to end and display caller names correctly on incoming calls. App Store builds do not. Every authenticated request fails on the device in roughly 47 ms, before anything leaves the phone: ciphermld(CipherML) requestData(byKeywords:shardIds:clientConfig:) threw NSURLErrorDomain Code=-1009 _NSURLErrorPrivacyProxyFailureKey = true nw_endpoint_proxy_handler_should_use_proxy: "Proxies not present, but required to fail closed" The network path is healthy in the same moment, and other processes on the device do receive proxy configuration. Only our extension's bundle identifier never does. We reproduced this on Wi-Fi and on cellular, and after a device restart. We have since learned, from a maintainer replying to an issue we opened on the pir-service-example repository, that "approved" in the CloudKit console is not the same thing as "successfully onboarded", and that we are still in the first state. That explains the behavior completely. What we cannot explain is how a provider is supposed to discover this. There is no status field in the console, no notification when the state changes, and nothing in the onboarding documentation that mentions a second stage exists. We wrote to Apple several times over these weeks. We were told more than once that an internal team would look into it, and we never received a reply. Apple Support told other providers in the same situation that this is a technical matter beyond their scope. Looking through the pir-service-example issues, this pattern is common. One provider reported waiting three months without a response. Another reported that form to production took almost four months. Another only discovered the feature had been enabled by noticing traffic arriving at their own server. My questions: Is there any supported way to check the onboarding state of a submitted configuration, or to ask about one that appears stuck? If not, is anything planned? Is the transition from "approved" to "successfully onboarded" expected to be automatic, and roughly how long should it take? For anyone who has been through this: did you eventually get a notification, or did you find out by watching your own server logs? We are not asking for our submission to be prioritized. We would simply like to know whether we are waiting on something or whether something needs to be resubmitted, and right now there is no way to tell the difference. Our paying subscribers cannot use the feature, and we have not been able to give them an accurate answer either. Thank you.

Summary Our Live Caller ID Lookup deployment works end-to-end from an Xcode-signed build but fails on the App Store build of the same app, on the same device, same network, same Apple ID. On the production build every authenticated request fails locally in ~47 ms, before any packet leaves the device. Our Identity & Trust configuration in CloudKit Console has read "Approved" since 2026-08-08. Device log at the moment of failure nw_endpoint_proxy_handler_should_use_proxy: "Proxies not present, but required to fail closed" ciphermld(CipherML) <Error>: queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token _NSURLErrorPrivacyProxyFailureKey=true NSUnderlyingError={NSPOSIXErrorDomain Code=50 "Network is down"} (_NSURLErrorNWPathKey=satisfied, Wi-Fi up, LQM: good) Control experiment: the device's privacy proxy stack is healthy at that exact moment 0.93 seconds before our extension is refused, the same device attaches a proxy to another connection without any problem: 11:51:59.417 mDNSResponder nw_endpoint_proxy_add_config_if_applicable Adding proxy masque Proxy: https://mask.icloud.com:443 11:52:00.337 ciphermld [C15 ... bundle id: <our extension>, proxy fail closed] start 11:52:00.346 ciphermld Proxies not present, but required to fail closed System state in the same capture: Privacy Proxy Service Status: 1 Privacy Proxy User Tier: 1 Privacy Proxy Networks: (<Cellular, Active>, <WiFi, Active>) Counts across the capture: nw_endpoint_proxy_add_config_if_applicable appears twice (mDNSResponder and Safari SafeBrowsing), while Proxies not present appears 16 times, all from ciphermld, all for our extension's bundle id. No connection made on behalf of our extension is ever given a proxy configuration. Reproduced on two networks and after a device restart, with the device charging and Low Power Mode off. Apple's own endpoint already recognises our issuer 11:51:59.405 ciphermld(CipherML) Fetching token issuer directory from https://gateway.icloud.com/pat-issuer-directory?issuer=<our-issuer-host> 11:52:00.332 200, 1511 bytes, 928 ms Our validation Bearer token from the onboarding submission also returns 200 on /token-key-for-user-token when Apple's validator calls it, which we observe on our server several times a day. A second observation that may be the key In apple/pir-service-example issue #139 an Apple engineer stated that once onboarding is complete, "all requests ... will automatically use OHTTP even when it is a development build". We captured our development build today with full device logging. Every one of its connections goes directly to our PIR host over QUIC, with no proxy fail closed stamp, and the words ohttp, oblivious, mask.icloud and our OHTTP gateway hostname appear zero times in the capture: 16 connections, all: Hostname#<our-pir-host>:443, attribution: developer "proxy fail closed": 0 "Proxies not present": 0 If a completed onboarding forces OHTTP even for development builds, then our development build going direct indicates the relay configuration was never distributed for our extension's bundle id, despite the console showing "Approved". Fleet-level data, not a single device On the day of release, 40 distinct premium accounts on the current App Store build fetched their user tier token from our backend. Across that entire day our PIR service saw zero Privacy Pass issuances and zero queries from App Store builds. For contrast, a single development-signed device produced 144 /issue requests in one day earlier in the month. What we already checked and fixed on our side HTTP/2 ALPN negotiates on all three hosts (service, issuer, gateway). The DNS TXT ownership record is in place. The OHTTP gateway serves a valid key config (X25519 / HKDF-SHA256 / AES-128-GCM). The PIR use case names match the required <extension bundle id>.block / .identity format exactly. The validation identity +1 408 555 1212 "Johnny Appleseed" is present in the live corpus. We found and fixed a real defect of our own: our OHTTP gateway's allowed target origin list was missing the issuer host. We corrected it and restarted the gateway (its HPKE key config was byte-identical afterwards, so no key rotation occurred). The failure reproduced with an identical signature seven minutes later, and the device log confirms these hops never touch our gateway anyway. Questions Is relay / privacy proxy provisioning for a production bundle id a separate step after the Identity & Trust configuration is approved, and what is the expected propagation time? Is there any way for a developer to check provisioning status? Right now an "Approved" badge and a completely non-functional production build look identical from our side. Is there a supported way to exercise the production privacy proxy path before shipping to the App Store? Development builds bypass it by design, so the first real test of the production path was made by paying customers. This seems likely to affect other adopters. Is provisioning keyed on the extension bundle id, the app bundle id, or the team id? Other system consumers on the same device receive proxy configurations normally. We accidentally submitted two identical configurations three minutes apart on 2026-08-08 and both show "Approved". Can a duplicate block or confuse provisioning, and should one be revoked? Environment: iPhone 17 Pro Max, iOS 26.6.1, Xcode 26.5 (17F42). App Store build version 14 (36). Feedback Assistant report with full device logs: FB24501570 GitHub issue with the same detail: https://github.com/apple/pir-service-example/issues/162 Configuration ID: 693155e2-b8ba-4b47-9b6c-64fd97677386 and a1959377-8069-4225-87b9-c1ff81016611

The documentation suggests that you can transfer files out of the crash reporting extension but it doesn’t outline if there are any gotchas to watch out for. Are there any limitations to this? Does it have full network access? Are app groups and keychain groups fully supported? Does the extension have a memory footprint limit we should watch out for? What is the lifecycle of the callback, what Is a reasonable amount of time to plan our implementation to do its work and be done within? 10 seconds? 30? And so on.

Hi all, we're using a CUPS notifier in a custom printer billing software. In the current macOS 27 beta, the notifier is never executed although it's correctly registered in subscriptions.conf. Is this a bug in macOS or was the functionality intentionally removed? Thanks and greetings, Andreas

Hey Everyone, I am looking for some help as I am completely lost in what to do, maybe I am missing something simple, but, our server-side WeatherKit REST integration has returned 401 on every request for several weeks, and the evidence points to service enablement on Apple's side rather than our configuration. Details: The 401 response body is {"reason": "NOT_ENABLED"}, per the documentation this indicates the WeatherKit service is not enabled for the App ID, not a malformed token. Deliberately corrupting the JWT produces a different rejection, which we can reproduce at will, so token validation is clearly passing. The JWT is structurally correct: header {alg, kid, id: "TEAM.BUNDLE"}, payload {iss: TEAM, sub: BUNDLE}. The same Team ID and signing flow produce a working MapKit JS token in production today. In Certificates, Identifiers & Profiles, the WeatherKit capability is checked for the App ID under both App Services and Capabilities, and has been for weeks. We have since minted a brand-new key (new .p8, re-encoded and verified) and the result is unchanged. Bundle ID: run.tayro.app. The failure is identical from our production servers and from curl. Developer Support declined to escalate twice, saying this is outside their scope so I'm posting here for help :) . Has anyone seen NOT_ENABLED persist despite the portal showing the capability enabled? And long shot but... maybe someone from the WeatherKit team can check the service enablement state for this App ID? or point me at the right channel to request that?

I have a persistent WeatherKit authentication failure that could be server-side JWT minting not being enabled for my App ID. Every WeatherService.shared.weather(for:) call fails with: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" The console shows the request reaching Apple's auth service and failing only at the JWT generation step. Account / app: Team ID: 634Q7K5DN8 Bundle ID: com.davidfrauenhofer.TripVault App: shipping on the App Store (this is an update adding a WeatherKit forecast) Device: iPhone 13 Pro, physical device (not simulator) Signing: Xcode automatic Everything I've verified locally: codesign -d --entitlements - on the installed binary confirms com.apple.developer.weatherkit = true, with application-identifier = 634Q7K5DN8.com.davidfrauenhofer.TripVault and matching com.apple.developer.team-identifier. WeatherKit is enabled on the App ID under both the Capabilities and App Services tabs, saved and confirmed. App ID Prefix equals my Team ID (634Q7K5DN8) — no legacy prefix mismatch. Fresh provisioning profiles downloaded; clean build folder; app deleted and reinstalled. Active Apple Developer Program membership; no pending agreements in App Store Connect. Valid coordinates passed (confirmed in logs). This has persisted for several weeks across many rebuilds and reinstalls so i should have cleared any propagation windows. Request to the WeatherKit team: Could someone verify whether JWT minting is enabled server-side for this Team ID / Bundle ID, and whether there is a stuck or incomplete WeatherKit registration for this App ID? Given the entitlement is confirmed present in the signed binary and all client-side configuration is correct, I believe this requires inspection of the auth-service registration on Apple's side. Happy to provide any additional logs or identifiers.

Hi all! I am seeing the following problem while developing a Quick Look extension to preview Markdown files on iOS and macOS: On iOS 26, Quick Look invokes an installed data-based Quick Look preview extension for .md files resolved as net.daringfireball.markdown, and the extension renders the Markdown correctly. On iOS 27, the same document and the same installed extension no longer work. Quick Look still resolves the file as net.daringfireball.markdown, but it does not invoke the extension and instead displays the raw Markdown source using the generic plain-text preview. Also the same extension runs perfectly on macOS 26 and macOS 27. The extension subclasses QLPreviewProvider, has QLIsDataBasedPreview enabled, and includes net.daringfireball.markdown in QLSupportedContentTypes. As a control, the same installed extension correctly launches and renders equivalent document content when it is presented through a custom Uniform Type Identifier. This confirms that the extension is embedded, installed, and otherwise invocable; the failure is specific to Quick Look's provider selection for Markdown on iOS 27. Reproduction: Install an app containing the data-based preview extension described above. On iOS 26, open an .md document in Quick Look and observe that the extension is launched and renders the Markdown. On iOS 27, open the same document with the same extension installed. I reproduced this through Files, although the issue concerns Quick Look provider selection rather than Files-specific behavior. Observe that the extension is not launched and the raw Markdown source is shown. Open an equivalent document registered with a custom content type supported by the same extension. Observe that Quick Look launches the extension and displays the rendered preview. The attached screenshots show the same Markdown case rendered by QuickMark on iOS 26 and falling back to plain text on iOS 27. Is there a supported way for a third-party preview extension to handle net.daringfireball.markdown on iOS 27, or is this an unintended provider-selection regression? Tested with iOS 27.0 (24A5408d) on an iPhone 17 Pro Max Simulator using Xcode 27.0 (27A5237l). Feedback filed as FB24481377.

Product: Vozzy — custom keyboard + containing app for user-initiated dictation. Bundle: br.com.buddyapps.FlowType App Group: group.br.com.buddyapps.FlowType Flow: User selects our keyboard in a host app (Notes/Messages). Without Full Access, QWERTY input works locally. With Full Access, user taps Microphone to dictate. Containing app owns mic permission, AVAudioSession, capture, SpeechAnalyzer, Foundation Models. Keyboard never captures audio; it reflects shared state and inserts via textDocumentProxy. Already settled (do not re-ask): No public API to identify the host app. No public API to return to the host app. Feedback: FB22247647. Question (single issue): App Review Guideline 4.4.1 says keyboard extensions must not launch apps other than Settings. Is there any public, App-Review-compliant mechanism for a custom keyboard to request its containing app to activate audio capture for this user-initiated dictation flow? If yes: Which public API / App Intent surface? Is a visible switch to the containing app required? May the audio session continue while the user returns to the host app? May Stop/Cancel commands travel through an App Group while the containing app is backgrounded? Our current policy: Launch uses public NSExtensionContext.open (Debug only). Release has no keyboard path that opens the containing app. Release does allow in-place signaling when the app is already resident (App Group command + Darwin notification; launches nothing). We will not enable Release launch without a written answer naming an allowed public mechanism. App Group payload inventory + retention, Full Access-off QWERTY behavior, onboarding privacy copy. I do not have a focused Xcode sample because this is an API / App Review policy question, not a crash or incorrect return value. The keyboard extension never captures audio. Debug uses public NSExtensionContext.open; Release compiles that path out. I can attach flow diagrams and a device screen recording. Related: FB22247647 (return to host — already answered No; not re-asking).

I am trying to get universal links to work in our app Firefox iOS The Problem: I am not able to get universal links to work for our release app or beta app scheme locally or with a TestFlight build. I am able to get it working on our development scheme with a locally hosted app site association file. I also was able to get it working using our development scheme but setting the bundle id to the release app bundle id. I also built a demo app with the release app id and the release app development certificate. It succeeded there as well. Implementation Steps: Added associated domains entitlement to the production and beta schemes for our main app target (No associated domains entitlements or capabilities added for any extensions) Confirmed that the bundle ids associated with these schemes have the associated domains capability Added applinks:blog.mozilla.org to associated domains list Confirmed in code that user activities are being handled via SceneDelegate.swift Steps to Debug: I have gone through and validated every step in the provided Universal Link Debugging. All were successful: Associated Domains Development -> Diagnostics: Opens Installed App Validate AASA host and applinks match curl -v https://blog.mozilla.org/.well-known/apple-app-site-association returns the expected json file swcutil dl correctly downloads the AASA blob swcutil verify succeeds I have inspected the IPA of our beta build and confirmed the App ID and the associated domains is an entitlement. I have looked at the console logs filtering by swcd. I am not seeing any errors and I see the download for the AASA file kick off: Beginning data task AASA-4BABF039-3C69-4E36-AA4E-ECCDF3D14878 { domain: bl….mo….org, bytes: 0, route: cdn } There is only one error that appears in the console but our app is not enterprise-managed so I assume this is normal. Error getting enterprise-managed associated domains data. If this device is not enterprise-managed, this is normal: Error Domain=SWCErrorDomain Code=1701 "Failed to get associated domain data from ManagedConfiguration framework." UserInfo={NSDebugDescription=Failed to get associated domain data from ManagedConfiguration framework., Line=298, Function=<private>} I have run Sysdiagnos and identified for our App ID: Site/Fmwk Approval: approved I am at a loss as to what is preventing universal links from working even though all validation steps pass.

I’m trying to understand what guarantees CSSearchableIndex batching provides. beginBatch() // submit changes to searchable items (add/update/delete) endBatch(withClientState: newState) Two questions: 1. Persistence before endBatch If the app crashes after submitting changes to searchable items, but before calling endBatch, are those changes guaranteed not to be persisted? If the answer is yes, then the follow-up question is: 2. Atomicity of endBatch When endBatch(withClientState:) succeeds, is the batch atomic with respect to all submitted item changes, and the new client state? In other words, is it guaranteed that: either all submitted item changes and the new client state are persisted, or neither is persisted? Or is there any internal failure scenario in which the batch is only partially persisted – for example, some or all of the item changes persisted, but without the corresponding client state?

Hello! Thanks for helping. This is driving me crazy. Since ios 16 Calendar App is getting notifications from shared calendar in the "inbox" bottom right like crazy. These invite are not related to my personnal calendar. How do I stop these ?? thanks in advance guys I have looked everywhere.

Does anybody know if Apple allows for apps to access a user’s applicationa’ usage data? As a part of an app idea I have I need to see What is the screen time of each user on each app (Not only mine). Is it possible?

Hello, Apple Developer Technical Support directed me to the Developer Forums for clarification on the following Family Controls use case. DTS reference: Case-ID 21723677 I am evaluating an iOS app called “Zone” before beginning full development. I would like to determine whether the proposed architecture is considered permitted individual device management for focus and productivity, or prohibited use “in organizational settings” under Section 3.3.3(P) of the Apple Developer Program License Agreement. Proposed architecture: Zone is offered to companies as a workplace focus and productivity service. The app is installed on an adult employee’s personally owned iPhone. Participation and each Focus Session are voluntary. The employee independently requests Family Controls authorization using individual authorization. Only the employee can select the apps and websites to restrict. Only the employee can start or stop a Focus Session. During the session, Zone applies restrictions locally on that employee’s iPhone using Family Controls and Managed Settings. The employer cannot authorize or revoke Family Controls access. The employer cannot select restricted apps or websites. The employer cannot remotely start, stop, or schedule a Focus Session. The employer cannot remotely manage or control the employee’s device. Zone would not provide the employer with: Screen Time or Device Activity data App or website tokens App usage history Website browsing history Information about attempts to open restricted apps Location, messages, photos, or other personal device information However, Zone would include a company web dashboard. The dashboard would show only an app-generated boolean status for each participating employee: Zone ON: the employee has voluntarily started a Focus Session Zone OFF: the employee has not started a Focus Session This status is generated by the Zone app itself. It is not derived from Screen Time usage data and does not indicate whether the employee actually attempted to use any restricted app or website. My questions are: Would this architecture be considered permitted individual device management for focus and productivity, even though the service is offered through an employer and the employer can see the Zone ON/OFF status? Or would the employer relationship and company dashboard make this prohibited use of Family Controls “in organizational settings”? If sharing the app-generated ON/OFF status with the employer is incompatible with the Family Controls terms, would the use be permitted if Family Controls operated entirely on-device and no Focus Session status or device information were sent to the employer? Is there another Apple-supported framework or architecture recommended for this use case? I understand that final entitlement approval and App Review decisions may depend on the submitted application. I am seeking architectural guidance before investing in implementation. Thank you.

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, I am facing a critical issue where the CallKit provider delegate method provider(_:didActivate:) is intermittently not triggered. This occasionally results in a total loss of audio during some VoIP calls, while other calls work perfectly fine. Here is the sequence of steps I am currently implementing: Report Incoming Call: The app receives a VoIP push notification and reports the call using reportNewIncomingCall(with:update:completion:). Answer Action: The user taps the answer button, and the app processes the CXAnswerCallAction. Configure Audio Session: Inside the provider delegate, I configure the AVAudioSession category and mode (e.g., setting category to .playAndRecord and mode to .voiceChat). Note: As per Apple's guidelines, I do not call setActive(true) manually, expecting CallKit to activate it automatically. Despite following this standard flow, there are times when provider(_:didActivate:) is skipped entirely, meaning the audio engine fails to initialize for that specific call session. We are currently receiving a large volume of user complaints regarding this issue, as it heavily impacts the core calling experience in production. Could an Apple engineer or anyone from the community look into this? Any insights into what might be causing CallKit to occasionally fail to activate the audio session or how to work around this would be highly appreciated. Thank you!