Como passar em uma entrevista de Swift: principais perguntas de A a Z

Introdução: Por que Swift é a chave para uma entrevista bem-sucedida

A entrevista de Swift não é apenas uma verificação de sintaxe. O ecossistema Apple exige compreensão dos princípios fundamentais da linguagem, gerenciamento de memória e frameworks modernos. Neste artigo, analisaremos as principais perguntas que certamente serão feitas em qualquer nível — do Júnior ao Sênior. Você aprenderá não apenas as respostas corretas, mas também as armadilhas típicas em que os candidatos caem.

O artigo foi escrito para o portal educacional PythonLib, mas adaptado para Swift. Estruturamos o material para que você possa revisar rapidamente os tópicos principais antes da entrevista.

1. Fundamentos do Swift: Optional, Value vs Reference Types

O que é Optional e para que serve?

Optional é uma enumeração (enum) que pode ser .none (nil) ou .some(Wrapped). É a forma do Swift trabalhar com segurança com a ausência de valor.

var name: String? = "Alice"var age: Int? = nil

// Extração seguraif let unwrappedName = name {    print("Hello, \\(unwrappedName)")} else {    print("Name is nil")}

Erro típico: Usar force unwrap (!) sem verificação. Sempre prefira guard let ou if let.

Value Types vs Reference Types

Swift separa estritamente os tipos:

• Value Types (structs, enums, tipos básicos) — são copiados na atribuição.
• Reference Types (classes) — são passados por referência.

struct Point {    var x: Int    var y: Int}

class Car {    var model: String    init(model: String) { self.model = model }}

var point1 = Point(x: 1, y: 2)var point2 = point1point2.x = 5 // point1.x permanecerá 1

var car1 = Car(model: "Tesla")var car2 = car1car2.model = "BMW" // car1.model também se tornará "BMW"

Pergunta de entrevista: "Por que a Apple recomenda usar structs em vez de classes?" Resposta: segurança de threads, previsibilidade, ausência de overhead do ARC.

2. Gerenciamento de Memória e ARC: Como evitar vazamentos

Como funciona o Automatic Reference Counting (ARC)?

O ARC conta automaticamente as referências a objetos de classe. Quando o contador chega a zero, a memória é liberada. Problemas surgem com referências cíclicas.

class Person {    let name: String    var apartment: Apartment?    init(name: String) { self.name = name }    deinit { print("\\(name) desalocado") }}

class Apartment {    let unit: String    weak var tenant: Person?  // weak — referência fraca    init(unit: String) { self.unit = unit }    deinit { print("Apartamento \\(unit) desalocado") }}

var john: Person? = Person(name: "João")var unit4A: Apartment? = Apartment(unit: "4A")john?.apartment = unit4Aunit4A?.tenant = johnjohn = nilunit4A = nil// Ambos os objetos serão liberados

Modificadores chave:

• weak — sempre optional, torna-se automaticamente nil ao ser liberado.
• unowned — não optional, assume que o objeto está vivo (risco de crash).

Pergunta típica: "Qual a diferença entre weak e unowned?" Resposta: weak é mais seguro, unowned é mais conveniente para dependências obrigatórias (por exemplo, delegate).

3. Frameworks: UIKit vs SwiftUI, GCD e Protocols

UIKit: Ciclo de vida do ViewController e Delegate Pattern

Entender viewDidLoad, viewWillAppear, viewDidDisappear é o básico. Mas na entrevista frequentemente perguntam sobre o Delegate pattern:

protocol MyDelegate: AnyObject {    func didTapButton()}

class MyView: UIView {    weak var delegate: MyDelegate?        @objc func buttonTapped() {        delegate?.didTapButton()    }}

class MyViewControlle