DEV Community: Doogal Simpson

Count-Min Sketch Explained: Trillions of Counters

Doogal Simpson — Wed, 10 Jun 2026 15:38:27 +0000

Quick Answer: A Count-Min Sketch is a probabilistic data structure used to estimate the frequency of events in massive datasets. By running items through multiple hash functions and storing counts in fixed-size arrays, it compresses trillions of counters into kilobytes of memory. It guarantees no underestimations but allows slight overestimations due to hash collisions.

If there is one thing I constantly think about when designing high-volume systems, it is how quickly memory gets devoured. Let's say your team is building an analytics engine for an ad network. You need to answer a seemingly basic question: How many times has each user seen each ad? If you have 2 billion users and 10 million ads, you are staring down 20 trillion unique counters. Storing that in a standard database table or hash map will eat up terabytes of RAM.

But what if I told you that you could store that exact same frequency data in just 16 kilobytes of memory? That is exactly what a Count-Min Sketch allows us to do.

Why use a Count-Min Sketch instead of a hash map?

A hash map requires memory that scales linearly with the number of unique items, which becomes impossibly expensive at massive scale. A Count-Min Sketch uses a fixed amount of memory by trading exact precision for highly accurate estimates.

When I look at our ad network scenario, allocating even a tiny 4-byte integer for 20 trillion counters demands massive memory overhead. A Count-Min Sketch avoids this by acting as a bounded probability structure. It does not store the keys (the user-ad pairs) at all. Instead, it relies on hashing to map an infinite stream of events into a strictly bounded memory footprint.

How does a Count-Min Sketch algorithm actually work?

It uses a matrix of independent arrays and corresponding hash functions to generate a unique footprint for every item. When an item is processed, it is hashed multiple times to increment specific counters across the arrays.

The results from these hash functions act as a unique fingerprint for your item across the arrays.

Here is exactly how I break down the mechanics of inserting an item into a Count-Min Sketch:

The Structure: Initialize four separate arrays, each containing 1,024 empty integer counters.
The Hash Functions: Assign a unique, independent hash function to each of the four arrays.
The Hashing: Take your incoming item (like a user ID combined with an ad ID) and run it through all four hash functions.
The Update: Each hash function outputs a specific index for its assigned array. Go to that index in each array and increment the counter by one.

How do you read the frequency count from a Count-Min Sketch?

To retrieve a count, you hash the item again using the same functions, look up the values in each array, and return the lowest number. Because hash collisions only ever inflate numbers, the minimum value is the most accurate estimate.

When you want to query the count, you take your item and run it through the exact same four hash functions. This gives you the fingerprint of your four array locations, returning four different numbers.

Because multiple different items might hash to the same index (a collision), some counters will be artificially high. But a counter can never be lower than the true frequency of your item. Therefore, returning the minimum value across your arrays filters out the noise from collisions. You get a mathematical guarantee that you are never going to have an underestimate.

What is the accuracy of a Count-Min Sketch?

A Count-Min Sketch is highly accurate, often exceeding 99% accuracy depending on the configured width and depth. You can predictably increase accuracy by adding more arrays and hash functions.

The only error you will encounter is an overestimate caused by hash collisions. However, the math works out in your favor remarkably fast. With just four arrays of 1,024 elements, the error rate is incredibly small. If you scale this up to just eight arrays and eight hash functions, the difference between your estimate and the actual real count hits 99.9% accuracy. I find it crazy that this structure is capable of storing trillions and trillions of counters in a footprint so small it can literally fit in a CPU cache.

FAQ

What happens when a Count-Min Sketch gets full?

It never technically gets "full" because it has a fixed size in memory. However, as you add a massive volume of items, the arrays become saturated. This increases the likelihood of hash collisions, which eventually reduces the accuracy of your estimates by artificially inflating the counts.

Can you delete an item from a Count-Min Sketch?

Generally, no. Because multiple items share the same counters due to hash collisions, decrementing a counter for one item would likely corrupt the counts of other completely unrelated items that happen to hash to that same bucket.

What is the difference between a Count-Min Sketch and a Bloom Filter?

A Bloom Filter is a probabilistic data structure used to check if an item exists in a set (returning a boolean true or false). A Count-Min Sketch is used to estimate how many times an item has appeared in a stream (returning an integer frequency count).

Apple Secure Enclave: Face ID Security Explained

Doogal Simpson — Wed, 10 Jun 2026 15:38:05 +0000

Quick Answer: No, neither Apple nor the government can read your Face ID data. Your biometrics are processed entirely on-device within the Secure Enclave—a physically isolated subsystem with its own CPU and memory. The main processor never sees the raw data; it only receives a simple "yes" or "no" match confirmation.

As a software engineer, I am naturally skeptical when a massive tech company asks us to scan our faces to unlock our devices. The immediate architectural question is always: where does that data go, and who holds the database keys? The short answer is that there is no biometric database in the cloud. The way modern iPhones handle Face ID is actually an elegant lesson in hardware-level security and threat modeling. Let's break down exactly how this system is designed to ensure nobody—not even the engineers who built it—can access your raw biometric data.

What is the Apple Secure Enclave and how does it isolate data?

The Secure Enclave is a dedicated, tiny computer sitting inside the main system-on-chip of your iPhone. It operates with its own completely separate CPU, memory, and a stripped-down operating system that is entirely independent of iOS.

Think of your iPhone as a massive corporate office building. The main CPU and iOS handle everything from the public lobby traffic to the cafeteria logistics. The Secure Enclave, however, is a windowless, bank-vault room in the basement. It has its own power lines, its own security guard, and it explicitly does not trust anyone else in the building. Its sole responsibility is processing highly sensitive cryptographic operations. Because its memory is physically separated and heavily encrypted away from the main system architecture, an exploit in iOS does not automatically grant an attacker access to the enclave.

How does the iPhone process Face ID sensor data securely?

When you look at your phone, the camera module captures and immediately encrypts the biometric sensor data before passing it to the main CPU. The main CPU cannot read this data; it blindly routes the encrypted package to the Secure Enclave, which then decrypts it, checks for a match, and returns a simple boolean result.

To make this highly digestible, here is the exact lifecycle of a Face ID authentication request:

Capture: The TrueDepth camera reads your facial geometry and creates a map.
Hardware Encryption: The camera hardware encrypts this raw sensor data on the spot.
Blind Routing: The encrypted package is handed to the main CPU (which lacks the decryption keys).
Decryption & Processing: The Secure Enclave receives the package, decrypts it safely inside its isolated memory, and compares it against the stored mathematical model of your face.
Resolution: The Secure Enclave passes a true (match) or false (no match) back to the main CPU to unlock the device.

