The iOS team in the city of (Swift) Love - dotSwift

The iOS team in the city of (Swift) Love - dotSwift

A blog by iCapps' iOS team

Last Monday, iCapps’ iOS team went to Paris. Besides putting our teeth into freshly baked baguettes and tasting fancy wines, we visited the annual dotSwift convention. The main ingredients of the convention: inspiring talks about the newest progressions within the Swift development world, a whole lot of Apple enthusiasts, and more food. The programme covered a large variety of subjects. In this blog we’ll look back on a few talks that caught our eye and inspired us.

 

Functional Programming

Let’s be honest: functional programming (FP) is not the most popular style in the Swift world. That’s probably the reason why several talks tried to motivate people to use FP and explained how to us it. Before we swiftly (pun intended) cover the content of these talks, it’s important to understand what the key advantages of FP are. In a nutshell: immutability and statelessness are key aspects of FP, which allow it to avoid problems like methods returning different results after passing the same parameters caused by a state or internal variable that changed.

In one of the talks, Paul Hudson focused on the advantages of FP. He talked about some of the higher-order functions in Swift, like filter, map, compactMap and reduce. His presentation was more of an introduction to FP, but overall it was truly entertaining. As one can expect of a British presenter, the presentation was full of French puns and pretty dry humour.

The more technical talk by FP wizard Graham Lee (Software architect at Wealth Wizards) went more deeply into how to use the FP style. Besides talking about collections of ducks, he presented a way of making setters immutable and explained how to turn mutable objects into immutable objects.

Accessibility

In a less technical session, Sally Shepard discussed the accessibility features in iOS, and the importance of using these. She talked about the extensiveness of the features in iOS aimed at giving any user the option to adjust the system to match their necessities. For example, someone who breaks his arm needs to be able to use any app with one hand, while someone with poor eyesight needs apps in which you can adjust the font size of any text. These features are often overlooked, even though it is very important that we develop apps in such a way that they can be used by anyone.

Coordinator Pattern

Ben Scheirman, screencaster at NSScreencast, talked about a lot more than the coordinator pattern, but the coordinator pattern stands out for us because it is definitely something that seems very useful for the type of projects we have worked on over the past year. Scheirman explained that the view controller should not be responsible for navigational code. This is especially true when you have to pass configurations or data to the next controller, and/or if certain navigations are triggered from several locations in the app. This is where the coordinator pattern comes in handy!

The pattern describes the creation of a new coordinator class that is in charge of creating the navigation controller. This makes the view controllers completely independent and means that they now have no knowledge of the context in which they are used. It also improves their testability. Instead of writing the navigation logic in your view controller, the view controller calls a method on the coordinator class which then handles the navigation logic.

The Icing on the Cake

Last but not least, we were treated to a talk by Ben Cohen, a member of Apple’s Swift Core Team. As this is an open-source programming language, anyone can submit a proposal to add or edit something in the Swift standard library. He talked extensively about the process of accepting and implementing these proposals. We learned which criteria they use to accept a proposal and we were shown specific examples of implementations that would be accepted, and others that wouldn’t. He ended his talk by encouraging us to regularly review proposals, or even create some ourselves.

Some of the talks failed to mention the purpose of choosing to use the particular design pattern or programming styles. This was nicely solved by a host who, after each talk, asked a few questions to summarize and clarify the key takeaways.

The dotSwift convention isn’t just a lovely place to gather inspiration from, it’s also a great way to meet and connect with Swift enthusiasts from pretty much anywhere in Europe. Overall we really enjoyed the talks and we definitely look forward to next year’s edition!