Apple’s pitch is undeniably seductive. The iPhone Duo unfolds from a 5.4-inch outer cover screen into an expansive 7.6-inch flexible OLED canvas. It runs on the A20 Pro chip, incorporates an intricate titanium hinge, and brings multi-window Split View to the iPhone lineup for the first time.

I love Apple hardware, and from an industrial design perspective, the Duo is a marvel. But software engineering teams do not operate on aesthetic admiration. They operate on sprint velocity, headcount budgets, and opportunity cost.

If your team is currently weighing whether to divert engineering cycles toward building custom experiences for the iPhone Duo, here is the unvarnished mathematical reality: for roughly 95% of existing applications, investing in bespoke iPhone Duo optimization at launch is an engineering trap.

Here is the math, the platform economics, and the technical breakdown of what it actually takes to adapt legacy codebases.

1. The Denominator Problem: 10 Million vs. 2.5 Billion

The most dangerous bias in mobile product development is confusing hardware capability with addressable market size.

To evaluate whether a new device justifies engineering effort, consider where the iPhone Duo sits in the global hardware landscape:

• The Active Apple Ecosystem: Apple’s active installed base exceeds 2.5 billion devices worldwide. Standard iPhone shipments alone move between 240 million and 258 million units every year.

• The Global Foldable Baseline: Despite seven years of persistent investment by Samsung, Google, and Huawei, foldables account for less than 2% of the global smartphone market, with 2026 industry shipments estimated around 22.9 million units.

• Projected iPhone Duo Shipments: Analysts at IDC forecast that Apple will ship approximately 10 million iPhone Duo units during its first twelve months.

Even if Apple hits every production milestone, the iPhone Duo will represent approximately 0.4% of the active Apple device ecosystem and roughly 4% of annual iPhone sales.

When your team allocates sprint capacity, it is assigning finite engineering hours to an addressable audience that rounds down to zero compared to the core smartphone base. Building bespoke features for 0.4% of your user base is rarely sound commercial math.

2. A $1,999 Device Sits Firmly "Pre-Chasm"

The Duo’s market footprint is constrained by its retail price. Starting at $1,999 for the base tier and reaching toward $3,000 for top storage options, the Duo is not positioned for the mainstream consumer replacement cycle.

In Everett Rogers’ classical Diffusion of Innovations framework, technology adoption follows a predictable curve:

At $2,000, the Duo sits squarely before Geoffrey Moore’s famous "chasm." It is a luxury showcase. Until manufacturing yields improve, component prices decline, and carrier trade-ins make it indistinguishable from standard monthly hardware financing, the device cannot reach mainstream users.

Building custom software for the Duo on Day One means expending engineering resources exclusively for a pre-chasm user cohort.

3. What Happens If You Do Nothing? (The Compatibility Reality)

There is a pervasive fear among product teams that skipping launch-day support will result in broken user experiences. Apple’s official documentation confirms the opposite: unmodified legacy applications run completely safely.

According to Apple's Human Interface Guidelines on Designing for iPhone Duo and developer technical sessions, legacy iOS behavior follows clear rules:

• Zero Crash Risk: Applications compiled against earlier SDKs execute within an automated system compatibility sandbox.

• Aspect Ratio Preservation: On the 7.6-inch inner display, older binaries run centered and letterboxed, maintaining their familiar mobile aspect ratio with inactive borders. Touch handling and coordinates remain intact.

• Outer Screen Parity: On the 5.4-inch outer cover screen, legacy applications report standard compact size classes and behave like standard single-screen iPhones.

Your app will not crash, data flows will not break, and core customer flows remain functional. The only downside is visual letterboxing on the inner display when unfolded.

4. The "Few Hours" Myth: What Adapting Actually Demands

Apple states in its developer sessions that updating an app can take "from a few hours to several days".

What that marketing statement leaves out is that the "few hours" path applies almost exclusively to teams that already maintain a modern, declarative iPadOS application with responsive size classes and multi-window scene delegates.

For the broad ecosystem of iPhone-first applications, Apple’s HIG and technical sessions reveal that adapting to iOS 27.1 requires refactoring fundamental mobile assumptions:

Orientation Locks Are Ineffective

On the 7.6-inch inner display, iOS 27.1 actively ignores app-level interface orientation locks for resizable software. If your codebase branches layout logic on UIDevice.orientation or UIScreen.main.bounds—practices present in thousands of legacy production codebases—the layout fails immediately. Supporting the Duo requires auditing view hierarchies to rely strictly on dynamic size classes and local coordinate environments.

Lateral Navigation and Asymmetric Safe Areas

On both the outer display and inner landscape mode, system navigation bars, tab bars, and toolbars shift from top and bottom edges to the lateral sides of the display to preserve vertical reading space.

This shift makes safe area insets asymmetric. In Split View, when an app shares the inner canvas with a secondary application, layout margins differ on every edge. Standalone UIKit toolbars cannot participate in this vertical layout; only system-managed container bars reposition automatically, requiring custom controls to undergo explicit vertical opt-ins and fixed-width compliance.

Reserved Region Topography

Codebases must dynamically track two system-level hardware obstructions:

• .division — The physical folding crease. It splits the active layout into separate usable zones when partially folded, but has zero width when the device is laid flat.

• .occlusion — The under-display front camera. While invisible when inactive, it dynamically claims screen space when the sensor turns on, requiring the interface to yield.

While continuous scrolling feeds may flow underneath the fold, primary interactive controls, action sheets, and modal forms must reposition outside these zones. Supporting dynamic poses requires adopting ArrangementView or UIArrangementViewController, restructuring view hierarchies into Split or Overlay configurations.

