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)
  • iOS View Architectures and VIPER Explained
• 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:

• Form model validation
• Clean Value Transformations in Swift

Programming Principles

• Magic Numbers Represent Concepts, you just have to name them!
• Single Responsibility Principle
  • Location Matters
• Tell, Don’t Ask
  • versus Storyboard Segues

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

• Coffee Consumption during development of 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.
  • Proceeds are trickling in constantly without marketing
  • Sources/Referrers after 1 month

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.