While working on a Swift protocol-oriented and generic linked list, I got to thinking about Apple’s “improvements” to version 4.2 of their flagship language. Since a linked list is a list, I thought, “Why not add a subscript to my linked list to facilitate finding specific nodes in my list?” I did that in Swift 4.1 and got what most developers would’ve expected, e.g., used linkedList["node4"]
to get the node in the list associated with the keyword “node4.” With Swift 4.2, I can use the controversial new @dynamicMemberLookup
language attribute and implement dot/member notation, like linkedList.node4
to get that same node in the list associated with “node4.” Big improvement, huh? Well, maybe. We’ll talk about how this new and improved subscript is more than just about syntactic sugar, but that the “driving motivation for this feature is to improve interoperability with inherently dynamic languages like Python, Javascript, Ruby and others.” Note that all code shown in this tutorial was written in two Xcode 10 beta playgrounds.
Author: Andrew Jaffee
Xcode 9 playground error: No such module ‘UIKit’ (or ‘AppKit’)
While creating a new Xcode playground on my MacBook Pro today, I got the most bizarre error message: “No such module ‘UIKit'”. I was using Xcode Version 9.2 (9C40b). Yes, I know there are more recent versions, but I haven’t had the need to upgrade my MacBook Pro. Parenthetically, I do have Xcode 9.4.1 (9F2000) and Xcode 10 beta 6 (10L232m) loaded on my main development machine. I’ll share the solution to this problem with you in the hopes that you, like me, will learn something new about Xcode today.
Continue reading “Xcode 9 playground error: No such module ‘UIKit’ (or ‘AppKit’)”
Swift 4.2 improvements: #warning and #error compiler directives
We’re in the middle of Apple’s annual product upgrade cycle and this article is the second in a series of tutorials, started last week, meant to highlight the most important new features of Swift 4.2. Today, we’ll look at two two new Swift 4.2 features, the #warning
and #error
compiler directives.
Continue reading “Swift 4.2 improvements: #warning and #error compiler directives”
Two Behavioral Design Patterns in Swift: Observer and Memento
My original article — “Design Patterns in Swift #2: Observer and Memento” — was published on appcoda.com.
This tutorial is the second installment in a series on design patterns started last week. There are 23 classic software development design patterns probably first identified, collected, and explained all in one place by the “Gang of Four” (“GoF”), Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in their seminal book, “Design Patterns: Elements of Reusable Object-Oriented Software.” Today, we’ll focus on two of these patterns, “observer” and “memento,” which fall into what the GoF calls the “behavioral” category. Follow along with the Xcode projects, both on GitHub, available for observer here and memento here.
Continue reading “Two Behavioral Design Patterns in Swift: Observer and Memento”
Swift 4.2 improvements to Collection and Sequence protocols with method allSatisfy
We’re in the middle of Apple’s annual product upgrade cycle and this article is the first in a series of tutorials meant to highlight the most important new features of Swift 4.2. Instead of trying to cover all of the 4.2 features/improvements in one very long article, I’m going go talk about each aspect of the new 4.2 version, one or two features at a time. (If you’re interested in more details as to why I’m focused on 4.2, see section “Swift version methodology” below.) Today, I’ll cover the allSatisfy(_:)
instance method (see also here) of the Sequence
protocol (see also here), of course intimately related to the Collection
protocol (see also here).
Controlling chaos: Error checking in Swift 4 with if let, guard, and failable initializers
In this tutorial, the third in a series of tutorials, we’re going to finish the arduous topic of looking for unexpected values, events, and conditions that arise during program execution, using a technique I like to call “error checking.” Today, I’ll concentrate on
nil
values, optionals, optional binding, the guard
statement, failable initializers, and finally, give you some advice about keeping your error checking code consistent, for example, when to use Swift “Error Handling” or when just to return true/false
or use guard
statements.
Two Creational Design Patterns in Swift 4: Factory Method and Singleton
My original article — “Design Patterns in Swift #1: Factory Method and Singleton” — was published on appcoda.com.
There are 23 classic software development design patterns probably first identified, collected, and explained all in one place by the “Gang of Four” (“GoF”), Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in their seminal book, “Design Patterns: Elements of Reusable Object-Oriented Software.” This tutorial focuses on two of those patterns in terms of what the GoF calls the “creational” category: “factory method” and “singleton.” Follow along with the Xcode projects both on GitHub, available for factory method here and singleton here.
Continue reading “Two Creational Design Patterns in Swift 4: Factory Method and Singleton”
Finding memory leaks with the Xcode Memory Graph Debugger and fixing leaks with unowned and weak
In this tutorial, I’ll show you how to track down memory leaks within Xcode via the Memory Graph Debugger, new since Xcode 8. This is a powerful visual tool and doesn’t require you to step out of Xcode and start the Leaks Instrument. Once we identify some memory leaks, I’ll show you how to plug those leaks by using the Swift language’s weak
and unowned
qualifiers, and talk about the differences between the two qualifiers.
I recently discussed iOS memory management and memory leaks that occur when using reference semantics and reference types (classes) in my tutorials on “Swift 4 memory management via ARC for reference types (classes)” and “Fixing memory leaks — strong reference cycles — in Swift 4.” After reading these articles, you should understand how easy it is to inadvertently encode and introduce a strong reference cycle into your Swift 4 code and thus end up with a memory leak. You should also understand how generally straightforward it is to fix such a memory leak. My sample code in both tutorials was didactic. What about real-world projects with hundreds of thousands or millions of lines of code? Suppose that you’ve heard reports of diminished app performance, low memory warnings, or just plain app crashes. Finding memory leaks in your code is quite cumbersome when trying to debug via rote inspection, setting breakpoints, adding logging statements, etc.
Fixing memory leaks — strong reference cycles — in Swift 4
PREREQUISITES FOR THIS TUTORIAL
If you don’t understand how Swift manages memory for classes (reference types), you need to read the first article in this series, “Swift 4 memory management via ARC for reference types (classes)”. Once you understand how reference type-based memory is managed with ARC, you’ll be ready to understand how to prevent memory leaks from occurring in your app. Remember that ARC only applies to reference (class
) types, not value types like struct
and enum
instances.
THE ARC DEALLOCATION PROCESS
Remember how we visualized the reference count that ARC maintains on the allocated instance of reference type Widget
in my introductory ARC tutorial?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
... // reference count is zero; nothing allocated widgetReference = Widget(name: "eraser", manufacturer: "Acme") // reference count is now 1 widgetReference1 = widgetReference // reference count is now 2 widgetReference2 = widgetReference // reference count is now 3 widgetReference = nil // reference count is now 3-1 = 2 widgetReference1 = nil // reference count is now 2-1 = 1 widgetReference2 = nil // reference count is now 1-1 = 0 |
Continue reading “Fixing memory leaks — strong reference cycles — in Swift 4”