Multi-Scene State Architecture

The iPhone Duo is the first iPhone capable of running two concurrent windows of the same application side-by-side in Split View. If your app relies on singleton managers, global state objects, or single-window assumptions, running two concurrent instances introduces immediate state synchronization bugs.

The Combinatorial QA Explosion

Consider the impact on your testing pipeline. Testing an interactive flow is no longer a matter of checking portrait and landscape on fixed resolutions. You must validate:

• Closed portrait (compact phone profile)

• Closed landscape (lateral toolbars)

• Open vertical (tall, regular/regular canvas)

• Open horizontal (wide, side-by-side arrangement)

• Tabletop partial-fold (media above, controls below the crease)

• Split View multi-window pairings (sharing screen width with another app)

For an established engineering team, this represents 6 to 8 engineer-weeks of refactoring, plus 3 to 4 QA-weeks of test matrix verification. At standard tech compensation rates, that is an immediate expenditure of $60,000 to $95,000, with an ongoing 20% annual maintenance overhead across future OS updates.

5. Lessons from iPad and Vision Pro

If you believe that hardware quality and brand reputation automatically generate software returns, recent platform history offers two cautionary precedents.

The iPad Baseline: When 500 Million Devices Aren't Enough

Apple has sold over 550 million iPads since 2010, maintaining an active installed base measured in the hundreds of millions. Yet for fifteen years, Meta’s Instagram famously refused to build a dedicated iPad application.

Instagram CEO Adam Mosseri repeatedly explained the decision through simple platform economics: the tablet audience was not large enough to justify the ongoing development overhead.

“Each surface adds overhead; we support iOS, Android, www, and IG Lite... It's still just not a big enough group of people to be a priority. Right now we're very heads down on other things.” — Adam Mosseri, Head of Instagram

Maintaining a dedicated tablet client meant diverting engineers from vertical video feeds, core messaging infrastructure, and monetization initiatives to serve users who were already using the app on their smartphones.

If an active installed base of 100 million tablets could not justify engineering priority for a major digital platform, 10 million Duo units will struggle to justify yours.

The Vision Pro Freeze: The Sub-Critical Niche

At the opposite extreme sits the Apple Vision Pro. Released in 2024 at $3,499, it achieved an estimated 390,000 shipments in its first year. By late 2025, quarterly shipments had fallen to roughly 45,000 units, production lines were idled, and marketing spend was curtailed.

The device experienced a coordination breakdown in multi-sided platform economics:

• Developers saw the small installed base and deferred building native applications (with major streaming platforms opting out of compatibility mode).

• Consumers saw the lack of specialized software and delayed purchasing the hardware.

• The ecosystem entered an adoption stall.

While the iPhone Duo will achieve substantially more volume than the Vision Pro, the underlying economic principle holds: third-party software development cannot run on novelty alone.

6. The Math: Calculating Your Developer Investment Threshold

We can remove all guesswork by calculating your Developer Investment Threshold.

At a high level, the expected value of optimizing for the iPhone Duo must exceed the total engineering cost of building and maintaining it:

Expected Value = (Addressable Duo Users × Conversion Rate × Value Lift) + Strategic PR Value

Where:

• Addressable Duo Users: The projected first-year hardware volume (approximately 10,000,000 units according to IDC forecasts).

• Conversion Rate: Your product's realistic penetration among early Duo buyers (accounting for the 1.5x to 2.5x higher purchasing propensity of early adopters).

• Value Lift (Incremental ARPU): The extra revenue an existing customer pays you specifically because you built custom dual-screen features.

• Strategic PR Value: The tangible monetary return of App Store editorial featuring or launch PR.

To justify the project, your Expected Value must exceed your Total Project Cost:

Total Cost = Direct Engineering + QA Matrix Testing + Annual Maintenance + Opportunity Cost

If we solve for the minimum audience needed to break even:

Break-Even Users = (Total Cost - Strategic PR Value) / Incremental ARPU Lift

Let’s run the numbers for two standard mobile business models assuming a conservative $100,000 fully burdened project cost:

Scenario A: The Ad-Supported Consumer Utility

• Monetization: Mobile advertising generating an average baseline ARPU of $1.50 per year.

• Marginal Lift: Dual-screen optimization increases session depth by 20%, yielding an incremental $0.30 per user per year.

• Strategic PR Value: $0.

Break-Even Audience = \(100,000 Dollars / \)0.30 Dollar = 333,333 active Duo users

To break even on an ad-supported utility, your app must capture over 333,000 active iPhone Duo users. In a 10-million-unit first-year hardware run, that requires capturing 3.33% of every person who buys an iPhone Duo worldwide. For a utility application, that conversion rate is virtually impossible. The project represents an immediate loss.

Scenario B: The Enterprise B2B SaaS Tool

• Monetization: Annual business subscription at $180/year.

• Marginal Lift: Tabletop review and side-by-side document comparison drive tier upgrades, yielding an incremental $40.00 per subscriber.

• Strategic PR Value: $20,000 (estimated value of a Day-One App Store feature).

Break-Even Audience = ($100,000 - $20,000) / $40.00 = 2,000 active Duo subscribers

To break even, this tool needs only 2,000 subscribers, representing a modest 0.02% penetration of early Duo buyers. Here, early optimization is economically rational.

7. The Decision Framework: When Is It Worth Building?

Before committing engineering resources to iPhone Duo support, evaluate your product against five operational criteria:

1. Monetization Depth: Does your product generate high subscription ARPU, where converting a few thousand power users moves company metrics?

2. Workflow Fit: Does your product genuinely benefit from side-by-side multitasking or tabletop media layouts, or are you forcing standard content into a split screen?

