The documentation for NSURL -URLByAppendingPathComponent: states: "Returns a new URL by appending a path component to the original URL." Path component is singular. But this "works" : NSURL *testURL = [applicationsDirectory URLByAppendingPathComponent:@"Evil/../../" isDirectory:YES]; So my questions are: One) Was it always this way? I can't recall if it was like this before the Foundation rewrite and I just never stumbled across? and Two) Is it intended behavior? The API seems to suggest that you append one path component on the url with this method. But I guess you can append as many as you want?

Hi, I’m looking for clarification on TN3134: Network Extension provider deployment, specifically iOS deployment requirements for: packet tunnel provider DNS proxy provider From the documentation: Packet Tunnel Provider App extension (min iOS 9.0): per-app mode requires a managed device DNS Proxy Provider App extension (min iOS 11.0): supervised devices only App extension (min iOS 11.0): per-app mode requires managed devices Issue I implemented a DNS proxy using NEDNSProxyManager. Works as expected in debug builds on a local device Fails to configure when distributed via TestFlight Console Output (TestFlight build) error 10:05:39.872258-0500 nehelper The production version of *** is not allowed to create DNS proxy configurations. Use MDM to create DNS Proxy configurations for the production version of ***. Question Is it possible to distribute a DNS proxy provider for use on non-MDM / non-supervised devices? If not: Is the limitation strictly enforced at distribution/runtime? Is a packet tunnel provider the only viable alternative for App Store distribution? There is a lot of different VPN apps on the App Store that appear to work out of the box without MDM or supervision, which suggests they are using a different deployment model. Thank you for any clarification or guidance!

Hi, I’m seeing a reproducible issue with local StoreKit testing on the iOS 26.4 Simulator. Environment: Xcode 17E192 iOS 26.4 Simulator StoreKit Testing in Xcode using a .storekit configuration file attached to the Run scheme SubscriptionStoreView StoreKit 2 What happens: Tapping a subscription purchase button starts the flow, but the purchase immediately returns: StoreKit.Product.PurchaseResult.userCancelled No purchase dialog appears. No transaction is created. Debug > StoreKit > Manage Transactions remains empty. Transaction.updates, Transaction.unfinished, and Transaction.currentEntitlements do not produce any new purchase-related events. Important detail: This happens not only in my app, but also in Apple’s sample: Implementing a store in your app using the StoreKit API I tested the sample with its own .storekit file and shared scheme. The sample shows the same behavior on iOS 26.4 Simulator. On iOS 26.2 Simulator: The purchase flow does react differently. I see the warning: Making a purchase without listening for transaction updates risks missing successful purchases. Create a Task to iterate Transaction.updates at launch. So 26.2 does not appear completely broken in the same way. What I already checked: The .storekit file is attached to the active Run scheme. Simulated failures are disabled: _disableDialogs = false _failTransactionsEnabled = false _storeKitErrors = [] I tried both SubscriptionStoreView(groupID:) and SubscriptionStoreView(productIDs:) I erased app data, reinstalled, and tested on a fresh simulator. Manage Transactions has no records at all. My own app and Apple’s sample both reproduce the issue on 26.4 Simulator. This makes me suspect a simulator/runtime regression in local StoreKit testing on iOS 26.4 rather than an app-specific bug. Has anyone else seen this on iOS 26.4 Simulator? Is this a known issue with StoreKit Testing in Xcode on the 26.4 runtime? If needed, I can provide the exact simulator/Xcode versions and a minimal repro using Apple’s sample project.

