Some slides I prepared once upon a time for one of our knowledge-sharing meetings with our iOS team at Inaka.

1. Little lessons
learned from Swift
Very first steps after
transitioning from Objective-C

2. Switch
switch is much more powerful in Swift than in Obj-C
You can replace lots of if statements by switch statements

3. Even if you’re able to do something with a single if statement,
sometimes it has much more sense to think of a switch
instead, for example:
Switch

4. Advantage
Code intention is clearer, it tells you that you have (or might
have) more options to switch over.
With a single if, you don’t realize that.
Switch

5. When you combine the powerful of switch with enums, you
are working on the base of the Pattern Matching concept.
case .Delayed(let minutes)
println("delayed by (minutes) minutes”
Switch & Enum

6. Table view sections
Interesting use case
“raw” type
= 0
= 1
= 2
// implicit
// raw
// values
toRaw
fromRaw
Switch & Enum

7. A very interesting use case of Pattern Matching in our world is
for completion functions…
Another interesting use case
Completion is a type.
.Success with Array<T>
.Failure with NSError
… or …
Switch & Enum

8. Switch & Enum
*switches in Swift don’t fall through automatically

9. It takes a function as argument, whose argument is a
Completion type.
The function is executed here, passing a .Success case
with an array of Contributions.
Switch & Enum

10. It takes a function as argument, whose argument is a
Completion type.
The function is executed here, passing a .Success case
with an array of Contributions.
Computed property
Switch & Enum

11. Computed Properties
// process whatever you need
// in order to return the array

12. Computed Properties

13. Computed Properties

14. Computed Properties

15. Optionals

16. Optionals
An optional is a type

17. Optionals
An optional is a type
An optional is actually an enum, so that:

18. Optionals
An optional is a type
An optional is actually an enum, so that:

19. Optionals
An optional is a type
An optional is actually an enum, so that:

20. Optionals
An optional is a type
An optional is actually an enum, so that:

21. Optionals
An optional is a type
An optional is actually an enum, so that:

22. Optionals
String? “A String that can be nil”

23. Optionals
String? “A String that can be nil”

24. Optionals
String? “A String that can be nil”
An Optional that can be a String

25. Optionals
String? “A String that can be nil”
An Optional that can be a String
…or can eventually be nil

26. Optionals
String? “A String that can be nil”
An Optional that can be a String
…or can eventually be nil
String?
String
nil

27. Optionals
String? “A String that can be nil”
An Optional that can be a String
…or can eventually be nil
String?
String
nil
stringThatCanBeNil
// not a String, but a String?

28. Optionals
String? “A String that can be nil”
An Optional that can be a String
…or can eventually be nil
String?
String
nil
stringThatCanBeNil
// not a String, but a String?
stringThatCanBeNil!
// The ! operator "unwraps" the optional,
// you get String then

29. Optionals
But… warning!
If you try to unwrap an optional and it
happens to be nil, the app will crash!

30. Optionals
But… warning!
If you try to unwrap an optional and it
happens to be nil, the app will crash!

31. Optionals
So, should we use the unwrapping (!) operator…?

32. Optionals
So, should we use the unwrapping (!) operator…?
Well, yes (in some cases)…
Because sometimes we do want the app to crash!

33. Optionals
So, should we use the unwrapping (!) operator…?
Well, yes (in some cases)…
Because sometimes we do want the app to crash!
Example:

34. Optionals
So, should we use the unwrapping (!) operator…?
Well, yes (in some cases)…
Because sometimes we do want the app to crash!
Example:

35. Optionals
So, should we use the unwrapping (!) operator…?
Well, yes (in some cases)…
Because sometimes we do want the app to crash!
Example:
Will return TransactionCell if possible,
nil otherwise

36. Optionals
So, should we use the unwrapping (!) operator…?
Well, yes (in some cases)…
Because sometimes we do want the app to crash!
Example:
Will return TransactionCell if possible,
nil otherwise

37. Optionals
So, should we use the unwrapping (!) operator…?
Well, yes (in some cases)…
Because sometimes we do want the app to crash!
Example:
Will return TransactionCell if possible,
nil otherwise

38. Optionals
amount is String?
value is String
// value doesn’t need to be unwrapped
"if let" unwraps variables automatically

39. Optionals
Obj-C

40. Optionals
Obj-C
Swift

41. Optionals
The ?? operator

42. Optionals
The ?? operator
let a: Int?
let b: Int
let result: Int

43. Optionals
The ?? operator
if let value = a {
result = value
} else {
result = b
}
let a: Int?
let b: Int
let result: Int

44. Optionals
The ?? operator
if let value = a {
result = value
} else {
result = b
}
result = a ? a! : b
let a: Int?
let b: Int
let result: Int

45. Optionals
The ?? operator
result = a ?? b
if let value = a {
result = value
} else {
result = b
}
result = a ? a! : b
let a: Int?
let b: Int
let result: Int

46. Tips
A good place to set a delegate
How to declare constants in your class

47. Tips
Interesting piece of code

48. Tips
Interesting piece of code
Defining a computed property

49. Tips
Interesting piece of code
Define constants
Defining a computed property

50. Tips
Interesting piece of code
Define constants
Using as?
Defining a computed property

51. Tips
Interesting piece of code
Define constants
Using as?
Defining a computed property
Using ?? operator

52. Syntax Sugar
// initialized nil by default
// initialized nil by default

53. self.property vs property
<< the debate >>

54. self.property vs property
http://stackoverflow.com/questions/24215578/when-should-i-access-properties-with-self-in-swift

55. Fun with arrays!
sort
filter
map
reduce

56. Fun with arrays!