3. Architectural Readiness: Does your codebase already use modern SwiftUI, adaptive size classes, and multi-window scene delegates, or will supporting Duo require unwinding years of UIKit orientation hacks?

4. App Store Alignment: Does your team have the direct developer relations ties required to secure primary editorial featuring on launch day?

5. Opportunity Cost: What critical roadmap feature—checkout speed, performance optimization, core reliability, or Android parity—are you willing to postpone to fund this work?

If you cannot answer yes to at least four of these questions, allocating resources to custom Duo layouts is an inefficient use of engineering bandwidth.

The Takeaway: Protect Your Roadmap

Every sprint your engineering organization spends managing dynamic safe areas, debugging hinge angle callbacks, and re-architecting navigation bars for iOS 27.1 is a sprint not spent on:

• Streamlining your purchase funnel.

• Reducing app launch times on standard devices.

• Resolving accessibility and compliance backlogs.

• Reaching feature parity on Android.

Supporting new hardware form factors is not a matter of engineering prestige; it is a capital allocation decision. Unless your business model directly capitalizes on a high-ARPU professional audience using side-by-side workflows, the pragmatic engineering strategy for the iPhone Duo at launch is straightforward:

Recompile against iOS 27.1 for basic runtime safety, allow system compatibility mode to handle window scaling, and let other organizations absorb the early adoption costs while your team ships features that move the needle for the other 99.6% of your users.

UPDATE 20 Sep 2026:

Following constructive peer review and a technical audit against Apple’s latest developer documentation, I want to clarify a few key assumptions, market data points, and historical examples cited in this post:

• UI Compatibility Mode vs. Blanket Runtime Safety: In Section 3, I stated that unoptimized legacy apps run with "zero crash risk" and universal letterboxing. While Apple does provide a UI compatibility presentation mode via UIDesignRequiresCompatibility to center unadapted binaries, Apple’s official Preparing your app for iPhone Duo guidance explicitly instructs teams to test their software across displays, poses, reserved regions, and scene lifecycles. Compatibility mode is an automatic presentation fallback, not a universal guarantee against input glitches, scene disconnects, or runtime edge cases.

Source Attribution on Market Sizing:

• The 10-million-unit first-year shipment estimate is an analyst forecast from IDC (reported by Bloomberg in August 2026), not an official Apple shipment disclosure.

• The 2.5 billion active devices benchmark is an official milestone announced by Apple in their January 2026 Q1 earnings release.

• The total foldable market is forecasted by IDC to reach 22.9 million units in 2026 (up 12.6% YoY). Comparing the Duo against this segment demonstrates that while 10 million units would capture nearly half of all global foldable volume, it still represents approximately 0.4% of Apple's broader active ecosystem.

• The Instagram on iPad Example: In Section 5, I cited Instagram’s long-standing refusal to build an iPad app. While Adam Mosseri’s famous 2022 remarks ("still just not a big enough group of people to be a priority") remain a textbook case study in platform opportunity cost, Meta did eventually launch a dedicated Instagram iPad client in September 2025. The historical lesson remains valid—major complementors often wait over a decade until platform scale justifies surface overhead—but the example should not be read as current platform resistance.

• Vision Pro Sizing: The Vision Pro figures cited (390,000 units in 2024; ~45,000 in late 2025) are third-party IDC research estimates (reported via the Financial Times and MacRumors), not Apple disclosures.

• Engineering Schedules and Financial Thresholds as a Decision Model: The schedules (6–8 engineer-weeks, 3–4 QA-weeks), the $100,000 fully burdened cost, and the ARPU marginal lifts are illustrative scenario models, not measured industry benchmarks. If calculating this for your own organization, adjust the break-even math strictly against your team’s actual loaded payroll and net contribution margins (e.g., at an unadjusted $100,000 cost, a $15–$30 pro creative lift breaks even at 3,333–6,667 users; a $50–$100 SaaS lift breaks even at 1,000–2,000 subscribers).

The central thesis remains unchanged: unless you maintain a high-ARPU subscription workflow that natively benefits from side-by-side multitasking, building bespoke dual-screen interfaces at launch remains an inefficient allocation of finite engineering capital.

For the greater part of human history, education was the vehicle for distributing what was scarce: knowledge. The teacher knew; the student learned. Books were limited, experts were difficult to access, and knowledge itself was a precious resource. Today, for the first time, humanity faces the exact opposite problem. Knowledge is no longer scarce. Artificial intelligence can summarise millions of sources in seconds, write software, produce text, and answer questions with fluency. If knowledge is no longer scarce, what, then, is education for?

My contention is this: artificial intelligence has not changed the purpose of education; it has merely made it visible. The true role of education was never merely the transmission of information. Its deeper purpose was to equip human beings with the mental tools needed to establish a reliable relationship with reality. Logic, critical thinking, the scientific method, probabilistic reasoning, and ethical judgement. These should not be treated as "subsidiary subjects", but as the very foundation of all education.

This idea is not new. Socrates emphasised asking better questions rather than rote memorisation. Aristotle argued that reason and character must develop in tandem. The Stoics remind us to govern our judgements. Karl Popper demonstrated that science progresses through falsifiability. John Dewey maintained that genuine understanding does not arise from the passive reception of information, but through experience and inquiry. Daniel Kahneman's work demonstrates how easily our minds can err, turning rigorous reasoning skills from a luxury into a necessity. Even Asimov's fiction serves as an indirect guide here, as his stories are built far more on human responsibility than on technology.

