Article Overview
Software Architecture
I tend to think about two parts of the architecture that depend on each other: “structure” and “process”. The former is about statical snapshots and most patterns; the latter is about the design of information flow, control flow, and message passing.
- When You Code, You Design Both Structure and Information Flow sums this up.
- Try to draw more diagrams!
Structure: Architectural Patterns
- Plain Swift Objects
- Plain Controllers to Help View Controllers. You can always add a new service type to perform a task, and then delegate from view controllers to that. I have the feeling this needs to be repeated more often. An app doesn’t just live in its view controllers.
- Modularization
- Iteratively Improving Your App: Decoupling Components at Module Seams and Adding Facades
- Framework-Oriented Programming: this is really about larger modules, and how to box them in to make cohesive parts to use in apps.
- Layered Architecture
- So I’ve finished my model, now what?
- Making Cocoa the Outermost Layer and wrap all the AppKit/UIKit stuff in things you own.
- VIPER (View–Interactor–Presenter–Entity–Repository)
- CQRS (Command–Query-Responsibility-Segregation)
- Separate Read Model from Write Model to Support Complex Forms; it’s a simplistic take on the topic, but nevertheless could get you started thinking along the lines of CQRS.
Process: Information Flow
- 5 Heuristics for “I have a complicated nested view controller setup. How do I handle passing data?”
- Unidirectional Data Flow
- ReSwift Actions and UI Events
- Handle Pending File Changes with ReSwift using “pending” states.
- How I Avoided Over-Architecting a Simple Event Handler with ReSwift, Cheating with Existing Reactive Code. Instead of doing All The Things in ReSwift (which is like redux.js), I went with keeping the flow in my Application layer of code, where RxSwift/reactive code lives.
- Reactive programming is all about making the flow obvious to the reader.
- 3 RxSwift Building Blocks of UI Components: input and output ports of types in the UI layer map to Observer and Observable, and mutable properties can be expressed as well. This piece shows how.
Day-to-Day Coding
Learning to do things in Swift, the nice way:
Programming Principles
- Magic Numbers Represent Concepts, you just have to name them!
- Single Responsibility Principle
- Tell, Don’t Ask
Design Patterns
I argue that design patterns are not software architecture. They are practical for your daily work, and to express the information exchange between a couple of objects in a succinct way. But they cannot inform you about the structure of your application, why and how to decouple modules, or what a module is in the first place. That’s higher-level thinking you need to do in a different kind of mind-set.
- Façade
- Iteratively Improving Your App: Decoupling Components at Module Seams and Adding Facades – the nice thing about a façade is that it can be added without cost, and you can transition to using it in client code immediately.
- MVVM (Model–View–View-Model)
- MVVM Primer – it’s a “model of the view”, not “a model for the view” in my understanding.
- Decouple UI from Model with View Models and Controls is a practical intro to the term “view model” and how you can change it from a controller (or “control”).
- MVVM Is Quite Okay at What It Is Supposed to Do – not as smashing a statement as other folks tend to propagate, but I still think it nails down the problem really well: people expect a design pattern like MVVM to do far to much.
- MVVM’s Place in Your App should be very confined. It’s just glue code between view objects and application logic. (It is not, for example, your database.)
- As generalization of the above, Do Not Apply Code Heuristics When You Need a Broader Perspective talks about the problem of applying code-level tricks to much higher-level problems.
- Testable Singleton in Swift
- Strategy Pattern using blocks/closures
- The “Cake Pattern” is useless in practice
Solopreneurship and Indie Development
- My book: Make Money Outside the Mac App Store
- App Pricing and How to Make More Money
- Being Afraid to Change a Working App
- To Subscribe or not to Subscribe? A guest post uncovering the phrases of the advocates of the subscription model of payment.
Behind the Scenes
- Being Afraid to Change a Working App: it’s a bit more personal than the usual data-sharing.
The Archive
TableFlip
- Coding TableFlip: the Bigger Picture
- Splitting Up the Monolithic View Model and an aftermath
- Putting TableFlip on the App Store because I wanted to see how bad it really is, and if it makes a difference for my business.
General Things About Programming and Stuff
- Programming Does Not Grow Up: the amount of programmers grows just too quickly to have enough experienced people teach the newcomers about best practices. Programming, in this regard, is very much unlike traditional crafts.