Flutter Warsaw interview with Jakub Biliński

Intro

Before the Flutter Warsaw #13, we interviewed our speakers. We've asked Jakub how did he convince such a big corporation that is ING to use Flutter for such an important project, and about pros and why did he choose this technology after all.
Jakub is the software engineer at ING Bank Śląski. He is responsible for the architecture, approach and development of a new version of the mobile application for strategic and corporate clients of the Bank.

Speakers

Mateusz Wojtczak

LeanCode

Senior Flutter Developer

Jakub Biliński

ING Bank Śląski

Software Engineer

Interview

What is your background as a developer?

In the beginning, I started with C++ by writing games and watching videos - all in all, I still do it in my free time. When it comes to mobile apps, I started to write them a few years ago, and it somehow drew me in. Today I hope to tell you how I got to Flutter straight from native apps.

How long have you been programming in Flutter?

(thinks) It'll be about two years now.

Were you doing this as research, hobby or were you already working at the time?

Right away at work. I learned Flutter specifically for the project that I’m going to talk about today. I didn't know it before.

How did you convince your corporation to use Flutter for such an important project?

After long research, we came to the conclusion that although Flutter is not so purely native, it still gives you access to writing natively and gives you so many possibilities that no other approach other than pure native does, including the speed and other elements you need. However, convincing the corporation to do so was difficult, because it had to go through architects, etc. Eventually, we managed to persuade them using a proof of concept that was made in a few different technologies. The one made in Flutter was the best, and the time spent on writing it was minimal, even though we didn't know this technology before.

Were you not scared that Flutter is not mature enough for a project of this scale? Were you not afraid?

We were very afraid of it, especially since we started two years ago, and it was around Google I/O 2018. We saw it on Youtube. It was still in beta then, so we were even more afraid than now. (laughs) Since the technology was still in beta, we were worried that Google might still abandon this project. We were afraid of it, but we decided to take the risk because there was no equal alternative. So we took that risk.

Were there any problems with Flutter itself or with the libraries you used that stressed you? Or that you worried it might be a blocker?

Yeah. Maybe not precisely with the libraries but with the lack of them. When we started, in many cases, there were no paved ways nor architectures; how to do it, how to deal with the simplest things. When we began to develop this project, Google said: "Hey, maybe you'll use BLoC". (laughs)

So we tried to pull out as many of these things as possible. Because a lot of people in my team are experienced in developing mobile apps, we decided to create something based on that practice. Some of the things we had to create from scratch, and now probably a lot of people would tell me "listen, there are libraries exactly for that". Once when we started, they didn’t exist yet. So we had to pave these ways ourselves. It was a pretty big blocker here. I'd say more of a time blocker than that it’s impossible to be done.

Are you in the Flutter Community? Do you follow it? If so, who - in your opinion - is the most helpful person within the Community? Do you read their blog posts, etc.?

From the Community itself, I mainly associate Googlers, because we mainly read their articles on Medium at work and watch their videos that are available on Google’s official channels like Google I/O videos or Widget of the Week. But their articles on the Medium are pretty resourceful for us. And as I was saying - mainly people from Google. There's no just single person I can give.

How did you and your teammates learn Flutter? Was it some courses, documentation, maybe blog posts?

Like I said before, we did not have many sources to learn Flutter from. We had to pave the way ourselves. We mainly focused on Flutter's documentation, which is good, even very good when compared to Android’s docs so that you can get a lot out of it. If you open up the Android documentation, you see magical integers, e.g. enter 17 as a 30th parameter and then 42 here. That's not the case with Flutter. Reading all the documentation - because we read it cover to cover several times - both Dart’s and Flutter’s gave a strong foundation to work with. And experience from other projects and technologies has also helped us a lot. We developed everything we lacked at the moment.

Would you currently recommend Flutter for every type of mobile project or are there still some small cases where you would say: "No, Flutter will not fit in here"?

I would definitely recommend Flutter to the majority of projects, but not to everything. For example, if I worked for a company that releases a new model of phone and I created a camera app for it, I would go the native way, because I would know that I would go into such low-level things that I would not benefit from Flutter there at all. But if I am writing an application designed to be dual-platform or even more multiplatform in the future like when Fuchsia comes out or something else, I would definitely say to go with Flutter.

What’s the best and worst thing about Flutter? Tell me the first things that come to your mind.

The best will be easier. (laughs) Definitely documentation. It's just good. I'm allergic to documentation. Especially since I started with C++ (laughs) were creating a window means passing 100 parameters, and every one of them has a random value. Anyway, in Android, it is the documentation that just burns my eyes out. In Flutter and Dart, the documentation is brilliant. When it comes to the worst thing, I’ll have to think about it for a while as it’s not that obvious. (thinks)

Everybody's always thinking about it. (laughs)

I think I know. There is one thing we sometimes have problems with, as we have a large and powerful application - Flutter is changing very fast. It is not just an advantage for me. When building an extensive application `flutter upgrade` can also do some negative things like sometimes the application fails to compile for us, so these upgrades seem to me to be the biggest problem. Sometimes these problems are not easy to solve, even though we only have few third-party libraries in the application, it is the Flutter itself that can change underneath, too.

Are you on stable or some other channel? And how often do you upgrade?

We are on stable virtually always. We switch to master after releases to see if there will be any problems with it if a new version comes out in a while. If so, we can prepare for it better. Speaking of upgrading, we try to be always up to date with the newest stable, except before a new app release as it can cause a delay in shipping the features. In the bank, we have to be consistent with the release windows.

The talk

Using Flutter in the Enterprise environment

Building one of the biggest Fintech applications in Flutter was very challenging. Jakub Biliński is responsible for the architecture, approach and development of a new version of the mobile application for strategic and corporate clients of the bank. In his, he shows how his team had to adjust to FinTech security compliance,  write a custom HTTP client, maintain application scalability and more.
logo

We build communities

Technology

Flutter