Hi Team, Our universal links were working fine but since last week we are facing issues and when tapping the links outside app it takes to browser and not the app. Apple CDN is returning 404 for our domain and not the contents of AASA file. https://app-site-association.cdn-apple.com/a/v1/app.ooredoo.om sudo swcutil dl -d app.ooredoo.om returns The operation couldn’t be completed. (SWCErrorDomain error 7.) Can we get the exact issue apple is facing to cache the AASA file in CDN. Any server config which we need to do for AASA bot to access the file. Thanks in advance.

I'm using Product.products(for:) to get my auto-renewable subscription on watchOS: let products = try await Product.products(for: [<##Identifier##>]) However, it doesn't return any value, and doesn't throw errors. The console shows an error: Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.billingPlanType], expected: StoreKit.BackingValue) Is this a bug or I did't configure something well? This product has been approved by App Review.

We're using the iOS ibeacon APIs to wake up our app for vehicle bluetooth key and to enable the seamless walk-away features; Does the Measured Power value in the advertising packet affect an app’s background launch? If so, what is the mechanism? If not, what is the actual purpose of this field in Core Location? For different beacon devices/vehicle models, does this value need to be adjusted? For example, we have different vehicle models – should each model set this value based on actual calibration data? Our current understanding: Measured Power is typically used for our APP to do the distance estimation but we are not sure whether the system also uses it as a weighting factor for background wake‑ups or region triggers. We have noticed some discussions in forums about similar scenarios where it is mentioned that Measured Power needs to be set correctly.

Hello AD Forums, I am a member of the ADP and am working on an iOS app for the App Store. My app needs to match the user’s current location to one of Germany’s 400 district-level administrative areas: Landkreise and kreisfreie Städte. In Firebase, each region has a geoTagName field. The app compares the detected location name against this geoTagName to load the correct internal region document. I need to understand the recommended Apple/Core Location field for this use case. My current understanding is: CLPlacemark.administrativeArea usually represents the federal state in Germany, for example “Thüringen” or “Bayern”. CLPlacemark.locality usually represents the city, municipality, or town. CLPlacemark.subAdministrativeArea seems to be the most likely candidate for the German Landkreis / kreisfreie Stadt level. However, I need to know whether CLPlacemark.subAdministrativeArea is the correct and reliable field for identifying German Landkreise and kreisfreie Städte. I also tested Apple Maps Server API /v1/reverseGeocode. For district-level locations in Germany, it often returns values such as: administrativeArea: Thüringen locality: Bad Sulza but no value such as: subAdministrativeArea: Weimarer Land Example coordinate tested: 50.9957525, 11.5129989 My questions are: Is CLPlacemark.subAdministrativeArea the recommended field to identify German Landkreise and kreisfreie Städte in an iOS app? Are there known differences between iOS CLGeocoder.reverseGeocodeLocation and Apple Maps Server API /v1/reverseGeocode regarding subAdministrativeArea? Does Apple provide any official list, dataset, or recommended validation method for the exact district-level names used by Core Location / Apple Maps in Germany? How should an app distinguish cases where a kreisfreie Stadt and a Landkreis have the same name, for example: Stadt Augsburg Landkreis Augsburg Stadt Ansbach Landkreis Ansbach Stadt Aschaffenburg Landkreis Aschaffenburg Should administrativeArea be avoided for this use case because it represents the federal state level in Germany? The goal is to create reliable matching between the Apple/Core Location result and our Firebase geoTagName values. Thank you.

