ImmutableData: Easy State Management for SwiftUI Apps

[vanvoorden (Rick van Voorden)]

@Datagram

I would like to know how this package differs from TCA regarding usability and performance ?

Good question! We still don't really have a very strong opinion about TCA… it wasn't really on our radar when learning SwiftUI or building ImmutableData. If you're looking for a detailed "pros and cons" comparing TCA to ImmutableData, I don't really have a great answer for you on that.

One of our goals building ImmutableData was to keep our state management solution light-weight. We don't introduce strong opinions on orthogonal concepts like navigation or dependency injection and we don't import external package dependencies like swift-syntax. Our focus is state management and all the infra is built on top of tools from the Apple SDK: Foundation, Observation or Combine, and SwiftUI. The infra can be imported from the standalone ImmutableData repo or built from scratch following the instructions in Chapter 01 and Chapter 02 of "The ImmutableData Programming Guide".

One of our goals was to keep our infra affordable and reduce the barriers to entry: there is no price. ImmutableData is free. The documentation is free and that includes all the "conceptual" documentation teaching the first principles to build the infra. The sample code and sample application products are free. It's all free and it will remain free.

A more detailed investigation of usability and performance could start with the FoodTruck sample project:

ImmutableData-FoodTruck: Incrementally Migrating State Management and Data Flow

https://github.com/Swift-ImmutableData/ImmutableData-FoodTruck Good news! We just shipped our latest tutorial for our ImmutableData project. What is ImmutableData? ImmutableData is a lightweight framework for easy state management for SwiftUI apps. Apple ships a lot of sample code and tutorials for learning SwiftUI. For the most part, these resources are great for learning how to put views on screen with a “modern” approach: programming is declarative and functional. The problem is these very …

If you are looking for some real-world and head-to-head comparisons based on the state of these frameworks today my suggestion would be for an engineer experienced with TCA to rebuild the incremental migration on Food Truck and preserve the functionality of the ImmutableData migration. If we present that incremental migration here to the community we can then compare them together to see how these different frameworks solve the same problem.

Here would be some requirements for an incremental migration:

• Start by forking sample-food-truck from the original Apple repo.

• The Food Truck app should continue to deploy back to macOS 13.3 and iOS 16.4.

• Some bugs we need to fix:

  • Editing a Donut value from DonutEditor leads to stale data displayed:
    • TruckOrdersCard displays stale data.
    • OrderCompleteView displays stale data.
    • OrderDetailView displays stale data.
    • OrderRow displays stale data.
  • Completing an Order from OrdersView does not end a Live Activity that was started from OrderDetailView.

• A feature we need to add:

  • OrdersView should add a Button that adds a new Order value to our global application state.

• Some features we need to continue supporting:

  • The components we migrate should support Xcode Preview components.
  • TruckOrdersCard and OrdersView should support animation when new Order values are added to our global application state.

• Some minor bugs that were also fixed during the ImmutableData migration:

  • The TruckOrdersCard component displays Order values on app launch starting with oldest Order first. The TruckOrdersCard should display Order values starting with newest Order first.
  • The OrderDetailView component should correctly request authorization before attempting to schedule a local notification.
  • The OrdersView component can select an Order marked as complete and mark it as complete again. Only Order values that are not complete should have the ability to mark as complete.
  • The OrdersView component can select multiple Order values and then attempt to display OrderDetailView. Displaying OrderDetailView should only be possible if the user has selected just one Order value.

An important goal during an incremental migration is that migrating individual view components should not break any view components that are still built on the legacy MV* architecture.

Once the incremental migration is complete we can compare the two frameworks to see what they look like stacked against each other:

• Which migration is fewer lines of Swift code added to our project?
• Which migration compiles faster?
• Which migration compiles down to a smaller binary and smaller app install size?
• Which migration uses less CPU at runtime?
• Which migration uses less memory at runtime?

There are also important details that are less easy to measure and quantify:

• Which migration leads to better code quality?
• Which migration leads to less complex view component implementations?
• Which migration leads to better separation of concerns between state and views?
• Which migration is more robust against future changes to our state and views?
• Which migration is easier to maintain over time?
• Which migration is easier to debug?
• Which migration is easier to write unit tests for?

It's also important to consider which migration comes with an easier learning curve. It's not just about how easy it is for the author of the framework to build the incremental migration. How easy would it be for an engineer new to the framework to build the incremental migration or extend it in new directions?