SwiftUI or Flutter ?

Foreword

I believe every person you meet SwiftUI developer, these doors will immediately ship a new UI framework and Flutter linked together. Yes, they who have too many similarities, similar declaration syntax, real-time updates heat, cross-platform (SwiftUI only cross-platform Apple) and so on, so the envy of the outbreak of the front-end technology mobile development circles also busy for a while . So SwiftUI and Flutter in the end what is similar and different? They are also what advantages and disadvantages? And, finally, solely on the technical direction, who is the winner in the future cross-platform program it?

Language

Modern computer languages tend to become more similar is an indisputable fact, because the basic objectives of each language are quite consistent: simple, flexible, secure, high-performance. At the same time, excellent properties in various languages is also learn from each other, reducing the gap between one step closer to the respective languages.

Swift and Dart, respectively, as the only official language of these two UI framework, the difference in the level of grammar is actually very small, there are plenty of articles online to compare the advantages and disadvantages of these two languages. My experience and most people like, for now, Swift and Dart advantages and disadvantages.

Swift is more concise than the Dart. Swift itself in the syntax level has been much simpler than the Dart, such as the end of the sentence without adding ;semicolons. This is in direct written SwiftUI and Flutter will become particularly evident. But the problem is not all problems caused by language level, but also with design both UI frameworks related.

ForEach(userData.landmarks) { landmark in
	NavigationButton( destination: LandmarkDetail(landmark: landmark)) {
    LandmarkRow(landmark: landmark)
  }
}
复制代码

SliverList(
  delegate: SliverChildBuilderDelegate(
    (context, index) {
      final landmark = landmarks[index];
      return LandmarkCell(
        landmark: landmark,
        onTap: () {
          Navigator.push(
            context,
            CupertinoPageRoute(
              builder: (context) => LandmarkDetail(
                landmark: landmark,
              ),
            ),
          );
        },
      );
    },
    childCount: landmarks.length,
  ),
),
复制代码

Both have achieved a clickable list page are called a custom Cell.

Swift is more stringent than the Dart, that sense will be more secure, of course, safety or rely on this kind of thing Tracing the bottom tearing people.
Swift released in the first five years and have not even await / async, although the proposal but has not been implemented already down. But here there is no available selection Dart. Both can only say that is not enough to absorb each other.
Dart Black Technology: supports both AOT and JIT, which also gives the thermal overload characteristic Flutter Web level, is Flutter duel SwiftUI powerful weapon.
Swift and Dart are open source languages. Apple is open to Swift unprecedented, now Swift may have run out of macOS, there has also been in the community, such as the back-end framework for Vapora series of interesting things, etc., it is to become Tensorflowone of the official languages. All this greatly expands the Swift usage scenarios. However, Dart on playability obviously go faster than the Swift. With its back-end framework developed by a number of companies have been put into the production environment, Google Web framework AngularDart(non-Flutter Web) have long been stable operation for a long time on some services. With Flutter traveled to mention iOS Android macOS Windows Web, just to be the arrogance to describe.

A language of design is good or bad does affect the popularity of a framework, I have heard countless Flutter developers nesting problem Tucao Dark endless. Although higher replayability Dark, but in terms of a single UI framework, I personally think that the use of Swift feeling much better than Dart.

grammar

SwiftUI and Flutter without exception use declarative syntax to describe their DSL UI, its advantage is that you can see at a glance the actual structure of the UI from the structure of the code, and to avoid repetitive logic code. SwiftUI binding data and state management replace the original complex control logic, so that the DSL and the UI hierarchy codes and highly consistent in structure.

VStack {
    MapView()
        .edgesIgnoringSafeArea(.top)
        .frame(height: 300)

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

    VStack(alignment: .leading) {
        Text("Turtle Rock")
            .font(.title)
        HStack(alignment: .top) {
            Text("Joshua Tree National Park")
                .font(.subheadline)
            Spacer()
            Text("California")
                .font(.subheadline)
        }
    }
    .padding()

    Spacer()
}
复制代码

The above is a SwiftUI Demo LandMark appear on WWDC. Even if you have not learned SwiftUI grammar, reading a little about the code above, you can find it in the UI and the picture is one to one. This is the advantage of declarative syntax. But at the time of writing specific code, Flutter and Swift feel a big change, most notably: Flutter than SwiftUI complicated too much. How to write the code to achieve the above results with Flutter it? I have not come to more than paste method, or else my article would be half Dart code. But here there is a man modeled on the Demo wrote a version of Flutter LandMarks , you can refer to.

Why is declarative syntax, Fluter complex than SwiftUI so much of it. In fact, this reflects the different ideas Apple and Google in the design of both UI framework, and even representatives of the different cultures of the two companies. IOS and Android have some understanding for the developers know, a lot easier than iOS developers, Android developers. Alone configuration of development environments, iOS will be earlier than Android 1 it began to write code. I can not say more complex framework, platform compatibility confusion, jerky and difficult documents.

