Swift Interview Questions and Answers

for i in 0...4 {
  print("Hello!")
}

Swift implements two range operators, the closed operator and the half-open operator. The first includes all the values in a range. For example, the following includes all the integers from 0 to 4:

0...4

The half open operator doesn’t include the last element. The following produces the same 0 to 4 result:

0..<5

tutorial1.difficulty is 1, whereas tutorial2.difficulty is 2.

Structures in Swift are value types, and they are copied by value rather than reference. The following line creates a copy of tutorial1 and assigns it to tutorial2:

var tutorial2 = tutorial1

From this line on, any change to tutorial2 is not reflected in tutorial1.

If Tutorial were a class, both tutorial1.difficulty and tutorial2.difficulty would be 2. Classes in Swift are reference types. Any change to a property of tutorial1 would be reflected into tutorial2 and vice versa.

view1 is a variable and can be re-assigned to a new instance of UIView. With let you can assign a value only once, so the following code doesn’t compile:

view2 = view1 // Error: view2 is immutable

However, UIView is a class with reference semantics, so you can mutate the properties of view2 (which means the last line will compile):

let view2 = UIView()
view2.alpha = 0.5 // Yes!

The first simplification is related to the parameters. The type inference system can calculate the type of the parameters in the closure, so you can get rid of them:

let sortedAnimals = animals.sort { (one, two) -> Bool in return one < two }

The return type can also be inferred, so drop it:

let sortedAnimals = animals.sort { (one, two) in return one < two }

The $i notation can substitute the parameter names:

let sortedAnimals = animals.sort { return $0 < $1 }

In single statement closures, the return keyword can be omitted. The return value of the last statement becomes the return value of the closure:

let sortedAnimals = animals.sort { $0 < $1 }

This is simpler already, but don’t stop now!

For strings, there’s a comparison function defined as follows:

func <(lhs: String, rhs: String) -> Bool

This neat little function makes your code as easy as:

let sortedAnimals = animals.sort(<)

Notice that each step of this progression compiles and outputs the same result, and you made a one-character closure!

Ray also moved to the new building! Address is a class and has reference semantics, so headquarters is the same instance, whether you access it via ray or brian. Changing the address of headquarters will change it for both. Can you imagine what would happen if Brian got Ray’s mail or vice versa? :]
The solution is to create a new Address to assign to Brian, or to declare Address as a struct instead of a class.

There is no difference. Optional.None (.None for short) is the correct way of initializing an optional variable lacking a value, whereas nil is just syntactic sugar for .None.

In fact, this statement outputs true:

nil == .None // On Swift 1.x this doesn't compile. You need Optional<Int>.None

Remember that under the hood an optional is an enumeration:

enum Optional<T> {
  case None
  case Some(T)
}

The compiler will complain about the last line. The ThermometerStruct is correctly declared with a mutating function to change its internal variable temperature, but the compiler complains because the registerTemperature is invoked on an instance created via let, thus it’s immutable.

In structures, methods that change the internal state must be marked as mutating but invoking them from immutable variables is not allowed.

It’ll print I love cars. The capture list creates a copy of thing when the closure is declared, so the captured value doesn’t change, even if you assign a new value to thing.

If you omit the capture list in the closure, then the compiler uses a reference instead of a copy. In this case, any change to the variable is reflected when the closure is invoked, as in the following code:

var thing = "cars"
 
let closure = {    
  print("I love \(thing)")
}
 
thing = "airplanes"
 
closure() // Prints "I love airplanes"

In Swift 2.0, generic types can be extended with conditions by enforcing type constraints. If the generic type doesn't satisfy the constraint, the extension is neither visible nor accessible.

So the global countUniques function can be rewritten as an Array extension:

extension Array where Element: Comparable {
  func countUniques() -> Int {
    let sorted = sort(<)
    let initial: (Element?, Int) = (.None, 0)
    let reduced = sorted.reduce(initial) { ($1, $0.0 == $1 ? $0.1 : $0.1 + 1) }
    return reduced.1
  }
}

Notice that the new method is available only when the generic Element type implements the Comparable protocol. For example, the compiler will complain if you call it on an array of UIViews as follows:

import UIKit
let a = [UIView(), UIView()]
a.countUniques() // compiler error here because UIView doesn't implement Comparable

The new guard statement introduced in Swift 2.0 provides an exit path if a condition is not met. It's very helpful to check preconditions, because it lets you express them in a clear way -- without the typical pyramid of doom of nested if statements. Here is an example:

guard dividend != .None else { return .None }

It can also be used for optional binding, making the unwrapped variable accessible after the guard statement:

guard let dividend = dividend else { return .None }

So the divide function can be rewritten as:

func divide(dividend: Double?, by divisor: Double?) -> Double? {
  guard let dividend = dividend else { return .None }
  guard let divisor = divisor else { return .None }
  guard divisor != 0 else { return .None }
  return dividend / divisor
}

