5 takeaways from Swift & Fika
5 takeaways from Swift & Fika
We were proud sponsors of the first ever Swift & Fika conference in Stockholm. It was an incredible event with people from all over the world (Trinidad, Brazil, South Africa, Japan) coming together to learn how to be better at writing Swift and developing great apps. Here’s the top 5 things we learned while drinking coffee and consuming too many of those oh-so-Swedish kanelbullar:
1) Swift static analytics: We are big fans of SwiftLint here at Daresay, and JP Simard took it to another level by crafting some “bespoke, artisanal static analysis” tools for creating better builds in Swift. Most other languages build their own tooling, so why not Swift? The Swiftlint static analyzer dives deep into the Xcode compiler logs (Clang/LLVM) and can dig out information about dead code and unused imports, which can really speed up build time.
Running the analyzer before release on the Clas Ohlson Home app, we found 78 analyzer violations (mostly unused imports) which we removed! Awesome!
It’s just in the very beginning stages of development, and it’s proof that the open source movement around Swift is just getting started. Speaking of which…
2) How to do Open Source: Roy Marmelstien of Spotify and creator of PhoneNumberKit spoke about how to create thriving source communities. We all use open source libraries, but Roy presented great tips about how to get started open sourcing our own code, and presented motivations for doing so. Building the community around your open source project is critical for preventing burnout or abandonment, and one of the best ways to do this is to allow pull requesters write access to your project. Thinking of code as frameworks or separate repositories also helps to decouple projects and increase code flexibility. At Daresay, we’ve done our Open Source Love Jam afterwork to create PRs for our favorite projects, but the next step is taking our knowledge and making it open source. Stay tuned for more!
It’s the first time Swift & Fika has been held in Stockholm
Carplay in use at a Swift & fika event in Stockholm
3) Decomposition/Decoupling: Several presenters, including John Sundell (Swift by Sundell) and Paul Hudson (Hacking with Swift) talked about decoupling and decomposing, two closely related concepts to increase code flexibility and reduce duplication.
Decomposition is breaking down massive code into smaller, reusable, and more easily managed components. We can use a few techniques to do this, including:
- Use Child View Controllers to keep UI components small.
- Create “Shared Services” which can be reused across the app, and get injected as dependencies into other components. Good examples of this are network or caching services (or other types singletons).
Decoupling is the concept of keeping the various classes of your code separated so that each object does exactly what it needs to and nothing more. An example of bad coupling is in `UIStackView`. It inherits from `UIView`, which has a `backgroundColor` property, so it’s valid to do this:
myStackView.backgroundColor = UIColor.red
But since `UIStackView` is non-drawing, this code does nothing! Except confuse the developer. A decoupled example here would use a protocol and composition to give the UIStackView only the properties it really needs.
This is a trend that’s been popular for a while but it was great to get more confirmation that decomposition and decoupling (regardless of design pattern) can help you write better, more testable, and more maintainable code.
4) System design: John also talked about the need to visualize the parts of a new feature before starting to code. While just jumping into coding a new project is often the most fun, it runs the risk of becoming a spaghetti pile and if multiple platforms are involved it just gets worse. Having whiteboard discussions to lay out (and name!) key components in the architecture before you begin can be a real time-saver as the codebase grows.
In addition, Paul reminded us to keep in mind the Rule of Three and “don’t build it until you need it”. This should be critical to anyone developing software under deadline (who isn’t?) and is a good reminder that over-engineering a solution isn’t the best idea either. A good software project shouldn’t be a thrown-together shack, but it doesn’t need to be the Hoover Dam either.
5) Fika > Swift: The best thing about this conference was the socializing. There were lots of social activities on Sunday, plus generous coffee breaks (Fika) that allowed plenty of time to get to know fellow attendees and discuss (or argue about depending on how you see it) new ideas. It was great to see what an amazing tech community Swift & Fika has brought together. We’re overjoyed to have sponsored such an amazing event.