Screen Time | eventDidReachThreshold triggers immediately

The eventDidReachThreshold calls immediately not waiting for accumulated time.

Example of setting the event:

let events: [DeviceActivityEvent.Name: DeviceActivityEvent] = [
     .monitorEducation: DeviceActivityEvent(
          applications: educationalApps.applicationTokens,
          threshold: DateComponents(minute: 15)
     )
 ] 

What could be wrong?

It's possible that you are using date components for your schedule that the system is interpreting as an ongoing or "active" schedule (i.e. it's finding the previous time matching those date components), and the app you are monitoring has already accumulated 15 minutes of usage since the previous instance of the start components. For example: if your schedule starts at 12:00am and ends at 11:59pm and your apps calls startMonitoring for your .monitorEducation event at 4pm, your extension's eventDidReachThreshold function will be invoked immediately if educationalApps.applicationTokens have already been used for 15 minutes since 12:00am.

Kmart, what if day already ended, but eventDidReachThreshold invokes anyway? What if on the previous day, I didn’t open specified apps, but eventDidReachThreshold invokes anyway? Where else could be the problem?

Getting the same issue here. Some applications trigger eventDidReachThreshold immediately even if they have never been opened since the start of the Activity Interval. Are the DeviceActivitySchedule backwards looking? i.e. does a time used during a previous interval count towards the current interval? Wouldn't make much sense, but otherwise these thresholds would appear to be working inconsistently.

FYI this is still an ongoing issue and extremely tough to debug as Family Controls is still a blackbox on how it's making these decisions. The convention/opinionation is really important for developers to understand, but it's taking a lot of cobbling together bits and pieces of docs and forums all over the place, which I still find myself lacking understanding. Family Controls really solves a great specific use case, but I also find it really limiting, especially in coordinating if we need to reblock (re-add a shield) during the scheduled activity monitor, and for example intervalDidEnd only fires once we either call stopMonitoring or activity is detected OUTSIDE of the scheduled window, which is counterintuitive. So we can't rely on threshold because it fires only once and is inaccurate, we have a small limit on the number of monitors, and intervalDidStart and intervalDidEnd function differently from each other, and the warning functions clamp, so if you have a threshold duration less than your warning duration, it's really tough to coordinate.

@Kmart I absolutely appreciate you continuing to support us with your responses, which are amazingly helpful, and I'm happy to help as much as I can, but how can we get these use cases and scenarios officially outlined?

Screen Time | eventDidReachThreshold triggers immediately
 
 
Q