Notice the absence of the implicitly unwrapped operators on the last line, because both dividend and divisor have been unwrapped and stored in non-optional immutables.

One more thing. You can group guard statements, so you can make the function simpler:

func divide(dividend: Double?, by divisor: Double?) -> Double? {
  guard let dividend = dividend, divisor = divisor where divisor != 0 else { return .None }
  return dividend / divisor
}

There are now only two guard statements, because you specify the non-zero condition using the where clause on the unwrapped variable divisor.

Swift defines the following protocols that enable a type to be initialized with literal values by using the assignment operator:

• NilLiteralConvertible
• BooleanLiteralConvertible
• IntegerLiteralConvertible
• FloatLiteralConvertible
• UnicodeScalarLiteralConvertible
• ExtendedGraphemeClusterLiteralConvertible
• StringLiteralConvertible
• ArrayLiteralConvertible
• DictionaryLiteralConvertible

Adopting the corresponding protocol and providing a public initializer allows literal initialization of a specific type. In the case of the Thermometer type, you implement the FloatLiteralConvertible protocol as follows:

extension Thermometer : FloatLiteralConvertible {
  public init(floatLiteral value: FloatLiteralType) {
    self.init(temperature: value)
  }
}

And now you can create an instance by using a simple float.

var thermometer: Thermometer = 56.8

Create a new custom operator in two steps: declaration and implementation.

The declaration uses the operator keyword to specify the type (unary or binary), the sequence of characters composing the operator, its associativity and precedence.

In this case, the operator is ^^ and the type is infix (binary). Associativity is left, and precedence is set to 155, given that multiplication and division have a value of 150. Here's the declaration:

infix operator ^^ { associativity left precedence 155 }

The implementation is as follows:

import Foundation
 
func ^^(lhs: Int, rhs: Int) -> Int {
  let l = Double(lhs)
  let r = Double(rhs)
  let p = pow(l, r)
  return Int(p)
}

Note that it doesn't take overflows into account; if the operation produces a result that Int can't represent, e.g. greater than Int.max, then a runtime error occurs.

No, you cannot. A raw value type must:

• Conform to the Equatable protocol
• Be literal convertible from any of the following types:
  • Int
  • String
  • Character

In the code above, the raw type is a tuple and is not compatible -- even if its individual values are.

They both do. The Pizzeria protocol declares the makeMargherita() method and provides a default implementation. The method is overridden in the Lombardis implementation. Since the method is declared in the protocol in both cases, the correct implementation is invoked at runtime.

What if the protocol doesn't declare the makeMargherita() method but the extension still provides a default implementation like this?

protocol Pizzeria {
  func makePizza(ingredients: [String]) -> Pizza
}
 
extension Pizzeria {
  func makeMargherita() -> Pizza {
    return makePizza(["tomato", "mozzarella"])
  }
}

In this case, only lombardis2 would make the pizza with basil, whereas lombardis1 would make a pizza without it, because it would use the method defined in the extension.

The else body of any guard requires an exit path, either by using return, by throwing an exception or by calling a @noreturn. The easiest solution is to add a return statement.

func showKitten(kitten: Kitten?) {
  guard let k = kitten else {
    print("There is no kitten")
    return
  }
  print(k)
}

Here's a version that throws an exception.

enum KittenError: ErrorType {
  case NoKitten
}
 
struct Kitten {
}
 
func showKitten(kitten: Kitten?) throws {
  guard let k = kitten else {
    print("There is no kitten")
    throw KittenError.NoKitten
  }
  print(k)
}
 
try showKitten(nil)

Finally, here's an implementation calling fatalError(), which is a @noreturn function.

struct Kitten {
}
 
func showKitten(kitten: Kitten?) {
  guard let k = kitten else {
    print("There is no kitten")
    fatalError()
  }
  print(k)
}

An optional is used to let a variable of any type represent the lack of value. In Objective-C, the absence of value is available in reference types only, and it uses the nil special value. Value types, such as int or float, do not have such ability.

Swift extends the lack of value concept to both reference and value types with optionals. An optional variable can hold either a value or nil any time.

There's an ongoing debate about whether using classes over structures is a good or bad practice. Functional programming tends to favor value types, whereas object-oriented programming prefers classes.

In Swift, classes and structures differ by a number of features. You can sum up the differences as follows:

• Classes support inheritance, structures don't
• Classes are reference types, structures are value types

There's no universal rule that determines what's best to use. The general recommendation is to use the most minimal tool required to accomplish your goal, but a good rule of thumb is to use structures unless you need inheritance or reference semantics.

For more details, check out this detailed post on the matter.

Generics are used to make algorithms safely work with types. In Swift, generics can be used both in functions and data types, e.g. in classes, structures or enumerations.

