class Print1To10 implements Runnable {
    public int sum = 0;

    public void run() {
        for (int i = 1; i <= 10; i++) {
            System.out.println("Thread Name: " + Thread.currentThread().getName() + ", task value: " + i);
            sum += i;
        }
    }
}

class PrintEven implements Runnable {
    public void run() {
        for (int i = 2; i <= 20; i += 2) {
            System.out.println("Thread Name: " + Thread.currentThread().getName() + ", task value: " + i);
        }
    }
}

class PrintOdd implements Runnable {
    public void run() {
        for (int i = 1; i < 20; i += 2) {
            System.out.println("Thread Name: " + Thread.currentThread().getName() + ", task value: " + i);
        }    
    }
}

class IncrementCounter {
    protected int counter = 0;
    public int incrementCount = 100000;

    public int getCounterValue() {
        return counter;
    }
}

class IncrementCounterUnsynchronized extends IncrementCounter implements Runnable{
    public void run() {
        for (int i = 0; i < incrementCount; i++) {
            counter++;
        }
    }
}

class IncrementCounterSynchronized extends IncrementCounter implements Runnable {
    private final Object lockCounter = new Object();
    
    public void run() {
        for (int i = 0; i < incrementCount; i++) {
            synchronized (lockCounter) {
                counter++;
            }
        }
    }
}

public class java_15ThreadsRaces {
    public static void main(String[] args) {
        Print1To10 print1To10 = new Print1To10();

        Thread print1To10Task = new Thread(print1To10);
        Thread printEvenTask = new Thread(new PrintEven());
        Thread printOddTask = new Thread(new PrintOdd());
        
        Thread print5Multiple = new Thread(() -> {
            for (int i = 5; i <= 50; i += 5) {
                System.out.println("Thread Name: " + Thread.currentThread().getName() + ", task value: " + i);
            }
        });

        print1To10Task.start();
        printEvenTask.start();
        printOddTask.start();
        print5Multiple.start();

        try {
            print1To10Task.join();
            printEvenTask.join();
            printOddTask.join();
            print5Multiple.join();
        } catch (InterruptedException e) {
            System.out.println("Exception Occurred: " + e);
        } 

        boolean print1To10TaskCompleted = print1To10Task.isAlive();
        boolean printEvenTaskCompleted = printEvenTask.isAlive();
        boolean printOddTaskCompleted = printOddTask.isAlive();
        boolean print5MultipleCompleted = print5Multiple.isAlive();

        System.out.println(
            !print1To10TaskCompleted && 
            !printEvenTaskCompleted &&
            !printOddTaskCompleted &&
            !print5MultipleCompleted ? "All tasks complete. Result of Print1To10Numbers: " + print1To10.sum : "Tasks still pending"
        );

        System.out.println();
        System.out.println("unsynchronized [5+ runs, showing some incorrect] Unsynchronized Run + ==================== +");
        for (int i = 0; i < 5; i++) {
            IncrementCounterUnsynchronized unsynchronizedIncrement = new IncrementCounterUnsynchronized();
            int incrementCountUnsynchronized = unsynchronizedIncrement.incrementCount;

            Thread unsyncThread1 = new Thread(unsynchronizedIncrement);
            Thread unsyncThread2 = new Thread(unsynchronizedIncrement);
            Thread unsyncThread3 = new Thread(unsynchronizedIncrement);
            Thread unsyncThread4 = new Thread(unsynchronizedIncrement);

            unsyncThread1.start();
            unsyncThread2.start();
            unsyncThread3.start();
            unsyncThread4.start();

            try {
                unsyncThread1.join();
                unsyncThread2.join();
                unsyncThread3.join();
                unsyncThread4.join();
            } catch (InterruptedException e) {
                System.out.println("Exception Occurred: " + e);
            }

            System.out.println("Counter Value Expected (4 threads times " + incrementCountUnsynchronized + "): " + 4 * incrementCountUnsynchronized);
            System.out.println("Counter Value Actual (Run " + (i+1) + "): " + unsynchronizedIncrement.getCounterValue());
        }
        System.out.println(" + ==================== + Unsynchronized Run ");

        // This works because synchronized locks another thread to interrupt 3 step process of increment
        // ReentrantLock was not used due to not requiring much of the methods available by it and synchronized can handle this task efficiently
        System.out.println("\nfixed [5+ runs, all exactly correct] Synchronized Run + ==================== +");
        for (int i = 0; i < 5; i++) {
            IncrementCounterSynchronized synchronizedIncrement = new IncrementCounterSynchronized();
            int incrementCountSynchronized = synchronizedIncrement.incrementCount;

            Thread syncThread1 = new Thread(synchronizedIncrement);
            Thread syncThread2 = new Thread(synchronizedIncrement);
            Thread syncThread3 = new Thread(synchronizedIncrement);
            Thread syncThread4 = new Thread(synchronizedIncrement);

            syncThread1.start();
            syncThread2.start();
            syncThread3.start();
            syncThread4.start();

            try {
                syncThread1.join();
                syncThread2.join();
                syncThread3.join();
                syncThread4.join();
            } catch (InterruptedException e) {
                System.out.println("Exception Occurred: " + e);
            }

            System.out.println("Counter Value Expected (4 threads times " + incrementCountSynchronized + "): " + 4 * incrementCountSynchronized);
            System.out.println("Counter Value Actual (Run " + (i+1) + "): " + synchronizedIncrement.getCounterValue());
        }
        System.out.println(" + ==================== + Synchronized Run ");

        final Object lockA = new Object();
        final Object lockB = new Object();

        System.out.println();
        System.out.println("=== 1. DEMONSTRATING DEADLOCK ===");
        Thread deadlockIncorrectA = new Thread(() -> {
            try {
                synchronized (lockA) {
                    System.out.println(Thread.currentThread().getName() + " acquired Lock A");
                    Thread.sleep(50);
                    
                    synchronized (lockB) {
                        System.out.println(Thread.currentThread().getName() + " acquired Lock B");
                    }
                }
            } catch (InterruptedException e) {
                System.out.println("Exception Occured: " + e);
            }
        });

        Thread deadlockIncorrectB = new Thread(() -> {
            try {
                synchronized (lockB) {
                    System.out.println(Thread.currentThread().getName() + " acquired Lock B");
                    Thread.sleep(50);
                    
                    synchronized (lockA) {
                        System.out.println(Thread.currentThread().getName() + " acquired Lock A");
                    }
                }
            } catch (InterruptedException e) {
                System.out.println("Exception Occured: " + e);
            }
        });

        deadlockIncorrectA.setDaemon(true);
        deadlockIncorrectB.setDaemon(true);

        deadlockIncorrectA.start();
        deadlockIncorrectB.start();

        try {
            deadlockIncorrectA.join(2000);
            deadlockIncorrectB.join(2000);
        } catch (InterruptedException e) {
            System.out.println("Exception Occured: " + e);
        } 

        boolean thread1Alive = deadlockIncorrectA.isAlive();
        boolean thread2Alive = deadlockIncorrectB.isAlive();
        
        System.out.println("Timeout expired. Thread 1 alive? " + thread1Alive);
        System.out.println("Timeout expired. Thread 2 alive? " + thread2Alive);
        System.out.println(thread1Alive && thread2Alive ? "-> Result: Deadlock successfully occurred!\n" : "-> Result: Threads finished.\n");

        final Object lockC = new Object();
        final Object lockD = new Object();
        // NOTE: not using locks A and B as they are deadlocked until main is completed,
        // Therefore using the same locks will show the same output and not provide a solution to deadlock

        System.out.println("=== 2. FIXING THE DEADLOCK (Consistent Order) ===");
        Thread deadlockCorrectA = new Thread(() -> {
            try {
                synchronized (lockC) {
                    System.out.println(Thread.currentThread().getName() + " acquired Lock C");
                    Thread.sleep(50);
                    
                    synchronized (lockD) {
                        System.out.println(Thread.currentThread().getName() + " acquired Lock D");
                    }
                }
            } catch (InterruptedException e) {
                System.out.println("Exception Occured: " + e);
            }
        });

        Thread deadlockCorrectB = new Thread(() -> {
            try {
                synchronized (lockC) {
                    System.out.println(Thread.currentThread().getName() + " acquired Lock C");
                    Thread.sleep(50);
                    
                    synchronized (lockD) {
                        System.out.println(Thread.currentThread().getName() + " acquired Lock D");
                    }
                }
            } catch (InterruptedException e) {
                System.out.println("Exception Occured: " + e);
            }
        });

        long startTime = System.currentTimeMillis();

        deadlockCorrectA.start();
        deadlockCorrectB.start();

        try {
            deadlockCorrectA.join(2000);
            deadlockCorrectB.join(2000);
        } catch (InterruptedException e) {
            System.out.println("Exception Occured: " + e);
        } 

        long elapsedTime = System.currentTimeMillis() - startTime;
        boolean fixedThread1Alive = deadlockCorrectA.isAlive();
        boolean fixedThread2Alive = deadlockCorrectB.isAlive();
        
        System.out.println("Elapsed time: " + elapsedTime + " ms");
        System.out.println("Timeout expired. Thread 1 alive? " + fixedThread1Alive);
        System.out.println("Timeout expired. Thread 2 alive? " + fixedThread2Alive);
        System.out.println(fixedThread1Alive && fixedThread2Alive ? "-> Result: Deadlock successfully occurred!\n" : "-> Result: Threads finished.\n");
    }
}