I’m building an iOS app that uses FamilyControls + ManagedSettings + DeviceActivity. Goal: temporarily “unlock” a shielded app for N minutes, then automatically re-apply the shield when the timer expires. What I do: In the main app, when user picks an expiry (e.g. 15 min, 30 min). I start a non-repeating DeviceActivity schedule and remove the app’s ApplicationToken from ManagedSettingsStore().shield.applications. I also store activeUnlockBundleID etc. in an App Group so the DeviceActivityMonitor extension can re-lock at the end. Expected: DeviceActivityMonitor.intervalDidEnd(for:) is invoked when the non-repeating interval ends, and I re-add the token to the shield set. Actual: The app does not re-lock when the interval expires. I added OS logs as well as “debug local notifications” from the DeviceActivityMonitor extension in: init() intervalDidStart intervalDidEnd eventDidReachThreshold None of these logs or notifications ever appear, which suggests the extension is never invoked (or cannot schedule local notifications or OS logs). Environment: Device: iPhone 17 Pro iOS 26.3.1 Xcode 26.4 Running on a physical device Notification permissions for the app: granted App + extensions are in the same App Group entitlement. Extension Info.plist has: NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = $(PRODUCT_MODULE_NAME).DeviceActivityMonitorExtension Questions: Are there known limitations/requirements for DeviceActivityMonitor callbacks where intervalDidEnd doesn't to fire? Is posting local notifications / OS Logs from a DeviceActivityMonitor extension supported/reliable? If not, what’s the recommended way to verify the extension is invoked? If this looks like a platform bug, should I file Feedback Assistant? If so, what logs/artifacts are most useful?

Hi everyone, I’m the developer of one sec, an app used by a large number of users globally to reduce time spent on social media and to build healthier digital habits. Because of this, we rely heavily on Apple’s Screen Time / DeviceActivity / FamilyControls, ManagedSettings APIs – and unfortunately, we’re seeing increasingly severe issues in production that directly impact hundreds of thousands of real iOS users. During the past years, we have been busy filing dozens of feedback requests for different Screen Time issues – and there has been no response from Apple at all. Developer Relations might be able to "confirm" that the bugs are present and that they ended up with the right team – but they are never addressed, neither are workarounds provided. Instead, the situation gets worse and worse. iOS 26 introduced a series of heavy regressions (which have been reported via Apple’s official bug report tool "Feedback Assistant" on iOS 26 beta 1 in June 2025 – and have not been addressed 10 Months later). This is very frustrating for us as developers, but also for our end-users who run into these issues every day. In the end this impacts our ability to build an amazing product and hurts revenue (which affects both us and Apple). 1. DeviceActivity thresholds are not firing at all This affects both: our app’s usage of the API and Apple’s own Screen Time limits Radars: FB22304617, FB20526837, FB15491936, FB12195437, FB15663329, FB18198691, FB18289475, FB19827144 2. Screen Time usage data is clearly corrupted Websites showing hundreds of hours per week Up to ~20 hours per day of usage reported for a single domain Radars: FB22304617, FB17777429, FB18464235 3. DeviceActivity thresholds reaching threshold immediately Newly introduced with iOS 26 Reported on iOS 26 beta 1 in June No response so far / no workaround DeviceActivity calls didReachThreshold immediately after creating the DeviceActivityEvent – instead of waiting till the defined threshold is actually reached. Radars: FB13696022, FB18351583, FB21320644, FB18927456, FB18061981 4. Randomly Randomizing ApplicationTokens From time to time, and without consistency, Screen Time suddenly provides new, random, unknown tokens to my app in the ShieldConfigurationDataSource and ShieldActionDelegate. This has been reported on many times before here on the dev forms, many many years back already: https://forums.developer.apple.com/forums/thread/756440 https://forums.developer.apple.com/forums/thread/758325 https://forums.developer.apple.com/forums/thread/758325?answerId=793267022#793267022 Radars: FB14082790 and FB18764644 5. Moving Tokens from one ManagedSettingsStore to Another Removing an ApplicationToken from one SettingsStore and then adding it to another while the target app remains in foreground leads to the re-use of the ShieldConfiguration. Which can be wrong in many scenarios. It is not possible to request a re-request of the ShieldConfiguration in that scenario. Radar: FB14237883 6. Unable to Open Parent App (one sec) from Shield Many times, when a target app is blocked by a shield, the user wants to perform some action (e.g. to unlock more time for the target app via an intervention). That means, that somehow I have to forward the user from a ShieldActionDelegate back into my target app. Unfortunately, there’s no API for that. Many apps on the App Store rely on private API to achieve that, but that’s too risky for a popular app like one sec. Radar: FB15079668 7. Unable to Open Target App from an ApplicationToken When a user has completed an intervention within one sec, and they indend to to continue to the target app, there is no way that one sec can open the target app just from the token alone. Sure, there are URL schemes, but that means the user has to manually assign URL schemes to each ApplicationToken. That is not a very user friendly process (and in many cases impossible, because not every app registers URL schemes). It would be better if there was a way that my app could open a target app directly from an ApplicationToken, e.g. via an AppIntent that can be run on a button press. This way, the selected apps would remain fully private while still offering advanced functionality: struct OpenTargetAppIntent: AppIntent, OpenAppFromApplicationTokenIntent { func perform() { return .result(openAppFromApplicationToken: applicationToken) } } Radar: FB15500695 Summary Thanks a lot for taking the time to read my feedback. If you have any questions, please feel free to reach out to me any time. I’m always happy to provide more details, logs, and steps to reproduce in my radars / feedback requests or in-person in Cupertino. It would be extremely helpful if someone from the Screen Time / DeviceActivity engineering team could: Take a look at the listed radars. Work on bug fixes and be transparent about when fixes will be shipped. Provide workarounds in the meantime. We genuinely want to build great, reliable experiences on top of Screen Time – but in its current state, it’s becoming very difficult to depend on. – Frederik