Platform & Versions React Native: 0.85.3 Expo SDK: 56 react-native-iap: 15.3.3 iOS: 18.7.8 Device: iPhone 16 Pro Distribution: TestFlight (distribution: "store" via EAS Build) Problem In a TestFlight build (App Store distribution, not ad-hoc), calling initConnection() from react-native-iap throws a TypeError: "undefined is not a function" on iOS. This happens on every app launch. The error is caught in a try/catch around initConnection() and we never reach getSubscriptions() or purchaseUpdatedListener(). The app never connects to StoreKit. All IAP attempts fail immediately with "Store unavailable." What we've confirmed Sandbox tester account is configured in Settings → App Store → Sandbox Account "Allow Purchases & Renewals" is ON in the Sandbox Testing screen An active sandbox subscription exists (visible in Settings → App Store → Sandbox Account → Subscriptions), meaning StoreKit was reachable at some earlier point react-native-iap is listed in the Expo config plugins in app.json — EAS should be linking StoreKit.framework and adding the com.apple.developer.in-app-payments entitlement Built with --clear-cache to force a clean native project generation All 5 IAP product IDs (2 subscriptions, 3 consumables) are linked to the app version in App Store Connect and are in "Ready to Submit" state ITSAppUsesNonExemptEncryption is set to false in Info.plist Code try { await initConnection(); // throws "undefined is not a function" // never reaches here await getSubscriptions({ skus: ['com.smartailearning.iem.pro.yearly', 'com.smartailearning.iem.pro.monthly'] }); } catch (e) { console.error(e.message); // "undefined is not a function" } Question Is react-native-iap v15 incompatible with React Native 0.85 / Expo SDK 56 on iOS? Is there a known issue with the StoreKit native module not loading in EAS-managed builds? Should we be using StoreKit directly via a custom native module instead?

I’m trying to submit the first release of my iOS app together with the app’s first consumable in-app purchases, and I’m stuck in what looks like an App Store Connect state issue. My app was already rejected by App Review because the in-app purchases did not appear inside the app when the reviewer opened the paywall. Current setup: First app release Current app version page: iOS App Version 1.0.2 Current attached build: 5 App has never been released before 4 consumable IAPs: com.glowup.credits.100 com.glowup.credits.500 com.glowup.credits.1000 com.glowup.credits.2500 What I see in App Store Connect: All 4 IAPs show Waiting for Review On the iOS App Version 1.0.2 page, the In-App Purchases and Subscriptions section does not appear at all Because of that, I cannot explicitly select or attach the IAPs from the version page What I’ve already done: Uploaded a new build and attached build 5 to version 1.0.2 Removed my local StoreKit configuration file so the app now uses live App Store / StoreKit only Confirmed RevenueCat is configured correctly and sees the offering/packages RevenueCat logs show the products exist remotely, but StoreKit cannot fetch any live products and returns an “offerings empty / none of the products could be fetched” type error RevenueCat also reports the products are still in WAITING_FOR_REVIEW My questions: If the IAPs already show Waiting for Review, are they automatically linked to the current app submission? Is it expected that the In-App Purchases and Subscriptions section can disappear from the app version page in this state? For a first-release app that was already rejected, is attaching a new build and clicking Update Review enough, or is there another step required to associate the IAPs with the resubmission? Has anyone seen App Review reject an app for missing IAPs while the IAPs were still pending review and not yet fetchable from StoreKit? Any guidance from someone who has dealt with this exact first-release + first-IAP submission flow would help a lot.

