Lasso is an iOS application architecture for building discrete, composable and testable components both big and small - from single one-off screens, through complex flows, to high-level application structures.
Without a set of structural principles, it's very easy for an application's code base to become hard to both reason about, and maintain. In particular, these problems will eventually arise:
- tight coupling of components makes it hard to change/test things
- business logic living in strange places makes it hard to modify/reuse/debug/test existing code
- view presentation choices made in inappropriate places makes it hard to refactor/reorganize/test flows
- inconsistent organization across team makes it hard to cross-contribute
The Lasso way
Lasso encourages a strong separation of concerns by clearly defining discrete, single-responsibility components where specific types of code should live, and a clear, flexible way for these components to communicate. Larger units of behavior are easily composed, and re-composed.
We generally think of a screen as a single page/view in an app - e.g., a login view, a contacts list view, an audio settings view, etc.
In Lasso, a
Screen is the collection of types used to implement a single view:
View (i.e., a
UIViewController) is responsible for:
- accurately rendering the current
State(i.e., the content) of the screen
- forwarding user interactions to the
Store(i.e., the decision maker)
- responding to state changes to keep the presentation up to date
Lasso views tend to be small, with practically zero logic in them.
A unidirectional data flow is used to ensure consistency: a
View never re-renders anything in direct response to a user action.
Actions to the
Store, which updates the
State, which come back to the
State change notifications.
Store is where a screen's decisions are made, and is the source of truth for the screen's
Store is responsible for:
- all business logic for the screen
- responding to
Actions(i.e. events sent from the
- updates to the screen's
Store can also generate an
Output when an event occurs that is more appropriately handled elsewhere. E.g., a login screen might generate a "user did login" output as a signal to a higher-level system to move to a logged-in portion of an app; or a contact list screen might generate a "did select contact" output as a signal to a higher-level flow to either present or push a contact detail screen.
Flow represents a feature - or area - of an app, and is commonly composed of a collection of
Screens. For example, a "new user" flow might be composed of a series of one-time informational screens followed by a single "let's get started" screen.
Flow is instantiated and started within an appropriate context of a view hierarchy (e.g., a "sign up" flow might be presented on a menu screen, or a "welcome" flow might be pushed onto a navigation stack). The
Flow starts by creating its initial
Screen, and listens for
Output signals. As
Outputs arrive, the
Flow decides what to do with them - it can create and place another
Screen into the view hierarchy, emit its own
Output (when an event occurs that is more appropriately handled elsewhere), or whatever is appropriate for the
Flows are encapsulated modules with discrete entry and exit points, it's quite easy and common for a
Flow to manage both
Flows. In this way, it becomes possible to define your application as a hierarchy of components, reducing complexity from the top level down.
To run the example project
- Clone the Lasso repo
pod installfrom the
- Open up
- Lasso: Introducing a new architectural framework for iOS - article that introduces Lasso, with a concrete example of creating a
- Lasso: An introduction to Flows - article that shows how to orchestrate a number of
- Lasso coding style guilde - tips for writing Swifty Lasso
- Notes about declaring types - more details and best practices about declaring Lasso types
- Memory management - information about memory management in Lasso, and tips to avoid strong reference cycles:
Lasso supports iOS 10 and up, and can be compiled with Swift 4.2 and up.
The core Lasso framework is added to the primary target in your Podfile:
LassoTestUtilities to your test target(s):
Swift Package Manager
The Lasso package URL is:
For sample usage, see: Swift Package Manager Sample.
We love contributions!
If you have a feature in mind, and/or have found a bug, the best thing to do is:
- Search the issues to see if someone has already brought it up!
- Create a new issue that explains in detail the improvements you'd like to see.
- If you have a code change in mind, that's awesome!
- Fork the Lasso repo
- Create a branch for your feature change
- Open a PR!
Lasso is licensed under the Apache-2.0 Open Source license.
You are free to do with it as you please. We do welcome attribution, and would love to hear from you if you are using it in a project!
You may find interesting
Version 1.2.0 - 2020-10-07T11:53:49
Adds a way to configure the time out for view life cycle assertions (
This configuration is per XCTestCase subclass. For more granular control, the pre-existing
timeout parameters can be used.
To override the timeout for an
XCTestCase subclass, add
AssertionTimeoutOverride conformance to your subclass, and provide a value for
defaultLassoAssertionTimeout to use a custom timeout.
Version 1.1.1 - 2020-08-27T10:54:56
Updates for iOS 14, Swift 5.3, and Xcode 12 compatibility.
Version 1.0.1 - 2020-02-27T16:14:18
Documentation and CI updates.