NearLens: local answers with Apple Intelligence, explicit signals with PMSG

Privacy Intelligence addresses that task. It combines a local activity report with questions answered through the on-device model available through Apple Intelligence. The user can ask about the latest detection, recurring manufacturers or the busiest hours in their history without uploading that history to a hosted chatbot.

This release update explains how that interpretation works and where its evidence stops. It also follows our earlier article on PMSG, which described the integration as upcoming. Support announced in version 2.4.2 adds another kind of observation: privacy states voluntarily broadcast by compatible devices.

The language model does not scan Bluetooth or decide whether a nearby person is recording. It receives a representation of observations that NearLens has already processed.

The report itself uses calculations over the available history. Detection counts, activity by hour and manufacturer frequency do not require generative AI. Keeping those calculations separate gives users a useful report even when the language model is unavailable.

Natural-language questions serve a different purpose. Instead of inspecting several entries to find the most recent match or comparing manufacturer counts manually, the user can ask a question about that information.

For example, “Which brand appears most often?” can be answered from the manufacturer distribution in the local record. “What is the busiest hour?” refers to the hours represented in that history. Neither answer establishes how many glasses were actually present outside the periods when the app was scanning.

This distinction matters because a fluent explanation can sound more complete than its source. NearLens has a partial record of observable Bluetooth activity. Apple Intelligence cannot fill in the missing observations.

NearLens prepares the context in application code before requesting a response. It calculates totals, manufacturer counts, activity distributions and summaries of recurring observations. It also includes a bounded selection of recent entries.

The current question flow limits those recent rows to ten. Aggregates can cover a larger retained history, so ten rows does not mean that only ten detections contribute to every answer. It does mean that the model does not receive an unrestricted transcript of every stored entry.

Device names are excluded from this flow. Bluetooth addresses are used internally for record handling and device grouping, but are not included as addresses in the generated context. Manufacturer labels, timestamps, signal readings and derived summaries provide the information needed for the supported questions.

That reduces unnecessary detail in the prompt. It does not make the history meaningless or automatically anonymous: the timing and frequency of nearby-device observations can still be sensitive.

Fields originating in Bluetooth advertisements are treated as untrusted input. NearLens sanitizes device-controlled text before placing it in the context, and the model instructions distinguish observations from commands. These are defensive measures against instruction-like content in radio data, not a guarantee that a language model can never be misled.

The iOS implementation uses Apple's Foundation Models framework. A native Swift module checks the availability of SystemLanguageModel.default, creates a LanguageModelSession with the prepared instructions and detection context, and requests a streamed response.

The implementation uses the system's on-device language model. It does not route these questions to a NearLens inference server or substitute a hosted model when local generation is unavailable. Foundation Models supports other capabilities, but their existence does not mean NearLens uses them.

The React Native interface receives incremental text through the native bridge. Each generation carries a request identifier so that tokens, completion events and errors can be associated with the question that produced them.

Slide 18 of the NearLens case study shows the Privacy Intelligence interface and the Ask NearLens question field, alongside the locally computed activity summaries.

The model is instructed to answer from the supplied history, keep responses concise and say when the data is insufficient. It is also instructed not to identify owners or speculate about real people. An observation associated with a manufacturer is not evidence of who owns the device or why it was nearby.

Those instructions describe the intended behaviour. Generated answers can still be inaccurate. Counts and records remain the basis for checking an answer, rather than the confidence of its wording.

Access to the local history for questions is controlled by Ask about your local history, a toggle under Settings > Privacy. It is off by default and remains separate from the preference for saving detection history.

That separation lets someone retain a useful log without authorizing the language model to interpret it. Enabling the toggle grants the question flow access to the local context; it does not authorize an upload.

The question composer also requires detection data and an available model. Before there is history, Intelligence presents the scan-first state rather than an input that cannot produce a grounded answer.

Disabling the preference interrupts an active response and clears the displayed conversation derived from that history. The setting persists, so moving between tabs does not silently change the user's choice.

The privacy boundary is specific: detection history is not automatically uploaded for these answers. User-initiated sharing of a log is a separate action and should not be confused with the inference path.

The native integration requires iOS 26 or later, Apple Intelligence-capable hardware, Apple Intelligence enabled and a model that is ready on the device. NearLens checks the actual availability state rather than assuming that a supported operating-system version is enough.

An ineligible device needs a different explanation from one that is still preparing its model. The interface distinguishes those conditions. When generation is unavailable, the app can still calculate statistics and provide predefined local-history queries without presenting them as Apple-generated responses.

Users can stop a streamed answer. Cancellation reaches the native generation task as well as the interface. Request identifiers and UI invalidation prevent late events from an older request from appearing as part of a newer answer.

Clearing the conversation or revoking history access also invalidates the active request. These controls matter because text generation continues over time: removing a loading indicator alone would not stop inference.

An RSSI reading is a signal-strength measurement. NearLens converts it into rough proximity ranges, but walls, orientation, interference and radio hardware affect those estimates. A model describing a detection as nearby is not measuring its physical position.

Recurring observations also require care. Bluetooth identifiers can change, and grouping observations does not establish a person's identity. A repeat pattern should not become a claim that somebody is following the user.

The history has storage limits: up to 90 days and a maximum of 500 recent entries. It represents retained observations, not a complete account of every device encountered over that period.

Scanning currently runs while NearLens is active in the foreground. Leaving the app pauses it. There may therefore be gaps that no local summary or generated answer can reconstruct. Zero recognised matches does not rule out nearby glasses or recording.

The useful role for Apple Intelligence is to make the available record easier to question while retaining these limits. It should not turn incomplete radio observations into claims about intent, identity or safety.

PMSG addresses a limitation earlier in the process: what information a recording device makes available to nearby software.

Conventional recognition uses available manufacturer identifiers, advertised names and other Bluetooth characteristics. Those can suggest a device category. They do not establish whether its camera or microphone is active.

The PMSG Bluetooth privacy signal convention, credited to Paul Stefaan Mooij, proposes that cooperating devices advertise privacy-related states directly. NearLens's implementation can interpret camera and microphone activity, capability flags and do-not-record requests carried by compatible broadcasts.

The parser distinguishes a service-data status byte from a UUID-only advertisement or a convention-based name match. Those inputs carry different amounts of information. A recognised service UUID without a status byte is not the same evidence as an explicit active-recording flag.

This makes PMSG a promising technical addition to NearLens: it supplies a device-reported state alongside presence inference. It is still voluntary signalling. It cannot force a device to advertise, authenticate the truth of every declaration or prevent an uncooperative camera from recording.

A do-not-record signal expresses a preference. Whether capture stops depends on the receiving device's implementation. NearLens displaying that request does not itself enforce it.

Apple Intelligence and PMSG serve different parts of the product. The former explains a prepared local history; the latter can improve the information available from cooperating devices.

They should not be conflated. Displaying a current PMSG state does not automatically establish a complete recording timeline, and the current question context should not be described as an exhaustive history of PMSG recording events.

NearLens now has an implemented path for reading the convention described in the earlier article. The next question is how consistently participating hardware advertises those states under real conditions. Decoder support, simulated demonstrations and validation with physical devices are separate forms of evidence.

For this release, the technical direction is clear: use explicit declarations where devices provide them, explain the observations locally and preserve uncertainty where the evidence is incomplete.

NearLens is an attempt to mitigate the privacy problem around smart glasses, bring it into public discussion and test practical responses while legislation catches up with the pace of hardware and AI. I believe people should have a say in whether they are recorded, rather than being left to accept what a device allows. Better information can help in the meantime, but it does not replace manufacturers' responsibilities or enforceable legal protections.