[Feat] Delay After Threshold Crossed

[joeljfischer]

Problem Statement

While having the criteria before requesting a review is good, it's also likely to interrupt the user while they are doing something within the app. For example, in my weather app, a positive criteria is selecting a day of the week to check the weather for. But having the review appear right after the user taps a day may be disruptive to their thought process.

Suggested Solution

Set a delay after the threshold is crossed before presenting the review dialog. For example, the framework could see that the threshold has been crossed, then wait 5 seconds before presenting the dialog. If the user does another positive event, that would reset the timer.

Additional Considerations

• A possible good default value would be 5 seconds.

[Jeehut]

@joeljfischer Thank you for requesting this feature and sorry for getting back to you so late.

I totally understand your use case and the need to delay the request. But I'm not sure if we need to add anything to the library in order to do this. I think it's easy enough to delay the calls like so, or is there anything I'm missing:

Task {
    try await Task.sleep(for: .seconds(5))
    ReviewKit.recordPositiveEventAndRequestReviewIfCriteriaMet()
}

I think this is not a use case that's needed all the time (depends on the screen/feature) so the additional 2 lines of code you need to write seem reasonable. Also note that you could simply call ReviewKit.recordPositiveEvent() which counts a positive event but does not show a prompt, as long as you have enough other places where you call requestReviewIfCriteriaMet().

Therefore I think I'm gonna close this and reopen in case you convince me otherwise.

[joeljfischer]

FWIW, I integrated this into a fork where I do use it all the time, because I never want the user to press a button and instantly be presented with the review dialog. I also do use recordPositiveEventAndRequestReviewIfCriteriaMet() everywhere instead of the alternatives, so I don't like spinning off tasks everywhere. I understand that it's not necessarily a use-case everyone needs, but I do think that the UX of having a presentation instantly after a button press is not what the developer usually would want.

[Jeehut]

@joeljfischer I do understand your point, I will think about that when iterating over this library again. But please note that my idea of making this call is not "after a button press" but more like "after the user has completed a workflow".

In that case, the "button press" would be something like the "Done" button after completing a workflow or the "Send" button in an app that helps you make social media posts, for example. In that case, you do want to show the dialog right away. And from my experience, there's also some delay added by Apple themselves, or at least I had this impression sometimes.

But I do see your point, so I will reopen this and try to tackle it at a later time.