From a software perspective, the main CPU is essentially calling an asynchronous, black-box function that only ever returns a boolean. The main thread never has access to the underlying variables or state.

Why did Apple architect Face ID to be completely inaccessible?

Apple built the Secure Enclave this way to intentionally eliminate their own ability to access user biometrics. By making it architecturally impossible to retrieve the data, they protect themselves from being legally compelled to hand it over to governments or law enforcement.

In system design, we frequently talk about the principle of least privilege. Apple took this to the absolute extreme: zero privilege. If they had built a backdoor or a software hook to extract Face ID data for debugging, that exact same mechanism could be targeted by a legal subpoena. By deliberately throwing away the keys and keeping all processing strictly localized to a secure hardware component on the user's physical device, they avoid the situation entirely. When pressed by outside authorities, they can honestly respond that they simply do not possess the technical capability to fulfill the request.

FAQ

Does Face ID data get backed up to iCloud?

No. Face ID mathematical models never leave your physical device. They are never synced to iCloud, sent to Apple's servers, or even transferred over when you migrate your data to a new iPhone.

Can a software update modify the Secure Enclave to expose data?

The Secure Enclave runs its own bare-bones operating system that strictly limits its operational capabilities. While Apple can issue firmware updates to the enclave, its fundamental hardware architecture is designed to prevent it from ever exporting raw biometric data back to the main CPU.

What happens to Face ID data if I wipe my iPhone?

When you erase all content and settings on your device, the cryptographic keys stored inside the Secure Enclave are securely and permanently destroyed. This instantly renders any existing biometric models or encrypted device data permanently unreadable.

How Face ID Adapts to Beards and Facial Changes

Doogal Simpson — Wed, 10 Jun 2026 15:37:52 +0000

Quick Answer: Apple's Face ID doesn't rely on a single, static image. Instead, it stores a high-precision mathematical map of your facial geometry that continuously updates. Every successful unlock merges slight physical variations into your stored profile. For sudden, dramatic changes—like shaving a full beard—it falls back to your passcode to securely verify and register your new geometry.

I always find it fascinating how authentication systems handle edge cases. Have you ever wondered why Face ID doesn't suddenly lock you out just because you've aged a few years, gained a bit of weight, or decided to grow a beard?

As engineers, I think we can all appreciate how brittle static comparisons can be. If a security system expects byte-for-byte perfection, even a slight shift in environmental variables causes a failure. Face ID sidesteps this by treating your face not as a hardcoded static asset, but as a living, continuously updating dataset.

How Does Face ID Handle Gradual Facial Changes?

Face ID handles gradual changes by continuously merging new, successful scans into your existing biometric profile. Instead of a static check, every unlock acts as a micro-update to the mathematical model of your face.

Think of it like calculating a moving average in a time-series database. Face ID maps the geometry of your face down to the millimeter. When you attempt to unlock your phone, the system compares the current depth-map against its baseline. If the contours match within an acceptable threshold of confidence, the phone unlocks. But the operation doesn't stop at a simple boolean true or false.

The system takes the delta—the slight millimeter changes from your new stubble or weight shift—and merges it with the baseline data. Because this happens dozens of times a day, the model drifts perfectly in sync with your actual physical appearance.

What Happens to Face ID When You Shave a Beard?

When you drastically alter your appearance, Face ID detects a partial match but fails the overall confidence threshold, prompting a passcode fallback. Entering the correct passcode provides the secondary authorization needed to overwrite the biometric mismatch and register your new face shape.

Sudden transformations break that moving average we just talked about. Let's say you shave off a massive beard. The system scans your face and recognizes the unchanged data clusters—your forehead, your eye spacing, the bridge of your nose. However, the lower half of the geometry is completely foreign. Because the delta is too large, the system rejects the biometric authentication.

To bridge this gap, the software pivots to a fallback mechanism. Let's say you are building a fintech app. If a user suddenly logs in from a completely new IP address on an unrecognized device, you don't instantly lock their account; you ask for a two-factor authentication code. Face ID operates on the exact same logic. By entering your passcode, you provide deterministic proof of identity. The system then takes that heavily modified facial scan, attaches it to the secure passcode validation, and drastically updates your baseline model so you can seamlessly unlock your phone the next time.

How Does the Algorithm Respond to Different Severity Levels?

The Face ID algorithm classifies geometric variations into minor, gradual, and drastic changes based on match confidence thresholds. Minor or gradual shifts are handled invisibly by merging the new data, while drastic deviations trigger a hard security gate. Here is a quick breakdown of how the system resolves these varying scenarios:

Change Severity	Example Scenario	Biometric Match Confidence	System Resolution
Minor	Morning puffiness, 1-day stubble	High	Unlocks immediately and silently updates the mathematical model.
Gradual	Growing a beard over a few months	High (maintained by daily updates)	Unlocks immediately and incrementally shifts the baseline.
Drastic	Shaving a long beard, heavy bandages	Partial / Low	Rejects biometrics, prompts for passcode, then drastically updates model upon passcode success.

Frequently Asked Questions

Does Face ID store photos of my face?

Face ID does not store actual photographs of your face. It stores a mathematical representation of your facial depth map locally on the device's Secure Enclave, which cannot be reverse-engineered into an image file.

Why does Face ID sometimes require my passcode randomly?

Aside from drastic facial changes, iOS imposes strict time and failure-based limits to ensure the overall integrity of the device. For instance, the system will force a passcode fallback if the phone hasn't been unlocked in over 48 hours or has recently rebooted. It will also lock down and demand a PIN if it detects five consecutive unsuccessful biometric match attempts.

Can Face ID learn two completely different faces?

Yes, you can manually set up an "Alternate Appearance" in the iOS settings. This allows the system to maintain a secondary baseline model, which is highly useful if you regularly wear heavy, face-obscuring safety gear for work.

Optimize Your Codebase for AI Coding Agents

Doogal Simpson — Mon, 08 Jun 2026 14:02:21 +0000

TL;DR: Quick Answer
If your codebase doesn't contain the exact nouns and verbs you use to prompt your AI coding agent, the agent will do a much worse job. By ensuring your code reflects your spoken domain language, agents can map instructions directly to components, preventing them from generating messy, monolithic scripts.

If you're using a coding agent and your codebase does not contain the nouns and the verbs that you use to prompt the agent with, your agent will do a worse job. Period. I see this happen all the time. What do I mean by this? Let's say you're building a system that sells t-shirts online. You've got a bit where you have to take payment by calling a payment processor, a bit to update an order in a database, and a bit to send a message to a warehouse to ship the item.

