Open Task Manager and you see processes; read developer docs and threads come up. Both seem like “something that runs,” but what exactly sets them apart?
If I had to name the most common technical interview question, this would be it: “Explain the difference between a process and a thread.”
The reason it comes up so often is simple: this one question checks memory structure, operating systems, and concurrency in one go.
This article explains the difference between the two from a memory-structure perspective and covers how far you should go in an interview answer.
Let’s start with the essentials.
- Process: A running program. It receives an entire independent memory space.
- Thread: An execution flow inside a process. It has its own stack and shares the rest.
- Sharing makes threads lightweight and fast, but it also creates data races.
- Processes are isolated and safe, but correspondingly heavier and more cumbersome to communicate between.
Process: A Running Program
A program is a block of code stored on disk. It is not doing anything yet.
The moment you run it, the operating system loads it into memory and prepares to assign CPU time. That “running program” is a process.
The operating system gives each process an entire independent virtual memory space. It has four main regions.
| Region | Contents |
|---|---|
| Code (Text) | Machine code to execute |
| Data | Global and static variables |
| Heap | Memory allocated dynamically at runtime |
| Stack | Function-call information and local variables |
The important word here is “independent.” Process A cannot inspect process B’s memory. The operating system blocks it at the source.
That is why one process can crash while the others remain fine. Chrome launches a separate process for each tab for this reason. One crashed tab does not bring down the entire browser.
Thread: An Execution Flow Inside a Process
A thread is the unit of execution flow that actually runs code inside a process. Every process starts with at least one thread—the main thread.
The key is what gets shared. Threads in the same process share the code, data, and heap regions, while each has its own stack.
The reason each thread has its own stack is clear: it records which function is currently executing and how far it has progressed, so every execution flow needs one.
Because the heap is shared, threads can exchange data immediately through a variable. No separate communication procedure is needed.
Why Use Threads? It’s About Cost
You might think, “If I want to do several things at once, why not launch several processes?” The issue is cost.
Creation cost. Creating a process requires preparing an entire independent memory space. For a thread, adding one stack is enough.
Switching cost. When the CPU moves to another process, it must replace the entire memory map (context switching). Switching threads within the same process is much lighter.
Communication cost. Processes must use IPC (inter-process communication), such as pipes or sockets, to exchange data. Threads can simply read the same variable.
In short, a thread is the unit for doing several things at once with low overhead.
Nothing Is Free: Data Races
Every advantage of threads comes from sharing memory, and their biggest weakness comes from exactly the same place.
If two threads write to the same variable at the same time, the result is unpredictable. That is a data race.
Even one-line code such as count += 1 is internally three steps—read, add, and write—so overlapping threads can make an increment disappear in practice.
That is why synchronization tools such as locks and semaphores are needed. Misusing them opens the door to another nightmare: deadlocks.
Processes do not have this problem because their memory is isolated from the start. It is a trade-off between safety and efficiency.
From an iOS Developer’s Perspective
On iOS, one app is one process. Because of sandboxing, an app cannot access another app’s memory. The process isolation described above applies directly.
Inside an app, the main thread handles the UI, while networking and heavy computation are sent to other threads. The rule “update the UI on the main thread” is built directly on the thread concept.
However, directly creating threads is uncommon in modern iOS development. Submit work to a GCD queue or a Swift Concurrency Task, and the system assigns it from a thread pool. The abstraction layer is simply one level higher; threads still run underneath.
How to Answer in an Interview
It is best to begin with a one-sentence answer.
“A process is an execution unit with an independent memory space, while a thread is an execution flow inside a process that has its own stack and shares the remaining memory.”
The follow-up questions are almost predictable: “What does a thread share and keep separately?” (only the stack), “Why are threads lighter?” (creation, switching, and communication costs), and “What goes wrong when memory is shared?” (data races and synchronization). Covering these is enough to meet the bar.
Add one real-world example, such as Chrome tabs or the iOS sandbox, and you will sound like you understand the topic rather than memorized it.
Summary
- A process is a running program and receives an independent memory space from the operating system (code, data, heap, and stack).
- A thread is an execution flow inside a process; it has its own stack and shares the code, data, and heap.
- Threads are lightweight because creation, switching, and communication are inexpensive, but shared memory creates a data-race risk.
- Processes are isolated and safe but heavy, and they require IPC for communication.
- On iOS, an app is one process, while GCD and Task are abstractions built on threads.
- Interview answer outline: one-sentence definition → sharing scope → cost difference → data races