Apple treats developers like in dealing with novice alike, doing all it can to simplify the development process, reduce the workload of the development, and even allow developers to become an elegant thing, which from the appearance design features of Xcode Swift API and then to the system language is so. And Google in the treatment of developers, is treated more like a geek, as will a lot of work and creation to the developer and let them freedom to create interesting things. But correspondingly, its threshold is too high, and bring freedom fragmentation and uncontrollable can lead to reduced development efficiency.

When designing SwiftUI the API, Apple hides a lot of internal details, so developers will be able to call as little code as to achieve the appropriate effect. Developers do not need to rewrite initialization method does not require the use return, do not need to be concerned about contextcontext, it should be no need to worry about a StatefulWidgetstill StatelessWidgetmore need not be concerned with is the Material Design or iOS Style. Apple will do to help you do a good job in-house, you need to do is tell the compiler that you need to control what they are what they should be in any place, nothing more. If Flutter brings mobile development to the declarative syntax to let everyone shines, then SwiftUI emergence is to tell everyone (including Flutter), what is the real declarative syntax.

Live Update

SwiftUI most heavy feature is the long-awaited heat load, which is updated in real time. Web development efficiency ultra-high end mobile terminal has been coveted skills, RN appeared to all mobile developers for the first time to see such a possibility, although it now also has its own problems. Flutter as an extension of Web technology, inherited a large number of Web technology, thermal load also seems to be a Shoudaoqinlai skills. The SwiftUI in order to achieve real-time refresh Web approximate as difficult to face much more complex. From my practical experience down, but also fully illustrates this point.

SwiftUI live preview preview divided into static and dynamic preview. The default is to display a static preview, it's fast, and supporting code and visualization are written in both ways. But it does not have any response to events, not scroll and jump page. If you need dynamic debugging, you need to switch to dynamic preview. The dynamic preview take some time to compile, then in the form of a fully dynamic, real-time response to changes in the UI, and real-time debugging at the real machine. But dynamic preview of restrictions still more, can not do the kind of Flutter compiled only once, after the entire App can achieve dynamic update.

Why static and dynamic preview preview it? I believe that if not for consideration a number of issues (performance issues, Bug difficult to deal with), Apple is categorically not to complicate the issue. I can only say that the current version of the thermal load is disabled Apple will give us the best results. Precisely because the current SwiftUI so-called real-time refresh, from the Web and Flutter, or pediatrics. Static UI debugging in fact, can be achieved by StoryBoard, while the real practical dynamic preview there are some limitations. But SwiftUI still in the testing phase, being unable to make a final conclusion on its performance.

performance

Google claims Flutter One of the goals is smooth (60Hz), the present situation, it does in most of the scenes did. However, according to my tests (this fashion in beta), such as page transitions, animation controls this scene, went to 60 Hz or a certain pressure. I have been concerned about Flutter project, we are also internal attempts to rewrite part of the module using the Flutter. But what I experience so far down, the current Flutter, can only say that it is close to the fluency of a native platform. But even Flutter can reach fluency of a native system, it still can not avoid the issue of performance loss. iOS native UI framework (including SwiftUI) are built on top of Metal, Metal GPU for use efficiency is much higher than OpenGL. It brings the results in my tests also show the same page rendering and animation, Flutter for CPU and GPU utilization is higher than iOS native UI framework. The consumption of high-performance, high fever means that the equipment and low life. This is particularly serious on mobile devices.

In contrast SwiftIU, Apple seems to copy all the original control system, in principle, there will be change in performance, but your eyes do not be fooled, Apple in your sight, under a big chess.

The above two pictures are SwiftUI and iOS native rendering Label, all running in the iOS platform, all look exactly the same, but behind them are two completely different things. We found that, SwiftUI text is not the native iOS controls the system, but a new type, called Text. It is actually a new control inherits from UIView, full name is DisplayList.ViewUpdater.Platform.CGDrawingView. Observation Properties window on the right, found two controls have completely different properties. UILabelIt has a complex property that control the style, interaction and so on. And Textwill have a much more streamlined.

There are rumors that, SwiftUI the portion of the control system has been abandoned native UI framework in favor of a more direct use of the underlying, but also in Apple ecosystem is more common Core Animation, Core Graphics, Core Text rendering. Whether direct use of the underlying framework for efficient rendering I was not yet conceivable, but it is certain that, Apple will SwiftUI are stripped out of the original UI framework, lost a heavy historical burden. This is bound to bring many benefits, such as a higher degree of freedom, better performance, and the true meaning of: cross-platform.

Cross-platform?

Many people will say, SwiftUI and Flutter simply can not compare with, SwiftUI not a true cross-platform. Yes, SwiftUI currently cross only Apple's own ecosystem, including iOS (iPadOS) macOS watchOS tvOS, while next door Flutter already tired of the mobile side, Windows macOS and began marching to the Web. However, you undeniable, SwiftUI really did achieve a Write once, use anywhere on a completely different system platforms. Moreover, hidden behind this idea is also completely different.