Why do AI coding agents write monolithic scripts instead of modular code?

AI agents write monolithic scripts because they lack clear semantic hooks in your existing codebase. If your code doesn't explicitly define the business concepts you are prompting for, the agent defaults to a procedural list of database updates and API calls to satisfy the request.

As I'm describing that t-shirt store flow above, there are some clear nouns in there: order, payment processor, warehouse. There are also some verbs: take payment, create order, send message. I want to stress that you want all of these things to exist in your codebase as named verbs and nouns. If you just prompt an agent to build the system for you without any of that semantic structure already in place, you'll just get a long script. The AI will just make a raw API call, create a row in a database, and send a message all in one file. You won't have any of these concepts properly modeled.

How do nouns and verbs improve AI coding agent accuracy?

Explicit nouns and verbs allow the agent to map human-language prompts directly to specific classes and methods. When your prompt matches the structural language of your codebase, the AI understands your intent by conceptual analogy rather than just blindly grepping for syntax.

Think about what happens when you have all of these concepts written as first-class systems. The next time you prompt the agent—because you prompt it with human language, using nouns and verbs—you might say something like: "Every time taking a payment fails, roll the order back."

Because the structure is there, the agent is able to figure out, "Oh, you've prompted me with the noun order, and I can see in the codebase there's this thing called Order. You used the verb take payment, and there is a verb within this codebase called takePayment." It starts to search by analogy. This makes agents so much more effective at actually doing the thing you want it to do and not making mistakes.

// The agent can easily map natural language to this structure
class PaymentProcessor {
  async takePayment(orderId) { /* ... */ }
}

class Order {
  async create(items) { /* ... */ }
  async rollBack() { /* ... */ }
}

What are the best naming conventions for AI coding agents?

The best naming conventions treat your business domain as first-class citizens in the code. You should align your variables, classes, and function names exactly with the plain-English vocabulary you use when describing features to your team or your AI tools.

If you're refactoring your codebase, remember that your biggest context is your codebase itself, and it should reflect the nouns and verbs that you use to prompt it. Here is how that translation looks in practice:

Spoken Prompt Language	Poor Implementation (Procedural)	AI-Optimized Implementation (Nouns/Verbs)
"Take the payment"	`await fetch('https://api.stripe.com/charge')`	`paymentProcessor.takePayment()`
"Create the order"	`db.query('INSERT INTO orders...')`	`order.create()`
"Message the warehouse"	`axios.post('http://warehouse/api')`	`warehouse.sendMessage()`

If your current code looks like the middle column, you can ask an agent to refactor it into the format on the right. Once those nouns and verbs are established, every subsequent prompt will be drastically more accurate.

Frequently Asked Questions about AI Coding Agents

Does domain-driven design actually matter for AI?

Yes, absolutely. Domain-driven design (DDD) drastically improves AI coding assistants because it forces developers to use a ubiquitous language. When the codebase uses the same terminology you use in your prompts, the AI can seamlessly translate your natural language into the correct structural changes.

Why does my AI keep hallucinating functions that don't exist?

I usually see this happen when the agent understands your intent but cannot find the corresponding structural concepts in your codebase. If you ask an agent to "process a refund," but your code only has a generic database update query, the AI might invent a processRefund method because the noun and verb you prompted with were missing from the code entirely.

Can I just use an agent to fix my messy procedural code?

Yes, this is one of the highest-leverage ways to use an agent. You can prompt the AI to extract procedural scripts into dedicated classes and functions using specific nouns and verbs. Once refactored, the agent will have a much easier time navigating and modifying the code in the future.

Prompting AI Coding Agents to Write Clean Code

Doogal Simpson — Mon, 08 Jun 2026 14:01:56 +0000

Quick Answer: AI coding agents default to writing dense, monolithic scripts because they seek the path of least resistance to your desired outcome. To fix this, you must explicitly define what "good code" means for your project using concise, unambiguous, and highly opinionated rules stored in an agents.md file.

Imagine handing a feature ticket to a junior developer with zero architectural guidelines and walking away. You would expect a messy, monolithic pull request that technically works but is an absolute nightmare to maintain. That is exactly how AI coding agents operate out of the box.

I see developers getting frustrated with AI output all the time, complaining that the generated code is a dense wad of unreadable script. But the reality is that the agent is just giving you exactly what you asked for: a functional result, achieved via the absolute shortest path possible.

If you want better output, you have to engineer your environment to demand it.

Why do AI agents default to writing bad code?

AI agents output poor-quality code because they are optimized to reach a functional outcome through the path of least resistance. Unless instructed otherwise, they prioritize immediate execution over long-term readability, modularity, or architectural patterns.

By default, an LLM treats your prompt like a one-off task. It doesn’t automatically understand your project's separation of concerns, your naming conventions, or how you manage state. It just wants to get the feature working as fast as possible. If you don't explicitly ask for well-structured code, you are going to get a dense, monolithic script. That script will be difficult for you to read, and eventually, it will be difficult for other AI agents to read and modify in the future.

How can I force my AI agent to write clean code?

You need to instruct the agent with specific, opinionated rules about your codebase rather than just telling it to "write good code." Your instructions must clearly define your architectural preferences while remaining concise and unambiguous so the model doesn't get confused.

You can't just slap "make no mistakes and write clean code" at the end of a prompt. The agent is just guessing what "clean" means to you. You need to be deeply opinionated. Do you want early returns? Do you prefer functional programming principles or object-oriented classes? You have to lay out exactly what "better code" looks like in your specific environment.

However, tokens are a real constraint. If you overload the agent with a massive wall of text, or if you provide advice that contradicts itself, the agent will get confused and hallucinate. Conciseness and clarity are non-negotiable.

What is the best way to structure AI coding guidelines?

The most effective approach is a two-tier documentation system: a highly detailed reference document in your codebase for deep context, and a summarized, punchy Markdown file that the agent reads by default. This keeps the token count low while providing a fallback for complex refactors.

Here is how I recommend breaking down your guidelines so the agent stays on track without blowing up your context window:

Document Type	File Location	Purpose	Detail Level
The Rules Engine	`agents.md` (or `.cursorrules`)	The default file the agent reads on every prompt. Keeps the agent aligned with core patterns.	Summarized. Bullet points, hard constraints, and extremely concise opinions.
The Deep Context	`/docs/architecture.md`	A fallback reference used only when the agent veers off track or tackles a major refactor.	Detailed. In-depth explanations of how the codebase is laid out and why.

