SwiftUI slowly adoption

“The best way to build an app is with Swift and SwiftUl.”

But…

Most companies can’t move development to iOS 14/15 and again with iOS 16 we have to wait another year for some basic features:

  • Allow (or block) device orientations (portrait / landscape) by View
  • Pull-down to refresh for ScrollView
  • Custom controls for VideoView
  • MapView custom view for user location, map configurations and other options
  • UICalendarView
  • More ScrollView features (events, zoom, offset control, …)

Many of these features can be implemented ASAP. How complicate is to implement map configurations? How many years we have to wait?

Developers needs more from your team. Thank you!

Replies

what I do is write the apps in swiftui then its pretty easy to bridge to UIKit for a particular view or part of it to get all of the functionality u have listed. I believe there is a WWDC session on this specifically. SwiftUI and UIKit generally plays together pretty well. Tbh its way easier and faster to do it that way than write everything in UIKit.

some of what you have listed have been implemented in native swiftui already. eg pull down to refresh - have a look at the "what's new in swiftui" from the past few years wwdc's. I believe its called .refreshable

MapKit has been recently brought into swiftui. not sure about the specific functionality you need but I recently converted my UIKit maps components into the native swiftui version.

For the custom controls on a Video view, I overlayed some custom swiftui controls over the top of a bridged AVKit video player using a ZStack.

it'll be another decade before everything is in swiftui, if ever. they still haven't got everything in objective c implemented for swift (try catching a core data fetch thrown exception in swift) and there are still a few obscure functionality that u still need to fall back to C for. So it'll pay to learn how to bridge the UIKit controls into swiftui so u can move to swiftui more seamlessly.

  • Yes, pull-down to refresh is available but only for List, in real world we use ScrollView with lazy stacks and grids.

Add a Comment

How many years we have to wait to change TextEditor background?

SwiftUI has a lot of merits. But drawing UI in a graphic editor and then connect to the code is really a must. So maybe what we need is to have a preview that is a full storyboard editor and which generates the SwiftUI code, so we can work in code or in storyboard.

I also appreciate a lot the concept of segue, more than NavigationLinks… But that's a personal preference.

How many years we have to wait to:

  • Change TextField placeholder color?
  • Custom TextFieldStyle (and include isFocused: Bool)?

What they actually said during the talk was this:

... if you're new to our platforms or if you're starting a brand-new app, the best way to build an app is with Swift and SwiftUI.

Features can be added to existing apps, and Apple is trying to slowly incorporate SwiftUI into UIKit (and other platform-equivalent frameworks), but the orignial statement is aimed at people starting with Swift and learning to build apps with SwiftUI. Companies with apps can still use UIKit (and similar) and incrementally adopt SwiftUI, but don't have to restructure everything, yet.

  • The problem is that we still need UIKit for some cases and sometimes not use some SwiftUI feature at all. Some things can easily be done today asap.

Add a Comment

How many years we have to wait to config (without using UIKit) NavigationBar / TabBar standard, scrollEdge and compact appearance?