Generics solve the problem of code duplication. A common case is when you have a method that takes a type of parameter and you have to duplicate it just to accommodate a parameter of another type.

For example, in the following code the second function is a "clone" of the first one -- it just accepts strings instead of integers.

func areIntEqual(x: Int, _ y: Int) -> Bool {
  return x == y
}
 
func areStringsEqual(x: String, _ y: String) -> Bool {
  return x == y
}
 
areStringsEqual("ray", "ray") // true
areIntEqual(1, 1) // true

An Objective-C developer might think to resolve with an NSObject:

import Foundation
 
func areTheyEqual(x: NSObject, _ y: NSObject) -> Bool {
  return x == y
}
 
areTheyEqual("ray", "ray") // true
areTheyEqual(1, 1) // true

This code works as intended, but it's unsafe at compile time. It allows comparing a string with an integer, like this:

areTheyEqual(1, "ray")

The application doesn't crash, but allowing the comparison of a string to an integer is probably not the intended result.

By adopting generics, you can conflate the two functions into one and keep type safety at the same time. Here's the implementation:

func areTheyEqual<T: Equatable>(x: T, _ y: T) -> Bool {
  return x == y
}
 
areTheyEqual("ray", "ray")
areTheyEqual(1, 1)

Since you're testing equality in this case, you restrict the parameters to any type that implements the Equatable protocol. This code achieves the intended result and prevents passing parameters of a different type.

The most common reasons to use implicitly unwrapped optionals are:

1. When a property that is not nil by nature cannot be initialized at instantiation time. A typical example is an Interface Builder outlet, which always initializes after its owner has been initialized. In this specific case -- assuming it's properly configured in Interface Builder -- the outlet is guaranteed to be non-nil before it's used.
2. To solve the strong reference cycle problem, which is when two instances refer to each other and require a non-nil reference to the other instance. In such a case, one side of the reference can be marked unowned, while the other uses an implicitly unwrapped optional.

• forced unwrapping ! operator -- unsafe
• implicitly unwrapped variable declaration -- unsafe in many cases
• optional binding -- safe
• new Swift 2.0 guard statement -- safe
• optional chaining -- safe
• nil coalescing operator -- safe

Swift is a hybrid language that supports both paradigms.

It implements the three fundamental principles of OOP:

• Encapsulation
• Inheritance
• Polymorphism

As for Swift being a functional language, there are different but equivalent ways to define it.

One of the more common is on Wikipedia: "…a programming paradigm [...] that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data."

It's hard to argue that Swift is a full-fledged functional language, but it has the basics.

• 1 and 2 are included. Generics can be used in classes, structs, enumerations, global functions and methods.
• 3 is partially implemented via typealias. It's not a generic type per se, it's a placeholder name. It's often referred to as an associated type and it's defined when a protocol is adopted by a type.

A const is a variable initialized with a compile time value or an expression resolved at compilation time.

An immutable created via let is a constant determined at runtime, and it can be initialized with the result being either a static or dynamic expression. Notice that its value can only be assigned once.

static makes a property or a function static and not overrideable. By using class, you can override the property or function.

When applied to classes, static becomes an alias for class final.

For example, in this code the compiler will complain when you try to override illuminate():

class Star {
  class func spin() {}
  static func illuminate() {}
}
 
class Sun : Star {
  override class func spin() {
    super.spin()
  }
  override static func illuminate() { // error: class method overrides a 'final' class method
    super.illuminate()
  }
}

No, it's not possible. An extension can be used to add new behavior to an existing type, but not to alter the type itself or its interface. If you add a stored property, you'd need extra memory to store the new value. An extension cannot manage such a task.

Compilation fails with the following (cryptic) error message:

unimplemented IR generation feature non-fixed multi-payload enum layout

The problem is that the memory size of T cannot be determined upfront because it depends on the T type itself, but enum cases require a fixed-sized payload.

The most used workaround is to box the generic type into a reference type, conventionally called Box, as follows:

class Box<T> {
  let value: T
  init(_ value: T) {
    self.value = value
  }
}
 
enum Either<T, V> {
  case Left(Box<T>)
  case Right(Box<V>)
}

This problem affects only Swift 1.0 or later, but it has been solved in 2.0.

Closures are reference types. If a closure is assigned to a variable and the variable is copied into another variable, a reference to the same closure and its capture list is also copied.

There's an initializer for that:

UInt(bitPattern: Int)

A circular reference happens when two instances hold a strong reference to each other, causing a memory leak because none of two instances will ever be deallocated. The reason is that an instance cannot be deallocated as long as there's a strong reference to it, but each instance keeps the other alive because of its strong reference.

You'd solve the problem by breaking the strong circular reference by replacing one of the strong references with a weak or an unowned reference.

It's the indirect keyword that allows for recursive enumeration cases like this:

enum List<T> {
    indirect case Cons(T, List<T>)
}