Комментарии 4
И вот имея кучу примеров реализации в виде сторонних библиотек и 100500 способов это сделать руками в UIKit, Apple должна была зашивать это в iOS 15 без обратной совместимости.
Зачем?
Apple всегда пытается привлечь больше новых разработчиков под свои платформы (оно и очевидно, Apple имеет свой процент + наполнение стора). Один из способов — снижение порога вхождения: переход на Swift, SwiftUI, расширение возможностей UIKit и тп.
Думаю в данном случае именно такая ситуация — видя что элемент дизайна стал очень популярным в большом количестве приложений, кто-то решил добавить «решение из коробки».
А обратная совместимость не самый главный приоритет в последнее время, к сожалению.
Думаю в данном случае именно такая ситуация — видя что элемент дизайна стал очень популярным в большом количестве приложений, кто-то решил добавить «решение из коробки».
А обратная совместимость не самый главный приоритет в последнее время, к сожалению.
Да я же не против этих новшеств, просто я так понимаю, что если они не могут сохранить обратную совместимость, то каждый раз, добавляя новый компонент, они хардкодят его в UIKit, меняя предыдущие кода (иначе бы компонент мог бинарником идти вместе с софтом).
А хардкодить в своем же фреймворке для добавления таких вещей – не самый крутой архитектурный подход…
В то же время, стоит рассмотреть обратную сторону вопроса. Если оставить только самые базовые компоненты в фреймворке, то бинарник приложений мог бы значительно вырасти. Так же это даёт более простой доступ к UI/UX решениям, которые используются в стандартных приложениях, плюс опять же скорость разработки.
Думаю должен быть плюс минус баланс в таких вопросах.
Думаю должен быть плюс минус баланс в таких вопросах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BottomSheet в iOS 15: возможности UISheetPresentationController