[FB22327481] We are observing a rare issue where alarms scheduled using AlarmKit occasionally fire exactly at 12:00 AM, even though the alarm was scheduled for a different time. This issue happens only for a very small number of users (for example, 1–2 users per several thousand per day), but multiple reports confirm that the alarm goes off exactly at midnight. We also found that other developers are experiencing the same issue: https://developer.apple.com/forums/thread/815714 Observed behavior For a small number of users: Alarm fires at exactly 00:00 (midnight) This happens even when the scheduled alarm time is something like 7:30 AM Happens rarely Hard to reproduce internally Appears to happen only on real devices in production Additional notes We are using AlarmKit fixed schedules (not relative) Dates passed to AlarmKit are correct at scheduling time We do not intentionally create midnight alarms Issue seems random Question Are there any known limitations or edge cases with AlarmKit fixed schedules that could cause alarms to fire at midnight? For example: Invalid date fallback? Schedule expiration fallback? Time zone changes? Background refresh timing? Maximum schedule window? Any guidance would be appreciated, as this is affecting real users but is difficult to reproduce.

On iOS 26.3.1, deviceactivityd produces zero log output and never wakes a DeviceActivityMonitor extension at the scheduled time, even when the schedule is successfully registered. The extension's intervalDidStart(for:) method is never called. Steps to Reproduce: Create an app with a DeviceActivityMonitor extension subclass Add the com.apple.developer.family-controls entitlement to both the main app and extension targets Add a shared App Group entitlement to both targets In the main app, call: let center = DeviceActivityCenter() center.stopMonitoring([.myActivity]) let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 17, minute: 30), intervalEnd: DateComponents(hour: 17, minute: 45), repeats: true ) try center.startMonitoring(.myActivity, during: schedule) Verify registration succeeds: DeviceActivityCenter().activities.contains(.myActivity) returns true Background the app completely and wait for the intervalStart time (5:30 PM in this example) Expected Result: intervalDidStart(for:) is called in the extension process at 5:30 PM. ManagedSettings shields are applied without any user interaction. Actual Result: intervalDidStart(for:) is never called. No extension process is launched. Filtering Console.app for deviceactivityd on the device returns 0 messages — the daemon produces no logs whatsoever despite an active registered schedule. Shields are never applied. Additional Evidence: Third-party apps using DeviceActivity (e.g. Prayer Lock) successfully apply shields at scheduled times on the same device and OS version, confirming the framework is not universally broken Filtering Console.app for the app's bundle ID at the trigger time shows the main app process applying shields via a UNCalendarNotificationTrigger fallback — but no extension process activity DeviceActivityCenter().activities correctly lists the registered activity before and after the trigger time, confirming the schedule registration API is functional Environment: iOS 26.3.1 Physical device (required for FamilyControls) Development-signed build with com.apple.developer.family-controls entitlement provisioned App Group shared between main app and extension targets