I generally have my long-form, detailed version of how I want my codebase to be laid out sitting safely in a docs folder. Then, in my agents.md file, I keep a tightly summarized version.

By default, the agent reads the agents.md file and does a reasonable job keeping the code clean. If I find that the agent is starting to veer away from the architecture I want, I don't argue with it in the chat. Instead, I explicitly point it toward the detailed docs folder to realign its context.

Frequently Asked Questions

What should I include in my agents.md file?

Keep it strictly to your non-negotiable coding standards. Include rules on file structure, preferred libraries, naming conventions, and specific patterns to avoid (like "never use nested ternaries" or "always extract API calls to a service layer").

Does giving an AI too many coding rules break its output?

Yes. Providing overly verbose or contradictory rules overloads the context window, causing the agent to lose focus on the actual task. This is why keeping your default instructions concise and unambiguous is critical for stable performance.

How do I stop my AI agent from ignoring my system prompts?

If the agent ignores your rules, your instructions might be too vague or conflicting. Ensure your agents.md uses strong, directive language (e.g., "Always do X", "Never do Y") and temporarily point the agent to your detailed docs folder to reinforce the structural requirements.

Why COBOL Still Powers Modern Banking Systems

Doogal Simpson — Mon, 08 Jun 2026 14:01:29 +0000

Quick Answer: COBOL still runs 95% of ATM transactions and 43% of banking systems because replacing it is overwhelmingly risky and expensive. Originally adopted in the 1960s for its readable, English-like syntax, COBOL became the foundation of financial business logic. Today, modern languages are simply layered on top of this legacy core.

Next time you pull cash out of an ATM, take a second to think about the software architecture making that transaction happen. I often hear engineers assume their request is hitting a modern Go microservice or a highly optimized Rust backend.

The reality is much older. That transaction is almost certainly passing through a piece of software written in a programming language from 1959.

COBOL (Common Business-Oriented Language) is over 60 years old, yet it refuses to go away. Despite decades of new frameworks and paradigms, it remains the core of global finance. Let's look at why this old language still runs the majority of our banking systems today.

Why is COBOL still used in banking systems today?

COBOL remains deeply embedded in finance because ripping it out poses a massive operational and financial risk to institutions. Over decades, banks built their core business logic on this language, meaning modern applications are typically just layered on top of a legacy COBOL foundation.

The sheer volume of legacy code is hard to wrap your head around. There are roughly 220 billion lines of COBOL still sitting in production environments right now. Over the years, instead of replacing it, banks started adding Java, Python, and other modern languages into their stack.

What happens in practice is that a mobile app request hits a modern API, which then routes through various middleware layers, until it eventually talks to the COBOL core to actually move the money. You have a situation where the core of these old systems is entirely COBOL. Touching that foundation is incredibly risky, so the industry just keeps building around it.

COBOL's Footprint in Modern Finance

Metric	Percentage
ATM Transactions	95%
In-Person Banking Transactions	80%
Active Bank Adoption	43%

What made COBOL so popular for business logic in the 1960s?

COBOL was explicitly designed to read a bit like plain English. This readability allowed non-technical managers to review the code and verify it was executing the correct business rules.

In the 1960s, 70s, and 80s, bridging the gap between business requirements and technical execution was a major priority for businesses. If you were writing financial software, you wanted managers to come along, look at what you wrote, and say, "Okay, I think I understand what this thing is doing, and I can verify this is what I want it to do."

Because of this management-friendly approach, banks and massive corporations wrote nearly all of their business logic in COBOL. It solved a communication problem between the business side and the engineering side. The adoption was so widespread that by 1997, 80% of all business logic globally had been written in it.

Why is migrating away from COBOL so difficult for banks?

Migrating legacy banking systems requires translating decades of complex, undocumented business rules into modern languages without breaking a live financial network. For technical leaders, the massive cost and high risk of failure usually outweigh the benefits of modernization.

Imagine you are a bank's CTO and the board asks what project you want to prioritize next year. You could propose a complete COBOL replacement project. But realistically, migrating software that has been patched and modified for 40 years is highly likely to go wrong. If it breaks, transactions stop, regulators get involved, and you will probably lose your job. Most leaders look at that risk and decide to leave the migration for later.

When a bank actually commits to a rewrite, the undertaking is massive. For example, the Commonwealth Bank of Australia spent five years and three-quarters of a billion dollars to finally get rid of their COBOL. They did it eventually, which is a great engineering achievement. However, other institutions have tried to replace their COBOL and failed, burning millions of dollars in the process before reverting to the mainframe. It is simply very expensive and highly risky to get rid of this stuff.

Frequently Asked Questions

Can we automatically translate COBOL to Java or Python?

While there are automated transpilers and AI tools that can convert COBOL syntax into Java or Python, they generally produce code that is hard to maintain. More importantly, automated tools cannot untangle decades of undocumented business logic, which still requires engineers to manually test and verify.

Are there still developers writing new COBOL code?

Yes, though they are rare. Most modern COBOL work is strictly maintenance, bug fixing, or writing API wrappers to allow modern web applications to communicate with the legacy systems, rather than building completely new standalone COBOL applications from scratch.

What happens if a bank's COBOL system fails?

If a core COBOL system goes offline, the bank effectively stops processing transactions. ATM withdrawals halt, card transactions are declined, and inter-bank transfers queue up or fail entirely until the system is restored, which is why banks invest heavily in maintaining these environments.

How OLED & LTPO Enable Always-On Displays

Doogal Simpson — Sun, 07 Jun 2026 17:05:54 +0000

TL;DR: Always-on displays don’t drain your phone battery because they rely on two hardware advancements: OLED panels and LTPO technology. OLEDs save power by physically turning off pixels to display black backgrounds. Meanwhile, LTPO allows the screen’s refresh rate to drop to 1Hz, preventing the CPU from constantly waking up.

I often glance down at my phone sitting on my desk. The screen is technically "sleeping," but the time and a few notification icons are still glowing brightly. As a software engineer, I know that powering a display is usually the most expensive operation on a mobile device. So why doesn't this "always-on" state completely tank my battery by lunchtime?

It comes down to two specific hardware technologies doing heavy lifting in the background: OLED and LTPO.

How do OLED screens save battery on lock screens?

OLED screens save battery by physically turning off individual pixels to display the color black. Since the majority of an always-on lock screen is black, the phone only draws power for the few active pixels showing the time or notifications.