Today’s program is short, but nearly every line in it answers a question that computer scientists were asking before most programmers alive today were born. Why can two correct pieces of code produce a wrong answer together? What does it mean to take turns safely? What exactly has to be true for two threads to freeze each other?

This article is the theory companion to the practical walkthrough of today’s code. Last lesson, we looked at the theory behind lazy evaluation, folds, and Optional, and the Streams guide showed it in code. Streams were about values flowing through a pipeline. Today is about what happens when several flows touch the same value at the same time.

Sequential Processes and the Problem of Interleaving

Why the output of four threads has no fixed order

In the 1960s, Edsger W. Dijkstra’s essay “Cooperating Sequential Processes” (EWD123, 1965) framed concurrent programs as a set of ordinary sequential processes that occasionally need to coordinate. A key idea was that the relative speeds of those processes are unknown and arbitrary. A correct program may not depend on one process being faster than another.

That idea is what the first block of our program demonstrates:

print1To10Task.start();
printEvenTask.start();
printOddTask.start();
print5Multiple.start();

Each Thread is a sequential process. Within Thread-1, 2 is always printed before 4. Across threads, the JVM scheduler and the operating system decide who runs when, so the lines may appear grouped or mixed, and either is a valid outcome. Programs that only work because one thread happened to be quicker are exactly what Dijkstra's principle rules out.

The same line of thinking explains why join() exists. It is the point where one process waits for another to finish, so main can safely read print1To10.sum afterwards.

Critical Sections and Mutual Exclusion

The problem that gave counter++ its danger

In 1965, Dijkstra published “Solution of a Problem in Concurrent Programming Control” in Communications of the ACM (volume 8, issue 9). The problem it stated is one that still defines the field: several processes, each with a stretch of code that must never run in two places at once. That stretch is called a critical section, and keeping processes out of each other’s critical sections is called mutual exclusion. Dijkstra’s paper gave a solution using only ordinary reads and writes of shared variables.

In our code, the critical section is one line:

for (int i = 0; i < incrementCount; i++) {
    counter++;
}

The line looks tiny, but it contains three separate actions: read counter, add one, write the result back. If two threads are between "read" and "write" at the same moment, each overwrites the other's work. In the language of the theory, the critical section was not protected, so the final total is no longer the sum of the work done.