I’m running into a hardware reality. MEMS sensor thermal drift. If a user zeroes out the tilt indoors at 20°C and then takes the phone outside in the cold, the accelerometer baseline shifts just enough as the device cools to throw off the readings. I want to apply a simple thermal compensation curve to the CoreMotion data to keep the "zero" perfectly level regardless of the weather. However, ProcessInfo.thermalState only gives broad buckets (nominal, fair, etc.) which doesn't help me calculate a continuous offset for a phone cooling down degree by degree. Is there any public API, or even a proxy metric, that can give me a rough battery or internal temperature integer? I don’t need high resolution decimals. Just a general device temp to offset the hardware drift. Any undocumented tricks or proxy metrics anyone has used to handle this?

Good day) Colleagues, please tell me how can I change the notification on the locked screen "pass changed" in PKPASS when changing several fields? Thank you very much for your answer

Problem: custom icons for folder aliases not showing System drive and external drive custom alias folder icons don't showup on desktop or external drive (OS14.6 Sonoma 2023); they only show-up as plain folders or with an odd document icon. Alias doesn't connect to image; however it's there, easily accessible via spacebar. Finder doesn't save the custom icon to the alias. See below for workaround. Summary: I have custom alias icons on my desktop linking to their source files on the system drive and external drive.. however they do not display the custom icon. After upgrading from OS10.14 Mojave to OS14.6 Sonoma 2023, system drive & external drive custom alias icons no longer display the icon on either drive (there is a work-around for Mojave; see history section). Personal impact: hampered file navigation and workflow; I'm lost, can't tell where anything is; not having my icons makes it especially difficult to navigate my files and hampers my workflow significantly. Desired outcome: all custom icons for folder aliases linking to source files (on system & external drives) appear on the desktop, and in all directories on system & external drives (including encrypted external drives). Status.. August 2024: called apple support, they said there is no solution, and there are no plans to fix it, and no plans for a fix in OS 15 Sequoia (in public beta now) Action: ❯ leave feedback at https://www.apple.com/feedback/macos/ ❯ join this campaign to fix this once and for all! -- After 20 years of dealing with this issue.. we need to fix this. History: ▪ OS 10.14 Mojave 2018: external drive alias icons don't work; because upon startup, the icon images for these files disappear; because when system starts it loads the system drive icons but not the external drive icons because it's password protected, hence icon information does not get loaded; alias icons can't connect with unmounted external drive @ boot; however it's there, easily accessible via spacebar the FIX: alias the icons on the desktop each time after boot, however the names are altered ▪ OS X 10.11 El Cap 2015: drag the icons to a folder then back to desktop.. sometimes this works I stayed on OS9 as long as possible because of the OS10 icon problem ▪ OS 9: all custom alias folder icons worked fine Givens: space bar has fast access to icon -highlight alias and press space bar -- seems that it would be a simple solution, since the image is there -- get info for alias also has the image in preview How to make a custom icon: open a pic (typically from a screenshot; .png), select image with cursor with shift key down (for a perfect square), copy ⌘C, click target folder, get info ⌘I, click on folder icon on top left corner, paste ⌘V Fix -- How? --make a solution approach for a macOS dev? some bash process to link to icon; how to access icon Swift? process to renew the alias icon process goes through all desktop icons.. fixes them; new icon, correct name routine where all icons on desktop link to their files easily making a new alias.. as easy as making a regular alias; cammand L, etc make alias search for the image app that makes alias create custom desktop.. a GUI w links -- INTERIM FIX / WORKAROUND create a new folder on your desktop, name it, place it's alias inside the folder, fix the icon, when you open the desktop folder, you will then have to click on the alias --this is very time-consuming and tedious note: there may be easier options for OSs prior to Sonoma; review History section workflow: symbol note: ⇧ shift, ⌃ control, ⌥ option, ⌘ cammand create new folder on desktop ⌘⇧N , name it.. if the name is already taken by the alias, change the alias's name; for example.. alias it ⌘^A click on this new folder then ⌘I (get info) click on the alias, open source location ⌘R (or ⌘⌥^A on older OSs), click on source file (if not highlighted) then ⌘I (get info) , click on folder icon on top left corner, copy ⌘C click on the get-info window you opened for the new folder, click on folder icon on top left corner, paste ⌘V (if not working see ¹ below), close each of these windows with ⌘W place the associated aliased folder into the new folder you can also do this in groups of folders (3-6 seems is optimal).. for example.. move 3 alias icons to clear area on desktop, create 3 new folders and place them below the aliases, select all aliases and ⌘C, open a text document and ⌘V, fix names & name new folders, select new folders, ⌘I, select target aliases, ⌘R, ⌘I for each, move the alias windows below the new folder windows, copy/paste icons from source to new file, close these windows, place alias folders into new folders ¹ if paste function not working.. move on to the next folder and come back.. it can be moody, if it's not working at all.. restart the computer note2: some icons now have a yellow streak at the bottom let us know if you have any solutions or workarounds, or can code this (provide a script or app)