To understand why this matters, I always think about traditional LCDs. Let's say you have an application with a dark mode interface running on an LCD device. To show black, the screen's backlight still blasts at full power, and the liquid crystals just block the light from passing through. It's like leaving the main power breaker on in your house and throwing a heavy blanket over the lamps to make a room dark. You're still paying for the electricity.

OLED (Organic Light-Emitting Diode) panels are fundamentally different. Every single pixel generates its own light. If a pixel needs to be black, it just shuts off entirely. When my phone enters its resting state, roughly 95% of the display is physically powered down.

Why is the CPU the real battery drainer for phone screens?

The display panel itself is only part of the power consumption equation; the CPU driving it is the real battery killer. Traditional screens require the CPU to wake up 60 times a second just to tell the display what to render, which prevents the processor from staying in a deep sleep state.

Even if most of the pixels are turned off because of OLED tech, standard OLEDs still have a fixed refresh rate of 60Hz. Imagine you have a background worker polling a database every 16 milliseconds just to see if a value changed. That constant polling overhead is going to chew through your resources. For a phone, waking the CPU up 60 times a second just to render a static clock is incredibly inefficient. I find that the problem isn't the active pixels—it's the CPU thrashing.

What is an LTPO display and how does it reduce battery usage?

LTPO (Low-Temperature Polycrystalline Oxide) is a backplane technology that improves how capacitance is stored within a pixel, allowing the screen's refresh rate to dynamically scale. For always-on displays, LTPO can drop the refresh rate down to just 1Hz, meaning the CPU only wakes up once per second.

By holding the charge longer, the display doesn't need constant hand-holding from the processor. Instead of waking up 60 times a second, the CPU fires up just once a second to update the minute on the clock or pulse a notification icon. Going from 60 wake-ups a second down to one is a massive reduction in compute cycles. This allows the device to stay in a low-power state almost indefinitely while still showing you relevant information.

Display Technology Power Breakdown

Display Tech	Black Pixel Behavior	Refresh Rate	CPU Wakeups / Sec	Battery Impact for Always-On
Standard LCD	Backlight stays on, blocks light	Fixed 60Hz	60	Severe
Standard OLED	Pixels physically turn off	Fixed 60Hz	60	Moderate
LTPO OLED	Pixels physically turn off	Dynamic (down to 1Hz)	1	Minimal

FAQ

Does always-on display cause screen burn-in on OLEDs?

No, modern always-on displays prevent screen burn-in through software tricks. The operating system will imperceptibly shift the position of the clock and icons by a few pixels every minute, ensuring no single pixel is left on for extended periods.

Can LCD screens support an always-on display?

Technically yes, but practically no. Because an LCD requires the entire backlight to be illuminated to show even a single white pixel of text, an always-on state would drain the battery exactly as fast as if you were actively using the phone.

How much battery does an always-on display actually use?

With LTPO and OLED technology combined, an always-on display typically consumes about 1% to 2% of your battery life per hour. If you leave your phone sitting untouched for an entire 8-hour workday, you might only lose around 10% of your total capacity.

Why Mobile CPUs Have Performance & Efficiency Cores

Doogal Simpson — Sun, 07 Jun 2026 17:05:38 +0000

Quick Answer: Unlike traditional laptops that rely on a single type of power-hungry CPU core, modern mobile phones use a hybrid architecture combining high-performance cores with low-power efficiency cores. The operating system dynamically shifts workloads between them, using performance cores for intensive tasks like gaming, and efficiency cores for background tasks, ultimately maximizing battery life.

I constantly see developers obsessing over raw processing speed. But as a software engineer writing code for these devices, I always emphasize one harsh reality: in the mobile world, raw speed is completely useless if the device dies in thirty minutes. Imagine building a sports car that can hit 200 miles per hour, but it only holds a single gallon of gas. You'd have a blast for about a minute before you're stranded on the side of the road. That is the exact challenge hardware engineers face when designing modern mobile CPUs.

When I look at traditional computers, like older laptop architectures, they typically rely on one type of CPU core. It’s powerful, it gets the job done, but it is incredibly energy-hungry. Mobile phones don't have the luxury of a massive battery or an AC adapter plugged into the wall, so they had to adopt a completely different architectural approach to survive a full day off the charger.

Why do mobile phones have different types of CPU cores?

Mobile phones use different types of CPU cores to solve the competing demands of high-end processing speed and all-day battery life. By pairing "performance" cores with "efficiency" cores, the device can physically switch processing engines based on how demanding the current workload is.

I like to think of it like a hybrid vehicle. When you are cruising through a slow suburban parking lot, the car uses a small electric motor that sips energy. But the second you merge onto a fast highway, the combustion engine kicks in to give you the necessary power. Mobile CPUs do the exact same thing with the code we write.

How do performance cores and efficiency cores compare?

Performance cores run at higher clock speeds and consume significantly more power, whereas efficiency cores operate at lower speeds but offer vastly superior performance-per-watt. The efficiency cores are deliberately designed to be "worse" at raw speed so they can handle lighter background loads without needlessly draining the battery.

To put this into perspective, let’s look at the Apple A17 Pro chip. It utilizes a split architecture consisting of two performance cores and four efficiency cores.

Core Type	Core Count	Clock Speed	Power Draw	Efficiency Ratio
Performance	2	3.78 GHz	~8 Watts	Standard
Efficiency	4	2.00 GHz	~1.5 Watts	~5x more performant per watt

Looking at those numbers, I find it fascinating that the efficiency cores only draw a fraction of the power but still deliver respectable clock speeds. In fact, those efficiency cores end up being about five times more performant per watt than their high-speed counterparts.

How does the operating system decide which core to use?

The operating system acts as a traffic controller, constantly analyzing the real-time demands of running applications and routing instructions to the appropriate CPU core. High-priority, foreground tasks get routed to performance cores, while background tasks get handed off to efficiency cores.

Let's say you and I are building a mobile 3D game. When the user is actively playing, rendering heavy graphics, and interacting with the screen, the OS routes that workload to the performance cores. We get all the raw speed we need to keep the frame rate high and the gameplay smooth.

But what happens when the user locks their phone and puts it on the desk? The device still needs to stay awake enough to receive a text message or ping our server for push notifications. The OS recognizes this low-priority state and routes those background tasks exclusively to the 1.5-watt efficiency cores. The phone processes the data perfectly fine, but it isn't burning through battery power to do it.

Why isn't "more CPU cores" always better for mobile?

Simply adding more high-powered cores to a mobile device generates too much heat and drains the battery faster than the system can physically handle. True mobile optimization is about having the right type of core available when you need it, rather than just maximizing the total core count.

