Building the SwiftUI Sample App in Flutter

Building the SwiftUI Sample App in Flutter

Very Good Ventures re-built the SwiftUI sample app to do a side-by-side comparison of SwiftUI and Flutter, and found there’s a lot to love about both.

Kevin Gray (Principal Engineer), Martin Rybak (Engineering Director), and Albert Lardizabal (Principal Engineer) contributed to the writing of this article and the development of the Flutter Landmarks project. Read more of their content on the Very Good Ventures blog.

How Does SwiftUI Compare to Flutter?

When Apple announced SwiftUI at WWDC 2019, the team at Very Good Ventures got really excited as did many other mobile developers. We’ve been building iOS and Android apps for a long time, and for the last two years we’ve been building declarative UIs with Flutter. We wanted to learn more about Apple’s approach to building a declarative and composable layout system.

So, we enthusiastically downloaded the Xcode 11 beta app and started exploring SwiftUI. Apple provided an excellent example project, Landmarks, with a step-by-step tutorial to learn how to get up and running with SwiftUI.

Since the declarative nature of SwiftUI has similarities with Flutter and we have a lot of experience with Flutter, we wanted to know: “How does SwiftUI compare to Flutter?”

We decided it would be a fun challenge and a fruitful educational exercise to recreate the Landmarks app in Flutter. Then, we could compare the resulting codebases and identify similarities and differences between the two.

Landmarks Flutter

Our team dove in and attempted to faithfully reproduce the Landmarks app using Flutter. We’ve made the git repo publicly available so that anyone can download the code and see how it compares.

Check out our version of SwiftUI’s Landmarks project built in Flutter on GitHub!

Prepping Assets

Prepping the Flutter app to use the assets in Apple’s example project was quick to set up. Simply copy the Resources folder over to the assets folder and make the folder known in the pubspec.yaml, and we now have access to all of the data that the iOS project has!

    - assets/

The User Interface


Stacks in SwiftUI are comparable to Flex widgets in that they display their children in one-dimensional arrays. So a VStack is similar to a Column, an HStack is similar to a Row, and a ZStack lays out its children one on top of the other, which (surprise!) is the kind of Stack Flutter developers are familiar with. Composing views with HStack s and VStacks in SwiftUI feels very familiar to a Flutter developer.

The code in SwiftUI feels a bit lighter owing to the lack of return statements and child or children params everywhere. The naming of the SwiftUI Stack widgets will take some time to get used to since Flutter’s Row, Column, and Stack widgets seem to be more intuitively named.


Table views in UIKit are now Lists in SwiftUI. Wrap children objects in a List and you’re all set. This is a welcome improvement over implementing a number of delegate methods to set up a table view on iOS.

On the Flutter side, you have your choice of several options. You can use a ListView for displaying multiple children or a SingleChildScrollView if you have only one child to display. For our example in Flutter, we used a CustomScrollView and slivers in order to recreate the same animations with the navigation bar you get in the SwiftUI Landmarks example.

SwiftUI uses a ForEach command to generate List children on demand. We opted to use a SliverList and a SliverChildBuilderDelegate to leverage the builder callback to dynamically generate our LandmarkCell widgets. Slivers are optimized to lazily load their children and are Viewport-aware, so that child views aren’t built until they are displayed.


ForEach(userData.landmarks) { landmark in
    if !self.userData.showFavoritesOnly || landmark.isFavorite {
        destination: LandmarkDetail(landmark: landmark)) {
            LandmarkRow(landmark: landmark)


  delegate: SliverChildBuilderDelegate(
    (context, index) {
      final landmark = landmarks[index];
      return LandmarkCell(
        landmark: landmark,
        onTap: () {
              builder: (context) => LandmarkDetail(
                landmark: landmark,
    childCount: landmarks.length,

Loading and Parsing Data


Loading our raw data from assets is similar in Dart and Swift. We have some data we know is JSON, and we want to create some models from it.


let file = Bundle.main.url(forResource: filename, withExtension: nil)
data = try Data(contentsOf: file)


final fileString = await rootBundle.loadString(‘assets/$filename’);


Parsing our data into a list of Landmark objects is where the path diverges a bit. Flutter does not currently support reflection, so we are unable to parse JSON in the same way that Swift does it. Let’s take a look at the definition of the load function in Swift:

func load(_ filename: String, as type: T.Type = T.self) -> T

and with this, Swift is able to generate the data model with this simple call and no manual data parsing:

**let** landmarkData: [Landmark] = load(“landmarkData.json”)

The reason it can do this is because in Swift, Landmark is a Codable and therefore a Decodable. So by some underlying magic the type T can be instantiated and decoded.

As stated, this just isn’t currently possible in Flutter. Try to instantiate an object just by its type and you’ll find it quite impossible yourself! So, we need to manually parse this data. Our load function in the Flutter app is defined:

Future load(String filename, T Function(dynamic) builder) async

What this does is the generic function of loading the data, but leaves the building of the data up to the caller of the function. So we load the landmarkData in the following way:

Future loadData() async {
  _landmarkData = await _load('landmarkData.json', (data) =>   List.unmodifiable((data).map((element) =>         Landmark.fromJSON(element))));

The fromJSON function of Landmark is a factory constructor that does exactly what you expect, constructs a Landmark from a Map. We opted to manually parse this small amount of data, but there are options for code generation if you’re interested.


For most of our development in Flutter, we use Material widgets. But since we wanted to create a real apples-to-apples comparison, we decided use a Cupertino theme.

Navigation controllers in UIKit have been replaced with a NavigationView. In Flutter, we used a CupertinoPageScaffold with a CustomScrollView child. To get the expanding/collapsing animation of the navigation bar, such as in the SwiftUI example, a CupertinoSliverNavigationBar was perfect. When expanded, the widget passed into the largeTitle property of the CupertinoSliverNavigationBar is displayed. When you scroll down and the navigation bar collapses, a smaller version of the title is displayed in the middle of the collapsed navigation bar.

We’ve become accustomed to using callbacks on the children of a ListView to communicate data back to the parent widget when the user taps a cell. SwiftUI’s approach of wrapping List children in NavigationButtons to control the presentation of the next route is an interesting approach that we’ll have to explore in future posts.



For architecture, we attempted to mimic the same flow of data seen in the iOS app. The iOS app used some nifty Swift features so that the UI of the application updates in response to changes in the data. For example, when you dive into a Landmark detail and favorite it, the app just updates the isFavorite boolean of the Landmark like this:


and the star turns yellow in response. There is no explicit changing of this color, it just updates when the model updates. There is a similar flow of data for the favorites toggle on the Landmark list screen.

So how does this work on the iOS side? The answer is in the UserData object which is a BindableObject. A BindableObject is defined by Apple as:

A type of object that notifies the framework when changed.

So, the two bits of data we use to update UI (showFavoritesOnly and landmarkData ) will notify the framework when they change. The views that wish to be notified, LandmarkDetail for example, add…

@EnvironmentObject **var** userData: UserData

…to the declaration the view. The usage of @EnvironmentObject is defined as:

A linked View property that reads a `BindableObject` supplied by an ancestor view that will automatically invalidate its view when the object changes.

So, whenever one of those two pieces of data are updated, the views that listen to them will be invalidated and rebuild.


We were able to get a similar flow in the Flutter app. We simply set the Landmark model’s isFavorite value:


and the UI updates in response. We achieved this by having the Landmarkmodel extend the ChangeNotifier class. We added the following function to the class:

void setFavorite(bool value) {
  isFavorite = value;

and now anyone who cares to listen to changes in the model can do so. Here’s an example from our LandmarkDetail widget. Did you know that AnimatedBuilder can listen to a ChangeNotifier?

  animation: landmark,
  builder: (context, widget) {
    return StarButton(
      isFavorite: landmark.isFavorite,
      onTap: (value) {

For toggling the favorites list, we simply have a boolean on the StatefulWidget that builds the list, and when the toggle occurs we call setState.

You may notice a subtle difference in this flow, which is that in the iOS app, the view will be notified whenever the landmarkData list is updated, including any of the data of its children. We only listen to changes in a single Landmarkobject. Due to how Flutter builds, the favorites list will still update when we pop back to the list from a detail which works perfectly for our needs.

It is certainly possible to create an architecture where we listen to changes in any child of the list, and it depends on the size and efficiency of your data. For exampleListenable.merge(landmarkData) with ListenableBuilder would work here, but you can imagine this could get inefficient with a huge list of data.

Future Improvements to the Flutter version

You may notice that a few things are missing from our Flutter implementation.

First, the separator line between empty cells on the main screen’s SliverList is missing. This is the default behavior in a native iOS implementation (and is not often desired).

Second, you’ll see that when toggling the favorites switch, the table cells don’t animate in and out as they do in a standard iOS table view. We are working on implementing this functionality on a separate branch. We are using the AnimatedListwidget and got the animations pretty close but not perfect.

One challenge is that AnimatedList is not a SliverList and can’t be used inside a CustomScrollView. It must be wrapped inside a SliverToBoxAdapter. A SliverList is more efficient because it instantiates only child widgets that are actually visible through the scroll view’s viewport. This is not an issue for small lists as in this example, but could introduce a performance problem for much larger ones. We have reached out to the Flutter team for some guidance on these issues.

Do you have any ideas for improvements on making the code cleaner or simpler? Please file a pull request!

Early Takeaways From Our Comparison

Code Complexity

At first glance, it appears as if the Flutter version has a bit more lines of code and complexity. That’s the elephant in the room, so let’s explore why that is. It’s important to recognize that Apple has fine-tuned SwiftUI for working exclusively within Apple’s design system. That is, elements like the navigation bar and table animations appear trivial to implement because they are magically implemented behind the scenes. But if you want to tweak or modify this behavior, there is not much you can do.

In contrast, nothing in Flutter, including the fancy navigation bar, is implemented in a black box. Everything is explicit, composable, and modifiable. So in this example, special-looking things (such as fancy scrolling effects) have special-looking code (slivers). Flutter has a Cupertino theming library that makes it easier to build iOS-style experiences, but that’s not its mainstay. Flutter excels at empowering custom UI experiences that let your unique brand shine through, on multiple platforms. That said, where there is room for improvement to make iOS-only development easier, let the Flutter team know! We’ve already pointed out a few issues above.

Declarative UI FTW

Ultimately, we’re excited that Apple is moving towards the declarative programming paradigm. We think SwiftUI affirms what React Native and Flutter have already embraced.

Combined with Swift’s concise syntax, SwiftUI feels very modern to work with, compared to the often unwieldy layout constraint code that usually comprised half of the code in a class on iOS.

On the other hand, we were able to rebuild the SwiftUI Landmarks with Flutter in a really short amount of time. That’s an endorsement of Flutter, but also of the overall trend towards declarative UI—which of course now includes SwiftUI!

SwiftUI is just getting started

It’s important to note that SwiftUI is very new — it probably wont be ready for wide-scale production for some time (it is only an early beta after all). Flutter, on the other hand has been in the wild for a couple of years and officially out of beta since December 2018.

There are a few things in SwiftUI that are particularly promising. For instance, the designer is pretty cool, PreviewProviders that let you pin views with data is useful, and built-in support for things like accessibility, dark mode, and RTL are impressive. SwiftUI’s new ability to “hot reload” is something that Flutter developers have been enjoying for a while, and while it’s not quite the same, it’ll certainly make a lot of iOS developers happier.

It’s going to a take some time for SwiftUI to really get into the mainstream, but it’ll be fun to see how it evolves. At the end of the day, we anticipate it’ll lead to more high quality apps as developer productivity increases. It’ll also be fun to observe how Flutter and React Native evolve in parallel.

Design Guidelines (or are they rules?)

It’s an obvious statement to say that SwiftUI is for creating apps for Apple’s platforms. At the moment, SwiftUI really isn’t great if you want to create an app that doesn’t look and feel like an Apple app. There’s nothing really wrong with that, but it may be limiting from a design perspective.

This is in contrast to Flutter’s design goals — Flutter has always been about creating unique branded app experiences, not necessarily something wholly conforming to the design guidelines of a specific platform. So, as of this moment, Flutter is more flexible for creating a unique and custom UI experience compared to SwiftUI.

This is a huge topic with many camps and opinions. For now, it’ll suffice to say that it will be interesting to watch and see what kind of support SwiftUI provides in the long run for fully custom app designs.


One obvious area where SwiftUI has some early drawbacks is its portability. Currently, Apple’s documentation clearly states that SwiftUI will only work with iOS13.0+ beta, macOS10.15+ beta, tvOS 13.0+ beta, and watchOS 6.0+.

Flutter, on the other hand, will run on multiple platforms (iOS, Android, macOS, Windows, ChromeOS, Raspberry Pi, and Web), and is compatible with the long tail of iOS and Android devices running a variety of older OS versions. In fact, we were able to get the Flutter version running on Android with a trivial amount of extra work.

Again, it’s very early for SwiftUI, so we’ll have to see what kind of backwards compatibility and platform portability they’ll be able to achieve in the future. Who knows…perhaps one day we’ll be able to run SwiftUI on other platforms. (We can dream, can’t we?)

The Future is Composable

In the end, SwiftUI indicates a huge step forward for app developers. We’re excited to see how it develops, and watch as Apple and Google continue to create better tools for developers to create incredible apps.

Our team at Very Good Ventures is going to continue to explore SwiftUI (and Flutter too!). We’d love to hear from you what you think we should dig into next.

  • A comparison of app performance?
  • Side-by-side “hot reload” comparison?
  • A deep dive on the different tools for SwiftUI and Flutter?

Let us know what we should research next in the comments!

Tell us in the comments what we should dig into next in our comparison of SwiftUI and Flutter.

Thanks for reading!

Create a Post Reader App with Flutter

The Complete Flutter Development Bootcamp with Dart

Dart and Flutter: The Complete Developer's Guide

Learn Flutter & Dart to Build iOS & Android Apps

Flutter & Dart: A Complete Showcase Mobile App™

Flutter Grocery Shopping Mobile App

Flutter Grocery Shopping Mobile App

This Flutter grocery app is a pro version that has all features of online grocery purchase for your customers.

Are you looking to launch your online grocery shop or any E-Commerce mobile app then this flutter grocery app will help you to build the app in just days? We offer an online grocery software system. The mobile application offers amazing features to build a powerful online ordering system or app for your grocery shop. It enhances online home grocery stuffs ordering experience for your customers with your mobile grocery app. This Flutter grocery app is a fully functional mobile app that has all features of online grocery purchase for your customers. So what are you waiting for? Start your online business with your Mobile app today!

YOu check live demo and feature video at:

Flutter App Development Company | Hire Flutter App Developers

When it comes to Hybrid Mobile App Development Framework, Flutter is gaining the momentum. And, we as top development company don't hesitate to say that it is going to be future cross-platform mobile app development. Though there are few other frameworks available for cross-platform and hybrid mobile app development, Flutter is an increasing trend. In fact, intellectuals are comparing Flutter vs. React Native vs. Ionic and finding the best solutions out of them. Some of the top companies have already adapted Flutter, and they are very positive about it.

When it comes to Hybrid Mobile App Development Framework, Flutter is gaining the momentum. And, we as top development company don't hesitate to say that it is going to be future cross-platform mobile app development. Though there are few other frameworks available for cross-platform and hybrid mobile app development, Flutter is an increasing trend. In fact, intellectuals are comparing Flutter vs. React Native vs. Ionic and finding the best solutions out of them. Some of the top companies have already adapted Flutter, and they are very positive about it.

Flutter is the future of mobile app development 👏👏👏

Flutter is the future of mobile app development 👏👏👏

Flutter is a new mobile app SDK to help developers and designers build modern mobile apps for iOS and Android.” The modern, reactive ...🎁🎁🎁🎁

Flutter is a new mobile app SDK to help developers and designers build modern mobile apps for iOS and Android.” The modern, reactive ...

I dabbled a bit in Android and iOS development quite a few years back using Java and Objective-C. After spending about a month working with both of them, I decided to move on. I just couldn’t get into it.

But recently, I learned about Flutter and decided to give mobile app development another shot. I instantly fell in love with it as it made developing multi-platform apps a ton of fun. Since learning about it, I’ve created an app and a library using it. Flutter seems to be a very promising step forward and I’d like to explain a few different reasons why I believe this.

Powered by Dart

Flutter uses the Google-developed Dart language. If you’ve used Java before, you’ll be fairly familiar with the syntax of Dart as they are quite similar. Besides the syntax, Dart is a fairly different language.

I’m not going to be talking about Dart in depth as it’s a bit out of scope, but I’d like to discuss one of the most helpful features in my opinion. This feature being support for asynchronous operations. Not only does Dart support it, but it makes it exceptionally easy.

This is something you’ll most likely be using throughout all of your Flutter applications if you’re doing IO or other time-consuming operations such as querying a database. Without asynchronous operations, any time-consuming operations will cause the program to freeze up until they complete. To prevent this, Dart provides us with the async and await keywords which allow our program to continue execution while waiting for these longer operations to complete.

Let's take a look at a couple of examples: one without asynchronous operations and one with.

// Without asynchronous operations
	import 'dart:async';

	main() {

	longOperation() {
	    Duration delay = Duration(seconds: 3);
	    print('Waited 3 seconds to print this and blocked execution.');

	printSomething() {
	    print('That sure took a while!');

And the output:

3 seconds to print this and blocked execution.
That sure took a while!

This isn’t ideal. No one wants to use an app that freezes up when it executes long operations. So let’s modify this a bit and make use of the async and await keywords.

// With asynchronous operations
	import 'dart:async';

	main() {

	Future<void> longOperation() async {
	    var retVal = await runLongOperation();


	const retString = 'Waited 3 seconds to return this without blocking execution.';
	Duration delay = Duration(seconds: 3);

	Future<String> runLongOperation() => Future.delayed(delay, () => retString);

	printSomething() {
	    print('I printed right away!');

And the output once again:

I printed right away!
Waited 3 seconds to return this without blocking execution.

Thanks to asynchronous operations, we’re able to execute code that takes a while to complete without blocking the execution of the rest of our code.

Write Once, Run on Android and iOS

Developing mobile apps can take a lot of time considering you need to use a different codebase for Android and iOS. That is unless you use an SDK like Flutter, where you have a single codebase that allows you to build your app for both operating systems. Not only that, but you can run them completely natively. This means things such as scrolling and navigation, to name a few, act just like they should for the OS being used.

To keep with the theme of simplicity, as long as you have a device or simulator running, Flutter makes building and running your app for testing as simple as clicking a button.

UI Development

UI development is one of those things that I almost never look forward to. I’m more of a backend developer, so when it comes to working on something that is heavily dependent on it, I want something simple. This is where Flutter shines in my eyes.

UI is created by combining different widgets together and modifying them to fit the look of your app. You have near full control over how these widgets display, so you’ll always end up with exactly what you’re looking for. For laying out the UI, you have widgets such as Row, Column, and Container. For content, you have widgets like Text and RaisedButton. This is only a few of the widgets Flutter offers, there are a lot more. Using these widgets, we can build a very simple UI:

	Widget build(BuildContext context) {
	    return Scaffold(
	        appBar: AppBar(
	            title: Text('Flutter App'),
	            centerTitle: true,
	            elevation: 0,
	        body: Row(
	            children: [
	                    children: [
	                            child: Text('Some text'),
	                            child: RaisedButton(
	                                onPressed: () {
	                                    // Do something on press
	                                child: Text('PRESS ME'),

Flutter has more tricks up its sleeve that makes theming your app a breeze. You could go through and manually change the fonts, colors, and looks for everything one by one, but that takes way too long. Instead, Flutter provides us with something called ThemeData that allows us to set values for colors, fonts, input fields, and much more. This feature is great for keeping the look of your app consistent.

theme: ThemeData(
	    brightness: Brightness.dark,
	    canvasColor: Colors.grey[900],
	    primarySwatch: Colors.teal,
	    primaryColor: Colors.teal[500],
	    fontFamily: 'Helvetica',
	    primaryTextTheme: Typography.whiteCupertino.copyWith(
	        display4: TextStyle(
	            color: Colors.white,
	            fontSize: 36,

With this ThemeData, we set the apps colors, font family, and some text styles. Everything besides the text styles will automatically be applied app-wide. Text styles have to be set manually for each text widget, but it's still simple:

child: Text(
	   'Some text',
	   style: Theme.of(context).primaryTextTheme.display4,

To make things even more efficient, Flutter can hot reload apps so you don’t need to restart it every time you make a change to the UI. You can now make a change, save it, then see the change within a second or so.


Flutter provides a lot of great features out of the box, but there are times when you need a bit more than it offers. This is no problem at all considering the extensive number of libraries available for Dart and Flutter. Interested in putting ads in your app? There’s a library for that. Want new widgets? There are libraries for that.

If you’re more of a do-it-yourselfer, make your own library and share it with the rest of the community in no time at all. Adding libraries to your project is simple and can be done by adding a single line to your pubspec.yaml file. For example, if you wanted to add the sqflite library:

  sdk: flutter
 sqflite: ^1.0.0

After adding it to the file, run flutter packages get and you're good to go. Libraries make developing Flutter apps a breeze and save a lot of time during development.

Backend Development

Most apps nowadays depend on some sort of data, and that data needs to be stored somewhere so it can be displayed and worked with later on. So keeping this in mind when looking to create apps with a new SDK, such as Flutter, is important.

Once again, Flutter apps are made using Dart, and Dart is great when it comes to backend development. I’ve talked a lot about simplicity in this article, and backend development with Dart and Flutter is no exception to this. It’s incredibly simple to create data-driven apps, for beginners and experts alike, but this simplicity by no means equates to a lack of quality.

To tie this in with the previous section, libraries are available so you can work with the database of your choosing. Using the sqflite library, we can be up and running with an SQLite database fairly quickly. And thanks to singletons, we can access the database and query it from practically anywhere without needing to recreate an object every single time.

class DBProvider {
	    // Singleton

	    // Static object to provide us access from practically anywhere
	    static final DBProvider db = DBProvider._();
	    Database _database;

	    Future<Database> get database async {
	        if (_database != null) {
	            return _database;

	        _database = await initDB();
	        return _database;

	    initDB() async {
	        // Retrieve your app's directory, then create a path to a database for your app.
	        Directory documentsDir = await getApplicationDocumentsDirectory();
	        String path = join(documentsDir.path, 'money_clip.db');

	        return await openDatabase(path, version: 1, onOpen: (db) async {
	            // Do something when the database is opened
	        }, onCreate: (Database db, int version) async {
	            // Do something, such as creating tables, when the database is first created.
	            // If the database already exists, this will not be called.

After retrieving data from a database, you can convert that to an object using a model. Or if you want to store an object in the database, you can convert it to JSON using the same model.

class User {
	    int id;
	    String name;


	    factory User.fromJson(Map<String, dynamic> json) => new User(
	        id: json['id'],
	        name: json['name'],

	    Map<String, dynamic> toJson() => {
	        'id': id,
	        'name': name,

This data isn’t all that useful without a way to display it to the user. This is where Flutter comes in with widgets such as the FutureBuilder or StreamBuilder. If you're interested in a more in-depth look at creating data-driven apps using Flutter, SQLite, and other technologies, I encourage you to check out the article I wrote on that:

Final Thoughts

With Flutter, the possibilities are practically endless, so even super extensive apps can be created with ease. If you develop mobile apps and have yet to give Flutter a try, I highly recommend you do as I’m sure you’ll fall in love with it as well. After using Flutter for quite a few months, I think it’s safe to say that it’s the future of mobile development. If not, it’s definitely a step in the right direction.