We are seeing an issue after updating iPads to iPadOS 26.4 where cellular service is lost until network settings are reset. Environment: Devices managed via Apple Business Manager and Microsoft Intune Carrier: Verizon Confirmed affected devices: iPad (9th generation) eSIM Behavior: After update, device shows no cellular service No prompt to re-activate or re-add the cellular plan The plan appears to still be present on the device Workaround observed: Resetting Network Settings restores service Notes: This does not appear to be a provisioning issue (no need to re-add eSIM) Behavior suggests the cellular/eSIM state may not be initializing correctly after update Toggling Cellular or Airplane mode has not yet been tested for service restoration. We have not yet confirmed whether devices using a physical SIM are affected Still gathering data on scope across additional iPad models Additional observation: We have not observed this behavior on iPhones (e.g., iPhone 16 on iOS 26.4 with LTE remains unaffected) Has anyone else observed similar behavior on iPadOS 26.4, particularly on managed devices or eSIM configurations?

how to disable streamline purchasing, when I click turn off, it show error Streamlined purchasing cannot be turned off because your latest approved binary doesn’t include the required StoreKit APIs My app has subscribe button to click before start to use though not need to login, chatgpt had done the store kit and subscription part, do not understand why it can not turn off streamlined purchasing

Hi, i searched some information about how widgetKit updates widgets using "reloadAllTimelines/reloadAllControls" and i know about daily limit for apps to update their widgets. I only care about how to notify user instantly about vpn status change even if app is terminated and user launch vpn connection from ControlCenter(system widget) or SysSettings, is there a way to update my app's contolCenter widgets from Tunnel if widget and tunnel extensions already have same appGroup defaults?

