Swift Developments is a hand-curated newsletter containing a weekly selection of the best links, videos, tools and tutorials for people interested in designing and developing their own apps using Swift.
If you’ve ever subscribed to the Swift mailing lists, you’ll know that the reading through the sheer volume of traffic on those lists is something akin to drinking from a fire hose. However, this week has seen some positive news on this front though with @tkremenek announcing plans to transition these mailing lists to Discourse, a move that for many will be most welcome.
In other news this week, the swift-dev mailing lists have also seen the announcement of a new project to develop a Swift Syntax and Structured Editing library. In the short-term, the new library will be focused on infrastructure improvements for the Swift migrator but will hopefully bring additional tooling and performance benefits in the long-term.
@pbones of Rogue Amoeba takes an introspective look at their audio recording app Piezo, and looks at what effect removing Piezo from the Mac App Store has had on apps sales and revenue.
Use of a hamburger menus prompts a lot of discussion in app design circles with their use often frowned upon due to reduced user engagement and disruptive workflows. However, avoiding the use of hamburger menus leads to the question of what design approaches to use instead. @kovlex provides some useful suggestions.
With the relentless development of Swift still ongoing, many businesses are faced with the prospect of migrate their existing Swift 2 code bases to Swift 3. This writeup from @chengyinliu, @kompfner and @michaelbachand provides an interesting insight into how the team at Airbnb have tackled the problem.
The use of the Singleton design pattern is commonly frowned on in software development due to it’s difficulty to test and the complexity it tends to introduce to the rest of the code base. However, singletons are commonly used within Apple’s frameworks and they are sometimes a necessary evil in our app designs. So given that we occasionally need to use them, how do we incorporate them into our code in a clean and testable way? @jesse_squires investigates.
“Swift as a programming language focuses on making APIs descriptive and determinate. Completion blocks are less than perfect — but what is wrong with them, and how can we improve their usage?”
Back in Issue 56 I mentioned that Apple had released their own implementation and tooling to support the use protobuf within your Swift code. If you haven’t had a chance to investigate yet, @vincentngo2 has written a useful tutorial to help you get started.
Hydra from@danielemargutti is a lightweight library, written in Swift 3 that helps you write better asynchronous code through the use of promises and awaits. He’s also has an accompanying article that explains exactly how it works.
DeviceKit from @dennis_weissman provides a value-type replacement for
UIDevice supporting device, device family and device group detection, simulator detection along with battery state and battery level information.
I couldn’t leave the libraries this week without including at least one animation library. Normally
UICollectionView doesn’t have any transition effects when scrolling from one item to the next but AnimatedCollectionViewLayout by @jinw1990 provides a new
UICollectionViewLayout subclass that adds a bunch of custom transitions / animations that you can use.
In this talk, @pepibumur looks at the problem of integration testing the components in your iOS app and specifically the problem of how to test that your networking code is actually performing as expected.
Although this talk (video) from @simonbrown isn’t related to Swift or iOS directly, as someone who thinks in pictures, I really enjoyed it. When working as part of a large development team, I’ve often found that having a common vocabulary to help describe and document the structure of the code is extremely useful for helping people both understand and orient themselves within a code base and also helps to keep the overall design clean and managable. I agree with Simon that using all of UML is not usually the answer for this but I’ve often found that using a subset (think 80:20 rule) can be a useful approach.