Races, Atomicity, and the Java Memory Model

Why 400,000 became 135,072

One recorded run of the unsynchronized version produced this:

Counter Value Expected (4 threads times 100000): 400000
Counter Value Actual (Run 1): 135072

Brian Goetz and co-authors, in Java Concurrency in Practice (Addison-Wesley, 2006), call this pattern a read-modify-write sequence and explain that it is a race condition: the result depends on the unlucky timing of threads. The fix needs the three steps to be atomic, meaning indivisible from the viewpoint of every other thread.

There is a second, deeper problem hiding in this code. Chapter 17 of the Java Language Specification defines what a thread is guaranteed to see when another thread writes a value. It does this through a relation called happens-before, a term borrowed from Leslie Lamport’s 1978 paper “Time, Clocks, and the Ordering of Events in a Distributed System” in Communications of the ACM. The Java Memory Model itself is described by Jeremy Manson, William Pugh, and Sarita Adve in “The Java Memory Model” (POPL 2005). When two threads access the same variable, at least one access is a write, and nothing orders the accesses by happens-before, the specification calls it a data race. Our unprotected counter is exactly that. It is not only that the arithmetic can be lost, but that one thread is not even promised to see another's latest write.

Some of that ordering is provided for free. The specification states that all actions in a thread happen-before another thread successfully returns from join() on it. That is why this works:

print1To10Task.join();
// ...
System.out.println("... " + print1To10.sum);

The thread wrote sum, and join() creates the ordering that makes that write visible to main.

Monitors: Turning a Rule into a Language Feature

What synchronized really is

C. A. R. Hoare’s “Monitors: An Operating System Structuring Concept” (Communications of the ACM, October 1974, pp. 549–557) proposed gathering shared data together with the only code allowed to touch it, and having the system guarantee that one process at a time is inside. Per Brinch Hansen was developing the same idea at the same time, and the two are usually credited together. The point was to stop relying on programmers remembering to guard every access by hand.

Java adopted the monitor idea. The Java Language Specification, in its chapter on threads and locks, describes synchronization as implemented using monitors, with one monitor associated with every object. Our fix uses exactly that:

private final Object lockCounter = new Object();

public void run() {
    for (int i = 0; i < incrementCount; i++) {
        synchronized (lockCounter) {
            counter++;
        }
    }
}

Entering the block acquires the monitor of lockCounter, and leaving it releases the monitor, even if an exception is thrown. This is where Java differs from Hoare's original design: Hoare bound a monitor to a data structure, whereas Java lets any object serve as the lock, and the programmer chooses which one. That freedom is also a responsibility. Protection only exists if every thread contending for the data uses the same lock object, which is why all four threads in our run share a single IncrementCounterSynchronized instance.

The monitor also carries the memory guarantee from the previous section. In the specification’s happens-before rules, releasing a monitor happens-before every later acquisition of the same monitor. So the lock does two jobs at once: it provides mutual exclusion, and it makes each thread’s write visible to the next. That second job is why every one of our synchronized runs reports exactly 400,000.

Deadlock and the Four Coffman Conditions

Exactly what has to be true for two threads to freeze

In 1971, E. G. Coffman, M. J. Elphick, and A. Shoshani published “System Deadlocks” in ACM Computing Surveys (volume 3, issue 2, pages 67–78). They identified four conditions that must all hold at the same time for a deadlock to occur. Each of them can be pointed to in the deadlock demo:

• Mutual exclusion: a lock can be held by only one thread. This is the synchronized block itself.
• Hold and wait: a thread holds one resource while waiting for another. Thread A holds lockA while it asks for lockB, and the Thread.sleep(50) makes sure that both threads reach this state.
• No preemption: a resource cannot be taken away from its holder. A Java monitor is released only when the holding thread leaves its block, and a thread stuck waiting to enter a synchronized block cannot be talked out of it by an interrupt.
• Circular wait: there is a closed chain of threads, each waiting for a resource held by the next. A waits for B’s lock, and B waits for A’s.

// Thread A                          // Thread B
synchronized (lockA) {               synchronized (lockB) {
    Thread.sleep(50);                    Thread.sleep(50);
    synchronized (lockB) { ... }         synchronized (lockA) { ... }
}                                    }

The theory also explains the shape of the classic puzzle. Dijkstra set the dining philosophers problem as an exam question in 1965, and Hoare later gave it the form we know today: five philosophers, five forks, and each philosopher needs two forks to eat. If every philosopher picks up the left fork first, all of them can end up holding one fork and waiting forever. It is our two-lock program with more threads. Dijkstra’s treatment appeared in “Hierarchical Ordering of Sequential Processes” (Acta Informatica, volume 1, issue 2, 1971, pp. 115–138).

Breaking the Cycle: Why Lock Ordering Works

Removing one condition is enough

Because a deadlock needs all four conditions, removing any one of them prevents it. We cannot give up mutual exclusion, because that would bring back the race. We cannot cheaply give up hold-and-wait or no-preemption with plain synchronized. The practical condition to attack is circular wait, and the standard way is resource ordering: give every lock a rank and require everyone to acquire locks in rank order.

// Both threads now take lockC first, then lockD
synchronized (lockC) {
    Thread.sleep(50);
    synchronized (lockD) { ... }
}

If every thread follows the same order, a cycle cannot form. A thread holding lockD can never be waiting for lockC, because no thread ever asks for lockC while already holding lockD. This ordering discipline is also the resource-hierarchy solution to the dining philosophers problem, and Java Concurrency in Practice devotes a chapter on liveness hazards to lock-ordering deadlocks.

There is a price. The two threads now run one after the other through the locked section, and the measured 102 ms is the two sleep(50) calls back to back. Prevention trades some concurrency for the guarantee that the system cannot freeze. For our program that is clearly worth it.

Proving a Deadlock Without Living Through It