I often hear the misconception that "more CPUs is better," but that is only half right. If we crammed eight massive performance cores into a phone, it would thermally throttle within minutes. What I always look for in mobile engineering is highly targeted CPU efficiency—giving you the power exactly when you need it the most.

Frequently Asked Questions

Can software developers force the OS to use a performance core?
Generally, no. Modern operating systems abstract hardware scheduling away from the application layer. I recommend assigning different Quality of Service (QoS) priorities to your threads (like marking a thread as "user-interactive" versus "background"), which heavily hints to the OS where the work should go, but the system makes the final hardware routing decision.

Do modern laptops use efficiency cores now?
Yes. While older laptops relied on a single core type, modern laptop processors (like Apple's M-series or Intel's newer chips) have adopted this exact hybrid big.LITTLE architecture to improve battery life without sacrificing desktop-level performance.

What happens if all the efficiency cores are fully utilized?
If the efficiency cores are completely saturated with background tasks and a new process spins up, the OS scheduler will begin pushing workloads onto the performance cores to prevent system lag. The OS prioritizes keeping the device responsive, even if it means a temporary hit to battery life.

Amdahl's Law: Why More CPU Cores Don't Make Code Faster

Doogal Simpson — Sun, 07 Jun 2026 17:05:24 +0000

Quick Answer: Amdahl's Law dictates that the maximum speedup of a parallelized program is strictly limited by the portion of its code that must run serially. If one-third of your application relies on sequential operations like resource locking, your maximum possible speedup is exactly 3x—regardless of whether you use 8 or 64 CPU cores.

You're really excited. You just dropped serious cash on a shiny new 8-core CPU. You compile your heavy workload, spin it up, and eagerly watch the execution time drop. But wait—it's only running three times faster than it did on your old single-core setup.

Assuming it’s a hardware bottleneck, you empty your wallet for a massive 64-core beast. I often see developers make this assumption: more cores means more speed, right? Yet when you run the program again, you're even more disappointed to find it still caps out at exactly three times faster.

What is happening here? You’ve just run headfirst into Amdahl's Law.

What is Amdahl's Law in software engineering?

Amdahl's Law is a principle that calculates the theoretical maximum performance improvement of a system when only a part of that system is optimized. When I explain this concept to other engineers, I emphasize that it proves the speed of a parallelized program is ultimately capped by the percentage of its code that must execute sequentially.

If a third of your program is serial code, the absolute maximum speedup you can achieve is three times. It mathematically defines the ceiling on how fast a program can run based entirely on the proportion of code that simply cannot be parallelized.

Why does serial code limit parallel processing speed?

Serial code creates a hard mathematical ceiling because certain operations must happen one after another to maintain data integrity. When parallel threads hit a shared resource and have to wait in line, adding more CPU cores yields zero additional speed because those extra cores are just sitting idle in the queue.

Programs inevitably have some amount of their makeup that is inherently serial. If you have shared state in your application, running multiple parallel processes against it without guardrails will corrupt your data. To prevent this, we introduce locks on shared resources.

Imagine your team is building a ticketing system for a massive stadium tour. Thousands of users can browse seats in parallel, but the actual checkout process requires a strict lock to ensure two people don't buy the exact same front-row seat. That checkout lock is serial. There is always some amount of your program that simply cannot be run in parallel, and that puts a permanent ceiling on how much throwing more hardware at the problem actually helps.

How does the serial proportion impact maximum speedup?

The theoretical speed limit of your application is inversely proportional to the fraction of its serial execution time. As you add an infinite number of cores, the parallel execution time approaches zero, leaving only the serial execution bottleneck.

I put together this quick breakdown to show how that mathematical ceiling plays out based on the serial makeup of your code:

Proportion of Serial Code	Maximum Theoretical Speedup (Infinite Cores)
1/2 (50%)	2x
1/3 (33.3%)	3x
1/4 (25%)	4x
1/10 (10%)	10x
1/20 (5%)	20x

This demonstrates why the concept of "more cores is more fast" is ultimately a lie. You cannot just throw more cores at a system forever. To actually make your application faster once you hit this hardware ceiling, you have to do the hard engineering work of refactoring your architecture to reduce shared state, minimize lock contention, and shrink that serial footprint.

Frequently Asked Questions

How is Amdahl's Law different from Moore's Law?

Moore's Law is an observation about hardware scaling over time, stating that the number of transistors on a microchip doubles roughly every two years. Amdahl's Law is a mathematical formula regarding software execution, defining the strict limits of parallelizing a specific workload regardless of how powerful the hardware is.

Does Amdahl's Law apply to distributed microservices?

Yes. In distributed systems, network latency, synchronized database writes, and single-threaded message queues act as the serial bottlenecks. Even if you spin up hundreds of container replicas, the system can only process requests as fast as the slowest sequential dependency allows.

What is Gustafson's Law?

Gustafson's Law is the counter-argument to Amdahl's Law. It suggests that as developers get access to more computing power, they don't just run the exact same problems faster; they increase the size and complexity of the problem. As the problem size grows, the parallel portion of the workload usually scales up while the serial portion remains relatively fixed, improving the overall efficiency of adding more cores.

Why Quantum Computers Won't Replace Classical Computing

Doogal Simpson — Sat, 06 Jun 2026 08:30:08 +0000

Quick Answer: Despite the hype, quantum computers are not faster general-purpose replacements for classical machines. While a standard $400 smartphone can perform basic arithmetic millions of times faster than a quantum computer, quantum machines remain highly specialized tools designed exclusively for complex mathematical tasks like factoring large primes and breaking encryption.

I constantly see engineers assume that "quantum" is just a synonym for "infinitely faster." We hear about a 1,000-qubit computer that costs $10 million, requires temperatures colder than deep space to function, and we naturally expect it to run our web servers and game engines at warp speed.

But if I take a regular $400 smartphone and ask it to multiply two numbers, it will completely smoke that quantum computer. Let me break down why quantum computers are actually terrible at doing the things we write code for every day.

Are quantum computers faster than classical computers?

No, for general-purpose computing, quantum computers are massively slower than the device sitting in your pocket right now. A standard smartphone can execute basic mathematical operations millions of times faster than a quantum computer.

If I ask a $400 phone to multiply two numbers together, the processor handles it in picoseconds. Hand that exact same operation to a 1,000-qubit quantum computer, and it takes microseconds to complete. That makes the quantum computer roughly 10 million times slower at basic arithmetic.

