TrinamiX sues Apple over the depth sensor in every Face ID since 2017

TrinamiX sues Apple over the depth sensor in every Face ID since 2017

What did TrinamiX actually file, and where?

A patent-infringement suit against Apple. TrinamiX — a BASF subsidiary that works in optical sensing — alleges that Apple’s “current implementation” of Face ID infringes its patents, and the complaint reaches every TrueDepth-equipped device from the iPhone X in 2017 through the current lineup. Note the framing: the complaint targets the shipping hardware, not a line of your Swift. This is a hardware-and-optics dispute wearing the costume of a threat to an API you ship every day.

Which patents are alleged?

Multiple. The complaint asserts several TrinamiX patents tied to its depth-sensing and beam-projection work — the structured-light approach that projects and reads infrared to build a 3D map of a face. I’m not going to paste patent numbers I can’t stand behind; the source frames the dispute by category, so treat it as a cluster of optics patents, not a single silver bullet. The through-line in every count is the sensor, not the software above it.

What is TrinamiX asking for?

Damages and an injunction. It’s the standard patent-suit posture: compensation for past infringement plus a court order against continued infringing sales. Read that carefully — an injunction in a patent case bites on making and selling the accused product going forward. It is not a remote kill switch for hardware already in someone’s hand. If a licensing arrangement is where this lands, that’s a royalty conversation between two large companies, not a diff against your SDK.

Does this change anything in my code today?

No. LAContext, evaluatePolicy, biometryType — all unchanged. No deprecation notice, no new entitlement, no MDM key, no WWDC “here’s the migration path” session. A filed complaint is a filed complaint. It is not an injunction, and it is not a change to the framework.

Is TrinamiX going after software or silicon?

Silicon and optics. The alleged infringement lives in the TrueDepth camera, in how the device projects and reads infrared to sense depth. Your evaluatePolicy call sits several abstraction layers above the component in dispute, and none of those layers are named.

Could an injunction switch Face ID off on phones already out there?

Don’t reorganise your roadmap around that fear. I won’t hand you odds on the case — nobody credible can. What I’ll say plainly: Face ID on a device you already own runs locally, matched inside the Secure Enclave, with no server in the loop. There’s no over-the-air lever that reaches into a shipped iPhone and disables the sensor. Hardware patent fights resolve in damages, licensing, and future-sales terms. They don’t retroactively brick the biometrics in your pocket.

Should I add a passcode fallback because of this lawsuit?

You should already have one, and not because of TrinamiX. Face ID fails a dozen mundane ways daily — a mask, a bad sun angle, a lockout, a sibling with a similar face. If your only path to an unlocked session is biometrics, you built a support ticket. Use the policy that falls back to the device passcode automatically:

Example.swiftSwift
let context = LAContext()
var error: NSError?
​
// deviceOwnerAuthentication = biometrics, then passcode fallback for free.
guard context.canEvaluatePolicy(.deviceOwnerAuthentication, error: &error) else {
    return presentPasswordLogin() // no biometric hardware or none enrolled
}
​
context.evaluatePolicy(.deviceOwnerAuthentication,
                       localizedReason: "Unlock your account") { success, err in
    DispatchQueue.main.async {
        success ? self.unlock() : self.presentPasswordLogin()
    }
}

If you’re on .deviceOwnerAuthenticationWithBiometrics for the tighter prompt, fine — just make sure the failure branch lands somewhere useful instead of a dead end.

Does this touch my Secure Enclave keys?

No. A key created with a biometry-gated access control still unlocks with Touch ID, the device passcode, and Optic ID on Vision Pro. Face ID is one way to present the credential. It is not the vault, and the vault isn’t in the complaint.

What about payment apps and AutoFill?

Same machinery, same answer. Apple Pay authorization, password AutoFill, and your app’s biometric prompt all ride on LocalAuthentication and SecAccessControl. Nothing in the filing changes that contract.

I branch on biometryType returning .faceID. Problem?

Yes, but a pre-existing one. Never hardcode behaviour on .faceID. Read .faceID / .touchID / .opticID / .none to adjust the copy and the glyph, and let the policy handle the rest. Apps that assumed “biometrics means Face ID” already broke on Vision Pro.

So what do I actually do this week?

Nothing to the code. File this under watch, not act. If you want the hour to be productive, grep your codebase for every evaluatePolicy call and confirm each one degrades to a non-biometric factor. That audit pays off regardless of how a courtroom feels about infrared dot projectors.

A chemistry company may own a piece of the camera. It doesn’t own your login flow — so stop writing it as if it might.

Related Post