Timeouts, daemon threads, and the limits of detection

The program has to prove a deadlock happened without hanging forever, and it does so in two ways:

deadlockIncorrectA.setDaemon(true);
deadlockIncorrectB.setDaemon(true);
// ...
deadlockIncorrectA.join(2000);
deadlockIncorrectB.join(2000);
System.out.println("Timeout expired. Thread 1 alive? " + deadlockIncorrectA.isAlive());

The Java Language Specification’s section on program exit says the JVM exits once every non-daemon thread has finished. By marking the stuck threads as daemons, main can finish and let the program end. The timed join and isAlive() are a practical detection method: if both threads are still alive after two seconds, they are blocked.

This is a timeout, not a proof. A slow thread and a deadlocked thread look identical from outside, which is why the theory prefers to detect the cycle itself. For monitor locks, the JVM can do this: a thread dump from jstack, or the ThreadMXBean API, can report that threads are deadlocked and name the locks involved.

Putting It Together

Each idea, its origin, and the line of code that carries it

Interleaving with unknown speeds comes from Dijkstra’s sequential-process model, and it shows up in the four start() calls. Critical sections and mutual exclusion come from Dijkstra's 1965 work, and they show up in counter++. Atomicity, data races, and happens-before come from the Java Language Specification and the Java Memory Model research, and they show up in the result 135072 and in the join() before sum is read. Monitors come from Hoare and Brinch Hansen, and they show up in synchronized (lockCounter). Deadlock and its four conditions come from Coffman, Elphick, and Shoshani, and they show up in lockA and lockB. Resource ordering comes from the dining philosophers literature, and it shows up in lockC and lockD.

The recurring theme of this series, behavior that is silently wrong, is at its sharpest here. A race condition raises no exception. A passing run proves nothing. The theory gives us a way to reason about correctness that does not depend on getting lucky.

Further Reading

Dijkstra, E. W. “Cooperating Sequential Processes” (EWD123), 1965.

Dijkstra, E. W. “Solution of a Problem in Concurrent Programming Control.” Communications of the ACM 8(9), 1965.

Dijkstra, E. W. “Hierarchical Ordering of Sequential Processes.” Acta Informatica 1(2), 1971, pp. 115–138.

Coffman, E. G., Elphick, M. J., and Shoshani, A. “System Deadlocks.” ACM Computing Surveys 3(2), 1971, pp. 67–78.

Hoare, C. A. R. “Monitors: An Operating System Structuring Concept.” Communications of the ACM, October 1974, pp. 549–557.

Lamport, L. “Time, Clocks, and the Ordering of Events in a Distributed System.” Communications of the ACM, 1978.

Manson, J., Pugh, W., and Adve, S. “The Java Memory Model.” POPL 2005.

Goetz, B. et al. Java Concurrency in Practice. Addison-Wesley, 2006.

The Java Language Specification, chapters 12 (program exit) and 17 (threads and locks).

The Arbiter Journey So Far

This is lesson 15 of the Arbiter Learning Journey, a Java-from-scratch series building toward Arbiter, a microservices-based test management platform. Every concept is written and tested by hand before the next one begins. A test platform runs many things at once, so the ideas in this article, safe shared state and lock discipline, will matter every time Arbiter’s services handle more than one request.

Understand the concept in detail

Arbiter YouTube Playlist

Arbiter on GitHub

GitHub - Someone-anon-coder/Arbiter: Welcome to Arbiter - a documented, hands-on journey from Java fundamentals to a deployed microservices platform.

Arbiter Lessons

• List: Arbiter (Java) | Curated by Someone | Medium
• List: Arbiter (Java) Theory | Curated by Someone | Medium

Other series on this account

• List: Cybersecurity | Curated by Someone | Medium
• List: Python Guide | Curated by Someone | Medium
• List: Python Guide - Theory | Curated by Someone | Medium
• List: GoLang Guide | Curated by Someone | Medium
• List: GoLang Guide Theoretical | Curated by Someone | Medium
• List: My Progress - Matplotlib | Curated by Someone | Medium

What’s Next

Our program created 48 Thread objects by hand. The next lesson hands that job to the JVM with ExecutorService and thread pools, followed by CompletableFuture for results that arrive later.

Understanding Java Concurrency: The Theory Behind Threads, Race Conditions, Monitors, and Deadlock was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s been a lot of discussion lately about MCP and how it allows AI coding agents to interact directly with development tools.

For iOS developers, Xcode’s MCP integration sounds particularly interesting.

Instead of just generating Swift code, agents can potentially inspect projects, interact with Xcode, build applications, run tests, and work with SwiftUI previews.

And this isn’t limited to one AI agent. Tools like OpenAI Codex and Claude Code can connect to compatible MCP servers.

But I started wondering something.

Does connecting an AI coding agent to Xcode actually make it better at developing iOS applications?

Because Codex can already read source files, modify Swift code, execute terminal commands, and build applications using xcodebuild.

It can also interact with the iOS Simulator through command-line tools.

So what exactly are we gaining by adding MCP?

Instead of assuming it’s an improvement, I decided to test it.

The Experiment: Codex With vs. Without Xcode MCP

I wanted to keep this experiment as practical as possible.

No complicated architecture. No external dependencies. Just a small SwiftUI application with a real accessibility problem.

The setup was straightforward:

• Same SwiftUI project
• Same intentionally broken implementation
• Same prompt
• Same Codex development environment
• Xcode MCP disabled in one run and enabled in the other

The challenge was to identify and fix a SwiftUI layout issue that appeared at larger Dynamic Type sizes.

Both agents were asked to inspect the implementation, make the necessary corrections, build the application, run available tests, and verify the rendered interface.

I didn’t want to tell Codex exactly how to solve the problem.

And I didn’t want to artificially restrict its capabilities without MCP.

After all, the goal wasn’t to prove that MCP was better.

The goal was to find out whether it made a meaningful difference.

