С какими технологиями не хочешь работать?

С какими технологиами я предпочитаю не работать и почему

За более чем десятилетний опыт в iOS-разработке я пришел к выводу, что выбор технологий — это компромисс между функциональностью, поддержкой, производительностью и здравым смыслом. Есть несколько категорий технологий и подходов, с которыми я стараюсь избегать работы, если есть альтернативы.

1. Устаревшие, неподдерживаемые технологии Apple

В первую очередь, это устаревшие фреймворки и языки, которые Apple официально прекратила поддерживать или объявила deprecated.

• Objective-C без Swift: Хотя я уважаю Objective-C как основу iOS и могу с ним работать, начинать новый проект исключительно на нем в 2024 году нерационально. Apple активно развивает Swift, и все новые API заточены под него. Смешанная кодовая база (Swift + Obj-C) допустима для поддержки легаси, но не для greenfield-проектов.
• UIWebView: Полностью deprecated в пользу WKWebView. Использование UIWebView — это прямая угроза безопасности приложения и риск отказа при публикации в App Store.
• OpenGL ES: Для любой новой графической работы нужно использовать Metal. OpenGL ES хоть и работает, но не получает оптимизаций и нововведений, а его поддержка может быть прекращена в будущих версиях iOS.

// Нежелательный устаревший подход (UIWebView)
// let webView = UIWebView(frame: .zero) // DEPRECATED

// Предпочтительный современный подход (WKWebView)
import WebKit
let webView = WKWebView(frame: .zero)

2. Неофициальные "костыли" и излишне сложные архитектуры

• Слишком умные runtime-манипуляции: Чрезмерное использование method_exchangeImplementations (сваппинг методов) для простых задач, где можно обойтись наследованием, композицией или протоколами. Это сильно усложняет отладку и тестирование.
• Чрезмерно абстрактные архитектурные паттерны на маленьких проектах: Внедрение VIPER или собственного многослойного Clean Architecture в приложение с 5 экранами. Это создает непропорционально большую нагрузку на поддержку и развитие без реальной пользы. Для большинства проектов отлично подходит MVVM или даже аккуратный MVC.
• Самописные навигационные роутеры с "магией": Сложные системы, где зависимости инжектятся через строковые ключи или reflection, полностью скрывая flow приложения. Простота и прозрачность UINavigationController или координаторного паттерна (Coordinator) часто предпочтительнее.

3. Нестабильные или маркетинговые зависимости

• Непроверенные и быстро меняющиеся сторонние библиотеки: Библиотеки, которые каждую неделю выпускают мажорные версии с ломающими изменениями (breaking changes) без должного обеспечения обратной совместимости. Это делает обновления болезненными.
• Монолитные SDK "все-в-одном": Особенно от небольших вендоров, которые пытаются решить 20 задач одним модулем (сеть, кэш, аналитика, дизайн-система). Часто они плохо документированы, их тяжело кастомизировать, а при проблемах с одной функцией страдает всё.
• Технологии, противоречащие гайдлайнам платформы: Например, кроссплатформенные фреймворки, которые рендерят нативные контролы через "мост", но не дают полноценного доступа к новейшим iOS API (вроде SwiftUI, Metal API). Они часто отстают на 1-2 версии iOS и создают "ненативное" чувство в интерфейсе. Для приложений, где нативный UX и производительность критичны, это неприемлемо.

// Пример риска: зависимость от быстро меняющегося API сторонней библиотеки
// networkService.fetchFromUnstableSDK() // Может изменить сигнатуру завтра

// Более безопасный подход: инкапсуляция зависимости за своим интерфейсом (протоколом)
protocol DataFetching {
    func fetchUserData() async throws -> User
}

class StableNetworkService: DataFetching {
    func fetchUserData() async throws -> User {
        // Здесь может быть работа с чем угодно,
        // но внешний контракт для всего приложения стабилен
        return try await URLSession.shared.data(...)
    }
}

4. Причины такого выбора

Мой скепсис основан не на предубеждениях, а на практическом опыте, который показал, что эти технологии:

1. Увеличивают долгосрочную стоимость владения (технический долг, время на onboarding новых разработчиков).
2. Создают риски для безопасности и стабильности приложения.
3. Затрудняют обновление до новых версий iOS и Swift.
4. Снижают производительность как приложения, так и команды разработчиков.

Итог: Моя цель — строить стабильные, поддерживаемые и эффективные приложения. Поэтому я сознательно выбираю технологии с сильной экосистемой (Swift, SwiftUI, Combine, современные Apple фреймворки), продуманной архитектурой, умеренным количеством проверенных зависимостей и, главное, — те, что соответствуют долгосрочной стратегии Apple. Это не категоричный отказ, а взвешенная позиция, которая может быть пересмотрена, если технология докажет свою жизнеспособность и преимущества в конкретном контексте проекта.