The rise of large language models is more than just a technological advance. It represents a fundamental shift in humanity's cognitive environment. For the first time, many routine intellectual tasks can be delegated to machines. This should not diminish the value of human thought; rather, it should prompt us to question which forms of thinking are truly worth preserving. Perhaps the greatest challenge facing education is no longer teaching students what to think, but teaching them how to think in a world where information is limitless, certainty is rare, and persuasive illusions can easily pass for truth.

Future education systems must judge students not by how much information they can recall, but by their ability to distinguish evidence from opinion, identify flaws in reasoning, revise their beliefs in light of new evidence, and uphold intellectual integrity. Artificial intelligence has not rendered human intelligence obsolete. On the contrary, it has revealed that human judgement is more valuable than ever. In this new era, the education systems that thrive will not be those that produce the most information, but those that cultivate people who know how to reach the truth.

Haskell addresses this through the newtype construct, which creates a distinct type from an existing one with zero runtime cost. In Swift, we can replicate this rigorous type safety by combining Phantom Types with the RawRepresentable protocol.

The Compile-Time Safety Guarantee

The primary advantage of this pattern is that it shifts domain logic errors from runtime to compile time. If we define distinct types for our arrival and departure timestamps, the Swift compiler physically prevents us from swapping them.

Swift

func createFlight(destination: String, arrival: NewType<ArrivalTag>, departure: NewType<DepartureTag>) -> Flight {
    // ❌ Compiler Error: Cannot convert value of type 'NewType<ArrivalTag>' to expected argument type 'NewType<DepartureTag>'
    return Flight(arrival: departure, departure: arrival, destination: destination)
}

By explicitly tagging the types, the mistake of passing departure into the arrival parameter is caught immediately during development.

The Implementation

The following code demonstrates the generic NewType wrapper. By using empty enums as "Tags", we create distinct types for arrival and departure that the compiler will treat as strictly incompatible.

Swift

import Foundation

struct NewType<Tag>: RawRepresentable, Codable {
    let rawValue: TimeInterval
}

extension NewType: Hashable  {}
extension NewType: Equatable {}

enum ArrivalTag {}
enum DepartureTag {}

struct Flight: Hashable, Codable {
    let arrival: NewType<ArrivalTag>
    let departure: NewType<DepartureTag>
    let destination: String
}

let flightJSON = """
{
    "destination": "London LHR",
    "arrival": 2345,
    "departure": 876867
}
"""

func decodeFlight(from jsonString: String) -> Flight? {
    let decoder = JSONDecoder()
    
    guard let data = jsonString.data(using: .utf8) else { return nil }

    do {
        return try decoder.decode(Flight.self, from: data)
    } catch {
        print("❌ Decoding failed: \(error)")
        return nil
    }
}

if let flight = decodeFlight(from: flightJSON) {
    print("✅ Successfully decoded Flight:")
    print("   Destination: \(flight.destination)")
    print("   Arrival    : \(flight.arrival.rawValue)")
    print("   Departure  : \(flight.departure.rawValue)")
}

Functional Programming and Category Theory Concepts

Phantom Types

The Tag parameter in the NewType struct is a Phantom Type. It exists only in the type signature and does not appear in the stored properties of the struct. Its sole function is to serve as a marker for the compiler. This ensures that NewType<ArrivalTag> and NewType<DepartureTag> are seen as entirely different entities.

Isomorphism

From the perspective of category theory, the NewType struct is isomorphic to the underlying TimeInterval. This means there is a total, one-to-one mapping between a TimeInterval and a NewType<Tag> instance.

By utilising RawRepresentable, we preserve this isomorphism. We gain the semantic clarity of a custom type without losing the ability to access and manipulate the data in its original primitive form.

The Advantage of RawRepresentable and Flat Data

In Swift, defining a standard wrapper struct often results in nested JSON structures. For example, without specific conformance, a NewType might encode to a nested object like {"arrival": {"rawValue": 2345}}.

By adopting RawRepresentable, the Swift Codable system recognises the struct as a transparent wrapper around its rawValue. This enables flat data encoding: the JSON remains a clean, standard numeric timestamp, while the Swift domain model remains strictly typed. This provides the exact safety of Haskell's newtype while maintaining perfect compatibility with existing, flat API structures.

Conclusion

Utilising this pattern offers several critical benefits for architecture:

• Strict Type Safety: Logic errors regarding parameter roles are caught at compile time.

• No Performance Overhead: Structs are value types that the Swift compiler can heavily optimise, treating them identically to the underlying primitive at runtime.

• Declarative Intent: The code explicitly documents the role of each piece of data through the type system rather than relying on variable naming conventions.

In this post, we are going to write a tiny "login" program in Swift, disassemble it, and find the exact instruction that decides if our password is right or wrong.

Then, we are going to change that instruction to let us in with any password.

Part 1: The Swift Program

First, our highly secure, un-hackable login program, login.swift:

// login.swift

// Our login function with a very secret password
func login(pass: String) -> Bool {
    pass == "right-password"
}

// Get the password from the command line
// Note: CommandLine.arguments[0] is the program name
// CommandLine.arguments[1] is our first argument
let result = login(pass: CommandLine.arguments[1])

// Print success or failure
print(result ? "success" : "failure")

Let's compile it and run it to make sure it works as expected.

$ swiftc login.swift -o login

# Test with the wrong password
$ ./login wrong
failure

# Test with the right password
$ ./login right-password
success

It works perfectly. Now, let's break it.

Part 2: Disassembly

We will use objdump to disassemble the executable, turning its machine code back into (semi) readable ARM64 assembly.

$ objdump -D login

This produces a lot of output, which can be intimidating. But we are looking for two specific functions:

1. _main: This is the main entry point of our script.

