Alibaba Developer’s Initial Thoughts about SwiftUI

Apple this year threw at us a lot of surprises at WWDC 2019. To name a few of these surprises, the newly announced iPadOS will bring a new level of productivity and business to both users and developers alike. Next, given the new development architecture of SwiftUI, iOS projects can now be ported over to MacOS through some simple modifications — something you couldn’t ever do before. Last, they announced major hardware with the Mac Pro and Pro Display XDR for high-end professional workflows. However, among all of these announcements, for developers using Apple platforms, nothing is more important than the SwiftUI.

During some time ago, the UI development experience for front-end iOS developers wasn’t that great. The Frame layout system was primitive, and the Autolayout API was convoluted and difficult to use — making it super frustrating. There was no positive development experience to speak of at all.

Flutter, which rose to prominence last year, has brought a brand new experience to client-side development. Its declarative UI syntax and sub-second level real-time refresh have all improved development efficiency, but now all of these development workflows are implemented on SwiftUI. Think of it as framework with official native support.

As an avid Apple supporter, naturally, the first thing I do is to download the Beta immediately after it comes out. The Xcode11-beta can be installed on MacOS Mojave, but the Preview function can only be used on Mac OS Catalina. If you want a complete experience, it is best to upgrade your Mac.

Comparison with the Development Experience of Flutter



Aren’t they pretty similar? Well, they’ve got a similar declarative layout syntax, and Preview and Live Reload in debug mode. However, this time, we no longer need to rely on any third party anything, making for a much more intuitive experience.

Declarative Syntax

This is SwiftUI:

struct ContentView : View {
var body: some View {
VStack {
.frame(height: 300)

.offset(y: -130)
.padding(.bottom, -130)

VStack(alignment: .leading) {
Text("Turtle Rock")
HStack(alignment: .top) {
Text("Joshua Tree National Park")



And here’s Flutter:

Widget _listItemBuilder(BuildContext context, int index) {
return Container(
color: Colors.white,
margin: EdgeInsets.all(8.0),
child: Stack(
children: <Widget>[
children: <Widget>[
aspectRatio: 16/9,
child:[index].imageUrl, fit: BoxFit.cover),
SizedBox(height: 16.0),
style: Theme.of(context).textTheme.title
style: Theme.of(context).textTheme.subhead
SizedBox(height: 16.0),
child: Material(
color: Colors.transparent,
child: InkWell(
splashColor: Colors.white.withOpacity(0.3),
highlightColor: Colors.white.withOpacity(0.1),
onTap: () {
MaterialPageRoute(builder: (context) => PostShow(post: posts[index]))

See the difference? Looking at the details of the syntax, we can notice some features that are different. Flutter uses the typical declarative syntax. Developers declare the layout method of the UI, and all layouts are handed over to the engine. Dart uses commas (,) to separate different widgets at the code writing level, which causes parentheses (()) syntax nesting to be extremely complicated in a complex layout, and even more dazzling when matched with VSCode plug-ins.

Although Swift is also a declarative syntax, it can be noted that the view combination of Swift is not separated by commas (,) but by line breaks. Moreover, in Swift, function calls can be separated by line breaks. This DSL is more user-friendly for developers. It is presumed that SwiftUI uses features similar to tags for unified layout.

In this way, the code is clearly readable and the code length can be greatly shortened. This can be seen by the fact that Xcode finally supports miniMap. In the Objective-C era, the display does not have enough space to display MiniMap.

However, Xcode is not as good as Flutter in one respect — the code formatting function isn’t that great. But, I believe this can be compensated with plug-ins.

Live Reload

Moreover, in Xcode, you can not only change the real-time preview by code, but also generate code by editing the preview. This is amazing.

Imagine that in the later stage of service development, you can edit UI generated code directly without re-compiling, when you proofread the visual information with UED users.

Mix with UIKit

Obviously, Swift UI also takes this into account. Currently, in the official documents, SwiftUI can be easily mixed with the original UIKit system. This allows developers to access SwiftUI gradually.

Older iOS Versions

Ecosystem Imagination

I hope this picture eventually looks like this:

All images and screenshots are credited to Apple.

Original Source

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store