Find My arrives in a product requirement document as one line. The product should appear in the Find My app. Teams read that as a firmware task and schedule it late, because the radio is already on the board. It is a licensing gate, a privacy specification with hard numeric requirements, and a power architecture decision, in that order.

We worked through this on a battery powered, fingerprint secured product for a consumer security startup, built on a Nordic nRF52840 in a Raytac MDBT50Q-U1MV2 module. Everything below about Apple's protocol comes from public sources. The Find My network specification and its accessory development kit are distributed under Apple's non-disclosure agreement, and nothing from those documents appears here.

The program is a legal gate in front of the engineering

Apple's Find My developer page states that a developer or manufacturer looking to connect an accessory to the Find My network should enroll in the MFi Program to access the technical specifications and resources needed. There is no alternate route. Apple's 2021 announcement placed the accessory program inside Made for iPhone.

Enrollment is a corporate exercise. The MFi FAQ requires a business email on the company domain, the registered legal entity name, a physical business address, a D-U-N-S number, a tax identification and a payment method. Membership is USD 99 per membership year plus applicable taxes and fees. Apple will not comment on a product concept before a company joins.

Two scheduling consequences follow. Entity details take real calendar time when the trading name and the registered legal entity differ, common for small firms operating under a DBA. And access is layered: executing the MFi license is a separate event from gaining access to a given technology. Nordic shows the same layering, stating publicly that an active MFi license is required before it will grant access to the Find My software development kit in nRF Connect SDK. None of this runs in parallel with bring-up. It runs in front of it.

The public privacy model explains the constraints

Apple's Platform Security guide describes the offline finding system openly. A P-224 elliptic curve key pair is generated on the device and the private key is never sent to Apple. A missing device periodically broadcasts a derived public key in a Bluetooth advertisement, and Apple documents that this key is replaced approximately every fifteen minutes, derived through a key derivation function from a stored secret and a counter. Nearby Apple devices encrypt their own location to that key and upload the report, which carries no authentication information in its contents or headers.

Three engineering facts follow directly.

The advertised payload is the identifier. No separate device address does the identifying work, which is why rotation exists. A static advertised value would make the accessory a persistent tracking beacon for anyone with a scanner.

P-224 is a size decision. A compressed public key on that curve fits inside a single BLE advertisement payload. The curve is chosen because the advertisement is the channel.

Key material has to persist. The stored secret and its counter must survive power cycles or the accessory becomes unfindable after every sleep. Without external storage that lands in internal flash, and the budget has to be reserved before layout. Our board carries a W25Q16JV on SPI for this class of requirement.

Unwanted tracking rules are bill of materials line items

Apple and Google published the Detecting Unwanted Location Trackers specification jointly, and Apple implemented the detection side in iOS 17.5. The DULT accessory protocol is public. Its requirements are numeric and mostly physical, which makes it the most useful document available while scoping hardware.

The accessory rotates its address every fifteen minutes in the near owner state and every twenty four hours in the separated state, transitioning to separated after more than thirty minutes away from the owner device. A maximum advertising interval of four seconds is required, with two seconds or less recommended for detection rate.

The sound requirement reshapes mechanical design. The accessory must emit at least 60 phon peak loudness as defined by ISO 532-1:2017, measured at 25 cm from the accessory suspended in free space, for a minimum of five seconds and a maximum of thirty seconds, with twelve seconds recommended. That is an acoustic specification. A schematic note reading "buzzer" does not satisfy it. The requirement sets transducer selection, drive voltage, the current the rail must supply during the burst, and the size and placement of the enclosure port. A sealed enclosure chosen for ingress protection will fail it quietly and late.

Identifier retrieval is physical too. A user must be able to read the accessory identifier, which requires an NFC tag or a physical action such as a button press that enables the read state for five minutes. A serial number must be printed and accessible on the accessory, unique per product identifier. Motion sampling in the separated state runs at ten second intervals until motion is detected, then at half second intervals, which implies an accelerometer and a duty cycle the battery pays for.

The power architecture is the real decision

A Find My accessory advertises continuously. A battery powered product with a sensor wake model does not. Resolving that tension is the design work.

On this platform the product sleeps in System OFF and wakes on a touch at the fingerprint sensor. In System OFF the radio is not running, so the device is not findable. Find My gives the radio a duty cycle at all times, and at a two second advertising interval that sets a hard floor under average current. The floor is rarely the problem. What shares the rail is.

Here a single load switch feeds the fingerprint sensor, the motor bridge and the audio amplifier. Standby requires the sensor to stay powered so it can detect touch, which keeps the rail up and keeps two loads energized that standby does not need. The sensor is specified below 25 microamps in detection sleep, and measured standby will sit well above that until the other loads are gated separately. Split that rail before any Find My work starts, then measure. A quiescent figure taken on the wrong rail topology cannot be improved in firmware.

Coexistence is the second question. The product already runs its own GATT service for the phone application, and Find My brings its own advertising behavior. Running both on one SoftDevice is a matter of advertising sets and connection handling. It is tractable, and it belongs in the estimate.

Certification is two separate paths

Find My accreditation runs through MFi. Apple's public material describes licensed accessories becoming searchable on the MFi Licensed Accessories page once certification is complete and the manufacturer has opted in, and names Find My network as a qualifying technology alongside AirPlay audio, HomeKit and DockKit.

That path runs alongside the ordinary radio path rather than replacing it. The MDBT50Q series holds FCC, IC, CE, MIC, KC, SRRC, NCC, RCM and WPC approvals, with FCC Part 15C granted under FCC ID SH6MDBT50Q, and it is Bluetooth qualified. The finished product still needs its own unintentional radiator testing, RF exposure assessment and Bluetooth listing. The module removes the intentional radiator work and nothing more.

A workable order of operations

Apply to the MFi program at concept, before a schematic exists, because access sits in front of everything and the paperwork is slow. Read the public DULT specification during industrial design, because the sound and identifier requirements change the enclosure. Fit persistent storage for key material on the first board. Split the standby rail. Measure standby current on real hardware before anyone writes a battery life figure into a specification. Then integrate.

In that order, Find My is a firmware task. In any other order, it is a board respin.

References