Think of it like comparing a commuter car to a massive mining excavator. If I need to drive to the grocery store, the car gets me there efficiently. The excavator tops out at a crawl, burns a ton of fuel, and is entirely the wrong tool for the job. Classical computers are the commuter cars. They are perfectly optimized for adding, sorting arrays, running web browsers, and serving web traffic. If you try to run standard software architectures—like a neural network or a basic CRUD app—on a quantum machine, it simply will not work.

What are quantum computers actually good for?

Quantum computers excel at a very small number of highly specialized mathematical jobs rather than general application execution. Their most famous use case is quickly factoring massive prime numbers to break encryption protocols like RSA 2048.

Classical computers fundamentally struggle with factoring large primes. If I try to write a script to crack modern RSA encryption using standard brute-force computation on classical silicon, it would take an absurdly long time. Classical architecture isn't built to evaluate those distinct mathematical possibilities efficiently.

Quantum computing flips this problem on its head. By leveraging qubits, I can essentially nudge them into an arrangement that solves the prime factoring problem incredibly fast.

Here is a quick breakdown of how classical and quantum machines compare across different engineering workloads:

Workload / Operation	Classical Computer (Standard Silicon)	Quantum Computer (Qubits)
Basic Arithmetic (Multiplication)	Picoseconds	Microseconds (10M times slower)
Web Browsing & Application Logic	Highly Optimized	Completely Inefficient
Sorting Algorithms	Highly Optimized	Impractical
Factoring Large Primes (RSA 2048)	Centuries / Millennia	Exceptionally Fast
Operating Temperature	Room Temperature	Colder than Deep Space

Will quantum computers replace regular computers?

No, quantum computers will never serve as a catch-all replacement for classical computers. They are the next wave of specialized computation, meant to act alongside traditional silicon rather than replace it entirely.

I never expect to see a quantum laptop for writing React code or running Docker containers. Instead, the future of our industry points toward hybrid architectures. Let's say your team is building a fintech application that hits a highly specific, computationally dense mathematical problem. You will run your standard infrastructure on classical machines, and when your system hits that bottleneck, it will offload that single task to a quantum co-processor. Quantum is not a generic upgrade; it is a specialized tool for very specific use cases.

Frequently Asked Questions

Can quantum computers run standard software and operating systems?

No, quantum computers cannot run standard software like Linux, web browsers, or video games. Traditional software compiles into binary instructions designed for classical transistors, whereas quantum computers rely on quantum logic gates manipulating qubits.

Why do quantum computers need to be so cold?

Quantum computers must operate at temperatures near absolute zero to maintain the delicate state of their qubits. Any ambient heat or electromagnetic interference from the environment causes "decoherence," which collapses the quantum state and introduces massive calculation errors.

Is RSA encryption useless now that quantum computers exist?

Not yet. While quantum computers theoretically have the capability to break RSA 2048, current quantum hardware does not yet have enough stable, error-corrected qubits to execute this at scale. However, the tech industry is already moving toward quantum-resistant cryptographic algorithms to prepare for when the hardware inevitably catches up.

Spotify's Approximate Nearest Neighbor Search

Doogal Simpson — Sat, 06 Jun 2026 08:29:20 +0000

Quick Answer: Spotify skips exact nearest neighbor calculations because searching hundreds of millions of tracks is too slow. Instead, it uses an approximate nearest neighbor (ANN) approach. By structuring data in a multi-layered graph, the algorithm uses data "highways" to rapidly traverse the dataset, narrowing down the local neighborhood instantly to deliver fast recommendations.

You just finished listening to a track, and before you can even think about what to queue up next, Spotify seamlessly transitions into a song that perfectly matches the vibe. It feels like magic, but under the hood, it is a massive engineering challenge.

How do you figure out the absolute best next song when you have a catalog of hundreds of millions of tracks? If you do this the naive way, the database lookup would take far too long to keep the music playing smoothly. Here is how recommendation algorithms actually handle data at that scale.

Why doesn't Spotify use exact nearest neighbor search?

Exact nearest neighbor (KNN) algorithms calculate the mathematical distance between your current song and every single other song in the database to find the closest match. When a catalog hits hundreds of millions of records, computing these distances for every user query becomes incredibly data-intensive and far too slow for real-time playback.

Imagine your system is trying to find a high-energy dance remix. If the algorithm has to literally measure the distance from that track to every acoustic indie song, heavy metal track, and classical symphony in existence just to rule them out, the latency spikes. To keep the infrastructure costs sane and the user experience immediate, you have to abandon the idea of finding the absolute perfect match and settle for finding an incredibly close match, incredibly fast.

How does approximate nearest neighbor (ANN) search work?

Approximate nearest neighbor (ANN) search algorithms trade a tiny fraction of accuracy for massive performance gains by organizing data into navigable, multi-layered graphs. Instead of scanning the whole database, the algorithm drops into a top-level map with very few points and travels across massive distances, stepping down through layers of increasing density until it finds the right local neighborhood.

I like to picture this data structure as a real-world roadmap. At the very bottom level, every single song in the catalog lives on a map, clustered roughly by genre, tempo, or mood. Up in the "pop" neighborhood, all those songs are connected to each other by tiny minor roads or bridges.

Instead of making the algorithm drive through every single minor road to find a destination, we build layers on top of it:

Graph Layer	Map Analogy	Node Density	Navigation Distance
Top Layer	Highways / Motorways	Very Low (Few Songs)	Massive (Cross-genre jumps)
Middle Layer	Major Roads	Medium	Moderate (Sub-genre travel)
Bottom Layer	Minor Roads / Bridges	High (All Songs)	Small (Track-to-track)

How does the algorithm traverse this layered data?

The search starts at the highest, sparsest layer of the graph and looks for the nearest node before dropping down to the next level. It repeats this process, stepping down from highways to major roads to minor roads, naturally zeroing in on the correct cluster.

Let's say your song finishes. The system queries that top layer. It grabs a highway and travels a massive distance to reach the general vicinity of the target sound. Now that it is in the right neighborhood, it drops to the middle layer. It travels along major roads to get even closer to the specific vibe. Finally, it drops to the bottom layer where all the songs live, taking minor roads to bounce between a few highly relevant tracks until it finds the closest available neighbor.

Is approximate search accurate enough for music recommendations?

Yes, for recommendation systems, an approximate nearest neighbor is more than good enough because the user cannot tell the difference between a 99% match and a 100% match. The algorithm might skip over the theoretical exact nearest neighbor, but the track it outputs will still be mathematically adjacent to it.

In software engineering, you constantly weigh computational cost against user value. Spending massive amounts of CPU time to find the absolute mathematically closest song offers zero perceivable benefit to the listener. Traversing a layered graph cuts the search time down exponentially, keeping the music playing without a hiccup.