Hey everyone, We're using Push to Start Live Activities in our app (District: Movies Events Dining) where all Live Activities are entirely server-driven. At District, we've taken a unique approach to Live Activities. Since our customers often plan ahead reserving restaurant tables early in the week or booking movies days in advance we needed a way to surface timely, relevant information without requiring the app to be open. We power our Live Activities entirely from the server using Push to Start and Push to Update. This means the Live Activity is initiated and kept up to date by our backend from reservation confirmation all the way to the day of the experience. Whether it's a dining slot or a movie showtime, the Live Activity automatically appears in the notification tray with all relevant details, right when you need it no app launch required. FB Number: FB22062904 Problem: When a Push to Start payload is sent from the server, the user sees an Allow / Don't Allow prompt on their lock screen. If the user ignores this prompt (neither taps Allow nor Don't Allow), the Live Activity card stays stuck in the notification tray permanently with zero way to dismiss it programmatically. This happens because: The activity never officially "starts" on device Activity.end() cannot be called — there's nothing to end Sending an update/end push has no effect dismissal-date is not honoured in the start payload Steps to Reproduce Send a push-to-start APNs payload to a device Do NOT tap Allow or Don't Allow on the prompt Observe — card stays in notification tray indefinitely Send an end push from server — no effect Current Payload { "aps": { "timestamp": 1234567890, "event": "start", "alert": { "title": "Your table is reserved", "body": "Tap to view your reservation" }, "content-state": { ... }, "attributes-type": "ReservationActivityAttributes", "attributes": { ... } // ❌ dismissal-date has no effect here } } Expected Behaviour dismissal-date should be honoured in the push-to-start payload, so that if the user ignores the prompt, the notification auto-dismisses after the specified time — consistent with how standard Live Activity expiry works. Suggested Fix { "aps": { "timestamp": 1234567890, "event": "start", "content-state": { ... }, "dismissal-date": 1234568490 // ✅ honour this } } Impact This affects any app using server-driven Live Activities — dining reservations, movie bookings, food delivery, ride hailing, ticketing etc. Without this, there is no way to prevent permanent notification tray pollution for users who ignore the Allow prompt. Has anyone found a workaround for this? Would love to know if others are hitting the same issue.

I'm debugging the following kernel panic to do with my custom filesystem KEXT: panic(cpu 0 caller 0xfffffe004cae3e24): [kalloc.type.var4.128]: element modified after free (off:96, val:0x00000000ffffffff, sz:128, ptr:0xfffffe2e7c639600) My reading of this is that somewhere in my KEXT I'm holding a reference 0xfffffe2e7c639600 to a 128 byte zone that wrote 0x00000000ffffffff at offset 96 after that particular chunk of memory had been released and zeroed out by the kernel. The panic itself is emitted when my KEXT requests the memory chunk that's been tempered with via the following set of calls. zalloc_uaf_panic() __abortlike static void zalloc_uaf_panic(zone_t z, uintptr_t elem, size_t size) { ... (panic)("[%s%s]: element modified after free " "(off:%d, val:0x%016lx, sz:%d, ptr:%p)%s", zone_heap_name(z), zone_name(z), first_offs, first_bits, esize, (void *)elem, buf); ... } zalloc_validate_element() static void zalloc_validate_element( zone_t zone, vm_offset_t elem, vm_size_t size, zalloc_flags_t flags) { ... if (memcmp_zero_ptr_aligned((void *)elem, size)) { zalloc_uaf_panic(zone, elem, size); } ... } The panic is triggered if memcmp_zero_ptr_aligned(), which is implemented in assembly, detects that an n-sized chunk of memory has been written after being free'd. /* memcmp_zero_ptr_aligned() checks string s of n bytes contains all zeros. * Address and size of the string s must be pointer-aligned. * Return 0 if true, 1 otherwise. Also return 0 if n is 0. */ extern int memcmp_zero_ptr_aligned(const void *s, size_t n); Normally, KASAN would be resorted to to aid with that. The KDK README states that KASAN kernels won't load on Apple Silicon. Attempting to follow the instructions given in the README for Intel-based machines does result in a failure for me on Apple Silicon. I stumbled on the Pishi project. But the custom boot kernel collection that gets created doesn't have any of the KEXTs that were specified to kmutil(8) via the --explicit-only flag, so it can't be instrumented in Ghidra. Which is confirmed as well by running: % kmutil inspect -B boot.kc.kasan boot kernel collection at /Users/user/boot.kc.kasan (AEB8F757-E770-8195-458D-B87CADCAB062): Extension Information: I'd appreciate any pointers on how to tackle UAFs in kernel space.

SUMMARY iOS16 Beta system local network permission pop-up alert does not display STEPS TO REPRODUCE Install My App for the first time on iOS16 Beta system devices Open the My App and you will first see the local network permissions introduction page On this page we will send UDP broadcast packets RESULTS The user should then see the local network permission authorization pop-up alert，but there is no actual popup in iOS16Beta，but it works fine on the previous version of iOS system NOTES On the previous version of iOS system, by sending UDP broadcast, the local network permission authorization pop-up alert can be triggered normally, but in iOS16Beta, the pop-up alert will not appear, and the local network permission switch will not appear in the App-related system settings. I don't know how to deal with this problem. I have tried many methods and it doesn't work. Can someone help me.

Problem description Since macOS Sequoia, our users have experienced issues with multicast traffic in our macOS app. Regularly, the app starts but cannot receive multicast, or multicast eventually stops mid-execution. The app sometimes asks again for Local Network permission, while it was already allowed so. Several versions of our app on a single machine are sometimes (but not always) shown as different instances in the System Settings > Privacy & Security > Local Network list. And when several instances are shown in that list, disabling one disables all of them, but it does not actually forbids the app from receiving multicast traffic. All of those issues are experienced by an increasing number of users after they update their system from macOS 14 to macOS 15 or 26, and many of them have reported networking issues during production-critical moments. We haven't been able to find the root cause of those issues, so we built a simple test app, called "FM Mac App Test", that can reproduce multicast issues. This app creates a GCDAsyncUdpSocket socket to receive multicast packets from a piece of hardware we also develop, and displays a simple UI showing if such packets are received. The app is entitled with "Custom Network Protocol", is built against x86_64 and arm64, and is archived (signed and notarized). We can share the source code if requested. Out of the many issues our main app exhibits, the test app showcases some: The app asks several times for Local Network permission, even after being allowed so previously. After allowing the app's Local Network and rebooting the machine, the System Settings > Privacy & Security > Local Network does not show the app, and the app asks again for Local Network access. The app shows a different Local Network Usage Description than in the project's plist. Several versions of the app appear as different instances in the Privacy list, and behave strangely. Toggling on or off one instance toggles the others. Only one version of the app seems affected by the setting, the other versions always seem to have access to Local Network even when the toggle is set to off. We even did see messages from different app versions in different user accounts. This seems to contradicts Apple's documentation that states user accounts have independent Privacy settings. Can you help us understand what we are missing (in terms of build settings, entitlements, proper archiving...) so our app conforms to what macOS expects for proper Local Network behavior? Related material Local Network Privacy breaks Application: this issue seemed related to ours, but the fix was to ensure different versions of the app have different UUIDs. We ensured that ourselves, to no improvement. Local Network FAQ Technote TN3179 Steps to Reproduce Test App is developed on Xcode 15.4 (15F31d) on macOS 14.5 (23F79), and runs on macOS 26.0.1 (25A362). We can share the source code if requested. On a clean install of macOS Tahoe (our test setup used macOS 26.0.1 on a Mac mini M2 8GB), we upload the app (version 5.1). We run the app, make sure the selected NIC is the proper one, and open the multicast socket. The app asks us to allow Local Network, we allow it. The alert shows a different Local Network Usage Description than the one we set in our project's plist. The app properly shows packets are received from the console on our LAN. We check the list in System Settings > Privacy & Security > Local Network, it includes our app properly allowed. We then reboot the machine. After reboot, the same list does not show the app anymore. We run the app, it asks again about Local Network access (still with incorrect Usage Description). We allow it again, but no console packet is received yet. Only after closing and reopening the socket are the console packets received. After a 2nd reboot, the System Settings > Privacy & Security > Local Network list shows correctly the app. The app seems to now run fine. We then upload an updated version of the same app (5.2), also built and notarized. The 2nd version is simulating when we send different versions of our main app to our users. The updated version has a different UUID than the 1st version. The updated version also asks for Local Network access, this time with proper Usage Description. A 3rd updated version of the app (5.3, also with unique UUID) behaves the same. The System Settings > Privacy & Security > Local Network list shows three instances of the app. We toggle off one of the app, all of them toggle off. The 1st version of the app (5.1) does not have local network access anymore, but both 2nd and 3rd versions do, while their toggle button seems off. We toggle on one of the app, all of them toggle on. All 3 versions have local network access.

Description of the Issue: We are experiencing intermittent, severe latency spikes during cellular data transmission (specifically with MQTT Publish) on iPhone 17 devices. Through internal testing and cross-referencing with similar user reports online, we suspect this is caused by an aggressive power-saving or sleep mechanism in the cellular modem/iOS network stack when traffic is sporadic or low-frequency. Steps to Reproduce / Observations: Establish an MQTT connection over a cellular network (5G/LTE) on an iPhone 17. Publish messages at irregular or low-frequency intervals (e.g., sporadic IoT data transmission). Result: Severe latency spikes occur intermittently during transmission. Diagnostic Findings & Documented Workarounds: Workaround 1 (Constant Traffic): If we connect a secondary device (e.g., a PC) to the iPhone 17's Personal Hotspot and run a continuous background ping (with a 10ms interval), the MQTT latency spikes disappear completely. This high-frequency traffic prevents the device/modem from dropping into power-save mode. Workaround 2 (VPN Tunnel): Utilizing a VPN profile (such as Cloudflare's 1.1.1.1 app) significantly mitigates the issue. We suspect this is due to either the VPN's background keep-alive packets maintaining the active state of the modem, or iOS applying a less aggressive power-saving policy to active VPN interfaces. System Environment: Device: iPhone 17 series OS: iOS 19 (or specify your current version) Network: Cellular (5G/LTE) Questions Regarding Temporary Workarounds & Mitigations: To unblock our current development and ensure a reliable user experience before an official OS-level fix is deployed, we would highly appreciate Apple's technical guidance on the following questions: Recommended Keep-Alive Mechanism: Since higher frequency traffic effectively prevents the modem from entering power-save mode, does iOS have a recommended, power-efficient way for an application to maintain an active cellular network state (e.g., recommended TCP/MQTT keep-alive intervals or NWPathEvaluator configurations) without being suspended or penalized by the system? Network Optimization APIs: Are there specific Network Framework APIs (Network.framework) or socket configuration flags (such as Multipath TCP, or Quality of Service (QoS) flags like Background vs Default) that can signal to the iOS kernel to apply a less aggressive power-saving policy on the active cellular interface? Background Execution Policy: For IoT applications that need to publish MQTT data seamlessly while running in the background, what is the best practice to prevent the cellular link from dropping into deep sleep mode? We would appreciate it if the Apple Network/CoreOS engineering team could look into this cellular power management behavior. Thank you for your support.