The SwiftUI Problem

The application contained a simple screen displaying an activity summary, a progress card, and a button.

At normal text sizes, everything appeared straightforward.

But the implementation had three problems that could affect accessibility.

1. A title that couldn’t grow

The title was restricted to a single line:

Text("Your Activity Summary")
    .font(.largeTitle.bold())
    .lineLimit(1)
    .minimumScaleFactor(0.8)

That combination prevents the heading from wrapping naturally.

As the user increases their preferred text size, SwiftUI may shrink the text instead of allowing it to occupy additional lines.

2. A fixed-height progress card

The progress card used:

.frame(height: 170)

That might look fine with default text sizes.

But what happens when the heading, description, and button need more vertical space?

The card doesn’t grow.

Eventually, the content can become compressed or clipped.

3. No scrolling

The screen used a regular vertical stack without a scrolling container.

Even if we removed the fixed height, content extending beyond the available screen could become unreachable.

This made the challenge interesting because the application could compile successfully while still having a usability problem.

And that’s exactly the kind of issue I wanted an AI coding agent to identify and verify.

Experiment A: Codex Without Xcode MCP

For the first run, I removed the Xcode MCP connection.

codex mcp remove xcode
codex mcp list

Codex still had access to the repository and its regular development tools.

It could inspect Swift files, modify code, execute shell commands, and interact with the Simulator.

I submitted the prompt and let it work.

What Codex changed

Codex identified the layout constraints and addressed them directly.

It removed the title’s single-line restriction and shrinking behavior.

It removed the card’s fixed height.

And it introduced a ScrollView to keep content accessible when it exceeded the available screen height.

The corrected title followed this approach:

Text("Your Activity Summary")
    .font(.largeTitle.bold())
    .fixedSize(horizontal: false, vertical: true)

The card could now determine its height from its content, and scrolling provided access to elements outside the initial viewport.

The existing colors, padding, rounded corners, semantic fonts, and button action remained intact.

Nothing particularly complicated.

But the interesting part came afterward.

Codex didn’t stop at compilation

The application built successfully.

Then Codex added an accessibility-focused UI regression test.

The test launched the application at the largest accessibility text size, inspected the layout, scrolled to the progress button, and verified that the button remained reachable.

It also checked landscape behavior and captured screenshots as evidence.

The first full test run encountered a test-host startup problem.

Codex investigated and reran the suite with parallel testing disabled.

That second run succeeded.

Final results without MCP:

• Build succeeded
• Three UI tests passed
• One existing unit-test placeholder passed
• Simulator screenshots captured and inspected
• Dynamic Type layout verified at multiple text sizes
• No dependencies or project configuration changes required

Codex used tools including xcodebuild, simctl, and xcresulttool.

It was able to modify the application, run tests, interact with the Simulator, and visually inspect the result.

All without Xcode MCP.

That was already a meaningful outcome.

It demonstrated that Codex didn’t necessarily need direct access to Xcode’s MCP tools to perform a substantial development and verification workflow.

The agent reported completing the run in 10 minutes and 6 seconds.

Of course, this wasn’t exhaustive accessibility validation. Verification covered an iPhone 17 Simulator, not physical devices, and there was no complete spoken VoiceOver walkthrough.

But the experiment gave us a strong baseline.

Experiment B: Codex With Xcode MCP

Next, I restored the original broken implementation and repeated the experiment.

Same problem. Same prompt.

This time, Xcode MCP was enabled.

I connected Codex using:

codex mcp add xcode -- xcrun mcpbridge
codex mcp get xcode

With that connection available, Codex could access supported Xcode capabilities through MCP.

I was particularly interested in whether it would use Xcode’s project context or SwiftUI preview functionality to improve verification.

The implementation was almost identical

Codex identified the same underlying problems.

The heading couldn’t wrap.

The card had a restrictive fixed height.

And the screen needed scrolling.

The resulting code changes were essentially the same as in the first experiment.

This was interesting in itself.

Adding MCP didn’t fundamentally change how Codex understood the SwiftUI layout problem.

The same basic SwiftUI principles solved it.

Remove unnecessary constraints, allow content to grow, and provide scrolling when needed.

What changed during verification?

This is where MCP introduced something different.

Codex used Xcode-specific tools to inspect the workspace, available schemes, and run destinations.

It also attempted to render the SwiftUI preview directly through Xcode.

That’s a capability I was genuinely interested in.

Imagine asking an agent to fix a layout problem and having it inspect the rendered SwiftUI preview without requiring a separate manual step.

That could be useful.

Unfortunately, the preview attempts didn’t succeed.

The first returned:

PreviewsFoundationHost…TaskTimeoutError error 1

The second attempt returned:

UpdateTimedOutError: Updating took more than 5 seconds

So despite having MCP enabled, Codex couldn’t complete visual verification through the Xcode preview renderer.

Instead, it continued using the Simulator.

And this is worth emphasizing.

Having access to a tool doesn’t guarantee that the tool will work reliably.

MCP provided another way to interact with Xcode, but that particular capability wasn’t successful during this experiment.

Building and testing

The initial build attempt encountered a sandbox restriction when accessing the Simulator service.

After using approved access, Codex successfully compiled the application.

It also created a focused UI regression test to verify layout ordering, scrolling, and button reachability at the largest accessibility text size.

The tests completed successfully.

The agent exported and inspected Simulator screenshots to verify that the headings wrapped, the card expanded, and the button remained visible after scrolling.

Final results with MCP:

• Build succeeded
• Three UI tests passed
• One existing unit-test placeholder passed
• Simulator screenshots captured and inspected
• Xcode workspace and run destinations inspected through MCP
• SwiftUI preview rendering attempted but timed out
• No dependencies or project configuration changes required

This run took 6 minutes and 22 seconds, according to Codex’s reported work time.

That’s faster than the run without MCP.

