Спасибо большое за блестящее объяснение! Примерно год изучал и практиковался с UIKit. Как раз сейчас перехожу на SwiftUI. С вашим роликом вроде пазлы в голове нормально так собрались! =)
Очень годно. Сам сейчас портирую проект с C# под Windows на MacOS. По началу декларативный стиль проектирования интерфейса показался неудобным, но теперь я понял в чем его фишка. Хотя и XAML на WPF хорош)
Да, по ощущениям, как слом мозга. Хочется забыть, всё, что знал о программировании до этого и учить всё заново. Но поскольку я уже несколько раз менял подходы, то постепенно освоил подход SwiftUI / RXSwift и теперь очень комфортно себя чувствую.
Про время фигня. Просто вы слишком много говорили в секции про UIKit, да и реализовать можно было проще. UIKit для коммерческих проектов со сложным UI, а SwiftUI для простых приложений.
Про последнее утверждение я уже не соглашусь. Сейчас на SwiftUI можно сделать интерфейс любой сложности. Единственное оправдание, почему коммерческие проекты сейчас до сих пор на UIKit - это если им необходимо поддерживать версии iOS 12 и старее. Это практически не разумно: На начало лета 2022: iOS 15 - 89% iOS 14 - 10% earlier (не поддерживают SwiftUI) - 1% Сейчас уже большинство живых устройств на iOS 16. Сама Apple, Yandex, Telegram и другие вынуждены поддерживать свои приложения для старых iOS 10 - 12. Но это гиганты, они могут себе позволить. И да, я сам до сих пор занимаюсь поддержкой приложений для iOS 12+ на UIKit, заказчики не хотят терять даже этот процент... Но создавать новые проекты в 23 году нужно только на SwiftUI.
Когда дело дойдёт до более сложных приложений, SwiftUI уже не будет таким явным победителем, а скорее проигравшим. Существуя уже 3 год, он до сих пор является еще очень сырым, из-за чего приходится использовать компоненты из UIKit и переделывать их для SwiftUI
Первое оправдание, почему коммерческие проекты сейчас до сих пор на UIKit - это то, что им необходимо поддерживать версии iOS 12 и более ранние, хотя, практически это не разумно: На начало лета 2022: iOS 15 - 89% iOS 14 - 10% earlier (не поддерживают SwiftUI) - 1% Сейчас, в 2023, уже большинство живых устройств на iOS 16. Сама Apple, Yandex, Telegram и другие вынуждены поддерживать свои приложения для старых iOS 10 - 12. Но это гиганты, они могут себе позволить. Я сам (хоть и не гигант), до сих пор занимаюсь поддержкой приложений для iOS 12+ на UIKit, заказчики не хотят терять даже этот процент... Но создавать новые проекты в 23 году нужно только на SwiftUI. А второе оправдание, почему dev.компании не переходят на SwiftUI - банально нет специалистов такого уровня. Нужно освоить Combine. Таких людей очень мало. А использовать компоненты предыдущего языка - это, скорее, говорит о том, что Apple молодцы, что предусмотрели такую возможность! Я не знаю, но есть что-то подобное у Kotlin? И главное - сложных приложений очень и очень мало и становится меньше. Играют скорость и удобство программирования. Я давно пишу и знаю людей, которые кроме Objective-C ничего не хотят изучать, всё ждут, когда все дружно вернутся к этому "чудо-языку"?... А вот когда я пытаюсь молодежь учить или хотя бы показать Obj-C, они с первых же уроков говорят: достаточно, мы всё поняли, давай SwiftUI!
Денис, согласен! на iOS13 ещё много чего не так. По сути, только с 15-й и даже с 16-й iOS начинается нормальное программирование на SwiftUI. В 16й уже допилили NavigationView, наконец-то!
Если планируете разрабатывать самостоятельно и новые приложения, то лучше сразу осваивать SwiftUI. Если же учитесь, чтобы работать в командах и существующих проектах, то надо знать UIKit и тоже начинать учить SwiftUI. SwiftUI требует как минимум iOS13, а многие коммерческие проекты пока ещё требуют поддержки iOS12. Можно уже начинать некоторые модули делать на SwiftUI и аккуратно вставлять их в проекты на UIKit. Всё будет компилироваться.
Молодец! Отличное замечание! Это не совсем баг. Я об этом даже упомянул, что там не нужна кнопка Save. Но это только в этом учебном кейсе. На самом деле, в реальных приложениях, нужно обязательно следить за этим. Пользователь не простит, если встретит такое поведение приложения. Надо создавать временную сущность для хранения введённых данных и только если он нажал Сохранить, тогда обновлять основную сущность. И надо конечно предоставить кнопку Отмена, которая закроет вью без сохранения данных. Свайп вниз тоже не должен сохранять. Решать тут должен PM / заказчик или разработчик, все случаи разные.
Учил год UIKit, начал недавно учить SwiftUI. Как лучше поступить? Учить SwiftUI и продолжить учить UIKit, или полностью все силы на SwiftUI отдать? Если выберу второе то боюсь что все знания UIKit забудутся. Но эффективно ли будет если буду время отдавать сразу двум фреймворкам.
Это зависит от вашей цели: Если хотите устроиться в компанию работать, то придётся пока выучить UIKit. Если будете свои приложения делать, то уже достаточно только SwiftUI. При этом я согласен, что выбор по-прежнему сложный. Учить параллельно оба подхода - это издевательство над своими мозгами и путаница.
Все утверждают что для изучения swiftUI все равно нужно знать какие-то элементы из UIKit. Вот собственно и вопрос что именно там нужно знать и возможно подскажите, на что стоит сделать упор при изучении swiftUI?
Этот вопрос довольно широкий, просто не ответить, поскольку это зависит от задач, которые перед вами стоят. В основном, такие утверждения исходят из того, что на конец 22 года в SwiftUI ещё не все элементы доделаны и если нужно, например, использовать карту (MapKit), то приходится брать её из UIKit, добавлять оболочку UIViewRepresentable и уже через эту оболочку, с картой будет работать SwiftUI. Тот же NavigationView вот вроде только сейчас и только для iOS16+ можно использовать так, как принято в SwiftUI. Но это всё не означает, что можно составить список недостающих элементов / фреймворков и их изучать перед тем, как осваивать SwiftUI. Есть отличный ресурс, stackoverflow.com. Там можно найти или даже спросить вопрос по SwiftUI (перед вопросом надо поставить тег [swiftui] ) и сейчас уже чаще всего там предложат решение.
@@user-me5ry3vx1f как раз и нужно задавать вопросы, чтобы учиться! Правильно заданный вопрос приближает вас к ответу. Умение задать вопрос правильно и есть самый лучший навык!
Спасибо большое за блестящее объяснение! Примерно год изучал и практиковался с UIKit. Как раз сейчас перехожу на SwiftUI. С вашим роликом вроде пазлы в голове нормально так собрались! =)
Спасибо автору! Прошу больше видео! Вы очень круто рассказываете!
Спасибо за видео!
Очень годно.
Сам сейчас портирую проект с C# под Windows на MacOS.
По началу декларативный стиль проектирования интерфейса показался неудобным, но теперь я понял в чем его фишка.
Хотя и XAML на WPF хорош)
Да, по ощущениям, как слом мозга. Хочется забыть, всё, что знал о программировании до этого и учить всё заново. Но поскольку я уже несколько раз менял подходы, то постепенно освоил подход SwiftUI / RXSwift и теперь очень комфортно себя чувствую.
Знаю что курс не про это но было бы лучше если сразу писал weak var delegate и protocol EditorDelegate: AnyObject. Спасибо
Про время фигня.
Просто вы слишком много говорили в секции про UIKit, да и реализовать можно было проще.
UIKit для коммерческих проектов со сложным UI, а SwiftUI для простых приложений.
Про последнее утверждение я уже не соглашусь. Сейчас на SwiftUI можно сделать интерфейс любой сложности.
Единственное оправдание, почему коммерческие проекты сейчас до сих пор на UIKit - это если им необходимо поддерживать версии iOS 12 и старее. Это практически не разумно:
На начало лета 2022:
iOS 15 - 89%
iOS 14 - 10%
earlier (не поддерживают SwiftUI) - 1%
Сейчас уже большинство живых устройств на iOS 16.
Сама Apple, Yandex, Telegram и другие вынуждены поддерживать свои приложения для старых iOS 10 - 12. Но это гиганты, они могут себе позволить.
И да, я сам до сих пор занимаюсь поддержкой приложений для iOS 12+ на UIKit, заказчики не хотят терять даже этот процент...
Но создавать новые проекты в 23 году нужно только на SwiftUI.
@@AvenCode Я бы посмотрел вашу вёрстку в сложном проекте на SwiftUI. UIKit нужен и будет нужен для коммерческих проектов. Он никуда не исчезнет.
Когда дело дойдёт до более сложных приложений, SwiftUI уже не будет таким явным победителем, а скорее проигравшим. Существуя уже 3 год, он до сих пор является еще очень сырым, из-за чего приходится использовать компоненты из UIKit и переделывать их для SwiftUI
Первое оправдание, почему коммерческие проекты сейчас до сих пор на UIKit - это то, что им необходимо поддерживать версии iOS 12 и более ранние, хотя, практически это не разумно:
На начало лета 2022:
iOS 15 - 89%
iOS 14 - 10%
earlier (не поддерживают SwiftUI) - 1%
Сейчас, в 2023, уже большинство живых устройств на iOS 16.
Сама Apple, Yandex, Telegram и другие вынуждены поддерживать свои приложения для старых iOS 10 - 12. Но это гиганты, они могут себе позволить.
Я сам (хоть и не гигант), до сих пор занимаюсь поддержкой приложений для iOS 12+ на UIKit, заказчики не хотят терять даже этот процент...
Но создавать новые проекты в 23 году нужно только на SwiftUI.
А второе оправдание, почему dev.компании не переходят на SwiftUI - банально нет специалистов такого уровня. Нужно освоить Combine. Таких людей очень мало.
А использовать компоненты предыдущего языка - это, скорее, говорит о том, что Apple молодцы, что предусмотрели такую возможность!
Я не знаю, но есть что-то подобное у Kotlin?
И главное - сложных приложений очень и очень мало и становится меньше. Играют скорость и удобство программирования.
Я давно пишу и знаю людей, которые кроме Objective-C ничего не хотят изучать, всё ждут, когда все дружно вернутся к этому "чудо-языку"?...
А вот когда я пытаюсь молодежь учить или хотя бы показать Obj-C, они с первых же уроков говорят: достаточно, мы всё поняли, давай SwiftUI!
На ios 13 невозможно использовать SwiftUI например для attributed string в TextField надо офигеть как извертеться с их протоколами.
Денис, согласен! на iOS13 ещё много чего не так. По сути, только с 15-й и даже с 16-й iOS начинается нормальное программирование на SwiftUI. В 16й уже допилили NavigationView, наконец-то!
Интересное сравнение! Но новичку лучше все равно знать и то и другое? Либо уже сейчас стоит упор делать на SwiftUi?
Если планируете разрабатывать самостоятельно и новые приложения, то лучше сразу осваивать SwiftUI. Если же учитесь, чтобы работать в командах и существующих проектах, то надо знать UIKit и тоже начинать учить SwiftUI.
SwiftUI требует как минимум iOS13, а многие коммерческие проекты пока ещё требуют поддержки iOS12. Можно уже начинать некоторые модули делать на SwiftUI и аккуратно вставлять их в проекты на UIKit. Всё будет компилироваться.
Если хочешь работать в продуктовой компании это UIKit. 4 месяца делал приложение на SwiftUI трудно попасть в макет. А вот реактивщина это шик для меня
Нашел баг, если отредактировать текст и закрыть sheet не нажимая на Save, то текст все равно сохранится
Молодец! Отличное замечание! Это не совсем баг. Я об этом даже упомянул, что там не нужна кнопка Save. Но это только в этом учебном кейсе. На самом деле, в реальных приложениях, нужно обязательно следить за этим. Пользователь не простит, если встретит такое поведение приложения. Надо создавать временную сущность для хранения введённых данных и только если он нажал Сохранить, тогда обновлять основную сущность. И надо конечно предоставить кнопку Отмена, которая закроет вью без сохранения данных. Свайп вниз тоже не должен сохранять. Решать тут должен PM / заказчик или разработчик, все случаи разные.
@@AvenCode если не сложно можно подробное видео по созданию такой сущности. Спасибо
Учил год UIKit, начал недавно учить SwiftUI. Как лучше поступить? Учить SwiftUI и продолжить учить UIKit, или полностью все силы на SwiftUI отдать? Если выберу второе то боюсь что все знания UIKit забудутся. Но эффективно ли будет если буду время отдавать сразу двум фреймворкам.
Это зависит от вашей цели:
Если хотите устроиться в компанию работать, то придётся пока выучить UIKit.
Если будете свои приложения делать, то уже достаточно только SwiftUI.
При этом я согласен, что выбор по-прежнему сложный. Учить параллельно оба подхода - это издевательство над своими мозгами и путаница.
Все утверждают что для изучения swiftUI все равно нужно знать какие-то элементы из UIKit. Вот собственно и вопрос что именно там нужно знать и возможно подскажите, на что стоит сделать упор при изучении swiftUI?
Этот вопрос довольно широкий, просто не ответить, поскольку это зависит от задач, которые перед вами стоят. В основном, такие утверждения исходят из того, что на конец 22 года в SwiftUI ещё не все элементы доделаны и если нужно, например, использовать карту (MapKit), то приходится брать её из UIKit, добавлять оболочку UIViewRepresentable и уже через эту оболочку, с картой будет работать SwiftUI. Тот же NavigationView вот вроде только сейчас и только для iOS16+ можно использовать так, как принято в SwiftUI.
Но это всё не означает, что можно составить список недостающих элементов / фреймворков и их изучать перед тем, как осваивать SwiftUI.
Есть отличный ресурс, stackoverflow.com. Там можно найти или даже спросить вопрос по SwiftUI (перед вопросом надо поставить тег [swiftui] ) и сейчас уже чаще всего там предложат решение.
@@AvenCode А есть отличия в жизненных циклах приложения и view, делегатах и т.д?
@@user-me5ry3vx1f Не корректно заданный вопрос 🙂 Конечно, есть различия. А что вы имеете ввиду? У каждого свой жизненный цикл.
@@AvenCode Походу мне нужно учиться, а не вопросы задавать😅
@@user-me5ry3vx1f как раз и нужно задавать вопросы, чтобы учиться! Правильно заданный вопрос приближает вас к ответу. Умение задать вопрос правильно и есть самый лучший навык!