2. _$s5loginAA4passSbSS_tF: This is our login(pass: String) -> Bool function after Swift "mangles" its name.

Part 3: Finding the Password in the Code

Let's look at our login function's assembly first (_$s5loginAA4passSbSS_tF). Tucked inside, we see it loading some data:

00000001000007a4 <_$s5loginAA4passSbSS_tF>:
...
1000007c8: 90000000    adrp    x0, 0x100000000
1000007cc: 9124d000    add     x0, x0, #0x934
...
1000007f8: 94000036    bl      0x1000008d0 ; This calls the string comparison function
...
100000810: 12000000    and     w0, w0, #0x1 ; Result is 1 (true) or 0 (false)
...
10000081c: d65f03c0    ret                  ; Return

The add x0, x0, #0x934 instruction is loading the address of our hardcoded password. How do we know? If we look at the __TEXT,__cstring (string) section of the dump, we find this at that exact address:

0000000100000934 <__cstring+0x10>:
100000934: 68676972    ; "righ"
100000938: 61702d74    ; "t-pa"
10000093c: 6f777373    ; "sswo"
100000940: 0a006472    ; "rd"

The program literally has "right-password" stored inside it. This function compares the input password to this string and returns 1 (true) or 0 (false) in the w0 register.

Part 4: The Branch

Now, let's look at _main. This is where the decision to print "success" or "failure" is made, based on the return value from our login function.

0000000100000628 <_main>:
...
100000668: 9400004f    bl    0x1000007a4 <_$s5loginAA4passSbSS_tF> ; CALLS OUR LOGIN FUNCTION
10000066c: aa0003e8    mov   x8, x0          ; Moves the 1 or 0 result into register x8 (w8)
...
1000006bc: 39400108    ldrb  w8, [x8]        ; Loads the boolean result (1 or 0) into w8
1000006c0: 36000188    tbz   w8, #0x0, 0x1000006f0 <_main+0xc8>
1000006c4: 14000001    b     0x1000006c8 <_main+0xa0>

This is it. This is the whole security model.

• 1000006c0: 36000188 tbz w8, #0x0, 0x1000006f0

tbz stands for "Test Bit and Branch if Zero". This instruction does the following:

1. Looks at register w8 (which holds our 1 for success or 0 for failure).

2. Tests bit #0 of that register.

3. If that bit is Zero (meaning the password was wrong), it branches (jumps) to address 0x1000006f0.

What is at 0x1000006f0? It is the code that loads and prints "failure".

