From 5e669e63e962c421de4de3cbbb0e072e2b1561e0 Mon Sep 17 00:00:00 2001
From: liannacasper <67953602+liannacasper@users.noreply.github.com>
Date: Wed, 1 Apr 2026 18:01:33 +0300
Subject: [PATCH] docs: clarify iOS call detection timer limitation

---
 docs/developer-guide/Miscellaneous-Features.asciidoc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/docs/developer-guide/Miscellaneous-Features.asciidoc b/docs/developer-guide/Miscellaneous-Features.asciidoc
index bb3352abf2..17d8962c36 100644
--- a/docs/developer-guide/Miscellaneous-Features.asciidoc
+++ b/docs/developer-guide/Miscellaneous-Features.asciidoc
@@ -78,6 +78,8 @@ This API is intentionally *best effort* and should only be used as a UX hint (fo
 
 On iOS, `isInCall()` is inferred from app interruption lifecycle events, which means it can report `true` for non-call interruptions (e.g. Control Center, app switching, permission sheets), and some call flows may still be missed.
 
+Because iOS toggles this flag during app lifecycle transitions, polling it with a `UITimer` can miss the interruption window entirely (timers are paused while the app is inactive, and the flag is reset when the app becomes active again). If you need to react, check it from lifecycle callbacks such as your app's `stop()`/`start()` flow instead of periodic polling.
+
 On Android, call detection is currently unsupported because robust detection would require invasive telephony permissions that are intentionally avoided.
 
 [source,java]