Как использовать нарисованный интерфейс с помощью SKETCH в Xcode


#21

Спасибо! Но, чтобы вы посоветовали изучать в первую очередь, UIKit или SwiftUI?

Дело в том, что у меня очень хорошо получается рисовать все в sketch, это далеко не первый мой пробный дизайн.

Хотелось бы взять что-то и углубленно изучить , чтобы с ним постоянно работать.

Короче голова не понимает уже с чего начать, так как в курсах тоже сколько прошел, приходилось самостоятельно искать проблемы даже c firebase…


#22

Дело в том, что проходил курсы по UIKit и обучение которое проводил один преподаватель, вообще половина из этого непонятно. Какие-то элементарные настройки из кода знаю, а вот как работать с более интересными и сложными настройками пока непонятно. Буду искать еще обучения конечно. Правда нужно понять где искать…


#23

Ну в прямом смысле этого слова “рисовать” в Xcode не получится.
Если уже начинали проходить курсы на UIKit, то тогда продолжайте на UIKit.
Что касается Sketch’a, то врядли в компаниях разработчик будет заниматься созданием дизайна. Это две разные профессии.
Дизайнер создает UI в любой удобной среде, выкладывает в сервис, либо отдает скетчи разработчику, разработчик уже через сервис, либо через скетч смотрит все размеры, расстояния и прочее и на основе этого, создает экраны в Xcode.


#24

Проблемы в кастомизации и совместимости.
Например из очевидного - нельзя настроить экшен на свайп в списках, те добавить экшен кроме одного единственного удалить, изменить текст и экшн в удалить. Вариант с контекстным меню только. И это уже 1,5 года. Сложно сказать что тут: недоработка или намеренная попытка изменения пользовательского опыта. Мне больше кажется, что это унификация: тк у Эппл тренд идёт на универсальные приложения для всех платформ (телефон, часы, десктоп), то и свайпы выглядят чуждыми на часах и десктопе, например… ну или хз ))) Теоретически вы можете обычный UITableView накостылять через UIViewRepresentable и его кастомизировать как хотите, но какой тогда смысл в SwiftUI?

Совместимость.
Ещё пример как у Эппл не дружит их фреймворк ЮАй с их же фреймворками )))
CloudKit.
Решили вы сделать, например, шаринг записей из частной БД PrivateDataBase другому юзеру. Метод userDidAcceptCloudKitShareWith, срабатывающий при первоначальном принятии шары другим юзером, сначала находился в Appdelegate. Потом его перенесли в SceneDelegate. Теперь в цикле SwiftUI вы можете имплементировать Appdelegate через свойство @UIApplicationDelegateAdaptor, однако там этот метод не срабатывает… Вот и остаётся использовать UIKit life cycle, в SwifUI - ну глупость же.
Ну и много штатных контроллеров плохо дружат с UIViewRepresentable.

Если вы хороший дизайнер - так и развивайтесь в этом направлении. Зачем вам кодировка? ))

Если хочется учить код, то лучше начать с UIKit. Искать обучение не надо - вы на правильном сайте: здесь есть отличный курс (Приложения На Основе UITableView), который затрагивает почти все базовые знания Кита.


#25

Со стороны кажется, что лучше разрабатывать в ускоренном темпе на SwiftUI, а в затруднительных случаях использовать обертку над UIKit. По идее получается быстрее, чем всё разрабатывать на UIKit.


#26

Всё зависит от того, насколько вы знаете Кит или ЮАй. В любом случае вам необходимо знать Кит - вот с него и надо начинать. ЮАй на первый взгляд прост, что так и есть в плане вёрстки интерфейсов. Но очень много всяких но, которые вас могут вывести из себя ))). Я тоже думал: сейчас быстренько изучу ЮАй, делов то, максимум пару месяцев. Но в реальном кейсе это затянулось на полгода… ))) Естественно это не основная моя занятость.