I have the typical StoreKit 2 manager class, where I check currentEntitlements for subscription. I have filed a feedback (FB22349195), I hope someone can take a look at it. func updateCustomerProductStatus() async { var activeSubscription: String? = nil // BUG: In some cases the currentEntitlements does not emit a transaction until the device is reboot for await result in Transaction.currentEntitlements { print("Found transaction: \(result)") // This print does not appear until a restart! do { let transaction = try checkVerified(result) // Skip revoked transactions if transaction.revocationDate != nil { print("Skipping revoked transaction for \(transaction.productID)") continue } // Skip expired subscriptions if let expirationDate = transaction.expirationDate, expirationDate < Date() { print("Skipping expired subscription for \(transaction.productID)") continue } // Check product type switch transaction.productType { case .autoRenewable: activeSubscription = transaction.productID default: break } } catch { print("Unable to verify transaction: \(error)") } } // Update state once after processing all entitlements self.activeSubscription = activeSubscription print("updateCustomerProductStatus() activeSubscription: \(activeSubscription ?? "nil")") } There is some unexpected behavior where the currentEntitlements does not emit a result until the iPhone device is reboot. This bug appeared in iOS 26.4 (and in the betas).

Hello, I submitted a request for the Family Controls (Distribution) entitlement, but haven't received status update regarding approval/rejection etc. I submitted a previous contact support ticket as well. I'm wondering the timeline and also if my request went through - currently it says 'submitted' but it's remained this way for a while... I've had other developers in communities saying they were approved earlier, so curious if it's an app issue. Thank you

I am seeing an issue with NETransparentProxyProvider where the extension successfully transitions from sleep to wake, but stops receiving handleNewFlow(_:) calls. Only below two methods gets called, We don't apply rules in these methods: override func wake() override func sleep(completionHandler: @escaping () -> Void) This breaking complete proxy workflow as it stops intercepting traffics. We are not observing this issues always. FYI: com.apple.developer.endpoint-security.client is not present in .entitlement file. I am not sure adding this will help. Any possibilities nesessionmanager might fail to re-bind the traffic rules for this extensions? Any thing we can do to avoid this issues?

com.apple.main-thread 0 StarMaker 0x5c40854 _isPlatformVersionAtLeast.cold.2 + 4425680980 1 StarMaker 0x526d278 -[FPRScreenTraceTracker displayLinkStep] + 191 (FPRScreenTraceTracker.m:191) 2 QuartzCore 0xbe924 CA::Display::DisplayLinkItem::dispatch(CA::SignPost::Interval<(CA::SignPost::CAEventCode)835322056>&) + 64 3 QuartzCore 0x9bf38 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 880 4 QuartzCore 0xaf770 CA::Display::DisplayLink::dispatch_deferred_display_links(unsigned int) + 360 5 UIKitCore 0x7dee4 _UIUpdateSequenceRunNext + 128 6 UIKitCore 0x7d374 schedulerStepScheduledMainSectionContinue + 60 7 UpdateCycle 0x1560 UC::DriverCore::continueProcessing() + 84 8 CoreFoundation 0x164cc __CFMachPortPerform + 168 9 CoreFoundation 0x460b0 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION + 60 10 CoreFoundation 0x45fd8 __CFRunLoopDoSource1 + 508 11 CoreFoundation 0x1dc1c __CFRunLoopRun + 2168 12 CoreFoundation 0x1ca6c _CFRunLoopRunSpecificWithOptions + 532 13 GraphicsServices 0x1498 GSEventRunModal + 120 14 UIKitCore 0x9ddf8 -[UIApplication _run] + 792 15 UIKitCore 0x46e54 UIApplicationMain + 336 16 StarMaker 0x50c965c main + 18 (main.m:18) 17 ??? 0x19a9dae28 (缺少) Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x27d30 zorro::KbLog::Loop() + 88 (kblog.cc:88) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8 Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x19a4e4 zorro::ZkbLog::Loop() + 157 (zlog.cc:157) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8 Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x19c4d8 zorro::QosManager::Loop() + 966 (string:966) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8

After implementing the new structured concurrency API's for Network framework, we are noticing a few memory leaks in the Network framework when using API's like onViabilityUpdate and onBetterPathUpdate. Whenever a previously established connection is disconnected, the NWConnection object is never released by the Network framework when we use the 2 API's mentioned. Irrespective of what goes inside these handlers(or leave it empty), the connection object is leaking. If I comment out the handlers, there is no memory leak. Posting this here in the forum to understand if others have encountered similar issues and found a workaround? Raised a feedback assistant request with all the details and a sample app here: FB22339653

Hello, I am the developer of an app called one sec which helps users to spend less time on social media: https://one-sec.app Therefore, we make heavy use of the Screen Time API, and thus ManagedSettings and ShieldActionDelegate. One feature of one sec is the so-called “Doom Scroll Emergency Brake”. This blocks a target app after a certain usage threshold (e.g. 5 minutes) and requires going through an intervention (e.g. breathing exercise) to unlock more time. That added friction makes it very effective in reducing time spent on apps. One thing that is confusing for our users is the way they are prompted to unlock more time, if they want to. They have to: Have Push Notifications enabled for one sec Exempt one sec’s notifications from being delayed by AI prioritization (otherwise they are delayed by ca. 10s) Ensure that push notifications can be delivered during foci. Understand that they have to tap on the notification, which is not very straight-forward because it does not make sense from the user’s UX perspective. This is an artificial limitation of Apple’s screen time framework which has no reason (no security / privacy implications here…). Screenshots of the current flow attached. If would be much more reasonable if there was a new ShieldActionResponse.openParentApp value that can be returned from the completion handler of the ShieldActionDelegate.handle(…) callback. We have seen different apps use private API to achieve this, but we are afraid to do the same to avoid getting banned from the App Store. It would be fair if Apple would level the playground for all apps and offer such an API officially. – Frederik PS: Tracked under FB22347946, FB18846650, FB15500681, FB15079668, FB10393561 (all without responses so far…)

We are developing an MDM agent app that uses FamilyControls with .individual authorization to enforce Screen Time restrictions (app blocking, domain blocking via ManagedSettingsStore and DeviceActivityCenter). The Problem We are actively subscribing to AuthorizationCenter.shared.$authorizationStatus to detect authorization changes. However, when the user revokes the app's FamilyControls authorization through Settings (either via Settings > Screen Time > Apps With Screen Time Access, or Settings > Apps > [Our App]), the publisher does not emit any value. All ManagedSettingsStore restrictions are lifted immediately by the system, but our app receives no notification of this change. The only scenario where the publisher reliably emits is when a debugger is attached (i.e., running directly from Xcode). Without the debugger, the publisher is completely silent — even when the app returns to foreground. Code Example We tried subscribing directly to AuthorizationCenter.shared.$authorizationStatus with no intermediary, exactly as shown in the documentation: AuthorizationCenter.shared.$authorizationStatus .sink { status in print("[DIRECT] authorizationStatus emitted: \(status)") } .store(in: &cancellables) This subscription is set up at app launch and stored in cancellables. The result is the same — the publisher does not emit when the user revokes authorization in Settings without a debugger attached. Documentation Reference The documentation for authorizationStatus states: "The status may change due to external events, such as a child graduating to an adult account, or a parent or guardian changing the status in Settings." And: "The system sets this property only after a call to requestAuthorization(for:) succeeds. It then updates the property until a call to revokeAuthorization(completionHandler:) succeeds or your app exits." This suggests the publisher should emit when the status is changed via Settings, but in our testing it does not — unless a debugger is attached. What We Verified We tested with a development-signed build (which includes the com.apple.developer.family-controls entitlement), launched from Xcode, then disconnected the debugger, killed the app, and relaunched from the home screen. Scenario Publisher emits on revocation? Running from Xcode (debugger attached) Yes, immediately Development-signed build (no debugger) No — silent even on foreground return We also confirmed: MDM configuration profiles can disable Screen Time entirely, but cannot restrict the per-app authorization toggle — the user can always freely revoke the app's Screen Time access The Security Gap This creates a significant gap for parental controls use cases: User leaves the app (app goes to background) User goes to Settings and disables Screen Time access for the app All restrictions are immediately lifted User uses the device freely User re-enables Screen Time access and opens the app Everything syncs back to normal — administrator never knows Questions Is there any supported mechanism to receive a notification (background or foreground) when FamilyControls individual authorization is revoked? We are subscribing to AuthorizationCenter.shared.$authorizationStatus but it does not emit. Is the $authorizationStatus publisher expected to work only when a debugger is attached? Is this a known limitation or a bug? Can DeviceActivityMonitor extension detect authorization revocation? Based on documentation it appears limited to schedule/threshold events, but we haven't confirmed this. Is there a planned API improvement to address this gap? Environment iOS 26.2 Xcode 26.3 Swift 6.2.4 FamilyControls .individual authorization Related Threads Screen time API can be disabled easily Changing Screen Time Passcode does not protect apps