Logomark
A shot of to go with your morning coffee.

Curious? Get 3 great screencasts FREE.

Xom Venmo Tb Eyefi Twg Medium

Thousands of developers use NSScreencast to stay on top of iOS development.

Video Training for iOS Developers

The iOS landscape is large and changes often. With short, bite-sized videos released on a steady schedule, NSScreencast helps keep you continually up to date.

  • Quality content This isn't Youtube. Each screencast is carefully produced in HD quality.
  • Team Plans Get access for your whole team. NSScreencast makes for great lunch & learns.
  • Any Device Stream on the web, or use one of our apps for  tv, iPhone, and iPad.
Stay up to date!

Founded in 2012, NSScreencast has been releasing a new screencast each week for more than 6 years. With short videos you can learn a lot over time without a huge time commitment.

NSScreencast offers the largest collection of iOS development screencasts on the internet. With the range of videos that NSScreencast offers, there is something for people of every skill level.

Bite-sized screencasts on iOS and Mac development.

There are 31 episodes with tag 'swift'   Clear search
lock
#326
326 swift 4 keypaths
Swift 4 key paths allow us to refer to properties of Swift types in a dynamic way, enabling us to program against them without knowing the exact property in question. In this episode we will see how they are created, how they are used, and see examples of them in action with Key-Value Observing and Autolayout.
lock
#316
316 solid dip
In this episode we cover the dependency inversion principle, which states that high level components should not depend on low level components, but instead they both should depend on abstractions. We will look at two examples of this and leverage dependency injection to decouple classes from concrete dependencies.
lock
#314
314 solid interface segregation
In this episode we examine ISP (the Interface Segregation Principle). This one states that a type should not depend on methods from an interface that it will never use. Often times this means that the type probably carries too many responsibilities, but breaking it apart is difficult for other reasons (perhaps too many things depend on it and changing it would be expensive). You can extract smaller interfaces that support the individual responsibilities, but still have the same class adopt it. Doing so opens up opportunities for further refactoring and testing.
lock
#313
313 solid lsp
In this episode we examine the Liskov Subtitution Principle, which stresses the importance of the strong relationship a type has with its super type. Understanding LSP can help you identify when you are missing an important abstraction, or perhaps when inheritance is being abused as a tool.
lock
#312
312 solid ocp
The Open Closed Principle (or OCP) states that a class should be open for extension, but closed for modification. The goal is to write classes that are more stable, and don't require constant changes themselves to support every scenario the software encounters. Instead, having a stable class to inherit from can provide a nice extension point for our software to customize it for other needs.
lock
#311
311 solid srp
In this episode we'll examine a type that has too many responsibilities and refactor it into multiple types, each with their own responsibility.
lock
#310
Solid@2x
This episodes kicks off a new series on SOLID principles for improving at object-oriented design. Writing better code means writing code that costs less to change, which can be a crucial factor in delivering project successfully. In this series we will see how these principles apply to Swift.
lock
#307
306 codable caching
In this episode we continue with our caching example, this time introducing a new type that will handle the caching for us, as well as wrapping the response type into a new type that will indicate to the view controller if the response was served from the cache or from the network. We end the episode by implementing Equatable so that our store can avoid needless double callbacks if the data has not changed.
lock
#306
306 codable caching
In a recent project I leveraged the Codable protocol to save API responses to disk to make the application more responsive (and to have an offline mode). I was happy with the results. In this episode we will add some caching to an existing application, saving JSON responses to the caches directory on the device.
lock
#305
305 codable and polymorphism
Codable is a great API, but sometimes real APIs can be tricky to model. In this episode we’ll examine a real use case of an API that returns a collection of elements, each of them similar but specified by a type. We’ll leverage Codable and inheritance to create a representation of this structure and show how you can peek into the container in order to determine what type to decode.
lock
#279
278 swift 4 json parsing
We tackle some more complex (read: realistic) scenarios where the JSON structure doesn’t quite match the structure of the objects. We’ll do this by providing custom implementations of Encodable and Decodable, talk about keyed and unkeyed containers, and how you might be able to transform the date during the encoding process
lock
#278
278 swift 4 json parsing
Swift 4 finally answers the long-debated question of: How should I parse JSON with Swift? In this episode we'll take a look at the new Codable protocol in Swift 4, and talk about how to use JSONEncoder and JSONDecoder to serialize your objects into JSON and back again.
lock
#277
258 hello cloud kit part 1
We finish the CloudKitNotesManager by providing a generic save and delete methods that we can use for any CKRecordWrapper type. We also implement a custom notification when a note is saved so that we can update an interested view controllers to update their UI.
lock
#276
258 hello cloud kit part 1
In this episode we implement a CloudKit version of our NotesManager protocol. Along the way we'll implement a reusable query function and run into a limitation with Swift generics that we will have to work around.
lock
#275
258 hello cloud kit part 1
Since our model objects will be backed by a CKRecord, we will leverage computed properties to marshal values back and forth to the record. Doing so in a type safe way gets pretty redundant, so we can reuse a lot of this boilerplate code by extracting a protocol we’ll call CKRecordWrapper. We can leverage this protocol to give us type-safe access to record keys and to provide default implementations of identifier, modifiedAt, and createdAt fields.
lock
#274
258 hello cloud kit part 1
So far in this series we've been using CloudKit directly from our controllers. This can be somewhat limiting. It requires you to be online or everything fails, we may want to add a caching layer, or we might want to use CloudKit as a network synchronization layer, rather than a primary data store. In this episode we'll examine an architecture that will allow you to decouple your view controllers from CloudKit as a first step to achieving more flexibility with your CloudKit implementation.
lock
#273
273 storyboard initializable
In the refactoring series, Soroush mentioned a protocol he uses to make initializing view controllers from a storyboard as easy as adopting a protocol (and completely type-safe). In this episode we will build this using Swift protocol extensions. The end result is something you can easily carry with you from project to project.
lock
#261
261 sourcery
Writing boilerplate code can get tedious and boring. It can also lead to code duplication, which means it becomes a liability to keep in sync. Sourcery is a code generation tool that can help leverage your existing types and reflect on them in order to generate useful bits of code. In this episode Sam Soffes shows us how to install and use Sourcery, how to integrate it with Xcode’s build system, and how to create a simple Sorcery template to automatically count the number of items in a Swift enum and add it as an option.
lock
#251
251 swift grab bag
In this episode we cover some lesser-known features of Swift, including @discardableResult, escaping closures, defer, and using dump versus print for better debugging output.
lock
#250
250 poker hands part 3
In this final episode in the Poker Hands Kata with Soroush Khanlou, we finish off by improving the design of our program, improving our tests, and implementing the remaining features for detecting the more complicated hands.
lock
#249
249 poker hands part 2
In this episode I am joined again by Soroush Khanlou. We continue our exploration of the Poker Hands kata, focusing on fleshing out our types. We also begin matching poker hands, leveraging enums with associated types.
Shape
#248
248 poker hands part 1
In this episode I am joined by Soroush Khanlou. Together we pair up to implement the Poker Hands Kata. We start off by parsing the raw string input into structured types, complete with tests.
lock
#247
247 yahtzee kata
In this episode we will implement the Yahtzee Kata, which entails scoring hands based on dice rolls. We'll look at leveraging protocols and protocol extensions to mix & match shared behaviors across disparate types in order to perform matching and scoring of the dice.
lock
#246
246 improved guard setup for swift
In the last episode we showed how to run Swift tests automatically with guard, but it wasn't an ideal setup. We couldn't see compiler errors, nor could we see any output from our program using print. In this episode we leverage Ruby's open3 library to capture stdout and stderr so we can output it to the terminal in the appropriate colors.