SwiftUI fundamentally not build UI, but in the description of UI. Both what is the difference? When building UI, you will clear every type of control, or even accurate to the platform. For example, in the native UI framework, you need an input box, you have different platforms, selection of a particular use UITextFiled (iOS) or NSTextFiled (macOS), two input boxes which have different properties, according to the appearance and characteristics. In Flutter, you do not need to consider the type of control for different platforms, but you need to consider the style controls, the official Android and iOS Style controls of iOS controls in line with Material Design, and many of their characteristics are not consistent, all this to build UI bring a more complex logic and workload.

The SwiftUI more like a Web template, only describes UI, and specific controls look like, what features will be realized in accordance with local conditions compiled platform, and is automatic. It's like to put up a Web template, a theme.

Code left describes a form which contains some simple controls, including Picker, Toggle, Stepper, Button. If we put the code intact macOS project, it will become like this below.

You will find that the same code, showing out of the UI is completely different, but the content UI expression does exactly the same. Even more fine thinking very fear it is that Pickerthis "single list to select" control on iOS has been translated into a selection page, click on the cell will push all the selectable options, click on the option to return to the previous page and select to show the contents of the corresponding cell. In the macOS, Pickerit will be translated into common drop-down list on our desktop operating system. This transformation is incredible, I can only use Wow, Awesome, Amazing to describe it. Because it is fully consistent platform design language and user habits, while greatly reducing the development and adaptation of difficulty. However SwiftUI can do far more than that.

Yes, not just iOS and macOS, on tvOS and watchOS, SwiftUI also will be the best way to interact with the platform design language and conform to show each control. Also, you will automatically get a large number of system features such as Dynamic Type, Dark Model, adaptive reading direction and so on.

From this point of view, SwiftUI and React Native has a more similar ideas and technologies. But both the iOS and Android Facebook have almost no right to speak, and therefore have some questions on compatibility, consistency. In order to achieve this compatibility, not only React Native itself needs to do a lot of work, developers are struggling to cope with various problems need to be said to be a rather awkward intermediate technology.

The cross-platform UI and React Native SwiftUI and Flutter ideas are essentially different. Flutter completely abandoned the native operating platform UI framework, similar to the canvas on a pixel by pixel "draw" out each control, similar to a 2D game engine. Its purpose is very clear: to ensure that the same code shows the exact same UI under different operating systems, hardware equipment, screen size. This seems to be a developer wants, because we had enough uncontrollable differences RN exhibited on different platforms. But even blows differences in operating system design language, UI for different screen size should be at least very different. Desktop and mobile platform UI UI, UI even on the watch, should be based on the user's habits and controlled way to develop a completely different UI and interaction. If you want to achieve multi-platform adaptation on Flutter, the results of any programmers are likely to be a nightmare. You need to do a lot of judgment, and may need to use a variety of controls to implement a single function, and ultimately have to face a lot of testing and Bug.

However, beneficial to have disadvantages. SwiftUI near-perfect cross-platform program is built on a lower degree of freedom. By the example above you have discovered, Demo control style used in the system are native. That does not mean we can not be customized, but:

We can customize items are not enough
The more our custom content, the more the characteristics of our system automatically add the missing

For example, we want to change the background color of the list, then we will lose part of the system automatically Dark Model features we add, you need to do some extra work to tell App in black / white mode should show what the background color.

But fortunately Apple has begun to try the system out of the original UI framework, but let us be more convenient to customize part of UI. In the past we want to achieve the following Button's style, the need for a large number of parameters UIButton adjustment, because the default UIButton text on the left, the picture on the right. Today, SwiftUI out of the system set up after the UI framework, we can achieve complex UI style by a very simple code.

But this proud and Flutter "accurate to pixel" there is a gap, that we may not have complete control over all the details of UI controls like Flutter. But like painting, like, you lose a certain amount of freedom in exchange for faster and more efficient development, this is precisely reflects Apple's corporate style.

However, cross-platform story SwiftUI finished yet? I think this is precisely just the beginning. SwiftUI nothing to do with this platform, equipment, UI framework purely descriptive, it is precisely in the right direction is the cross-platform solutions. SwiftUI can be used to describe iOS macOS tvOS even watchOS the UI, why it can not be used to describe Android, or Web? SwiftUI already have Flex layout, combine data binding, thermal load and a series of features, we need only shining on this idea, the Android or Web templates apply on SwiftUI, we will be able to get in line with the same language and platform design specifications UI . Of course, I say this is far from simple, but do not forget, Swift is open source, cross-platform is not a problem. As long as conditions exist, everything is possible to achieve.

By then, however, Flutter turn into what look like? At least for now, Flutter or will become one of the most important cross-platform solutions company, SwiftUI Well, large-scale use something slightly or at least 2 to 3 years after.

Reproduced in: https: //juejin.im/post/5d05b45bf265da1bcc193ff4