Object literals are very useful and they often make your code easier to read and understand. String literals are a bit different, though. It’s true that a string literal is the easiest solution to create a String instance. It’s straightforward and everyone understands what’s going on. But there’s a price you pay every time you use a string literal. Did you know that?
In today’s tutorial, I’d like to show you an elegant example of the power and versatility of generics and protocols. I stumbled upon this implementation while browsing the RxDataSources repository a few months ago. I learned the technique I outline in this tutorial from Segii Shulga. Let me show you what it looks like.
Fatal errors have a negative connotation and with reason. You should use them sparingly if you want to avoid having your application crash and burn at the slightest hiccup. Despite their negative undertone, fatal errors are an integral part of my workflow as I write elsewhere in this book.
Many developers new to Swift seem to be struggling with JSON. Despite the speed of Foundation’s JSONSerialization class, it hands you an object of type Any, leaving it up to you to unwrap the object you received.
Last year, I wrote about the difference between private and fileprivate in Swift 3. With the impending release of Swift 4, it’s time for an update. Access control underwent several important changes since the introduction of the Swift language, several years ago.
Last week, I wrote about weak and strong outlets. But there’s another question about outlets that comes up frequently. Should outlets be declared as optionals or implicitly unwrapped optionals? This tutorial zooms in on the pros and cons of each of these options.
If you’re reading this, then I assume you’re familiar with Swift extensions. A Swift extension allows you to add functionality to a type, that is, a class, a structure, an enumeration, or a protocol. But extensions are more powerful than that. In this tutorial, I’d like to show you four clever uses of Swift extensions.
If you’ve been paying attention, then you may have noticed that we haven’t resolved the strong reference cycle of the Device class. Remember from earlier in this series, this is what the Device class looks like.
In yesterday’s installment of Understanding Swift Memory Management, you learned how weak and unowned references can be used to break a strong reference cycle. It’s time to take a closer look at what sets weak and unowned references apart from strong references. We also revisit weak and unowned references. What is the difference between weak and unowned references? When is it appropriate to choose an unowned reference over a weak reference?
Strong reference cycles can cripple your application. In this article, I show you how to resolve the strong reference cycles we created in the previous installment of this series.