But there’s an important distinction between observing a faster run and demonstrating why it was faster.

Comparing the Results

Here’s what happened when I put both experiments side by side.

MetricWithout MCPWith MCPSwiftUI layout fixCompletedCompletedBuildPassedPassedAutomated tests4 passed4 passedVisual verificationSimulatorSimulatorXcode project inspectionCLIMCP + CLISwiftUI previewNot usedTimed outAgent work time10m 06s6m 22s

Both approaches successfully fixed the same issue.

Both built the application.

Both passed four tests.

And both verified the rendered interface using Simulator screenshots.

The biggest functional difference was access to Xcode-specific tools.

But in this particular experiment, the Xcode preview attempts failed.

Was MCP faster?

The MCP run finished 3 minutes and 44 seconds sooner.

That’s approximately 37% less reported agent work time.

Interesting? Absolutely.

Conclusive? Not really.

This was one experiment per configuration.

AI agents can take different approaches even when working with the same prompt and codebase.

The runs also encountered different environmental issues and testing conditions.

So while the MCP-enabled run was faster, we can’t confidently attribute that difference to MCP alone.

A stronger performance comparison would repeat each configuration several times under controlled conditions.

For now, all I can say is that the MCP run finished faster in this particular test.

And I think that’s the responsible way to interpret the result.

So, What’s the Actual Value of Xcode MCP?

After running both experiments, I don’t think the biggest value of MCP is necessarily better Swift code generation.

Codex already understands SwiftUI well enough to identify common layout problems and implement reasonable fixes.

And command-line tools already provide a substantial amount of development functionality.

Where MCP becomes interesting is in access to development environment capabilities that might otherwise require additional tooling or manual interaction.

For example:

Xcode project context. An agent can discover workspaces, schemes, and run destinations through Xcode’s supported interface.

SwiftUI previews. In principle, an agent can render and inspect previews while working on visual changes.

Runtime debugging. Debugger integration could help an agent investigate behavior that isn’t obvious from static source inspection.

Development workflow integration. Instead of assembling every operation through unrelated commands, an agent can use interfaces exposed by the development environment.

Those are meaningful possibilities.

But I would evaluate each one based on its actual usefulness.

If a command-line workflow already solves the problem reliably, adding MCP might not provide much value for that specific task.

And that’s perfectly fine.

Not every tool needs to be used everywhere.

Final Thoughts

If there’s one thing I learned from this experiment, it’s that we shouldn’t confuse access to more tools with better software engineering outcomes.

Codex without MCP successfully fixed the SwiftUI layout, built the application, executed tests, and verified the interface.

Codex with MCP accomplished the same thing, while also accessing Xcode-specific capabilities.

The MCP run finished faster, but the preview renderer timed out, and the successful visual verification still came from Simulator screenshots.

So would I use Xcode MCP again?

Yes.

I think it’s worth exploring, particularly for debugging, previews, and more complex development workflows.

But I wouldn’t consider it mandatory for every iOS development task.

For me, the real value of AI-assisted development isn’t how much code an agent can generate or how many integrations it supports.

It’s whether the workflow helps us produce software that’s more reliable, maintainable, and easier to verify.

The question isn’t whether an AI agent can use Xcode MCP. It’s whether that connection actually improves the development process.

And that’s what I’ll continue testing.

Continue the Conversation

Have you tried Xcode MCP with Codex, Claude Code, or another AI coding agent?

Have you noticed a meaningful improvement, or do you prefer using command-line development tools?

I’d love to hear what you’ve experienced.

I also recorded the complete experiment for my CodeHero AI Coding Experiments series, where I test AI development tools against practical software engineering problems.

If you enjoy these kinds of experiments, consider subscribing to the my YouTube channel. It’s free and helps support future videos.

You can also find me at tony-trejo.com.

Thanks for reading, and I’ll see you in the next experiment.

Does Xcode MCP Actually Make Codex Better? I Tested Both. was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

In .NET, you have 6 ways to cache: IMemoryCache, IDistributedCache, Redis, HybridCache, FusionCache, and Output Cache.

This is the 2nd part of the Caching in .NET series.

Last week, in Part 1 we explored:

• Where Each Cache Sits in a .NET App
• In-Memory Cache (IMemoryCache) (Part 1)
• Distributed Cache (IDistributedCache) with Redis (Part 1)
• HybridCache (Part 1)

In this post, we will explore each caching option with pros, cons, pitfalls, and when to use it:

• FusionCache
• Output Cache
• Which Cache Should You Choose

Let’s dive in.

👉 Read original article on my newsletter: https://antondevtips.com/blog/all-types-of-caching-in-dotnet-and-when-to-use-each-part2

FusionCache

FusionCache is an open-source hybrid cache that existed years before HybridCache did.

It has the same L1 + L2 shape and the same stampede protection.
It also has what HybridCache lacks: a backplane that syncs L1 across instances, fail-safe, factory timeouts, and eager refresh.

FusionCache is the best caching option available in .NET today.

To get started with FusionCache, add these packages:

dotnet add package ZiggyCreatures.FusionCache
dotnet add package ZiggyCreatures.FusionCache.Serialization.SystemTextJson
dotnet add package ZiggyCreatures.FusionCache.Backplane.StackExchangeRedis
dotnet add package Microsoft.Extensions.Caching.StackExchangeRedis

Then you can configure it in the DI container:

var redisConnection = builder.Configuration.GetConnectionString("Redis")!;
 
builder.Services.AddFusionCache()
    .WithDefaultEntryOptions(new FusionCacheEntryOptions
    {
        Duration = TimeSpan.FromMinutes(10),
        IsFailSafeEnabled = true,
        FailSafeMaxDuration = TimeSpan.FromHours(1),
        FactorySoftTimeout = TimeSpan.FromMilliseconds(300)
    })
    .WithSerializer(new FusionCacheSystemTextJsonSerializer())
    .WithDistributedCache(new RedisCache(new RedisCacheOptions
    {
        Configuration = redisConnection
    }))
    .WithBackplane(new RedisBackplane(new RedisBackplaneOptions
    {
        Configuration = redisConnection
    }));

Three building blocks are registered here:

• Serializer for the L2 payload. System.Text.Json is the default choice.
• Distributed cache as L2. This is the same RedisCache type from IDistributedCache.
• Backplane as the channel that tells other instances about changes. It uses Redis pub/sub.

The handler uses IFusionCache:

internal sealed class GetShipmentByNumberHandler(
    ShipmentsDbContext dbContext,
    IFusionCache cache)
{
    public async Task<ShipmentResponse?> HandleAsync(
        string shipmentNumber,
        CancellationToken cancellationToken)
    {
        return await cache.GetOrSetAsync<ShipmentResponse?>(
            $"shipment:{shipmentNumber}",
            async (_, ct) => await dbContext.Shipments
                .Where(s => s.Number == shipmentNumber)
                .Select(s => s.MapToResponse())
                .FirstOrDefaultAsync(ct),
            tags: ["shipments"],
            token: cancellationToken);
    }
}

You can remove items by key or a tag, exactly like in HybridCache:

await cache.RemoveAsync($"shipment:{shipmentNumber}", token: cancellationToken);

The difference is what happens after that call on the other app instances:

The backplane message carries only the key and the action without a value.
Instance B drops its L1 (memory) copy, and the next read on B goes to L2 (Redis) and then to the database.

This is the direct fix for the biggest pitfall in HybridCache.

Using FusionCache as HybridCache

If your handlers already inject HybridCache, you don’t have to rewrite them.
FusionCache can register itself as the HybridCache implementation:

builder.Services.AddFusionCache()
    .WithSerializer(new FusionCacheSystemTextJsonSerializer())
    .WithDistributedCache(new RedisCache(new RedisCacheOptions { Configuration = redisConnection }))
    .WithBackplane(new RedisBackplane(new RedisBackplaneOptions { Configuration = redisConnection }))
    .AsHybridCache();

So you continue using HybridCache in your classes.

Note: through the HybridCache adapter you can only pass HybridCacheEntryOptions per call. Fail-safe, timeouts, and eager refresh are configured once in the default entry options.

What Else FusionCache Gives You

I will only name the features here, since this library deserves its own article:

• Fail-safe: when the database is down and the factory throws, FusionCache serves the last known value instead of an error.
• Soft and hard timeouts: if the factory takes longer than the soft timeout and a stale value exists, the stale value is returned and the factory keeps running in the background.
• Eager refresh: refresh an entry in the background before it expires, so hot keys never see a miss.
• Adaptive caching: the factory can set the TTL per entry based on what it loaded.

FusionCache has the following advantages:

• Backplane: L1 caches stay in sync across instances.
• Resilience features: fail-safe and timeouts keep your API answering when dependencies are slow.
• Drop-in for HybridCache: the AsHybridCache() adapter keeps your handlers on the Microsoft abstraction.
• Mature: in production since 2021, well documented, active maintainer.

Here are the drawbacks of FusionCache:

• Third-party dependency: one more package to track and upgrade.
• Bigger configuration surface: more options means more ways to misconfigure.
• Backplane needs Redis pub/sub: a managed Redis tier without pub/sub cannot run it.

Output Cache

Output Cache is middleware that stores the full HTTP response and serves it on the next matching request.

On a hit, your handler and your database never run.
This is the biggest win per line of code in ASP .NET Core, and I wrote a dedicated deep dive on Output Cache.

During registration, you define named policies:

builder.Services.AddOutputCache(options =>
{
    options.AddPolicy("shipment-by-number", policy => policy
        .Expire(TimeSpan.FromMinutes(5))
        .SetVaryByRouteValue("shipmentNumber")
        .Tag("shipments"));
});
 
var app = builder.Build();
 
app.UseOutputCache();

After that, the endpoint can use it by name:

app.MapGet("/api/shipments/{shipmentNumber}", async (
    string shipmentNumber,
    GetShipmentByNumberHandler handler,
    CancellationToken cancellationToken) =>
{
    var shipment = await handler.HandleAsync(shipmentNumber, cancellationToken);
    return shipment is null ? Results.NotFound() : Results.Ok(shipment);
})
.CacheOutput("shipment-by-number");

SetVaryByRouteValue makes each shipment number its own cache entry.
For list endpoints, SetVaryByQuery("carrier", "status") does the same for query parameters.

Use Tag("shipments") to quickly evict items from a cache.
You can inject IOutputCacheStore and evict by tag:

internal sealed class UpdateShipmentStatusHandler(
    ShipmentsDbContext dbContext,
    IOutputCacheStore outputCache)
{
    public async Task HandleAsync(
        string shipmentNumber,
        ShipmentStatus status,
        CancellationToken cancellationToken)
    {
        var shipment = await dbContext.Shipments
            .FirstAsync(s => s.Number == shipmentNumber, cancellationToken);
 
        shipment.UpdateStatus(status);
        await dbContext.SaveChangesAsync(cancellationToken);
 
        await outputCache.EvictByTagAsync("shipments", cancellationToken);
    }
}

By default, Output Cache stores responses in memory, which brings back the two-instances problem.
For such cases, you will need Redis:

dotnet add package Microsoft.AspNetCore.OutputCaching.StackExchangeRedis

builder.Services.AddStackExchangeRedisOutputCache(options =>
{
    options.Configuration = builder.Configuration.GetConnectionString("Redis");
});

Now every instance serves from the same cached responses, and EvictByTagAsync on one instance evicts for all of them.

Important note: ASP .NET Core also has the older Response Caching middleware (UseResponseCaching), which relies on Cache-Control headers sent by the client.
It is outdated for APIs. Clients can bypass it, you cannot evict by tag, and it does not support Redis.
Use Output Cache instead.

