Приложение на SwiftUI в AppStore – сложности разработки

[varton86]

А если сразу под iOS 14 писать? А там уже SwiftUI 2.0. По идее все, у кого iOS 13, быстро переходят на iOS 14, т.к. особого смысла оставаться на iOS 13 нет.

[VAnsimov]

Какой-то процент пользователей будет оставаться на iOS 13, но на iOS 14 SwiftUI показывает себя лучше.

[iFamily]

скорость разработки UI на SwiftUI в разы выше, чем UIKit

Если применять мою библиотеку UIKitPlus с LivePreview или даже без него разработка UI становится просто космически быстрой. Анимации действительно относительно легко реализовать на SwiftUI, но на UIKit ничто не мешает сделать аналогично и это скоро будет реализовано в UIKitPlus тоже.

[MFilonen2]

Может, я и не прав, не спорю, но мое мнение – SwiftUI не взлетит.

• UIKit разрабатывался очень гибким, пусть это и урезанная версия AppKit. SwiftUI не позволяет адекватно кастомизировать даже стандартные компоненты. Почему же на таком расчудесном фреймворке так сложно написать стандартные кнопки и текстовые поля?
• полтора года прошло, а он все еще в подвешенном состоянии. Все же за это время такая компания, как Apple, могла бы привести его в адекватное состояние, чего не происходит.
• есть сомнения в правильности концепции как таковой. Мне лично AutoLayout намного ближе и логичнее, чем некий урезанный аналог HTML/CSS. Да и UIKit сложный только для небольших проектов, чем проект сложнее, тем более оправдана комплексность этого фреймворка (и тем меньше она заметна на масштабе).
  Но, наверное, главный аргумент состоит в том, что Apple в принципе мало вкладывается в разработку инструментов для разработки. XCode как был глючным, так и остался, Swift как был приколочен гвоздями к экосистеме Apple и Objective-C рантайму, так в принципе и остался. Вряд ли что-то изменится, поскольку на данный момент Apple просто не собирается серьезно инвестировать в упрощение разработки…

[VAnsimov]

Мнение имеет право на жизнь. Помню, первое время, язык Swift был не в самом лучшем своем состоянии. Думаю, в будущем SwiftUI будет еще лучше.

[anti_smithhh]

всё еще "не взлетит"? или уже взлетел? как ситуация развивается?
а то из-за некоторых необновляемых девайсов на iOS10 возникает иногда желание вспомнить старый добрый UIKit.. правда, его я использовал только с ObjC по сути.

[MFilonen2]

Да с того времени мало что изменилось в принципе. Добавили ряд функций, но добавили-то только на iOS 15. На iOS 13 SwiftUI навсегда остался в 2019.
Прорыва в производительности превью тоже не наблюдается.

[classx]

Объект @StateObject можно инициализировать внутри init View

@StateObject var intent: HomeIntent
    
init(){
	let model = HomeModel()
	_intent = StateObject(wrappedValue: HomeIntent(model: model))
}

[VAnsimov]

Про такую запись не знал

_intent = StateObject(wrappedValue: HomeIntent(model: model))

Спасибо, будет полезно. От множественного вызова консруктора, к сожалению, не спасает, но делает работу чуть удобнее.

Поправил статью, убрал про это, чтобы не вводить людей в заблуждение.

[anti_smithhh]

можно и НУЖНО, если третий свифт использовать.

для объектов без "владения" нужно @ObservedObject.

Но это все для третьего Свифта. На ранних версиях (о которых тут речь) возможно это еще не было отшлифовано.

[HobbesT]

SwiftUI очень сырой инструмент, если «поиграться» и поделать анимации может сойдет. А в целом, учитывая не очень стабильную работу xcode, этот фреймворк только добавляет головной боли.

[classx]

в версии 2 это уже серьезный инструмент, делаю второй проект на нем и очень доволен

[AlexWoodblock]

И тем не менее, в таком серьезном инструменте до сих пор не хватает кучи вещей. Например, NSAttributedString все еще не поддерживается нормально, и есть два кривых выхода — либо UIViewRepresentable (что ведет к другим проблемам, например, невозможности нормально задать шрифт из SwiftUI кода, только через UIFont), либо же составлять единый View из нескольких Text, к которым применяются разные атрибуты.
Хотя бы не забыли завезти прокрутку до элемента в списке, уже спасибо…