How to Transition From Swift to Flutter

In this short story, I will describe what were the easiest and the most challenging dierences when transferring from Swift to Flutter.

Cross-platform tools for mobile development have been a holy grail for a very long time now. But, it is not easy, and there have been many contenders. Personally, I’ve been close to using React Native and even tried Xamarin; however, from what I’ve heard, they have both been struggling with bugs and missing features.

Selecting a cross-platform tool for a bigger project can also be risky as it is a huge buy-in to an ecosystem that has to survive the app’s lifetime. Will the tools be around? Can one find developers in the future when the app inevitably needs to be upgraded?

We will go through a few points such as:

• Architectures


• UI/UX


• Documentation


• Development & Maintenance

Let’s jump right into it!

Architectures

While native iOS apps use architectures such as MVC, MVVM, Viper, etc., Flutter uses a pattern called BLoC. Many developers think that BLoC is pretty much the same thing as MVVM, but in reality, they are not quite the same… MVVM implies data bindings between the view and the view model, which means that the view objects are mostly the ones commanding the view model.

MVVM seems to be a simplification of MVC to show the model “as is” behind the scenes. For example, Xamarin largely uses MVVM, and the controls on the screen like checkboxes, text input, etc., all do modify the model view behind the scenes.

You may already start to see a problem here. If you change the UI, you may have to change the MV as well. Suppose you have an entry number that must be between 0–255; where do you put this logic? Well, on MVVM, you put this logic on the view. But you must put these locks on the model view as well to guarantee data safety.

That means a lot of code rewriting to do the same thing. If you decide to change this range, you have to change it in two places, making your code more prone to errors. There are workarounds for this, but it is far more complicated than it should be.

On the other hand, BLoC works by receiving events and emitting states. It doesn’t care (although it may) from where the event came from. Using the same example from the above, the view would signal an event to the bloc/controller with “hey, my number changed!”, the bloc then would process this new event and, if suitable, emit a signal to the UI: “hey UI! You should change! I have a new state for you!”. Then, the UI rebuilds itself to present those changes.

For me, the advantage of BLoC over MVVM is that BLoC can entirely decouple the business logic from the view, which is overall a better way to do things. As our modern software development requires more and more UI changes (being dierent screen sizes, densities, platforms, etc.), having the UI side decoupled from the models is a fantastic feature to code reusability.

UI/UX

Xcode has multiple ways of configuring UI in your app. The most popular way is through Storyboard. Storyboard allows you to drag-&-drop a specific UI element on your UIViewController and position using Auto Layout and constraints. I won’t go into details, but you can read more here. You can also create your UI just by using code. For example, using UIStackView is a great way of doing it, and it’s also similar to Flutter in some way.

When using stack views, you can specify which axis will the stack view use (vertical or horizontal). You can place elements that you need along the axis inside the stack view (for example, button, label, or some custom UI element). Of course, there are much more parameters that you can use to display your UI elements inside the stack view (distribution, alignment, spacing, etc.), but I won’t go into details.

Flutter uses widgets that are built using a modern framework that takes inspiration from React. The central idea is that you build your UI out of widgets. Widgets describe what their view should look like given their current configuration and state. When a widget’s state changes, the widget rebuilds its description.

The framework dis against the previous description to determine the minimal changes needed in the underlying render tree to transition from one state to the next. There are a few basic widgets:

• Text
  
  The text widget lets you create a run of styled text within your application.


• Row/Column
  
  These flex widgets let you create flexible layouts in both the horizontal (Row) and vertical (Column) directions. The design of these objects is based on the web’s flexbox layout model.


• Stack
  
  Instead of being linearly oriented (either horizontally or vertically), a Stack widget lets you place widgets on top of each other in paint order. You can then use the Positioned widget on children of a Stack to position them relative to the top, right, bottom, or left edge of the stack. Stacks are based on the web’s absolute positioning layout model.


• Container
  
  The container widget lets you create a rectangular visual element. A container can be decorated with a BoxDecoration, such as a background, a border, or a shadow. A Container can also have margins, padding, and constraints applied to its size. In addition, a Container can be transformed into a three-dimensional space using a matrix.

This is most likely the hardest part of the transition for many developers such as myself. Building UI in Xcode is crazy simple, and once you get the hang of it, it’s as easy as working an assembly line. On the other hand, I feel that Flutter’s UI is diicult to handle because there is a lot of code, but maybe it’s just the lack of experience.

If this sounds interesting and you wish to go into more details about widgets, navigation, animations, etc., here is a link.

Documentation

When it comes to documentation, Apple provided all the details about almost everything. In my opinion, some of it may seem not very clear, so you may want to read the same article twice. Apple also has a WWDC (Worldwide Developer Conference), which takes place every year in June.

During the event, Apple explains new technologies that they develop in a pretty detailed description which, again, in my opinion, are fantastic, and explanations are more apparent than the one in the documentation provided on the oicial Apple site. Overall, Apple does a fantastic job explaining its technology and provides more than enough info for beginners to learn and start coding themselves.

Flutter comes close to Apple with its documentation, unlike Xamarin or React Native, where I feel like a lot is missing. Developers need to search the web for more info regarding a specific question, which usually results in slower development.

Flutter does a great job providing all the information you need. Flutter uses Dart as a programing language, so there are two sites that you can visit if you have any questions (https://dart.dev/guides and https://flutter.dev/docs).

If you can’t find the answer that you are looking for in some cases, there is no need to panic. Flutter is a trendy framework. Because of its popularity that has been going crazy lately, there are already many forums with all kinds of questions being asked and answered. If you can’t find the answer even then, ask a question on StackOverflow or similar websites. You will get an answer very quickly.

Overall, both Apple and Flutter provide their developers with all the info they need to start coding, or if they are experienced, to learn new things and upgrade to the next level.

Development & Maintenance

Now, the big question that most clients will ask. What is more cost-eective?

With no hesitation, the short answer is Flutter. While native apps need two codebases, Flutter requires just one. The cost of development is lower, time of development shorter, and end-product more eicient.

For example, let’s say that you need to develop a simple radio app. To cover both platforms with native apps (iOS and Andriod), you will most likely need 3 developers, one for the backend, one for iOS, and Andriod.

With Flutter, you will need 2 developers, one for the backend and one for both apps. That being said, in this example, your radio project will cost 25–30% less, and it will be ready for the end-users sooner.

When it comes to maintenance, Flutter wins again since there is just one codebase. The cost of maintenance in some situations could be half the cost for native apps.

For bigger and more complex projects, the development cost may not be 25–30%, but it will surely be cheaper to develop. Keep in mind that Flutter is a pretty new technology that is being upgraded every day and may lack some advanced frameworks, for example, 3D scanning of objects.

When it comes to end-users, there is no need to worry about their experience because 99% of them won’t even notice that they are using a hybrid app and not a native one. The finished product is built dierently when it comes to native and hybrid apps, using dierent architecture and UI elements, but the result is the same.

The performance dierence is close to zero; you can’t really notice that loading an image took 50 milliseconds for a hybrid app and 45 milliseconds for a native one. The hardware that we have in our phones and tablets today is more than enough to run apps that we use in everyday lives.