I have a MultipeerConnectivity-based app where a view controller is opened for a specific connected peer. When data arrives for that peer, my networking manager posts a Notification whose userInfo carries the sender's MCPeerID, and the view controller filters updates like this: guard let incomingPeerID = userInfo["peerID"] as? MCPeerID, incomingPeerID == self.peerID else { return } // apply update…

My app is sandboxed and for one feature listens for an incoming connection on a user selected port. When the firewall is enabled and block incoming (all, this app, or signed apps) is enabled, I want to be able to not offer this feature with a brief explanation. I tried using /usr/libexec/ApplicationFirewall/socketfilterfw but that fails when used in a sandboxed app. I have an XPC module, which is also sandboxed, and the call fails there as well. If I remove the sandbox from the XPC then the call succeeds but then is unable to communicate with the main app. Is there an API to determine if the firewall is enabled and all connections blocked? I've submitted a Feedback request (FB23378402) as well.

With the 27 OSes using UserDefaults.standard.integer(forKey: ) can cause a crash with EXC_BAD_ACCESS (code=1, address=0x0) It has been seen on a Multiplatform app, up to now tested on iOS/iPadOS and visionOS 27 Beta 1. In our code we use UserDefaults.standard.integer(forKey: ) from a singleton called during the SwiftUI app init(), and we don't know yet if this is the only moment there is a crash as we can't go farther. The API should return 0 if it can't get a value. There is no reason the app should crash if the API conforms to its contract. Running the same code from Xcode on iOS 26 runs it without issue. FeedBack FB23310748

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

