Requested by a user: "the option to automatically block all calls from numbers that are not in my contact list."
Why HuShield cannot do this directly
No third-party iOS app can. Two structural reasons:
- Call Directory is a static data source. You hand iOS a list of specific numbers. There is no wildcard, no "everything except", and the extension is never invoked per incoming call — it is queried periodically and that is all.
- Live Caller ID Lookup (iOS 18+, what Truecaller uses) does allow real-time decisions, but it works by making a privacy-preserving encrypted query to your server. The server cannot know the user's contact list. That is the entire design.
iOS already ships this feature: Settings ▸ Phone ▸ Silence Unknown Callers, which silences anyone not in Contacts, Mail, or recent outgoing calls. Apple reserved it for the system because it needs contact access no extension is granted.
The version worth building
Silence Unknown Callers is blunt: it also silences the doctor's office, the delivery driver, the school, the pharmacy. That is why people turn it back off.
HuShield has data Apple does not — community signal about which unknown numbers are legitimate. So the interesting feature is not "block all unknowns", it is "silence unknowns unless the community vouches for them."
Open question that decides the architecture
Does a Call Directory identification entry exempt a number from Silence Unknown Callers?
Apple does not document this. Evidence leans toward no — an Apple developer forum thread notes that call-blocking apps "have no way of knowing which numbers will be silenced by the Silence Unknown Callers setting", implying the subsystems are independent.
This needs a 10-minute device experiment, which is cheaper than either implementation:
- Enable Silence Unknown Callers
- Add a test number to the Call Directory as an identification entry (labeled, not blocked)
- Call the device from it
- Does it ring with the label, or go silently to voicemail?
If identification DOES exempt
Straightforward: push community-vouched numbers as identification entries. Needs a new positive-reputation tier (see below).
If it does NOT exempt
The only mechanism that reliably makes a number "known" is writing it into Contacts. The app could, with explicit permission, maintain a dedicated Contacts group of community-vouched numbers.
That works, but it means an app whose entire pitch is "we never touch your contacts" now writes to them. Local-only and never uploaded, so the literal privacy claim survives — but it must be an explicit, plainly-explained opt-in, not a buried toggle. Do not ship this quietly.
Backend work either path needs
Scoring currently has no positive-reputation tier. Scores never go negative — not_spam votes subtract and clamp at 0, so a heavily-vouched number just sits at unknown, indistinguishable from one nobody has ever seen. A vouched status would need:
- a scoring concept for positive consensus (not merely absence of spam reports)
- a new
Status value and blocklist-delta action (e.g. identify)
- abuse resistance — vouching is a more attractive attack target than reporting, since it grants rather than removes access
Related
Also worth evaluating separately: Live Caller ID Lookup support would let HuShield block on live score instead of waiting for a blocklist sync. Significant server work (Apple requires a PIR service with homomorphic encryption), but it is a real upgrade over the static list.
Requested by a user: "the option to automatically block all calls from numbers that are not in my contact list."
Why HuShield cannot do this directly
No third-party iOS app can. Two structural reasons:
iOS already ships this feature: Settings ▸ Phone ▸ Silence Unknown Callers, which silences anyone not in Contacts, Mail, or recent outgoing calls. Apple reserved it for the system because it needs contact access no extension is granted.
The version worth building
Silence Unknown Callers is blunt: it also silences the doctor's office, the delivery driver, the school, the pharmacy. That is why people turn it back off.
HuShield has data Apple does not — community signal about which unknown numbers are legitimate. So the interesting feature is not "block all unknowns", it is "silence unknowns unless the community vouches for them."
Open question that decides the architecture
Does a Call Directory identification entry exempt a number from Silence Unknown Callers?
Apple does not document this. Evidence leans toward no — an Apple developer forum thread notes that call-blocking apps "have no way of knowing which numbers will be silenced by the Silence Unknown Callers setting", implying the subsystems are independent.
This needs a 10-minute device experiment, which is cheaper than either implementation:
If identification DOES exempt
Straightforward: push community-vouched numbers as identification entries. Needs a new positive-reputation tier (see below).
If it does NOT exempt
The only mechanism that reliably makes a number "known" is writing it into Contacts. The app could, with explicit permission, maintain a dedicated Contacts group of community-vouched numbers.
That works, but it means an app whose entire pitch is "we never touch your contacts" now writes to them. Local-only and never uploaded, so the literal privacy claim survives — but it must be an explicit, plainly-explained opt-in, not a buried toggle. Do not ship this quietly.
Backend work either path needs
Scoring currently has no positive-reputation tier. Scores never go negative —
not_spamvotes subtract and clamp at 0, so a heavily-vouched number just sits atunknown, indistinguishable from one nobody has ever seen. Avouchedstatus would need:Statusvalue and blocklist-deltaaction(e.g.identify)Related
Also worth evaluating separately: Live Caller ID Lookup support would let HuShield block on live score instead of waiting for a blocklist sync. Significant server work (Apple requires a PIR service with homomorphic encryption), but it is a real upgrade over the static list.