Frequently Asked Questions

What is the difference between KNN and ANN?

Exact K-Nearest Neighbors (KNN) scans the entire dataset to compute the exact distance between the query and every possible point, guaranteeing absolute accuracy at the cost of speed. Approximate Nearest Neighbors (ANN) uses structured indexes (like graphs or trees) to quickly hone in on the right neighborhood, prioritizing extreme speed over perfect accuracy.

Do graph-based search algorithms consume a lot of memory?

Yes, algorithms that rely on multi-layered graphs, such as Hierarchical Navigable Small World (HNSW), require a significant memory footprint because they have to store all the connections (edges) between the nodes at multiple layers. However, the trade-off in ultra-low latency query times makes the memory cost worthwhile for large-scale consumer applications.

Why not use a standard relational database for song recommendations?

Standard relational databases are designed for structured querying (e.g., finding exact matches for "Artist = Daft Punk"). Recommendations rely on vector embeddings—complex arrays of numbers that represent the "vibe" or audio features of a song. Relational databases cannot efficiently calculate the distance between these high-dimensional vectors at scale.

How Face ID Works: Infrared Lasers & Neural Networks

Doogal Simpson — Mon, 11 May 2026 14:15:22 +0000

TL;DR: Face ID does not compare standard selfies to unlock your phone. Instead, it projects 30,000 infrared laser dots onto your face to create a highly precise 3D geometry map. A neural network converts this map into a mathematical feature vector, comparing it to your saved profile to authenticate your identity.

Most people think their phone unlocks by snapping a quick selfie and playing a game of spot-the-difference. I get it—from a user perspective, that’s exactly what it feels like. But under the hood, modern facial authentication relies on an entirely different stack of hardware and software. It’s not looking at your face; it’s reading your face's topography like a surveyor mapping a mountain range. Let's break down the actual engineering happening in the fraction of a second it takes to unlock your screen.

How does Face ID map your face in the dark?

Face ID uses infrared (IR) light instead of the visible light spectrum to detect depth. By projecting 30,000 microscopic infrared laser dots onto your skin, the system can operate flawlessly even in pitch-black conditions. This hardware approach creates a highly accurate 3D topographic map of your features.

Visible light cameras are useless without an external light source. If you’ve ever tried to build a computer vision pipeline using a basic webcam in a dark room, you know the struggle. To bypass this environmental limitation, facial recognition systems use an infrared emitter. Think of it like dropping a massive, invisible net of laser points over your face. As these dots hit your nose, cheekbones, and jawline, they scatter. Because the hardware knows exactly when and where these dots were fired, it can measure how they scatter to map the exact contours of your face down to half a millimeter of distance.

What happens to the scattered infrared data?

A dedicated infrared sensor captures the scattered light to build a raw 3D geometry map. This physical map is then fed into an onboard neural network to be translated into a mathematical format called a feature vector. This vectorization allows for instantaneous mathematical comparisons rather than heavy spatial rendering.

Raw infrared scatter isn't incredibly useful on its own for fast database lookups. Comparing two raw point clouds containing 30,000 spatial coordinates takes significant compute power, and a mobile CPU would choke trying to execute that matrix operation instantly. Instead, the local neural network performs dimensionality reduction. It takes this massive spatial geometry map and compresses it into a highly specific, lightweight array of numbers.

If you imagine a hashing algorithm turning a massive file into a short string, a feature vector is a similar concept, but optimized for physical spatial data. When the device authenticates you, it's essentially running a fast mathematical distance calculation between the live vector and the originally stored vector. If the distance between these two arrays of numbers falls within a strict geometric threshold, the neural network confirms your identity. It is a highly efficient boundary check rather than a heavy pixel-by-pixel image comparison.

What are the steps in the Face ID authentication pipeline?

The pipeline operates as a real-time hardware-to-software relay, transforming physical light into mathematical security tokens. It starts with infrared emission and reflection, moving into depth mapping, and finally executes neural network vectorization to determine a match. Here is exactly how the data flows from the sensor to the CPU during a single authentication request:

1. Emission: The dot projector fires 30,000 infrared lasers at the target surface.
2. Reflection: The lasers scatter based on the physical depth and contours of the face.
3. Capture: An infrared camera reads the distorted dot pattern.
4. Mapping: The system constructs a 3D geometry map from the captured depth data.
5. Vectorization: A neural network translates the 3D map into a unique feature vector.
6. Comparison: The system calculates the mathematical distance between the new vector and the originally saved lock-screen vector to approve or deny access.

Why can't you trick Face ID with a photograph?

A printed photo or a digital screen is a two-dimensional flat plane lacking any physical depth. Because Face ID authenticates based on 3D geometry rather than visual appearance, a flat surface immediately fails the depth check. The resulting depth map simply doesn't match human topography.

Let's say your team is building a fintech app that handles high-value wire transfers. If your internal biometric authentication relied purely on pixel-based visual matching (like a standard webcam feed), a malicious actor could bypass it simply by holding a high-resolution iPad photo of the victim to the lens.

But because Face ID relies on infrared depth mapping, holding up a screen or a printed photo just looks like a perfectly flat sheet of glass or paper to the IR sensor. The neural network expects to see a nose protruding several centimeters and eye sockets recessed into the skull. A flat plane produces a geometry map with zero depth delta. When that flat map is vectorized, the resulting embedding lands miles away from the authorized feature vector in the latent space, and the system instantly denies access.

What else do developers ask about Face ID?

When integrating biometric security, engineers often have secondary questions about privacy limits and hardware edge cases. Understanding how the device stores data and adapts to changes helps clarify system limitations. Here are three common follow-up queries regarding the lifecycle of a facial feature vector.

Does Face ID store photos of my face?

No, the system does not store visible light images or full 3D point clouds of your face. It only retains the mathematical representation, or feature vector, derived from your facial geometry. This vector is securely locked away on the device's hardware enclave and never leaves the phone.

Can Face ID adapt if I wear glasses or grow a beard?

Yes, because it relies on a neural network and feature vectors, the system continuously updates its mathematical model. If a newly generated vector is close enough to authenticate you, the system subtly adjusts the stored baseline vector. This accounts for gradual physical changes over time without requiring a manual reset.

How accurate is the infrared dot projector?

The hardware is exceptionally precise, mapping facial contours with a distance accuracy down to half a millimeter. This ensures that even the most minor topographic depth variations are captured and fed into the neural network. As a result, geometric spoofing of the authentication system is incredibly difficult.