It’s been an amazing WWDC this year. SwiftUI and Combine were some big announcements of the conference. They will have a huge impact on our daily life as iOS developers.
As we saw in “RxReduce: A Reactive State Container Architecture Part 1”, State is a central concern in applications. I strongly invite you to take a look at this first article. So far, we haven’t introduced the concept of Reactive Programming and how it can address some issues I’ve encountered in traditional implementations of State Containers. We will see how RxReduce, an open source framework of the RxSwiftCommunity, can help you handle the State, its mutations, and the asynchronous work related to the side effects, in a Reactive way.
State management has become a very popular concern lately in mobile applications. The idea of a state that should be the single source of truth within an application is quite attractive ! The views would only be a displayable artefact of this state 👌.
There are plenty of posts about doing a network layer in a type safe way with Swift. No matter the used network API, those approaches all rely on returning a data type that is precisely what we expect. The idea is to leverage the type inference / generics abilities of Swift to avoid casting the returned type. In this post we will try to go a little bit further by strongly coupling the endpoint we want to fetch and the data type it has to return.
Swift 4.1 is available since a few days now and it comes with an interesting feature: Conditional conformance. This is a new tool for achieving Protocol Oriented Programming as well as API designing. This post is a quick take on this brand new technic and will be followed for sure by deep dive posts in a few weeks.
Usually my posts are mostly about design patterns, software architectures (or RxFlow 😀), but this time it will be different and frankly I didn’t think I would write about this kind of topic. But I think I have something cool to share: so today we are going to talk about Animations with Swift.
Hi folks. Lately MVVM has become some sort of standard as an architecture for iOS apps. It offers a good separation of concerns, a good way to format data and great view binding mechanisms with frameworks such as RxSwift. In this post I will give few tips I use to ease the implementation of this pattern.
This is the final chapter of our journey within RxFlow. I’ve already exposed all the key features/principles of the framework in these 2 posts:
A few weeks ago I introduced in this blog an iOS framework called RxFlow. I’ve been working on this framework for several months, and it is now ready to be used. If you haven’t read it yet, I suggest you take a look at this post.
In Swift, some APIs such as RxSwift use a technic that confines the code they’re exposing in a dedicated namespace. In this post we will figure out how this is done in the most generic and versatile way.