100 Days of Mobile Architecture Bootcamp
Most mobile engineers learn by building. They pick up patterns from tutorials, adopt whatever architecture the senior engineer on the team prefers, and accumulate experience one production incident at a time. It works, eventually, but it is slow, expensive, and heavily dependent on luck. This bootcamp takes a different approach. Instead of teaching you what to build, it teaches you how to think; the architectural judgment that separates engineers who implement features from engineers who design systems. Every day covers one concept, one real scenario you have probably already lived through, and one hands-on exercise that applies the concept directly to your own code. No code syntax, no framework tutorials, just the thinking, the principles, and the practice. By Day 100 you will not have memorised a set of patterns; you will have developed the instincts, vocabulary, and decision-making frameworks that most mobile engineers spend a decade acquiring through trial and error, and a systematic way to keep building that judgment for the rest of your career. Built for Flutter, Android, and iOS engineers, with platform-specific depth built into the back half of the program.
Prerequisites
- You can already build mobile apps. This bootcamp teaches you to design them, not build your first one
- Experience with at least one mobile platform: Flutter/Dart, Android/Kotlin, or iOS/Swift
- No specific architecture experience required. Day 1 starts from first principles
- No new frameworks or tools to install. Every exercise runs against code you already have
- A current personal or work project is strongly recommended for applying the exercises
What You'll Learn
- What architecture actually is; the decisions that determine how expensive change will be six months from now
- How to read requirements like an architect and find the hidden decisions product teams did not know they were making
- How to evaluate any architectural pattern; what problem it solves, when to use it, and when not to
- The mental models that govern state, lifecycle, layers, and dependencies in mobile applications
- How to design systems that survive real production conditions; offline, process death, configuration changes, background restrictions
- Platform-specific architectural depth across Android, iOS, and cross-platform Flutter development
- How to read an unfamiliar codebase and understand the team and decisions that produced it
- When to follow architectural rules and when breaking them is the right call
- How to build architectural culture on a team so quality does not depend on one person being in the room
- What to optimise for over a career; the knowledge that depreciates and the judgment that appreciates
Who This Is For
Flutter, Android, and iOS engineers who can already build mobile apps and are ready to learn how to design them; self-taught developers closing architectural gaps, and engineers moving into senior, tech lead, or architect roles who want a systematic way to build the judgment those roles require.
What's Included
- 17+ hours of on-demand video
- Beginner friendly assignments that consolidate a stretch of the program's principles into a single review of your own project
The Program
What Is Architecture, Actually?
You will learn what architecture actually means, that is, the decisions that are hardest to reverse. You will leave with a working definition that applies to every project you will ever work on.
The Cost of a Decision
You will learn to see every architectural decision as existing on a reversibility spectrum (from trivially cheap to nearly permanent) and develop the habit of asking the reversal cost question before committing to anything significant.
Reading Requirements Like an Architect
You will learn to read a requirements document and find the architectural decisions hiding inside it; the offline assumptions, scale questions, ownership ambiguities, and evolution paths that product teams did not know they were leaving unanswered.
The Three Questions Before Every Design
You will learn the three questions that every design session should start with: what changes frequently, what must never break, and who else depends on this. These three questions alone will prevent the majority of over-engineered and under-engineered designs.
Separation of Concerns Is Not About Folders
You will learn what separation of concerns actually means and it's not folder names, but dependency direction, and how to test whether your concerns are genuinely separated or merely labelled.
State Is the Enemy
You will learn why state is the root cause of most mobile bugs, the two questions that govern every piece of mutable state (who owns it, how long should it live), and what architecture's actual job is when it comes to state; not making it easy to use, but hard to abuse.
The Lifecycle Trap
You will learn why mobile is fundamentally different from a server environment, why process death is a scheduled event rather than an edge case, and how to design screens and flows that survive interruption gracefully.
Layers Are for Isolation, Not Ceremony
You will learn the difference between a layer that provides real isolation and one that is just a label on a directory, and why architectures enforced only by convention always degrade under deadline pressure.
The Dependency Rule
You will learn the single most important law in layered systems: dependencies must point inward. You will understand what this enables (testability, portability, changeability) and what a single violation quietly destroys.
Naming Is Architecture
You will learn why naming is an architectural decision and not a style preference, how to test whether a name is doing its job, and why system vocabulary (shared consistent terms across the whole codebase) matters more than any individual class name.
The Abstraction Problem
You will learn when abstraction genuinely helps versus when it adds complexity without benefit, how to recognise premature abstraction, and the discipline of abstracting at the right moment rather than the earliest one.
The Rewrite Temptation
You will learn why the urge to rewrite existing code is almost always the wrong instinct, what the actual cost of a rewrite is versus an incremental improvement, and how to make the case, to yourself and your team, for the harder but smarter path.
Architecture Decision Records
You will learn what an ADR is, why documenting the why behind decisions matters as much as the decisions themselves, and how to write ADRs that are genuinely useful rather than ceremonial.
Interface Contracts
You will learn how to design clean interfaces between components; what belongs in the contract, what does not, and how a well-designed interface protects both sides from changes in the other.
Offline-First Architecture
You will learn why offline behaviour is an architectural commitment and not a feature, the design decisions that offline-first architecture requires upfront, and what it costs to retrofit offline support into a system that was not designed for it.
Navigation as Architecture
You will learn why navigation is not just routing but an architectural concern; one that affects the back stack, state preservation, deep linking, and the coherence of the user experience under real-world interruption.
Performance as a Design Constraint
You will learn to treat performance not as an optimisation you do at the end but as a constraint you design within from the start, and which architectural decisions create performance problems that no amount of later optimisation can fully fix.
Error Modelling
You will learn to design error handling at the architectural level; not just catching exceptions, but modelling the full space of things that can go wrong and making deliberate decisions about how each category is handled and communicated.
Testing as Architectural Feedback
You will learn to read your tests as signals about your architecture because code that is hard to test is almost always code that is too tightly coupled, and the test suite is often the first honest report on the quality of your design.
Architectural Instincts
You will learn what architectural instinct actually is, where it comes from, and how to develop it deliberately rather than waiting for ten years of accidental experience to provide it.
What a Pattern Actually Solves
You will learn to see patterns as solutions to specific problems rather than universal best practices, and develop the habit of asking what problem a pattern solves before deciding whether to adopt it.
MVVM Is Not About Files
You will learn what MVVM is actually designed to achieve, why most MVVM implementations get the purpose wrong by focusing on the structure, and what a correctly motivated MVVM looks like in practice.
The Repository's Real Job
You will learn what the Repository pattern is genuinely for; not just abstracting data sources, but being the single source of truth for a domain, and what happens when repositories leak their implementation details upward.
Use Cases and Single Reason to Change
You will learn what use cases are for, why one use case should have exactly one reason to change, and how to identify when a use case has accumulated too many responsibilities.
The Observer Pattern and Event Overload
You will learn how the Observer pattern enables reactive architectures, where it tends to go wrong as systems grow, and what event overload looks like before it becomes a crisis.
The God ViewModel
You will learn to recognise the God ViewModel antipattern (a ViewModel that has accumulated too many responsibilities), understand how it forms, and design the split that distributes those responsibilities correctly.
The Anemic Domain Model
You will learn what an anemic domain model is, why it is a trap disguised as simplicity, and how to move business logic back into the domain where it belongs.
Dependency Injection as a Maze
You will learn why dependency injection becomes painful at scale, the architectural signals that your DI setup has grown beyond its purpose, and how to design DI that remains navigable as the project grows.
The Leaky Abstraction
You will learn what a leaky abstraction is, why all abstractions leak to some degree, and how to design abstractions that leak as little as possible while still delivering their benefit.
The Singleton Trap
You will learn why singletons are so tempting, the specific ways they create architectural problems over time, and the alternatives that provide the same convenience without the hidden coupling.
Pagination as Architecture
You will learn why pagination is not a UI concern but a data architecture concern, what decisions need to be made at the design stage for pagination to work reliably, and what retrofitting pagination into an existing architecture actually costs.
Optimistic Updates Done Right
You will learn what optimistic updates are, why they improve user experience dramatically, and the architectural work required to do them correctly including rollback, conflict resolution, and error visibility.
Background Work Architecture
You will learn the three reliability tiers of background work (best effort, should complete, must complete), which platform mechanism corresponds to each tier, and why choosing the wrong mechanism produces failures that only appear for a percentage of users on real devices.
Multi-Platform Abstraction
You will learn where cross-platform abstraction genuinely holds, where it breaks under the pressure of platform-specific behaviour, and how to design the boundary between shared and platform-specific code so it stays honest.
Push Notifications as Data Architecture
You will learn to think about push notifications not as a delivery mechanism but as a data architecture concern; one that involves payload design, delivery reliability, state synchronisation, and fallback behaviour.
When Two Good Patterns Break Each Other
You will learn that patterns do not always compose cleanly, how to recognise when two individually correct patterns are creating tension in combination, and how to resolve the tension without abandoning either.
Clean Architecture Meets Feature Modules
You will learn the specific challenges that arise when you apply Clean Architecture across feature modules, the decisions that need to be made explicitly at the intersection, and the mistakes that happen when those decisions are left implicit.
Simple Beats Clever
You will learn why simplicity is an architectural virtue and not a sign of inexperience, what clever architecture actually costs the team over time, and how to defend the simpler approach when the team is tempted by sophistication.
The Right Pattern for the Right Scale
You will learn that patterns have appropriate scales, that the right architecture for a two-person team is not the right architecture for a twenty-person team, and how to choose patterns that match your current reality rather than an imagined future.
Recognising Patterns in the Wild
You will learn to read an unfamiliar codebase and identify the patterns in use including the accidental ones, the half-implemented ones, and the ones that are present in name but absent in practice.
Architecture That Absorbs Requirements
You will learn what it means to design a system that can accommodate change rather than resist it, the specific structural properties that make a codebase absorb new requirements cheaply, and the ones that make every new requirement expensive.
Feature Flags as Architecture
You will learn to treat feature flags not as a deployment convenience but as an architectural decision; one that affects your data model, your testing strategy, your technical debt, and your ability to reason about what the application is doing at any given time.
API Versioning and Backwards Compatibility
You will learn why API versioning is an architectural commitment rather than a technical detail, the different versioning strategies and their trade-offs, and what backwards compatibility actually requires of the systems on both sides of the contract.
Designing for Deletion
You will learn the underappreciated architectural practice of designing code to be deleted; writing features in a way that makes removing them clean rather than surgical — and why this matters for long-lived codebases.
The Migration Pattern
You will learn the architectural discipline of migrating from one approach to another without breaking the system in flight; the strangler fig pattern, the branch by abstraction, and the discipline of migrating incrementally rather than all at once.
Technical Debt Is Not One Thing
You will learn that technical debt is not a monolithic category but a spectrum of different types of compromise, each with different causes, different interest rates, and different resolution strategies.
Refactoring Strategy
You will learn how to approach refactoring as an architectural discipline rather than a cleanup activity with a clear scope, a defined end state, test coverage as the safety net, and a strategy for merging back to the main branch without disruption.
Code Review as Architectural Feedback
You will learn to use code review as an architectural tool; not just catching bugs and style issues, but finding coupling that should not exist, abstractions that are leaking, and decisions that will constrain future changes.
Documentation That Actually Helps
You will learn the difference between documentation that serves the reader and documentation that serves the writer's need to feel documented, and how to write architecture documentation that remains accurate and useful over time.
Consistency as a Quality Multiplier
You will learn why architectural consistency is a force multiplier for team productivity, what consistency actually means beyond naming conventions, and how to maintain it as a codebase grows and new engineers join.
Test at the Right Layer
You will learn why the layer at which you test matters as much as the fact that you test, how to match test type to architectural concern, and what the distribution of unit, integration, and end-to-end tests reveals about architectural health.
Test Doubles and Isolation
You will learn what test doubles are, the different varieties (stubs, mocks, fakes, spies), when each is appropriate, and how the architecture determines how easy or difficult test isolation actually is.
Contract Testing for Mobile APIs
You will learn what contract testing is, why it is especially valuable for mobile applications that communicate with backends they do not own, and how to implement it without requiring coordination between teams for every test run.
Testing Mobile-Specific Behaviour
You will learn how to test the behaviours that are unique to mobile (lifecycle events, process death, background transitions, device sensor responses), and why these require architectural consideration to be testable at all.
The Feedback Loop
You will learn why fast feedback is the most valuable property of a test suite, what makes feedback loops slow, and how architectural decisions directly determine whether your test feedback arrives in milliseconds or minutes.
Observability Is Architecture
You will learn to treat observability (logging, metrics, tracing) as an architectural quality built in from the start rather than instrumentation added after problems appear, and what it costs to retrofit it.
Crash Reporting That Helps
You will learn what makes crash reporting genuinely useful versus noise, how to design the metadata and context that transforms a crash report from a stack trace into a reproducible diagnosis.
Gradual Rollouts and Canary Releases
You will learn the architecture that enables releasing to a percentage of users before full rollout; what the system needs to support, how to instrument it to detect problems early, and what to do when a canary signals a failure.
Graceful Degradation
You will learn to design systems that fail gracefully; that provide a reduced but functional experience when dependencies are unavailable, rather than systems that fail completely when any component is unhealthy.
Thinking About Production from Day One
You will learn the discipline of designing for production from the first sprint rather than retrofitting production concerns at launch, and which production concerns, if not considered upfront, create the most expensive surprises.
The Android Process Model
You will learn how Android's process model works at the architectural level; why the OS kills processes, what state survives and what does not, and how to design your application's state strategy around the reality of process death on Android.
Jetpack Architecture Components and Their Contracts
You will learn to think about Jetpack components not as interchangeable building blocks but as components with specific contracts, and how to reason about what happens when two components' contracts interact.
Background Work Architecture on Android
You will learn the Android background execution model, the reliability tiers of different background mechanisms, and how to choose the right API for each type of background work based on its actual reliability requirement.
Configuration Changes as Architecture
You will learn why configuration changes are a first-class architectural concern on Android, what survives a configuration change and what does not, and how to design screens that handle rotation, locale changes, and system font size changes without breaking state.
The Android Back Stack as Architecture
You will learn to think about the Android back stack as a data structure you are responsible for designing and not just routing between screens; and how popUpTo and inclusive flags are architectural decisions rather than navigation configuration.
Memory Ownership and ARC Architecture
You will learn how Automatic Reference Counting works in Swift, what retain cycles are and how they form, and how to design ownership hierarchies that prevent memory leaks by understanding reference semantics at the architectural level.
App Extensions and Architecture Boundaries
You will learn why app extensions are process boundaries and not just additional targets, what the shared framework architecture looks like for sharing code across app and extension, and what App Groups provide for shared data.
SwiftUI State Architecture
You will learn the ownership and lifetime semantics of each SwiftUI state mechanism — @State, @StateObject, @ObservedObject, @EnvironmentObject, and how to design the right ownership model before writing the first line of state code.
iOS Background Modes and Architecture
You will learn iOS's permissioned background execution model, what each background mode actually allows, and how to design background operations that align with App Store requirements and user trust expectations.
The App Store as an Architectural Constraint
You will learn to treat App Store guidelines as architectural requirements that belong in the first design session; not launch blockers discovered at submission; including In-App Purchase requirements, Sign In with Apple, and privacy nutrition labels.
Where the Abstraction Holds and Where It Breaks
You will learn to identify which parts of a cross-platform application genuinely benefit from shared implementation and which parts need platform-specific design to feel correct, and why identical UI and quality UI are not the same thing.
Platform Channels as Architecture
You will learn to design platform channels as a proper integration layer with consistent contracts, unified error handling, and a defined threading model rather than a collection of ad-hoc implementations per feature.
Shared Business Logic with Platform UI
You will learn the architectural discipline required to maintain shared logic with platform-specific UI over time where the boundary must be, how to enforce it, and what happens when it is allowed to blur under delivery pressure.
Feature Parity vs Platform Idioms
You will learn the distinction between feature parity (same capabilities on both platforms) and platform idioms (interactions that feel correct on each platform), and why optimising for one at the expense of the other produces an app that satisfies neither platform's users.
The Cost of Lowest-Common-Denominator Design
You will learn to identify where your cross-platform strategy is leaving platform capabilities unused, map the experience gap that produces, and build the ROI case for targeted platform investment.
Camera and Sensor Pipeline Architecture
You will learn why camera API selection is an architectural decision with high reversal cost, how to evaluate the right API level for your feature roadmap rather than your current requirement, and how to design the threading model for a real-time camera pipeline.
Biometrics as a Trust Architecture
You will learn that biometric authentication is only as strong as the trust architecture around it; where the result is stored, what it authorises, how long the trust lasts — and how to design the full trust model rather than just the authentication check.
Push Notification Architecture Across Platforms
You will learn the real delivery reliability gap between APNs, FCM, and actual delivery on a fragmented Android device landscape; and how to design notification architecture that handles must-deliver notifications reliably without assuming push always works.
Widget and App Extension Architecture
You will learn the widget execution model (snapshots, refresh budgets, OS-managed scheduling), and how to design widget content that remains genuinely useful at its worst-case staleness rather than assuming fresh data.
Accessibility as Structural Architecture
You will learn why accessibility is an architectural quality and not a compliance checklist, how accessibility difficulty reveals underlying structural problems, and why investing in accessible architecture produces benefits for all users rather than just those using assistive technology.
Pragmatic Architecture
You will learn to match architectural complexity to the actual context of the project (team size, stage, timeline, codebase lifetime), and develop the honest judgment to distinguish appropriate simplicity from architectural laziness.
The Right Wrong Decision
You will learn that sometimes the architecturally incorrect decision is the right business decision, and how to make those decisions consciously, with documented scope, clear ownership, and a defined resolution plan rather than as undocumented accidents.
When Consistency Costs More Than It Saves
You will learn that consistency is a default, and not a rule, and develop the judgment to recognise when the cost of forcing consistency across genuinely different problems exceeds the benefit, and two clear approaches are better than one stretched one.
Technical Debt as a Tool
You will learn to think about deliberate technical debt as a financial instrument with a principal, an interest rate, a maturity date, and a paydown plan rather than treating all debt as uniformly bad or uniformly acceptable.
Shipping vs Perfect
You will learn the discipline of recognising when architecture is good enough to ship; not perfect, but appropriately fit for purpose and how to make that judgment rigorously rather than either shipping prematurely or refining indefinitely.
What a Codebase Reveals About Its Team
You will learn to read a codebase archaeologically; finding the architectural phases, the pressure indicators, the team signatures, and the load-bearing code before changing anything you do not yet understand.
Architectural Intent vs Architectural Accident
You will learn to distinguish patterns that were deliberately chosen from patterns that accumulated because someone followed the first example they saw and why following an accidental pattern confidently is how accidents become permanent architecture.
The Archaeology of a System
You will learn the discipline of reading code with the assumption that it makes sense and finding the sense behind what looks strange because the workaround that looks unnecessary is often the only thing standing between a working system and a production incident waiting to happen again.
Recognising When a Codebase Has Outgrown Its Architecture
You will learn the specific signals that indicate an architecture is no longer appropriate for the team and scale it is serving; merge conflicts, build times, unintended regressions, onboarding difficulty and how to distinguish architectural friction from team performance issues.
The Senior Engineer's Code Review
You will learn the architectural questions that a senior code review asks; what does this change do to the dependency graph, what does it commit the architecture to, what does it make more expensive in the future, and why one architectural comment is worth ten implementation improvements.
Code That Explains Itself
You will learn to design code that communicates its intent without requiring the reader to open implementations and how to test whether your code is self-documenting by measuring what a first-time reader understands from names and structure alone.
Architecture as Documentation
You will learn why a consistent architecture does more documentation work than any README, and how to measure the gap between your intended architecture and the one your codebase actually teaches new engineers.
Naming Systems, Not Just Things
You will learn to build a system vocabulary; a consistent set of canonical names for core domain concepts, and why vocabulary inconsistency across a codebase is a compounding coordination tax that grows with every engineer who joins.
Onboarding as an Architectural Quality Metric
You will learn to use time-to-first-productive-contribution as a direct measure of how clearly your architecture communicates, and which structural changes, rather than documentation improvements, would most reduce that time.
The README That Architecture Makes Unnecessary
You will learn the distinction between documentation that the structure already communicates and documentation that only exists because the structure is unclear, and how to shift your README from describing where things live to explaining why they were designed that way.
Knowing When You're Done
You will learn to identify the stopping criterion for architectural work — not the absence of improvement opportunities, but the point where the next improvement costs more than it contributes, and how to make that call with rigor rather than either fatigue or perfectionism.
Designing for the Team You Have
You will learn to evaluate whether an architecture is appropriate for the actual team building it; their current experience level, their shared understanding, their capacity to implement it correctly, rather than the ideal team you might wish for.
Building Architectural Culture
You will learn what architectural culture actually is; the shared judgment and practices that govern decisions when no designated architect is in the room, and which specific practices build that culture rather than merely documenting it.
The Senior Engineer's Instinct
You will learn what architectural instinct is made of, how to build it deliberately rather than waiting for it to accumulate through years of incidents, and how to codify it into review questions that transfer the instinct to the rest of the team.
What to Optimise For Over a Career
You will learn to distinguish the knowledge that depreciates (framework expertise, platform-specific APIs) from the judgment that appreciates (architectural principles, human factors, the ability to reason about systems), and design your learning investment accordingly.