Hy my name is max i would need help lurning i‘m trying to get developer mods to make apps

High Power Mode setting is not applied by powerd (possibly related to migrateenergyprefs) Summary On a MacBook Pro (14-inch, M5 Max), enabling High Power Mode in System Settings has no effect on the actual power governor. The system continues to run at the default (Automatic-equivalent) power ceiling regardless of the High Power Mode setting. The same symptom has been reproduced on a different physical machine, a MacBook Pro (M4 Max), ruling out a single hardware defect. Environment Affected device: MacBook Pro 14-inch (Apple M5 Max, 12P+6S+40GPU, 128GB RAM) macOS version: macOS 26.5.1 (Build 25F80) Migration history: Intel Mac → MacBook Air (M2) → MacBook Pro (M4 Max) → MacBook Pro (M5 Max), using Migration Assistant at each step Same symptom also confirmed on the MacBook Pro (M4 Max), which had the same migration history Symptom Selecting "High Power" under System Settings → Battery → Power Mode has no effect on system_profiler SPPowerDataType, which always reports High Power Mode: No. pmset -g custom correctly shows powermode 2 (the High Power equivalent) for AC Power, confirming the user-facing setting is being written correctly. Low Power Mode in the same system_profiler output correctly toggles between Yes/No depending on the UI selection (Automatic / Low Power / High Power). Only High Power Mode fails to track the UI selection. Benchmarking with 3DMark Steel Nomad Stress Test (Metal API) reproduces the score pattern that third-party reviews report for High Power Mode OFF (stabilized score ~3100–3400), rather than the ON pattern reported for the same model (~3600+). This confirms the issue is not just cosmetic (a wrong status string) but reflects an actual difference in the power ceiling being enforced. Investigation steps taken 1. Preference file inspection Inspected /Library/Preferences/com.apple.PowerManagement.<UUID>.plist. Multiple UUID-keyed files exist, each corresponding to a previously used device (identified by battery serial number in the BatteryWarn key). All of them contained HighPowerMode = 0, including the file matching the current machine's serial number. The MacBook Air (M2) used earlier in this device's migration history does not support High Power Mode at all. It's suspected that HighPowerMode = 0 originated from that device and was carried forward through subsequent Migration Assistant transfers to devices that do support the feature, without ever being correctly re-evaluated. 2. Direct write test Used defaults write to directly set HighPowerMode = 1 in the relevant plist. system_profiler then reported High Power Mode: Yes, and this persisted across a reboot. However, a subsequent benchmark run showed no improvement — powermetrics Combined Power remained in the 27–30W range, and the Steel Nomad Stress Test stabilized score actually dropped slightly (~3134 average over the last 10 loops). This indicates the displayed value is decoupled from the actual power governor state. 3. File deletion / regeneration test Deleted the UUID-keyed plist (after backing it up) and let powerd regenerate it from scratch. The newly generated file still showed HighPowerMode stuck at No and unresponsive to UI changes, while LowPowerMode continued to track UI changes correctly. The same test was repeated with the non-UUID common file (com.apple.PowerManagement.plist), with no change in behavior. This rules out stale/corrupted preference data as the root cause. 4. Binary-level investigation Searched the system for files containing the string "HighPowerMode". Aside from unified logging symbol caches (uuidtext, not relevant), the following were found: /System/Library/CoreServices/powerd.bundle/powerd (Apple-signed, Signed Time: Apr 19, 2026, Platform identifier 26) /System/Library/CoreServices/powerd.bundle/migrateenergyprefs.bundle/ (com.apple.migrateenergyprefs, LSMinimumSystemVersion 26.5, built with Xcode 2630) /System/Library/SystemProfiler/SPPowerReporter.spreporter/ /System/Library/ExtensionKit/Extensions/BatterySettingsIntentsExtension.appex/ The presence of a dedicated com.apple.migrateenergyprefs component strongly suggests this is the code path responsible for carrying power preferences across device migrations. We suspect this migration logic fails to correctly initialize or re-evaluate HighPowerMode when migrating from a device that doesn't support the feature to one that does. Reproducibility Reproduced on two distinct physical machines (M4 Max and M5 Max), making a hardware fault unlikely. Reproduced after deleting and regenerating the preference files, ruling out simple cache corruption. Reproduced after a full reboot, ruling out a transient in-memory state issue alone. Impact Because High Power Mode is not actually engaged, sustained CPU/GPU performance under heavy load is capped at a lower power ceiling than intended, resulting in measurably lower benchmark scores and sustained performance compared to the documented behavior of the same hardware configuration. Questions for Apple Could the com.apple.migrateenergyprefs logic be reviewed for how it handles HighPowerMode when migrating from a device that does not support the feature (e.g., MacBook Air M2) to one that does? Is there a known issue with HighPowerMode specifically (as opposed to LowPowerMode, which behaves correctly) not being written back by powerd in response to UI changes? Are there other users with a similar multi-generation Migration Assistant history reporting the same symptom? Happy to provide a sysdiagnose or additional logs if useful.

