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.aninterestingwebsite.com/forums/thread/756440
https://forums.aninterestingwebsite.com/forums/thread/758325
https://forums.aninterestingwebsite.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