Ответ
Нет, создавать подклассы UIApplication не рекомендуется и практически никогда не требуется. Apple явно указывает в документации, что UIApplication — синглтон, управляемый iOS, и его подклассирование может привести к нестабильности.
Правильный подход — использование UIApplicationDelegate:
class AppDelegate: UIResponder, UIApplicationDelegate {
func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
// Настройка приложения при запуске
return true
}
func application(_ app: UIApplication,
open url: URL,
options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
// Обработка deep links
return true
}
}Когда может потребоваться подкласс (крайне редко):
- Перехват всех событий приложения через
sendEvent(_:) - Кастомизация обработки удаленных уведомлений
Пример (не рекомендуется без веской причины):
class CustomApplication: UIApplication {
override func sendEvent(_ event: UIEvent) {
// Логирование или модификация событий
super.sendEvent(event)
}
}
// В Info.plist: Principal class = "YourApp.CustomApplication"Лучшие практики:
- Используйте
UIApplicationDelegateдля lifecycle событий - Для глобального перехвата событий рассмотрите
UIWindowилиUIResponderцепочку - Для модификации поведения используйте middleware-паттерны, а не подклассы
UIApplication - Следуйте документации Apple:
UIApplicationпредназначен для управления системой, а не для кастомизации
Ответ 18+ 🔞
Да ты послушай, что за дичь в голове у людей бывает! Сидят, блядь, и думают: «А дай-ка я возьму этот священный грааль, UIApplication, и нахуярю от него наследничков!». Ну, ёпта, мозги набекрень, честное слово.
Слушай сюда, распальцовка моя: делать подклассы от UIApplication — это идея уровня «пойду-ка я поссаю против ветра». Apple, эти хитрожопые ребята, прямо в документации пишут, что это синглтон, которым система рулит. Сунешься со своим велосипедом — получишь нестабильность, баги из ниоткуда и волнение ебать на ровном месте.
А как надо, спросишь? Да элементарно, Ватсон! Используй UIApplicationDelegate, для этого он и придуман, блядь.
class AppDelegate: UIResponder, UIApplicationDelegate {
func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
// Тут твои стартовые пляски с бубном
return true
}
func application(_ app: UIApplication,
open url: URL,
options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
// Лови deep link, обрабатывай, короче, работай
return true
}
}«А когда всё-таки можно?» — спросит дотошный чувак. Да почти никогда, блядь! Разве что если ты решил стать богом событий и перехватывать ВСЁ через sendEvent(_:). Или тебе неймётся с удалёнными пушками. Но это уже высший пилотаж, на грани фола.
Вот смотри, как это выглядит (но это не руководство к действию, а предупреждение!):
class CustomApplication: UIApplication {
override func sendEvent(_ event: UIEvent) {
// Тут ты можешь, типа, логировать всё или ещё какую хуйню творить
super.sendEvent(event)
}
}
// И не забудь в Info.plist ткнуть: Principal class = "YourApp.CustomApplication"Так как же жить правильно, чтобы не прослыть мудем?
- Живи по
UIApplicationDelegate. Для событий жизненного цикла — это твой отец родной. - Хочешь глобально что-то ловить? Смотри в сторону
UIWindowили в цепочкуUIResponder. Не лезь в кишки системы. - Паттерны, блядь, учи. Middleware, например. Красиво, модульно, и Apple не обосрётся.
- Запомни раз и навсегда:
UIApplication— это как пульт управления атомной станцией от системы. Твоя задача — нажимать разрешённые кнопки через делегат, а не перепаивать микросхемы внутри, думая, что ты умнее всех.
Короче, не выёбывайся. Система умнее. Обычно.