Output Cache has the following advantages:

• Nothing runs on a hit: no handler, no serialization, no database.
• Declarative: one attribute-like call per endpoint, policies in one place.
• Tag-based eviction that works across instances with the Redis store.

Here are the drawbacks of Output Cache:

• Whole-response granularity: you cache the entire payload or nothing. One changed field invalidates everything.
• Only GET and HEAD, and only 200 responses, by default.
• Authenticated requests are not cached by default. Requests with an Authorization header skip the cache entirely.

Output Cache Pitfalls

Caching per-user data without varying by user.
If you override the default and cache authenticated responses, you must vary by the user, or user A receives user B’s shipments:

options.AddPolicy("my-shipments", policy => policy
    .Expire(TimeSpan.FromMinutes(1))
    .SetVaryByHeader("Authorization")
    .Tag("shipments"));

Varying by the Authorization header works, but every token is its own entry, so the hit rate drops as the user base grows.

Eviction lives in the write path.
Every handler that changes shipments must remember to evict the tag; otherwise, stale responses persist until they expire.
Put eviction in one place, such as a domain event handler, rather than in each write handler.

👉 Read original article on my newsletter: https://antondevtips.com/blog/all-types-of-caching-in-dotnet-and-when-to-use-each-part2

All Types of Caching in .NET: When to Use Each (Deep Dive, Part 2) was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lazy loading is a powerful concept in modern web development that helps improve the performance of your application. In this blog, I’ll explain lazy loading in the simplest way possible, using an example from my own React project. By the end, you’ll understand what lazy loading is, how to implement it, and why it’s so beneficial.

What is Lazy Loading?

Imagine you’re at a buffet. Instead of putting all the food on your plate at once, you only take what you need when you’re ready to eat. This way, you don’t overload your plate, and you can enjoy your meal without wasting food.

Lazy loading in web development works the same way. Instead of loading everything on a webpage at once, you load only what’s needed at the moment. For example:

• Load the main content first.
• Load additional components or images only when the user interacts with the page (e.g., scrolling or clicking a button).

Why Use Lazy Loading?

Without lazy loading, your app might load everything upfront, which can:

• Increase the initial load time.
• Make the app feel slow and unresponsive.
• Waste resources by loading things the user might never see.

With lazy loading:

• You reduce the initial load time.
• Your app feels faster and more responsive.
• You save bandwidth by loading only what’s necessary.

Does it really usefull ?

Hell Yeah !! it is , let see some proffs.

1. Bundle size (using npm run build) : when using lazy loading your lazy loaded compoenets code gets build as a seperate chunk then your rest of the code .

In the image see 1st build without lazy loading (see all gets bundled in a single chunk)

Now with lazy loading ( notice HelperLazyChild compoents gets chunked)

2. Loading (using broswerr network tab ): Without lazy loading when the parent compoent is loaded the browser will load HelperLazyChild component also even though it is not visible and in use .

But with lazy loading intially browser will only load Parent one i.e LazyLoading.jsx and not HelperLazyChild.jsx

Lazy Loading in Action: My React Implementation

Here’s an example of how I implemented lazy loading in my React project. I have a parent component (LazyLoading.jsx) and a child component (HelperLazyChild.jsx). The child component contains an image that is loaded only when the user clicks a button.

Parent Component: LazyLoading.jsx

This component uses React’s :

lazy : Lets you defer loading a component’s code until it is rendered for the first time .

Suspense :Lets you display a fallback until its children have finished loading.

to load the child component only when the user clicks the "Load Child Component" button.

import { lazy, Suspense, useState } from "react"; // Importing React hooks and lazy/Suspense for lazy loading

const LazyLoading = () => {
    // State to track whether the child component should be visible
    const [isVisible, setisVisible] = useState(false);

    // Lazy load the child component. This ensures the component is only loaded when needed.
    const LazyLoadingChild = lazy(() => import('./HelperCompoenents/HelperLazyChild'));

    return (
        <>
            {/* Full-page container */}
            <div style={{ width: "100%", height: "100vh" }}>
                <h1>Welcome to Lazy Loading Page</h1>
                {/* Button to trigger the visibility of the child component */}
                <button onClick={() => setisVisible(true)}>Load Child Component</button>

                {/* Conditionally render the child component when isVisible is true */}
                {isVisible && 
                    <Suspense fallback={<div>Loading...</div>}>
                        {/* Lazy-loaded child component */}
                        <LazyLoadingChild />
                    </Suspense>
                }
            </div>
        </>
    );
};

export default LazyLoading;

Child Component: HelperLazyChild.jsx

This component contains an image that is loaded when the component is rendered.

import { useRef } from "react";

const HelperLazyChild = () => {
    const imgSource = useRef("../../../public/PublishMedium.jpeg");

    return (
        <>
            <img src={imgSource.current} alt="Lazy Loaded" />
        </>
    );
};

export default HelperLazyChild;

How It Works:

1. Initially, only the parent component (LazyLoading.jsx) is loaded.
2. When the user clicks the “Load Child Component” button:

• The child component (HelperLazyChild.jsx) is fetched as a separate JavaScript chunk.
• The image inside the child component is displayed.

When to Use Lazy Loading

You should use lazy loading when:

1. Your app has large components or assets:

• For example, images, videos, or charts.

2. Some components are rarely used:

• For example, admin panels or settings pages.

3. You want to optimize performance:

• Especially for users on slower networks or devices.

Conclusion

Lazy loading is a simple yet powerful technique to improve the performance of your React app. By loading components and assets only when needed, you can reduce the initial load time, save bandwidth, and provide a better user experience.

In this blog, I showed you how to implement lazy loading using React’s lazy and Suspense. I also explained the benefits, differences, and when to use lazy loading. Now it’s your turn to try it out in your own projects!

Happy coding! 😎✨

Lazy Loading in React : We use but do we really understand it ? was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.