Mocking and stubbing in tests is useful to verify behavior and replace collaborating objects with simpler alternatives. Since Swift is statically typed, you can't use a mocking library anymore. But it's trivially simple to write simple mock objects as subclasses in place.
You don't have to learn anything new if you work with Core Data in Swift. It's a pain to use NSManagedObject directly, so you better work with custom subclasses all the time. Unboxing optional NSNumbers is just too cumbersome. There are caveats you should be aware of, though.
The Observer pattern is one of the design patterns that I tend to use the most. The basic principle behind this pattern is a listener registers with a broadcaster and then at some later point in time the broadcaster notifies the listener when some predefined event happens. This pattern can be used to facilitate the communication between decoupled objects and also to implement a one-to-many relationship. The Observer pattern falls into the behavior pattern category.
When the 1.0 version of Swift was initially released it contains native String, Array and Dictionary types that were bridged with the NSString, NSArray and NSDictionary types. The one noticeable omission was Swift did not contain a native set type. With the 1.2 version of Swift, Apple corrected this omission and added the Set type.