Post

Replies

Boosts

Views

Activity

Reply to DeviceActivityMonitor intervalDidEnd not firing for non-repeating timed unlock
[quote='820956021, hkbm215, /thread/820956, /profile/hkbm215'] If this looks like a platform bug, should I file Feedback Assistant? If so, what logs/artifacts are most useful? [/quote] I haven't directly seen this bug because my apps do not rely on the intervalDidEnd being called reliably – but I have seen similar things happening with didReachThreshold. Even if your observations ends up not being a bug, I would always file a report through the feedback assistant: -> They might improve the documentation based on your input to prevent any similar (hypothetical) misunderstandings from happening in the future. I’m not saying yours is a misunderstanding…there is of course the chance that this is a bug indeed – and the sooner you report it, the better. Make sure you file it against the correct components: Developer Technologies & SDKs -> Device Activity Framework Attachments: Sysdiagnose of the affected device. Screenshots / screen recordings. Or even better: a quick demo video. Bonus: Minimal reproducing Xcode project. Don’t forget to post your feedback number here on the forums so other developers can reference it in their radars as well to help get dupes matched quickly. Hope that helps!
Topic: App & System Services SubTopic: General Tags:
3w
Reply to iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
[quote='883639022, DTS Engineer, /thread/808470?answerId=883639022#883639022'] I comprehend that without extensive testing, on your end, it may be challenging for you to verify the fix. I would recommend monitoring the situation closely. […] I am confident that you will be satisfied with the fix. [/quote] Hey @DTS Engineer – also on this thread: thanks a lot for your help and sharing more details! So far we are carefully optimistic: since this is a semi-decidable problem™️ we can only confirm the bug fix if the bug does not occur over a longer period of time. I’ll update my radars in case we can still reproduce on 26.5.
3w
Reply to Scheduled events reach threshold almost immediately on iOS 26.2
[quote='883642022, DTS Engineer, /thread/814559?answerId=883642022#883642022'] I'm sure you'll be very happy of the results. [/quote] So far I am 😎 …fingers crossed this bug fix holds up (I am careful to close my radar just now, since this particular bug comes back ca. once per month). Having this fixed would make the Screen Time frameworks so much more useful after years of being neglected by Apple. I’m really hopeful that that means we’ll see more and more bug fixes over the next weeks and months! Thanks @Albert for your help!
Topic: App & System Services SubTopic: General Tags:
3w
Reply to iOS 26.4 asks for Face ID instead of Screen Time passcode when disabling Screen Time access for an app
[quote='821959021, infovine, /thread/821959, /profile/infovine'] The system asks for Face ID instead of the Screen Time passcode, and Screen Time access is disabled. [/quote] I cannot reproduce this on my device. Once a screen time passcode is set, it asks for the code instead of FaceID. Maybe the code lock is a EU-only feature? Are you outside of the EU?
Topic: App & System Services SubTopic: General Tags:
3w
Reply to Family Controls Entitlement NOT applied to App Extensions (and Support Form is broken)
[quote='819573021, FocusPact_Support, /thread/819573, /profile/FocusPact_Support'] The Family Controls (Distribution) entitlement is not being applied to my app extensions [/quote] Hey @FocusPact_Support! Sorry to hear about your issues! The screen time permission system seems to be terribly broken unfortunately. I’ve filed some radars on this a while ago but they remain without reply until today: FB13698690, FB17981176, FB18997699, FB19018706, FB18352991, FB17272792, FB13690981, FB12108796. I even sometimes had bugs where bundle ids of my extensions were exposed to the user…which is of course super confusing UX:
3w
Reply to Scheduled events reach threshold almost immediately on iOS 26.2
[quote='814559021, sergey_nikitin, /thread/814559, /profile/sergey_nikitin'] Can you suggest any workarounds for this issue? [/quote] Hey @sergey_nikitin. My radar FB18061981 has been updated by Apple claiming that this terrible regression has finally been addressed in iOS 26.5 beta 1. So far it looks good on my device…can you confirm as well that you can no longer reproduce this? @DTS Engineer @DTS Engineer can you also confirm that the fix actually went into iOS 26.5?
Topic: App & System Services SubTopic: General Tags:
3w
Reply to Screen Time APIs showing severe inconsistencies (DeviceActivity not firing + impossible usage data)
[quote='882176022, hkbm215, /thread/819997?answerId=882176022#882176022, /profile/hkbm215'] Any OS-version-specific observations would be really helpful. Thanks in advance! [/quote] Hey @hkbm215! My radar regarding this one specific issue FB18061981 has just been updated by Apple (No. 3 from my list above): Apparently this regression has been addressed in iOS 26.5 beta 1! The bug has been present in iOS 26.0 (during the whole beta phase since June 2025), iOS 26.1, iOS 26.2, iOS 26.3, and iOS 26.4. I am currently not able to reproduce on my device…but I’m not yet closing my bug report. This issue is not consistently reproducible, sometimes it goes away for a couple of days or weeks…just to come back and hit even harder the next time. So we have reason to be careful optimistic! However, the other issues of my list still remain. But I think it’s good news that after half a decade of silence Apple is starting to put some engineering efforts into the Screen Time frameworks again!
Topic: App & System Services SubTopic: General Tags:
3w
Reply to iOS 26.2 RC DeviceActivityMonitor.eventDidReachThreshold regression?
[quote='882166022, kgaidis, /thread/809410?answerId=882166022#882166022, /profile/kgaidis'] that's iOS 26.2, iOS 26.3 and iOS 26.4 (3-4 months) of limits automatically activating most mornings without reaching the limit, and this also affects the default Apple Screen Time [/quote] Just for the record: it’s been one year almost. The regression was introduced with iOS 26.0 beta 1 in June 2025. I filed a radar about this serious regression the very same week…but did not get any response from Apple until now. Apparently now in iOS 26.5 it’s addressed, but that still takes a month or so to ship to customers. So 11 months in total to have the bug fix shipped that shouldn't have made it into the public release of iOS 26 at all. I hope some internal investigation will follow at Apple to prevent a horrible scenario like this from happening again!
Topic: App & System Services SubTopic: General Tags:
3w
Reply to iOS 26.2 RC DeviceActivityMonitor.eventDidReachThreshold regression?
[quote='883582022, kgaidis, /thread/809410?answerId=883582022#883582022, /profile/kgaidis'] How are people doing on iOS 26.5? So far so good, but this happened with the first 26.4 release too: it seemed to be fixed, but then (maybe) something got reverted. [/quote] Same: so far so good. But I’m hesitant to confirm the bug fix haha. As we all know the Screen Time frameworks are quite flaky and bugs come back all the time after a couple of weeks. Or even worse: new regressions. This time I’m hopeful though because my radar FB18061981 has been updated by Apple indicating that there has been a bug fix attempt for iOS 26.5 beta 1. So all in all, I think we can be carefully optimistic that this issue has been addressed on 26.5 🤞
Topic: App & System Services SubTopic: General Tags:
3w
Reply to iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
[quote='883535022, DTS Engineer, /thread/808470?answerId=883535022#883535022'] May I ask to test the latest beta released to see if you can reproduce the issue using that build? [/quote] Hey @DTS Engineer Albert! Thanks a lot for getting back to me! I’m currently in contact with the Screen Time team via my radar FB18061981 and they informed me that this specific problem should be resolved on the new iOS 26.5 beta 1. I have not been able to reproduce the issue there. However, that does not mean that the issue has actually been fixed: the difficult thing about this bug is that it is not consistently reproducible. There are sometimes weeks where everything works fine…and then the issue hits back. It’s only been one week with the new beta, so I don't want to be too quick to confirm the fix. But at least so far it looks good. I’m just super confused why such a serious regression takes almost one year to get addressed – even though I filed bug reports directly in June 2025 on beta 1 of iOS 26.0… For now I’m a bit hesitant to confirm the fix, especially because a similar screen time bug triggered the same notification for iOS 26.5 beta 1, and then it turned out the fix didn't make it into beta 1: FB18764644
3w
Reply to iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
[quote='883510022, ohadh123, /thread/808470?answerId=883510022#883510022, /profile/ohadh123'] Wondering if you got any resolution on this? [/quote] Hey @ohadh123! This might be fixed on iOS 26.5 beta 1, but we are still waiting for confirmation from Apple. Since this bug is not consistently reproducible, I don’t want to be too quick to give green light here :)
3w
Reply to Scheduled events reach threshold almost immediately on iOS 26.2
[quote='874812022, DTS Engineer, /thread/814559?answerId=874812022#874812022'] Make certain you properly handle rescheduling scenarios. [/quote] Hey Albert @DTS Engineer @DTS Engineer! Thanks a lot for your input on this! My bug report has been updated recently (FB18061981), and I have a follow up question: Now that the Screen Time devs have figured out the root cause of this bug, is it feasible to re-schedule the DeviceActivityEvent from within the eventDidReachThreshold(…) callback if we detect that it was called too early? We do have a workaround in place that dismisses the eventDidReachThreshold call if we detect that it was called unreasonably early: let timeSinceSchedulingActivity = currentTimeStamp - timeStampOfSchedulingActivity if timeSinceSchedulingActivity < 50 { // do not proceed to shielding the activity because this is not a real threshold callback, this is a bug!!! return } If we now, within this if condition, try to start a new DeviceActivityEvent that replaces the previous malfunctioning one, would that work? Or would that automatically run into the same problem again? I’m curious, because we are of course interested in providing a workaround until the fix is out & to provide a better-working version for the users that have not yet updated. Many of our users are afraid to update their iOS versions because historically more and more Screen Time bugs were introduced with every update instead of addressing previous bugs.
Topic: App & System Services SubTopic: General Tags:
Mar ’26
Reply to DeviceActivityMonitor intervalDidEnd not firing for non-repeating timed unlock
[quote='820956021, hkbm215, /thread/820956, /profile/hkbm215'] If this looks like a platform bug, should I file Feedback Assistant? If so, what logs/artifacts are most useful? [/quote] I haven't directly seen this bug because my apps do not rely on the intervalDidEnd being called reliably – but I have seen similar things happening with didReachThreshold. Even if your observations ends up not being a bug, I would always file a report through the feedback assistant: -> They might improve the documentation based on your input to prevent any similar (hypothetical) misunderstandings from happening in the future. I’m not saying yours is a misunderstanding…there is of course the chance that this is a bug indeed – and the sooner you report it, the better. Make sure you file it against the correct components: Developer Technologies & SDKs -> Device Activity Framework Attachments: Sysdiagnose of the affected device. Screenshots / screen recordings. Or even better: a quick demo video. Bonus: Minimal reproducing Xcode project. Don’t forget to post your feedback number here on the forums so other developers can reference it in their radars as well to help get dupes matched quickly. Hope that helps!
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
3w
Reply to DeviceActivityMonitor extension rejected by App Store Connect validator — NSExtensionPointIdentifier "com.apple.deviceactivity.monitor" invalid (IrisAPI -19241)
[quote='819904021, ChiliDev05, /thread/819904, /profile/ChiliDev05'] NSExtensionPointIdentifier [/quote] I believe the correct identifier is com.apple.deviceactivity.monitor-extension
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
3w
Reply to iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
[quote='883639022, DTS Engineer, /thread/808470?answerId=883639022#883639022'] I comprehend that without extensive testing, on your end, it may be challenging for you to verify the fix. I would recommend monitoring the situation closely. […] I am confident that you will be satisfied with the fix. [/quote] Hey @DTS Engineer – also on this thread: thanks a lot for your help and sharing more details! So far we are carefully optimistic: since this is a semi-decidable problem™️ we can only confirm the bug fix if the bug does not occur over a longer period of time. I’ll update my radars in case we can still reproduce on 26.5.
Replies
Boosts
Views
Activity
3w
Reply to Scheduled events reach threshold almost immediately on iOS 26.2
[quote='883642022, DTS Engineer, /thread/814559?answerId=883642022#883642022'] I'm sure you'll be very happy of the results. [/quote] So far I am 😎 …fingers crossed this bug fix holds up (I am careful to close my radar just now, since this particular bug comes back ca. once per month). Having this fixed would make the Screen Time frameworks so much more useful after years of being neglected by Apple. I’m really hopeful that that means we’ll see more and more bug fixes over the next weeks and months! Thanks @Albert for your help!
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
3w
Reply to Need Advice: Family Controls Fully Removed but App Review Still Detects Unapproved API Use
[quote='822078021, ios_older, /thread/822078, /profile/ios_older'] Removed related capabilities and entitlements from targets. [/quote] You could try removing the capability from the Identifiers developer page: https://developer.apple.com/account/resources/identifiers/list
Replies
Boosts
Views
Activity
3w
Reply to iOS 26.4 asks for Face ID instead of Screen Time passcode when disabling Screen Time access for an app
[quote='821959021, infovine, /thread/821959, /profile/infovine'] The system asks for Face ID instead of the Screen Time passcode, and Screen Time access is disabled. [/quote] I cannot reproduce this on my device. Once a screen time passcode is set, it asks for the code instead of FaceID. Maybe the code lock is a EU-only feature? Are you outside of the EU?
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
3w
Reply to Family Controls Entitlement NOT applied to App Extensions (and Support Form is broken)
[quote='819573021, FocusPact_Support, /thread/819573, /profile/FocusPact_Support'] The Family Controls (Distribution) entitlement is not being applied to my app extensions [/quote] Hey @FocusPact_Support! Sorry to hear about your issues! The screen time permission system seems to be terribly broken unfortunately. I’ve filed some radars on this a while ago but they remain without reply until today: FB13698690, FB17981176, FB18997699, FB19018706, FB18352991, FB17272792, FB13690981, FB12108796. I even sometimes had bugs where bundle ids of my extensions were exposed to the user…which is of course super confusing UX:
Replies
Boosts
Views
Activity
3w
Reply to Scheduled events reach threshold almost immediately on iOS 26.2
[quote='814559021, sergey_nikitin, /thread/814559, /profile/sergey_nikitin'] Can you suggest any workarounds for this issue? [/quote] Hey @sergey_nikitin. My radar FB18061981 has been updated by Apple claiming that this terrible regression has finally been addressed in iOS 26.5 beta 1. So far it looks good on my device…can you confirm as well that you can no longer reproduce this? @DTS Engineer @DTS Engineer can you also confirm that the fix actually went into iOS 26.5?
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
3w
Reply to Screen Time APIs showing severe inconsistencies (DeviceActivity not firing + impossible usage data)
[quote='882176022, hkbm215, /thread/819997?answerId=882176022#882176022, /profile/hkbm215'] Any OS-version-specific observations would be really helpful. Thanks in advance! [/quote] Hey @hkbm215! My radar regarding this one specific issue FB18061981 has just been updated by Apple (No. 3 from my list above): Apparently this regression has been addressed in iOS 26.5 beta 1! The bug has been present in iOS 26.0 (during the whole beta phase since June 2025), iOS 26.1, iOS 26.2, iOS 26.3, and iOS 26.4. I am currently not able to reproduce on my device…but I’m not yet closing my bug report. This issue is not consistently reproducible, sometimes it goes away for a couple of days or weeks…just to come back and hit even harder the next time. So we have reason to be careful optimistic! However, the other issues of my list still remain. But I think it’s good news that after half a decade of silence Apple is starting to put some engineering efforts into the Screen Time frameworks again!
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
3w
Reply to iOS 26.2 RC DeviceActivityMonitor.eventDidReachThreshold regression?
[quote='882166022, kgaidis, /thread/809410?answerId=882166022#882166022, /profile/kgaidis'] that's iOS 26.2, iOS 26.3 and iOS 26.4 (3-4 months) of limits automatically activating most mornings without reaching the limit, and this also affects the default Apple Screen Time [/quote] Just for the record: it’s been one year almost. The regression was introduced with iOS 26.0 beta 1 in June 2025. I filed a radar about this serious regression the very same week…but did not get any response from Apple until now. Apparently now in iOS 26.5 it’s addressed, but that still takes a month or so to ship to customers. So 11 months in total to have the bug fix shipped that shouldn't have made it into the public release of iOS 26 at all. I hope some internal investigation will follow at Apple to prevent a horrible scenario like this from happening again!
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
3w
Reply to iOS 26.2 RC DeviceActivityMonitor.eventDidReachThreshold regression?
[quote='883582022, kgaidis, /thread/809410?answerId=883582022#883582022, /profile/kgaidis'] How are people doing on iOS 26.5? So far so good, but this happened with the first 26.4 release too: it seemed to be fixed, but then (maybe) something got reverted. [/quote] Same: so far so good. But I’m hesitant to confirm the bug fix haha. As we all know the Screen Time frameworks are quite flaky and bugs come back all the time after a couple of weeks. Or even worse: new regressions. This time I’m hopeful though because my radar FB18061981 has been updated by Apple indicating that there has been a bug fix attempt for iOS 26.5 beta 1. So all in all, I think we can be carefully optimistic that this issue has been addressed on 26.5 🤞
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
3w
Reply to iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
[quote='883535022, DTS Engineer, /thread/808470?answerId=883535022#883535022'] May I ask to test the latest beta released to see if you can reproduce the issue using that build? [/quote] Hey @DTS Engineer Albert! Thanks a lot for getting back to me! I’m currently in contact with the Screen Time team via my radar FB18061981 and they informed me that this specific problem should be resolved on the new iOS 26.5 beta 1. I have not been able to reproduce the issue there. However, that does not mean that the issue has actually been fixed: the difficult thing about this bug is that it is not consistently reproducible. There are sometimes weeks where everything works fine…and then the issue hits back. It’s only been one week with the new beta, so I don't want to be too quick to confirm the fix. But at least so far it looks good. I’m just super confused why such a serious regression takes almost one year to get addressed – even though I filed bug reports directly in June 2025 on beta 1 of iOS 26.0… For now I’m a bit hesitant to confirm the fix, especially because a similar screen time bug triggered the same notification for iOS 26.5 beta 1, and then it turned out the fix didn't make it into beta 1: FB18764644
Replies
Boosts
Views
Activity
3w
Reply to iOS 26 regression: `DeviceActivityEvent`: `eventDidReachThreshold` called immediately (instead of waiting till threshold is reached)
[quote='883510022, ohadh123, /thread/808470?answerId=883510022#883510022, /profile/ohadh123'] Wondering if you got any resolution on this? [/quote] Hey @ohadh123! This might be fixed on iOS 26.5 beta 1, but we are still waiting for confirmation from Apple. Since this bug is not consistently reproducible, I don’t want to be too quick to give green light here :)
Replies
Boosts
Views
Activity
3w
Reply to Scheduled events reach threshold almost immediately on iOS 26.2
[quote='874812022, DTS Engineer, /thread/814559?answerId=874812022#874812022'] Make certain you properly handle rescheduling scenarios. [/quote] Hey Albert @DTS Engineer @DTS Engineer! Thanks a lot for your input on this! My bug report has been updated recently (FB18061981), and I have a follow up question: Now that the Screen Time devs have figured out the root cause of this bug, is it feasible to re-schedule the DeviceActivityEvent from within the eventDidReachThreshold(…) callback if we detect that it was called too early? We do have a workaround in place that dismisses the eventDidReachThreshold call if we detect that it was called unreasonably early: let timeSinceSchedulingActivity = currentTimeStamp - timeStampOfSchedulingActivity if timeSinceSchedulingActivity < 50 { // do not proceed to shielding the activity because this is not a real threshold callback, this is a bug!!! return } If we now, within this if condition, try to start a new DeviceActivityEvent that replaces the previous malfunctioning one, would that work? Or would that automatically run into the same problem again? I’m curious, because we are of course interested in providing a workaround until the fix is out & to provide a better-working version for the users that have not yet updated. Many of our users are afraid to update their iOS versions because historically more and more Screen Time bugs were introduced with every update instead of addressing previous bugs.
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
Mar ’26
Reply to Scheduled events reach threshold almost immediately on iOS 26.2
[quote='875340022, DTS Engineer, /thread/814559?answerId=875340022#875340022'] I encourage you to file a Feedback report of your own using Feedback Assistant, then post the Feedback ID here. [/quote] Here is my feedback report: FB18061981
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
Mar ’26