Comments 13
А если сразу под iOS 14 писать? А там уже SwiftUI 2.0. По идее все, у кого iOS 13, быстро переходят на iOS 14, т.к. особого смысла оставаться на iOS 13 нет.
0
скорость разработки UI на SwiftUI в разы выше, чем UIKit
Если применять мою библиотеку UIKitPlus с LivePreview или даже без него разработка UI становится просто космически быстрой. Анимации действительно относительно легко реализовать на SwiftUI, но на UIKit ничто не мешает сделать аналогично и это скоро будет реализовано в UIKitPlus тоже.
-1
Может, я и не прав, не спорю, но мое мнение – SwiftUI не взлетит.
- UIKit разрабатывался очень гибким, пусть это и урезанная версия AppKit. SwiftUI не позволяет адекватно кастомизировать даже стандартные компоненты. Почему же на таком расчудесном фреймворке так сложно написать стандартные кнопки и текстовые поля?
- полтора года прошло, а он все еще в подвешенном состоянии. Все же за это время такая компания, как Apple, могла бы привести его в адекватное состояние, чего не происходит.
- есть сомнения в правильности концепции как таковой. Мне лично AutoLayout намного ближе и логичнее, чем некий урезанный аналог HTML/CSS. Да и UIKit сложный только для небольших проектов, чем проект сложнее, тем более оправдана комплексность этого фреймворка (и тем меньше она заметна на масштабе).
Но, наверное, главный аргумент состоит в том, что Apple в принципе мало вкладывается в разработку инструментов для разработки. XCode как был глючным, так и остался, Swift как был приколочен гвоздями к экосистеме Apple и Objective-C рантайму, так в принципе и остался. Вряд ли что-то изменится, поскольку на данный момент Apple просто не собирается серьезно инвестировать в упрощение разработки…
+3
Мнение имеет право на жизнь. Помню, первое время, язык Swift был не в самом лучшем своем состоянии. Думаю, в будущем SwiftUI будет еще лучше.
0
всё еще "не взлетит"? или уже взлетел? как ситуация развивается?
а то из-за некоторых необновляемых девайсов на iOS10 возникает иногда желание вспомнить старый добрый UIKit.. правда, его я использовал только с ObjC по сути.
0
Объект @StateObject можно инициализировать внутри init View
@StateObject var intent: HomeIntent
init(){
let model = HomeModel()
_intent = StateObject(wrappedValue: HomeIntent(model: model))
}
0
Про такую запись не знал
Спасибо, будет полезно. От множественного вызова консруктора, к сожалению, не спасает, но делает работу чуть удобнее.
Поправил статью, убрал про это, чтобы не вводить людей в заблуждение.
_intent = StateObject(wrappedValue: HomeIntent(model: model))
Спасибо, будет полезно. От множественного вызова консруктора, к сожалению, не спасает, но делает работу чуть удобнее.
Поправил статью, убрал про это, чтобы не вводить людей в заблуждение.
0
можно и НУЖНО, если третий свифт использовать.
для объектов без "владения" нужно @ObservedObject.
Но это все для третьего Свифта. На ранних версиях (о которых тут речь) возможно это еще не было отшлифовано.
0
SwiftUI очень сырой инструмент, если «поиграться» и поделать анимации может сойдет. А в целом, учитывая не очень стабильную работу xcode, этот фреймворк только добавляет головной боли.
0
в версии 2 это уже серьезный инструмент, делаю второй проект на нем и очень доволен
+1
И тем не менее, в таком серьезном инструменте до сих пор не хватает кучи вещей. Например, NSAttributedString все еще не поддерживается нормально, и есть два кривых выхода — либо UIViewRepresentable (что ведет к другим проблемам, например, невозможности нормально задать шрифт из SwiftUI кода, только через UIFont), либо же составлять единый View из нескольких Text, к которым применяются разные атрибуты.
Хотя бы не забыли завезти прокрутку до элемента в списке, уже спасибо…
Хотя бы не забыли завезти прокрутку до элемента в списке, уже спасибо…
0
Sign up to leave a comment.
Приложение на SwiftUI в AppStore – сложности разработки