Why should installing a phone-prefix list need a battery warning? In issue #172, contributor Pierre-Yves Lapersonne called Saracroche’s list update costly and proposed asking before continuing in Low Power Mode. The merged pull request added that choice. It is a public clue that this is not merely a list download: it is a synchronization job across an iOS extension boundary.
The live list endpoint returned version 2026-07-12T01:00:59+00:00 with 1,548 wildcard patterns: 615 for blocking and 933 for identification. Applying the project’s wildcard rule produces 14,736,000 represented blocking numbers plus 2,220,000 identification numbers. That 16,956,000 total is a description of the list’s mathematical reach, not an installation count.
The payload itself complicates its ARCEP-flavoured name. Its description separates canvassing prefixes from additional operator ranges and “potential spam” ranges. The client stores the supplied name, action, and pattern, but this repository does not show how those additional ranges are selected, disputed, or retired. The source supports a mixed-origin list, not a claim that every entry is official policy.
The narrow doorway is a separate process
At fixed commit d9fc924, ListService reconciles a fresh payload against API-origin Core Data records. Missing patterns become explicit removal work rather than silently disappearing. The database lives in an App Group container shared by the app and its extensions.
The call path then has to materialize the compact rules. PhoneNumberHelpers expands a # into a numeric range; BlockerService slices those values into batches of at most 10,000. Each handoff writes one action and one number array to shared UserDefaults, reloads the extension, and waits for the next piece.
In the other process, CallDirectoryHandler reads and clears that handoff before issuing CallKit block, identify, or removal operations. A downloaded list and the system state are therefore separate truths the app has to reconcile.
SMS gets to keep the wildcard
Saracroche’s SMS extension takes a different route. MessageFilterService reads the same shared store and compares a sender to the compact pattern character by character. It does not need to expand a million-number prefix before answering one matching question. The interesting engineering is the translation forced by the call-extension interface, not the wildcard alone.
Freshness is a policy, not a result
The project’s reset trail shows why that translation stays alive. PR #175 added daily reprocessing for a fraction of expired patterns; a later commit switched to a full reset after 20 days and retry eligibility after two hours. That is a design for eventual reconstruction, not a benchmark of speed or battery use.
The README’s “every 6 hours” background-update wording needs the same care. The code asks iOS for work no earlier than six hours later, with network and external power required. Apple says earliestBeginDate is not an appointment.
Maintainer Camille Bouvat’s one-year retrospective is the useful final context: he names chunking, extension communication, memory/time limits, and background work as the difficult part of version 4. The next decisive public receipts would be reconciliation tests, a device-level installation benchmark, and provenance for non-ARCEP ranges. Until then, the source makes a narrow doorway visible; it does not prove that all 16.956 million represented entries pass through it.