Dog-paddling behind the bow wave

Those who make it their business to be on the leading edge of the rapid evolution of Swift are deep into figuring out what the latest developments are all about, and have begun sharing the fruits of their study and experimentation with the wider community, myself included.

What I've gleaned from the sliver of this growing abundance I've actually managed to take in is more about general impressions than about, for example, precise syntax. This is typical for me, and I believe it pegs me as a 'field-dependent' learner. (I tend to build a cognitive framework first and fill in the detail later, rather than working from detail to generalities.)

Immediately following WWDC, most of the attention went to SwiftUI — at least within the Apple ecosystem an altogether new approach to user interface design and construction, coming with an interactive Xcode component that does for UI much the same thing playgrounds have done for Swift code since Swift was first introduced, and enabling a degree of code-sharing among platforms previously only dreamt about.

As interesting as this is, the technologies making it possible are arguably even more so.

Combine continues to mystify me, somewhat, but I get that it's about data synchronization, so your UI and your data store remain in continuous agreement, for example, although the utility of combine goes far beyond UI synchronization.

Property Wrappers allow commonalities among the behaviors of various properties to be expressed once, and applied in any specific case as a single line of code.

Function Builders I've barely even got a sense for, but they seem to be about reducing repetitive code by generalizing function definitions to accept varying numbers and/or types of parameters, and/or to return tuples containing varying numbers and/or types of members. (Don't try spending this, it might prove to be counterfeit!)

While I have installed the betas of Catalina and Xcode 11, what coding I've had time for has mainly been in C (more precisely C code in .m files devoid of custom Obj-C classes), since I'm working toward building a new audio generator in C, which will live within an app otherwise written in Swift. I fully expect to get into SwiftUI and all that goes into it down the line, but I want to get that audio generator working first.