Using a basic animation example, namely creating a shaking effect on a rectangle view, Chris shows the hidden complexity of SwiftUI and how developers used to UIKit need to change their mental model about how to build views. Under the hood, SwiftUI seems very similar to React: a tree of views with wrappers all hover the place, with an efficient diffing algorithm deciding what to re-render.
A good counterpart to Chris’ talk to mention how Apple frameworks evolved from using the delegation pattern, then closures and are now adopting Reactive Programming. Combine will probably become the de facto framework to use, as opposed to RxSwift and ReactiveCococa, due to its 1st party nature. The only problem is that it is only available for iOS 13.
Many frameworks are available to bring the Redux pattern to iOS development, ie dispatch actions, reducers, immutable states, mapStateToProps, etc. It could be a good idea to use one to keep having architectural conversations relevant to the mobile and web teams.
Great talk promoting snapshot testing, something I tend to already do on ongoing projects 💪. Nataliya mentioned how we could benefit from a new feature of iOS/Xcode ie Previews. She wondered if tree inspecting libraries similar to
react-testing-library would eventually show up to inspect contents of SwiftUI tree representations. A cool idea for an OSS side-project 💡.
This talk was about how Heetch created a browsing interface within the debug release version of their app to demo work in progress to their product and quality teams as early as they could, building on the real continuous integration post by Soroush Khanlou.
When something looks a little complicated, should you spend time looking for a library doing what you need, or should you spend time implementing it yourself? Building on UISlider, Joel shows a real-case scenario of what to assess to make the best informed decision. Notably, UISlider had a much better accessibility support that 3rd parties equivalents.
Marcin shows up what’s under the hood of his work in progress code reordering tool. While we could benefit from such a tool, it sounds too immature to be integrated in a CI, but worth trying and keeping an eye on. Or even contributing? It involves playing with SourceKitten and Swift AST.
A prescription of a model to write table view view models.
The title of the talk is misleading. It was more about what is an iOS application in terms of entry point, event management, run loop, etc.
Good simple exercises on how to implement an alternative version of
map for arrays, generics, optionals, results, and combine. Basic & deep at the same time.
Don’t make things generic to early. Very similar to this AHA Programming
Anastasiia mentioned the real case of how her consulting company helped the Bear app to add security features in their app. What tradeoffs you should pick depending on the risks, threats, trust. Lots of recommended readings:
Really fun and innovative format. Many analogies to explain how pubgrub works for SPM, and how algorithms we took for granted are under-appreciated.
Almost a star for this one. The idea was: how AI is actually hidden everywhere and how 1st party frameworks can already help with a lot of stuff. Example: using the background color of a messaging app to give a hint of the tone of the message that is being written to help think twice about the choice of words being used.
Elaine insisted how voice-first could be important for accessibility, and to do it properly with existing frameworks.
Another approach to test using random values that can auto-discover edge cases of input values that will reveal bugs in a codebase. It is not self sufficient but can be a good complement to other testing strategies. Also, it can lead to randomness in tests: for instance, a test could fail at the 10th execution. But frameworks handling these kind of tests will provide you the failing data and you can turn this failing scenario into a deterministic test case by adding it in traditional test cases.
The story of how PDF Viewer was ported to macOS using a mix of AppKit, UIKit, private API, etc. The conclusion for me is that if you can invest on SwiftUI, it is not worth exploring Catalyst.
An exploration of property wrappers, a feature introduced by Swift 5.1. It is totally compatible with older version of iOS as it is interpreted at compile time. The idea is to DRY behaviors of some properties. Example use cases: clamping values into a range, handling UserDefaults with convenience, customizing how a type conform to Codable, database mapping, etc.