If the bit is Not Zero (i.e., it's 1, meaning success), it doesn't branch. It just falls through to the next instruction at 0x1000006c4, which takes it to the code that prints "success".

Part 5: The Patch: Bypassing the Check

So, how do we bypass this? We just need to stop that conditional branch from ever happening. We can "neuter" the instruction by overwriting it with a nop (No-Operation) instruction.

The nop instruction in ARM64 is d503201f. It literally does nothing.

By replacing the tbz instruction with a nop, the code will always fall through to the "success" block, no matter what the password is.

Here is our plan:

1. Find the bytes: The tbz instruction is 36000188. On a little-endian system (like Apple Silicon), this is stored in the file as 88 01 00 36.

2. Replace the bytes: The nop instruction is d503201f. This is stored as 1f 20 03 d5.

3. Use a hex editor (like hexedit) to find 88 01 00 36 and replace it with 1f 20 03 d5.

# 1. Open the file in the hex editor
$ hexedit login

# 2. Press Ctrl+S to search.
#    Search for hex bytes: 88 01 00 36

# 3. Type over it with the new bytes: 1f 20 03 d5
#    (The text will turn red)

# 4. Press Ctrl+X to exit, and 'y' to save.

Part 6: The Final Step (macOS Security)

If we try to run ./login now, it will hang or crash. We have modified the binary, which breaks its "code signature". macOS sees the file has been tampered with and refuses to run it.

We need to apply a new, ad-hoc signature to tell macOS we trust this new version.

$ codesign -f -s - login

The Result

Now, we run our patched app.

$ ./login anything-i-want
success

$ ./login blahblah
success

$ ./login 1234
success

We have successfully bypassed the password check by changing just 4 bytes in the compiled executable.

This is, of course, a very simple example, but it demonstrates the fundamentals of binary patching and reverse engineering. It also shows why hardcoding secrets in your client-side applications is never a good idea!

In modern software development, this isn't a trivial question. The answer can range from "nothing" to "everything, everywhere, all at once." Our tools give us some clues, but they often don't tell the whole story. What we need is a shared vocabulary to talk about the risk of change.

Let's propose one: The Change Impact Scale (CIS).

The Illusion of Access Control

As programmers, our first line of defense against unintended consequences is access control. Every language has a system for defining a "blast radius" for our code.

• In Swift, we have a rich vocabulary: private, fileprivate, internal, public, and open. Each provides a clear, compiler-enforced boundary on what code can see and use other code.
• In Go, the system is beautifully simple: identifiers starting with a capital letter are exported (public), while those starting with a lowercase letter are unexported (private to the package).
• Rust enforces strict privacy by default. Anything you want to expose outside of a module must be explicitly marked with the pub keyword.
• OCaml uses interface files (.mli) to explicitly declare the public API of a module (.ml), hiding implementation details by default.

These tools are fundamental. They are the bedrock of encapsulation and good software architecture.

But they are not enough.

Access control tells you who can call your code, but it tells you nothing about how they depend on it. A public function might be safe to change, while a private string constant might be a time bomb. This is because of hidden, implicit contracts that the compiler can't see.

Introducing the Change Impact Scale (CIS)

The CIS is a heuristic, a rule of thumb, designed to create a shared understanding of risk. It grades a change on a scale from 0 to 5, considering not just its visibility (Scope) but also the nature of its connections (Coupling Type).

CIS 0: Atomic Change (Fully Isolated)

• The Litmus Test: The change is completely invisible from the outside. No tests would need to be updated.
• Examples: Renaming a local variable inside a function, refactoring the internal logic of a private method without changing its behavior. This is the safest change you can make.

CIS 1: Controlled Internal Change

• The Litmus Test: The change's impact is contained within a single module, and your compiler is your safety net.
• Examples: Adding a parameter to an internal (Swift) or package-private (Java/Go) function. The compiler will force you to fix every call site, leaving no room for runtime surprises.

CIS 2: Brittle Internal Change (Implicit Contracts)

• The Litmus Test: The change breaks something within your own codebase, but the compiler cannot see the connection. This is the domain of "magic strings" and runtime failures.
• Examples:
  • Configuration Keys: Renaming a key in a YAML file that is read as a string in your code.
  • CSS Selectors: Renaming a CSS class in a stylesheet without updating the HTML/JSX that uses it.
  • Reflection: Relying on the string name of a method or class, as is common in logging or some DI frameworks.

CIS 3: Cross-Module / Service Contract

• The Litmus Test: The change breaks a contract with a "trusted peer" that you control, but which is deployed independently. Coordination is required.
• Examples:
  • Changing the JSON schema of an internal microservice API. The downstream service will fail to parse the response.
  • Modifying the schema of an event published to a message queue (Kafka, RabbitMQ), breaking consumer services.

CIS 4: Public Contract

• The Litmus Test: The change breaks a contract with "the outside world." You don't know all your consumers and must manage the change with versioning and deprecation policies.
• Examples:
  • Removing a field from a public v1 REST API.
  • Altering a public function in an open-source library you publish to npm or Maven.

CIS 5: Petrified Contract (Immutable Reality)

• The Litmus Test: The contract is so foundational that changing it would cause a catastrophic cascade of failures across an ecosystem.
• Examples: The structure of the JPEG file format, the meaning of an HTTP status code, or the syntax of a core language keyword like if.

Standing on the Shoulders of Giants

The idea of classifying dependencies isn't new. The CIS is a practical heuristic inspired by more formal computer science concepts.

Connascence: A term coined by Meilir Page-Jones, connascence is a way to measure software dependency. It means "born together" and describes the degree to which two components must change together. There are many types, like Connascence of Name (when multiple components must agree on a name, like a function name as a string—a perfect fit for CIS 2) and Connascence of Position (when the order of values matters, like function arguments). CIS can be seen as a simplified, practical application of this powerful idea.

Coupling and Cohesion: These are foundational principles of software engineering. CIS is, at its heart, a tool for identifying and communicating high-risk forms of coupling. A CIS 5 change represents the tightest possible coupling, while a CIS 0 change is completely decoupled.

How to Use the CIS in Your Team

The real power of the CIS is in communication.

• During Code Reviews: Instead of a vague "this seems risky," you can say, "This looks like a CIS 3 change because you're modifying a shared API model. Have you coordinated with the mobile team?"
• When Planning Refactoring: "Our logs show a lot of runtime errors from CIS 2 changes. Let's prioritize refactoring these config strings into type-safe constants."
• In System Design: "Can we design this interaction to be CIS 1 by using a compiled gRPC client instead of a CIS 3 dynamic JSON contract?"

Conclusion

Access controls are essential, but they only show us part of the picture. By also considering the type of dependency, the Change Impact Scale gives us a richer, more accurate way to assess risk.

It provides a shared vocabulary that allows us to move from fear and uncertainty to informed, confident decision-making. The next time you're about to make a change, ask yourself: What's the CIS level? 👍

This is where Merkle Trees come in. A Merkle Tree is a powerful data structure that allows you to efficiently and securely verify the integrity of a large set of data. In this blog post, I'll explore the concept of Merkle Trees and how you can use them in your Swift projects with the help of my open-source MerkleTree library.

What is a Merkle Tree?

A Merkle Tree, also known as a hash tree, is a tree in which every leaf node is labelled with the hash of a data block, and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes.

The root of the tree, called the Merkle root, is a single hash that represents the entire set of data. If any part of the data changes, the Merkle root will also change, making it easy to detect any tampering.

Why Use a Merkle Tree?

Merkle Trees offer several benefits:

• Efficiency: They allow you to verify the integrity of a large set of data without having to download or compare the entire dataset. You only need the Merkle root and a small amount of additional information, called an audit trail, to verify a specific piece of data.
• Security: They use cryptographic hash functions to ensure that the data cannot be tampered with without being detected.
• Decentralization: They are well-suited for use in distributed systems, where data is spread across multiple nodes. Each node can independently verify the integrity of the data it has, without having to trust a central authority.

Introducing my MerkleTree Swift Package

My MerkleTree Swift package is a lightweight, easy-to-use library that allows you to create and work with Merkle Trees in your Swift projects. It respects the Tree Hash EXchange format (THEX), which is designed for efficiently finding and transmitting differences between files.

Features

• Builds a Merkle Tree from an array of Data blobs.
• Handles both balanced and unbalanced trees.
• Generates audit trails (proofs) for a given item.
• Verifies audit trails.

Getting Started

To use my MerkleTree package in your project, add it as a dependency in your Package.swift file:

let package = Package(
    dependencies: [
        .package(url: "https://github.com/swift-tree/MerkleTree.git", from: "1.0.0")
    ]
)

Creating a Merkle Tree

Creating a Merkle Tree is as simple as calling the build(fromBlobs:) static method with an array of Data blobs:

import MerkleTree
import Foundation

let dataBlobs = [
    "Hello".data(using: .utf8)!,
    "World".data(using: .utf8)!,
    "This".data(using: .utf8)!,
    "is".data(using: .utf8)!,
    "a".data(using: .utf8)!,
    "Merkle".data(using: .utf8)!,
    "Tree".data(using: .utf8)!,
]

let merkleTree = MerkleTree.build(fromBlobs: dataBlobs)

// Get the root hash
let rootHash = merkleTree.value.hash
print("Root Hash: \(rootHash)")

Verifying Data with Audit Trails

An audit trail (or proof) allows you to verify that a specific piece of data is part of the Merkle Tree without having to reconstruct the entire tree. Here's how you can generate and verify an audit trail:

// Create a leaves array to get the audit trail
var leaves = [MerkleTree]()
func getLeaves(tree: MerkleTree) {
    if tree.children.left == nil && tree.children.right == nil {
        leaves.append(tree)
    }
    if let left = tree.children.left {
        getLeaves(tree: left)
    }
    if let right = tree.children.right {
        getLeaves(tree: right)
    }
}
getLeaves(tree: merkleTree)

// Get the hash of the item you want to audit
let itemToAudit = "Hello".data(using: .utf8)!
let itemHash = itemToAudit.doubleHashedHex

// Get the audit trail
let auditTrail = merkleTree.getAuditTrail(for: itemHash, leaves: leaves)

// Verify the audit trail
let isValid = merkleTree.audit(itemHash: itemHash, auditTrail: auditTrail)
print("Audit trail is valid: \(isValid)") // true

Use Cases of Merkle Trees

Merkle Trees are used in a wide variety of applications, including:

• Blockchain and Cryptocurrencies: In cryptocurrencies like Bitcoin, Merkle Trees are used to summarize all the transactions in a block, allowing for efficient verification of transactions.
• Distributed Systems: In peer-to-peer networks like BitTorrent, Merkle Trees are used to verify the integrity of file pieces downloaded from different peers.
• Certificate Transparency: Google's Certificate Transparency project uses Merkle Trees to create a public log of all issued SSL/TLS certificates, allowing anyone to verify that a certificate is valid and has not been tampered with.
• Verifiable Databases: Merkle Trees can be used to create verifiable databases, where a user can query the database and receive a cryptographic proof that the returned data is correct.

Conclusion

Merkle Trees are a powerful tool for ensuring data integrity in a wide range of applications. With my MerkleTree Swift package, you can easily incorporate this powerful data structure into your own projects.

I encourage you to check out my project on GitHub and try it out for yourself. I welcome any feedback or contributions!

For years, this concept fascinated and eluded me. This is the story of that project—a journey to translate one of the most abstract theorems in history into working Swift code.

The Winding Path to a Locked Room

My journey didn't start with Gödel. In fact, it started with a very practical interest in functional programming. Writing cleaner, more predictable code led me down the rabbit hole of Type Theory, the mathematical foundation for languages like Haskell and Swift. I was captivated by the idea that a program's type could be a proof of its correctness.

This led me to Gentzen's Proof Theory, where I started to see proofs not as static walls of text but as dynamic, structured objects that could be manipulated and reasoned about. With every step, I was unknowingly gathering the tools I needed to tackle the big one.

Every path seemed to lead back to Gödel.

I was reminded of a book on his proof I had bought over a decade ago. On my first attempt to read it, I admit I understood almost nothing. It was a dense, impenetrable wall of symbols. But this time, after my detour through types and proofs, something clicked. The symbols weren't just abstract logic anymore; they were components of a system. And systems can be built.

This project is the result of that "aha!" moment—an attempt to demystify the theorem by building its machinery from the ground up.

The Blueprint: How Do You "Build" a Theorem?

Before diving into code, we need to understand the core concepts we're trying to model.

1. Formal Systems: A Game of Logic

Imagine a simple board game. You have:

• Axioms: The starting positions of your pieces. These are statements you accept as true without proof (e.g., "0 = 0").

• Rules of Inference: The legal moves you can make (e.g., if you have statements A and "A implies B", you can derive B).

• Theorems: All the possible board states you can reach from your starting position using only legal moves.

A formal system is just this game of logic. The goal of the system is to generate all possible true theorems. Gödel's theorem asks: is it possible for a system to generate all true statements about numbers? His answer was a resounding no.

2. Gödel Numbering: Turning Logic into Math

Gödel's central genius was to find a way to make a formal system talk about itself. He did this by assigning a unique number (a Gödel Number) to every symbol, formula, and proof.

For this project, I assigned a number to each symbol in our simple logical language: ~ is 1, ∨ is 2, ( is 8, x is 11, and so on. A formula is a sequence of these numbers. To get a single unique number for a whole formula, we use prime factorization:

The formula s1, s2, s3, ... becomes 2^{g(s1)} x 3^{g(s2)} x 5^{g(s3)} x ...

Suddenly, statements about logic become statements about numbers. "This formula is a theorem" becomes "This specific, massive number has a certain mathematical property."

The Technical Challenge: An Impossible Number

A central challenge in implementing Gödel's proof is representing the "Gödel numbers" themselves. Let's take a simple 10-symbol formula from the project: (∃x)(x=sy). While it looks small, its Gödel number is anything but. Through logarithmic calculation, we can determine that its value requires approximately 287 bits (or 36 bytes) of storage.

For perspective, a standard 64-bit integer (UInt64), the largest in many languages, offers only 64 bits (8 bytes). Our number isn't just a little bigger; it's more than four times the size and represents a value so vast it's in a completely different universe of magnitude. And this is for a trivial formula. A real proof would require thousands or millions of bits, making it computationally impossible to store these numbers directly.

So, how do you work with a number you can't compute? You work on it symbolically. For this, I used a library I had previously built called ExpressionTree. Instead of calculating the final number, ExpressionTree represents it as a tree of its prime factors. For example, $2^8 x 3^4$ is stored like this:

* (^ 2 8) (^ 3 4)

This allows the program to reason about these immense numbers, compare them, and—most importantly—perform substitutions on them without ever needing to compute their final value.

A Walk Through the Code

The project's structure directly mirrors the concepts above.

• Proposition.swift: This is the alphabet of our formal language. It defines each logical symbol and assigns it a Gödel number.

• GodelNumbering.swift: This is our universal translator. It takes a formula string, converts it into a sequence of Gödel numbers, and then encodes that sequence into an ExpressionTree.

• GStatement.swift: The protagonist of our story. This struct represents the famous self-referential Gödel sentence, "G." Its one job is to enact the self-reference that creates the paradox.

The Climax: A Paradox in a Unit Test

The entire logical argument of the theorem comes to life in a single unit test: test_provable_leads_to_contradiction(). Let's walk through it.

Step 1: The Template (G)

First, we define our Gödel sentence, G. At this stage, it's just a template. It contains a placeholder variable, y, and it informally says:

"The formula you get by substituting y in the formula with Gödel number y is not provable."

Step 2: The Self-Reference (G(g))

This is the moment of magic. We perform a substitution on G, but we substitute the placeholder y with the Gödel number of G itself.

The formula is no longer a template. It's a concrete statement that now says:

"This very statement is not provable."

Step 3: The "What If" Scenario

Now we test the limits of our system. We ask, "What if our formal system was powerful enough to prove this statement?" We simulate this by creating a Proof object where our self-referential statement is manually added to the list of official theorems.

Step 4: The Contradiction

The final line of the test asserts that GStatement.isProvable() should be true. And it is—because we put the proof in ourselves. But think about what we've just done.

Our system has successfully proven a statement that is explicitly defined as being "not provable." It has proven a falsehood. This is a fundamental contradiction, meaning any system capable of this feat is logically inconsistent.

And what if the test had failed? That would mean our system is consistent... but it would also mean it failed to prove a statement that we know to be true (the Gödel sentence itself). That would make the system incomplete.

This is the dilemma. Consistent or Complete. You can't have both.

Conclusion: The Beauty of Limits

Gödel's theorem is often seen as a pessimistic result—a statement about what we can never know. But I see it differently. It's a beautiful map of the boundaries of formal reason. It shows that truth is a larger concept than provability.

For me, this project was the ultimate confirmation of a simple idea: the best way to understand a complex system is to build it. Going from an impenetrable book to a passing unit test transformed an abstract piece of mathematics into a tangible, working machine.

This feature, when enabled, provides a more convenient and equally secure way to authorize actions in the terminal that require elevated permissions. Let's dive into how you can set this up on your macOS machine.

What is PAM and Why Do We Modify It?

Before we get to the how, let's briefly touch upon the "why." macOS, like other Unix-like systems, uses a framework called PAM (Pluggable Authentication Modules) to handle authentication tasks. PAM acts as a layer between applications (like your terminal) and the actual authentication methods (like passwords, Touch ID, etc.).

PAM uses configuration files to determine how a user should be authenticated for a specific service. By modifying the PAM configuration file for sudo, we can instruct the system to accept Touch ID as a valid authentication method.

Enabling Touch ID for sudo

The process involves editing a PAM configuration file. The specific file differs slightly depending on your macOS version.

For macOS Sonoma (and later):

macOS Sonoma introduced a change that makes this modification more persistent across system updates by using a dedicated local configuration file.

1. Open Terminal: Launch the Terminal application from your Applications > Utilities folder or via Spotlight search.

2. Copy the template file: We'll create a local configuration file based on a template. Run the following command and enter your administrator password when prompted:

    sudo cp /etc/pam.d/sudo_local.template /etc/pam.d/sudo_local
   

3. Edit the configuration file: Now, open the copied file for editing using a command-line text editor like nano:

    sudo nano /etc/pam.d/sudo_local
   

4. Uncomment the Touch ID line: Look for the line that starts with # auth sufficient pam_tid.so. This line is commented out by default. Remove the # at the beginning of the line to uncomment it. The line should now look exactly like this:

    auth sufficient pam_tid.so
   

5. Save and Exit: Save the changes to the file. If you're using nano, press Control + O, then hit Enter to confirm the filename, and finally press Control + X to exit the editor.

For macOS versions prior to Sonoma:

If you are using an older version of macOS, you will directly edit the main sudo PAM configuration file. Be aware that this change may be reset after a macOS system update, requiring you to repeat these steps.

1. Open Terminal: Launch the Terminal application.

2. Edit the sudo configuration file: Open the sudo PAM file for editing with nano:

    sudo nano /etc/pam.d/sudo
   

3. Add the Touch ID line: Add the line auth sufficient pam_tid.so at the beginning of the file, just below any lines that start with a # (which are comments). It should look something like this:

    # sudo: auth account password session
    auth sufficient pam_tid.so
    auth include sudo_local
    # ... rest of the file ...
   

   Make sure auth sufficient pam_tid.so is above auth include sudo_local if that line exists.

4. Save and Exit: Save the file and exit the editor (using Control + O, Enter, and Control + X in nano).

Testing Your Setup

After making the changes and saving the file, close and reopen your Terminal application to ensure the new configuration is loaded.

Now, try running a command that requires sudo, such as:

sudo ls /private/var/root