Design patterns are very important tools for iOS developers to keep in their software engineering arsenals. These patterns, along with several other best practices I’ll mention below, help developers to create reliable and maintainable apps. In other words, design patterns help in managing software complexity. In this tutorial, I’ll introduce you to the “Model-View-ViewModel” or “MVVM” design pattern. For a historical and pragmatic perspective, I’ll compare the very well-known “Model-View-Controller” or “MVC” design pattern, long favored by many iOS developers, to MVVM, which has steadily been gaining traction among the same group of developers.
In order to help you understand these design patterns, I’ll walk you through the design and coding of my app shown here:
I’m going to talk about “delegates” and “delegation.” I’ll lead you through a simple example of implementing the delegation design pattern in Swift 4, with full source code. My intent here is to show you how delegation works without getting bogged down in some crazy complex example. To help you become the best of the best, I’m going to introduce you to one of the greatest design tools to aid in object-oriented software development, UML. I’ll show you a UML diagram that I drew up to design and document the implementation of the delegation design pattern used in the sample app we’ll build together. Download the Xcode 9 project with full Swift 4 source from GitHub to follow along.
I’ll show you how to build a user interface (UI) helper, a class that downloads a file at a specified URL. Most importantly, I’ll show you how, through delegation, a UIViewController subclass can be notified by the helper that an image file has finished downloading, and then the view controller can display the image on screen. For the sake of simplicity and clarity, we’ll pretend that Swift has minimal support for downloading a file from a URL. We’ll manually wire up the notification that the file has finished downloading using the delegation design pattern. Here’s the app we’ll build:
Let’s talk about creating understandable and maintainable code in Swift 4, code that can be easily read by other programmers, can be readily debugged, can be reused, and can be enhanced and extended in the future. We’re going to limit today’s discussion to: 1) how best to come up with good names for functions and how best to name their arguments, parameters, and argument labels, and 2) how to use meaningful and descriptive variable (var) names — and constant (let) and enumeration (enum) names, etc. The goal is to create code that reads as to close to English as possible.
You may believe that this topic is overly simplistic or pedantic, but sometimes it’s the “little things” in life that really matter — especially when you have applications that are made up of millions of lines of code, made up of “little things” like function definitions and function calls.
With this article, I’m starting a series about all the goodies — useful tools — that can be found in Xcode. Some of these tidbits are tools everyone knows about while others are barely documented to undocumented. For example, how many of you know that you can view, inspect, and debug all your Auto Layout constraints live during app execution using the “Debug View Hierarchy” Xcode feature? I discussed that feature in detail in this article, “Troubleshooting Auto Layout using Xcode’s Debug View Hierarchy.” Today, we’ll discover two editors that ship with Xcode, the “Open As > Hex” and “Open As > Source Code” editors, both only available by right-clicking on files in the “Project Navigator” to reveal a contextual menu.
We’re going to talk about “protocols” in the Swift 4 language today. I’ll explain them conceptually, and then we’ll start coding protocols with a simple example. We’ll then create our own versions of the Apple built-in Equatable and Comparable protocols, and apply them to two real-world classes, one for tracking financial securities and one for representing geometric lines/vectors. Finally, we’ll test our geometric “Line” class in a type of Swift playground that supports rendering user interface components (like UIView) live in the simulator. But first, please ponder the layman’s definition of the word “protocol” before moving on:
… The official procedure or system of rules governing affairs of state or diplomatic occasions. …
The accepted or established code of procedure or behaviour in any group, organization, or situation. …
A procedure for carrying out a scientific experiment…
Let’s talk about Swift 4 frameworks, one method for packaging, reusing, and sharing code. We’ll build our own framework and then include it in our own app. We could’ve talked about static libraries, but frameworks offer more advanced features — and will let us expand on code maintainability options in future discussions. (If you want to have that static versus dynamic library discussion, read this excellent article, but we won’t be debating the topic herein.) From Apple (my emphasis added):
How many times have you been looking at Swift or Objective-C code in Xcode and can’t remember what a framework method, argument, constant, etc. means? Did you know that help — full documentation — is just a keystroke away? Did you also know that you can add the same type of pop-up, context-sensitive help to your own code? Here’s how. Let’s say you’re looking at the following NSString class method and can’t remember exactly what the call does, what parameters it takes, and what is its return value:
It can be good to be an iOS app developer, but not easy to be a great one (we’ll talk about that later in this article). There are many opportunities for app programmers looking to work as employees for companies. There are plenty of opportunities for developers who prefer freelancing. It’s frustrating, trying to come up with novel apps that generate any significant revenue, when it seems that every idea under the sun has already been turned into an app by “someone else.” Apple continues to push out buggy versions of iOS, the iOS SDK, and Xcode — especially in early versions of new products. Yet most of us would agree that Apple’s hardware and software, even their development tools, continue to be elegant and cutting edge. It’s hard to argue with the bottom line as “Apple App Store developers raked in $20 billion in 2016, up 40% year over year,” according to an article from CNBC: