Tech Talk: "Multiplatform Strategy for the remove.bg Apps" mit Andreas Braumann von Kaleido

Tech Talk: "Multiplatform Strategy for the remove.bg Apps" mit Andreas Braumann von Kaleido

Alright so, I'm back hello!

I'm Andi from Kaleido. In case you missed my first talk about Canva apps, here in this corner you can have the link. Open it in another tab and watch it after this video, because you don't want to miss this!

Today I want to talk about Flutter. So, we have a lot of apps running on client systems. And they use a lot of technologies and yes, I want to take you basically on our thought process about; should we redo these apps, reimplement them, and what technology should we use? Also I would like to get your input actually – because it's not decided yet – what you think would be the best strategy for our apps.

So yeah, let's start!

First I want to tell you about the apps we have and what technology we use right now. This is all for remove.bg. Of course we also have Unscreen, where we have a plugin for Premiere and After Effects, but this is not part of this – so this is only about the remove.bg brand.

So we have the remove.bg desktop app, and everybody loves it. It's available for all the desktop systems, optimized for batch processing, so that you can drag in 1.000 images, process them and change the background. It's written in JavaScript, so it's a web technology, quite easy. It uses Electron Forge for the whole desktop bundling.

For the GUI it uses Vue.js, like on our website. There are some specialities like Photoshop export, so you can save Photoshop files in it. And it also supports design templates where you can batch process them too. So this is the Desktop app.

Another thing we have is our Android app. So if go to the Play store on Android, we have the remove.bg app there, it's basically a webview with a little bit of decoration right now, but it's written in native Android. So Android studio – it's written in Kotlin.

The speciality here is that you can share an image to the app and from the app. So, it can be a little bit tricky but yeah, that's supported.

Unfortunately we don't have iOS support yet, we didn't do that yet, and you can't purchase anything in the app. Which is a big thing in my opinion. So you have to purchase on the web and then you log in on the mobile app and then you get the credits there. Yes, that's the Android app.

And then we have the commandline interface, which is not so well known. It's open source actually, so the source code is available on GitHub and it's written in Go, which is a language that is almost forgotten I'd say, but yeah. At the beginning it was the quickest way to get it running and it was around on all operating systems of course. It's also deployed via the HomeBrew package manager. And it's also very nice for batch processing.

So, the question is what do we do with these three apps? The goals are: we want to reuse our code, so now we have a Go codebase, a JavaScript codebase and an Android codebase in Kotlin – additionally to the web view which has, like, another codebase but okay – and we want to have one uniform codebase where we can share all the code. We want to have one build process, where we don't have for every platform and different build process and different CircleCI pipelines and stuff. Also tests should be running across all platforms, so if I want to remove a background it should just do it on all the platforms and we shouldn't have to specifically write tests for all of them separately. Also, we want to share assets, for example logos or buttons like components and styles, all of that. And when we want to rebrand – like we did now for the Kaleido brand, we want to rebrand sometimes – it should be very easy by replacing one image and it's then used in all apps. Yeah, fix stuff only once. So if we find a bug, now I have to go to three codebases. I fix it in three different ways, test it in three different

ways, there are probably three different people involved because not one person knows all the code and in the future it would be nice to have only one person fixing the bug, building it and also shipping it.

So, what did we consider until now? For mobile, we considered React Native, so we built a prototype for React Native. Also, we considered staying with the native app, maybe removing the webview and integrating the functionality natively. It worked. Both proof-of-concepts worked – React Native is really nice to develop with expo. But again, it's a separate codebase so... For the commandline interface we considered Node.js, so there is a Node.js package where you can quite easy rewrite commandline tools, also package them. It's quite a big binary, it's around 80 MB because you have the runtime in there, but it works. It's JavaScript. We also considered Rust, but it's very exotic I think.

For the desktop app, we considered staying with Electron because it's like web technology. And just updating it because it hasn't been updated in a while. So, these were the considerations we had.

The big goal would be to have a unified codebase. So, yeah.

Another thing that I want to point out is the difference between our problem and lots of other companies' problems. Lots of companies want cross-platform. What does cross- and multi-platform mean?

So, cross platform means you have one codebase for iOS and Android, but it's mobile only. You can run it on your iPhone and Android devices and tablets or whatever. That's cross platform.

And what we have is actually multiplatform. So we have mobile platforms, plus also desktop platforms – Mac OS, Windows, Linux – and the command line interface would also be nice to have in this codebase. And it also runs on all the operating systems.

So, that's the solution that we came up with and I'd be happy to hear your opinions in the comments below – subscribing, you know, all that stuff, hahahaa!

So, Flutter – I don't know if you heard about Flutter. It's already at version 2.5, I think it was released quite recently. So it's built and supported by Google. And yeah, it's a cross platform. That means it runs in all desktop systems. So it supports the GUI and the commandline and it runs on Android and iOS. And maybe in the future it runs on your TV and – I don't know – microwave or whatever. So I think that's the vision of Google, to have this everywhere. On your watch, whatever.

And here is the link to Flutter, if you want to check it out, it's free of course.

And yeah, so what can we do with flutter? Flutter is basically just a framework and the programming language is called dart. So for the CLI we would just use a dart library and because you don't need a GUI for dart. There's no prototype yet, but I found and article on Medium, the link is there. Also, the slides are in the description if you want to check it out. So somebody built the weather command line in dart and I think we can just take that and turn it into the remove.bg command line interface

quite easily. And of course we have a component that is common for all these platforms where we share the code that we want to share, like authentication, API key validation, and of course the removal of the background. So that would be like the command line interface.

The next one is the Android app – so I made a small prototype, it's not doing a lot, you can see this screenshot what it looks like. It's a native app and you can have menus, you can have buttons, everything that you're used to. There's a lot of libraries for flutter for really nice menus, really nice animations, really playful stuff. That is really useable.

Also for iOS, looks quite similar. So if you compare that to that.

You have platform specifics where the menu looks a little bit different. On Android you have buttons of course, but it's the same code.

And the nice thing is you also have the desktop app! Same thing, same code. Flutter runs on Mac OS, it also runs on Windows and Linux. We have the same menu. If you want, you can also exchange the GUI if you want a different desktop GUI that has some – I don't know – not this menu on the side, because that's mobile specific – the core would be the same and the build would be the same. And there's also a bonus, you can even deploy it on the web if you want to, so yeah.

It's possible to also have the same thing, the same code running in the browser, which is really nice. So, if you are starting from scratch and don't have a website yet, that would also be a possibility to build your web app with this.

Yeah, so that's basically the summary of Flutter. The question is: do we want to throw away all our old code? And all our time we put into it, lots of bugfixes – do we want to redo all of that? And write it from scratch, but only once and then for the future we have a common codebase and save a lot of time?

That's the big question now. So yeah, that's the idea, I just wanted to show the outcomes.

So yeah, feedback time! I'd be happy to read the youtube comments. Last time there were some comments. If you have some ideas about this, if you have some other frameworks, if you have experience with Flutter, maybe you're the one, that wants to do it for us? Or React Native, I mean i think there is React Native desktop support, but it's very early stage. Or do you have another suggestion for a framework that you would use?

You can check out our apps. Play around with the API, if you want. And yeah, maybe you are the one to implement it for us!

So the summary that I came up with for Flutter is:

  • It's multiplatform, so it's even better then cross platform.
  • It's a single codebase for all the platforms.
  • We have native apps, so it's not like some emulation or stuff like Submarine, where you have like a layer in between.
  • It's supported by Google, which is always a good thing. Google is big.
  • You develop it in an Android Studio, which is I think quite a nice development environment. You can also use Visual Studio Code, but Android Studio is just the best, also for debugging.

Yeah the negatives would be:

  • It's a new tech stack, we have no experience with that, we don't know the risks, we don't know stuff that doesn't work, stuff that breaks on some devices. So it's a new adventure.
  • And the desktop support, also for Flutter is in beta. I think it is quite stable, but still... yeah it's in beta.

So, thats that! I'd be happy to read your comments about this topic.

Also we are hiring! If you spot me in that image, again, you get a beer from devjobs.at – I know somebody got a beer last time, somebody claimed it, hahaa!

And yeah, I'd be happy to see you in the office or virtually through Zoom. And yes, if you want to watch my other video, you can watch it here. It comes up right now – click on that!

And yeah, I wish you good luck, we are hiring, goodbye!

 

 

Erfahre mehr zum DevTeam von Kaleido