Зачем нужны неявно извлекаемые опционалы (Implicitly Unwrapped Optionals), если мы и так уверены, что значение есть?

Ключевое отличие: время жизни и инициализация

Вы правы, что IUO (String!) выглядят как "обман" системы типов. Но их главная цель — решить проблему отложенной инициализации, когда значение гарантированно появится до первого использования, но не может быть установлено в момент создания объекта. Это компромисс между безопасностью и удобством.

Представьте IBOutlet — связь между кодом и Storyboard/Xib. Когда ваш ViewController инициализируется (через init), Storyboard ещё не загружен, поэтому свойство не может быть установлено сразу. Но к моменту вызова viewDidLoad() оно точно будет задано. Если бы мы использовали обычный опционал (String?), пришлось бы каждый раз писать:

class MyViewController: UIViewController {
    @IBOutlet var myLabel: UILabel? // обычный опционал
    
    override func viewDidLoad() {
        super.viewDidLoad()
        // Постоянное извлечение
        myLabel?.text = "Hello"
        myLabel?.textColor = .red
        myLabel?.font = UIFont.boldSystemFont(ofSize: 16)
    }
}

Это утомительно и засоряет код. С IUO (UILabel!) мы говорим компилятору: "Доверься мне, я знаю, что после viewDidLoad это свойство всегда не nil". И тогда код становится чище:

class MyViewController: UIViewController {
    @IBOutlet var myLabel: UILabel! // IUO
    
    override func viewDidLoad() {
        super.viewDidLoad()
        myLabel.text = "Hello" // без ? или !
        myLabel.textColor = .red
    }
}

Однако важно помнить: если вы обратитесь к IUO, когда оно действительно nil, произойдёт runtime crash. Поэтому IUO — это обещание разработчика, которое нужно соблюдать.

Другие сценарии использования

• Lazy свойства, которые не могут быть lazy. Например, в SwiftUI или при работе с Core Data, когда объект создаётся с пустыми полями, но заполняется позже.
• Взаимозависимые классы. Когда два объекта ссылаются друг на друга, один из них может быть IUO, чтобы разорвать цикл обязательной инициализации.
• API Objective-C. Многие старые фреймворки возвращают IUO, так как в Objective-C нет опционалов. Swift автоматически преобразует их в IUO для совместимости.

Почему не использовать обычный опционал с guard let?

Вы можете спросить: "А почему бы не использовать var myLabel: UILabel? и в каждом методе проверять через guard let?". Это безопаснее, но добавляет многословность. В больших проектах с десятками IBOutlet это превращается в шум. IUO — это сознательный выбор для ситуаций, где вы на 100% уверены в наличии значения, и хотите писать лаконичный код.

Современный Swift (5.0+): Начиная с Swift 5.0, IUO ведут себя как обычные опционалы (String?) при присваивании и как извлечённые (String) при использовании. Это значит, что компилятор будет предупреждать о потенциально опасных местах, но не запрещать их — вы всё равно можете выстрелить себе в ногу.

Вывод

IUO — это инструмент для удобства, а не для обхода безопасности. Используйте их только там, где значение гарантированно появится до первого чтения: IBOutlet, внешние зависимости, циклы инициализации. В остальных случаях предпочитайте обычные опционалы с безопасным извлечением.