I saw there is a new es_new_descendants_client() function in Endpoint Security, with very interesting details: no TCC approval required no root privileges required which makes it very different from how we've known Endpoint Security so far. What is the real life use of this client? First, I thought it would be good to monitor processes I launch from my central application - but I won't fork() or exec() other apps - I will ask launchd to open them (NSWorkspace...), so they won't be descendants of my Endpoint Security client containing process. Not to mention, I don't understand how this aligns with the entitlement being attachable only to system(?) extensions. Or, can I now add this entitlement to an application? The dropping of root privilege as a requirement seems like this entitlement could be attached to regular apps. Or it can only be attached to a launchd agent, rather than a daemon? I haven't seen any pointers in Endpoint Security documentation other than this function's documentation. A tutorial would be very nice to have. Thanks in advance!

Hello, Quick clarification regarding age ratings: If a user is 17 years old and wants to download a 16+ app, is parental approval required? Or is parental consent only needed if the app’s rating does not match (or exceeds) the user’s actual age? Also, is this fully enforced by Apple, or is it up to developers how to implement these checks? Thanks!

Hello there, I am trying to clarify whether iOS 26 changed the expected Phone Recents behavior for CallKit calls reported with CXHandle.generic. On iOS 18 and earlier, CallKit calls reported with: CXHandle(type: .generic, value: <stable custom identifier>) were grouped and displayed in Phone Recents based on the stable handle value. The details/history screen for a Recents entry showed calls for that same handle value. On iOS 26, the same approach no longer appears to work the same way. Observed behavior on iOS 26 I tested multiple stable CXHandle.generic values. The Recents rows are created, but when opening the details/history screen for one Recents entry, the history shows all calls, not only calls for the selected generic handle value. I also tested other handle types: CXHandle(type: .emailAddress, value: <stable email-like identifier>) works as expected: Recents grouping and the details/history screen are isolated to that handle value. CXHandle(type: .phoneNumber, value: <phone number>) also works as expected for real phone-number-style identities: Recents grouping and the details/history screen are isolated to that phone number. CXHandle(type: .generic, value: <stable custom identifier>) does not work the same way on iOS 26: the details/history screen is not isolated to that generic handle value and instead shows all calls. Questions Is CXHandle.generic still intended to be a supported identity for Phone Recents grouping and the details/history screen on iOS 26? Given that .emailAddress and .phoneNumber handles appear to isolate history correctly, is .generic intentionally treated differently by the iOS 26 Phone app, or is this a regression? Did iOS 26 change Phone Recents/details matching so that CXHandle.generic values are no longer used as isolated per-caller identities? If this behavior is intentional, what handle type should be used for stable non-phone CallKit identities? Is using CXHandle(type: .emailAddress, value: "@example.invalid") an acceptable supported approach for stable non-phone identities, if the value is not a real user email address? Is there documentation describing the iOS 26 Phone Recents identity-matching behavior for CallKit calls? Minimal repro Configure a CXProvider with calls included in Recents. Report several CallKit calls using different stable generic handles, for example: CXHandle(type: .generic, value: "app-target-1") CXHandle(type: .generic, value: "app-target-2") End the calls. Open Phone Recents on iOS 26. Open the details/history screen for one of the Recents entries. Expected result: The details/history screen shows only calls for the selected generic handle value. Actual result: The details/history screen shows all calls. Could you clarify whether this is expected behavior on iOS 26, a regression, or an unsupported use of CXHandle.generic? Thank you.