Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.
We are now in the final stretches of polishing up the composable architecture so that it is production worthy. We’ve used the first few months of this year rounding off some of the rough edges of the architecture. Things like getting rid of code generation by using case paths and making the side effect and testing story more rock solid by baking the environment technique directly into the architecture.
Today we will begin looking at improving the performance of the composable architecture, because there’s one very naive thing we are doing that can be easily addressed. But, while solving the performance problem we are actually going to stumble upon a wonderful way to make the architecture adaptive to many situations. For example, perhaps you are making an app that ships on iOS and macOS, or maybe you are even making an app for all 4 platforms, iOS, macOS, tvOS and watchOS. Wouldn’t it be awesome if you could write the business logic of your application a single time, and have it adapt to each of these platforms very easily? Well, this is exactly what we are going to do.
Apple documentation around identifying memory-use inefficiencies though various means of measuring and profiling, including the memory graph debugger, which is used in this episode.