Canva Austria GmbH.

Startup

Alle Videos anzeigen

Multiplatform Strategy for the remove.bg Apps

Andreas Braumann von Kaleido untersucht in seinem devjobs.at TechTalk die Vor- und Nachteile von Flutter und wie man damit alle remove.bg Apps in einer einheitlichen Technologie haben könnte.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In "Multiplatform Strategy for the remove.bg Apps" erläutert Andreas Braumann die bestehende Landschaft—eine Electron/Vue-Desktop-App, eine native Android-WebView-App ohne iOS und In-App-Käufe sowie ein Go-basiertes CLI—und die Ziele einer einheitlichen Codebasis, gemeinsamen Builds/Tests und geteilten Assets. Er vergleicht React Native und native Entwicklung für Mobile, Node.js bzw. Rust fürs CLI und ein aktualisiertes Electron für Desktop, und schlägt Flutter/Dart als Multi-Plattform-Kandidaten vor: ein gemeinsamer Kern (Auth, API-Key-Validierung, Background Removal) für Android, iOS, Desktop, CLI und optional Web, mit Android-Prototyp und Beta-Status am Desktop. Zuschauer können die gezeigten Abwägungen und die Konsolidierungsstrategie auf eigene Multi-Plattform-Stacks und Build-Pipelines übertragen.

Multiplatform-Strategie für die remove.bg Apps: Warum Flutter den nächsten Konsolidierungsschritt möglich machen könnte

Kontext: Ein Produkt, viele Oberflächen – und die Suche nach einem einheitlichen Weg

In „Multiplatform Strategy for the remove.bg Apps“ skizziert Andreas Braumann (Canva Austria GmbH.) die Lage: remove.bg existiert heute als Desktop-App, Android-App und CLI – jeweils mit eigenen Technologien, eigenen Build-Pipelines und eigenen Tests. Dazu kommen Web-Komponenten und Spezialisierungen wie Photoshop-Export oder Designvorlagen für Batch-Prozesse. Das funktioniert, kostet aber zunehmend Wartungsaufwand.

Der Auftrag ist klar: Ein gemeinsamer Codekern, ein Build-Prozess, geteilte Assets und konsistente Tests über alle Zielplattformen hinweg. Was viele Unternehmen „Cross-Platform“ nennen (iOS und Android aus einer Codebasis), ist hier bewusst größer gefasst: Multi-Platform – inklusive Desktop (macOS, Windows, Linux) und idealerweise sogar die CLI.

Braumann nimmt uns durch die aktuelle Landschaft, die Evaluierungen (React Native, nativ, Node.js, Rust, Electron) und die Schlussfolgerung: Flutter könnte – trotz neuer Lernkurven – den Weg zur gemeinsamen Codebasis ebnen.

Der Status quo bei remove.bg: Drei Apps, drei Technologien

Desktop-App: Electron Forge, Vue.js, Batch-Power

Die remove.bg Desktop-App ist auf massives Batch-Processing ausgelegt. Tausende Bilder per Drag-and-Drop verarbeiten, Hintergründe tauschen, mit Design-Templates arbeiten – das ist der Kernnutzen. Technisch basiert sie auf Web-Technologien:

Electron Forge bündelt die Anwendung für macOS, Windows und Linux.
Vue.js treibt die GUI, analog zur Website.
Spezielle Features: Photoshop-Export (PSDs speichern) und Design-Vorlagen, die sich ebenfalls in Batch-Jobs integrieren lassen.

Android-App: Native Hülle, WebView im Kern

Die Android-App (im Play Store verfügbar) ist aktuell im Wesentlichen eine WebView mit „etwas Dekoration“. Sie ist nativ in Kotlin (Android Studio) entwickelt. Wichtig sind hier die Android-Sharing-Flows:

Bilder lassen sich in die App teilen (Share to)
und aus der App heraus weitergeben (Share from)

Was noch fehlt: eine iOS-Variante – und In-App-Purchases. Käufe laufen derzeit über das Web, anschließend melden sich Nutzer in der App an und sehen ihre Credits dort.

CLI: Go, Open Source, Homebrew

Die Kommandozeilen-Oberfläche ist Open Source (Code auf GitHub) und in Go implementiert – „eine fast vergessene Sprache“, wie Braumann scherzhaft anmerkt. Sie läuft auf allen gängigen Betriebssystemen und ist via Homebrew installierbar. Auch sie ist für Batch-Workloads prädestiniert.

Die Ziele: Einmal bauen, überall nutzen – Code, Pipelines, Tests und Assets teilen

Braumann fasst die Motivationslage in mehrere handfeste Ziele:

Code-Wiederverwendung statt getrennten Codebasen in Go, JavaScript/TypeScript und Kotlin.
Ein Build-Prozess statt „pro Plattform eine eigene Pipeline“.
Gemeinsame Tests, die sich über alle Plattformen abbilden lassen.
Geteilte Assets (Logos, Komponenten, Styles). Rebranding soll so einfach wie „ein Bild austauschen“ sein – und das Konsistenz über alle Apps hinweg sichern. Ein Hinweis: Genau das war in der Vergangenheit, etwa beim Kaleido-Rebranding, spürbar aufwändig.
Fehler nur einmal fixen. Aktuell müssen Bugs oft dreifach behoben, getestet und ausgeliefert werden – häufig von unterschiedlichen Personen mit jeweiligen Technologie-Schwerpunkten.

Das Zielbild ist klar: eine gemeinsame Codebasis, eine gemeinsame Delivery- und Teststrecke, eine konsistente UI-Bausteinbibliothek – und die Möglichkeit, das Ökosystem sauber zu erweitern.

Cross-Platform vs. Multi-Platform: Der entscheidende Unterschied

Viele Firmen sprechen von Cross-Platform, meinen aber primär Mobile (iOS/Android) aus einer Codebasis. remove.bg benötigt mehr. Multi-Platform meint hier:

Mobile (iOS + Android)
Desktop (macOS, Windows, Linux)
CLI (ohne GUI, aber Teil der selben Codewelt)

Dieser Unterschied ist zentral: Für remove.bg ist Desktop ein Erstklassen-Bürger (Batch-Prozesse, Photoshop-Export, Templates), und die CLI ist etablierter Bestandteil produktiver Workflows. Eine Strategie, die nur Mobile vereint, reicht deshalb nicht aus.

Evaluierte Optionen: Was wurde erwogen – und warum reicht es (allein) nicht?

Mobile: React Native (mit Expo) vs. nativ

Für Mobile gab es zwei Pfade:

Ein React-Native-Prototyp mit Expo – laut Braumann „wirklich schön“ in der Entwicklung.
Eine native Umsetzung, die den WebView-Anteil ablöst und Funktionen vollständig nativ integriert.

Beides funktionierte im Proof of Concept. Aber: React Native wäre wieder „eine separate Codebasis“, also keine Lösung für Desktop und CLI. Nativ bliebe ohnehin isoliert.

CLI: Node.js (pkg) und Rust als Alternative

Die CLI ließe sich mit Node.js umsetzen – inklusive Packaging. Der entstehende Binary ist zwar „recht groß“ (ca. 80 MB, inkl. Runtime), funktional aber machbar und naheliegend für JavaScript-Teams. Rust stand kurzzeitig im Raum, wurde aber als „sehr exotisch“ bewertet.

Desktop: Electron modernisieren

Auf Desktop-Seite lag „Weiter mit Electron, aber aktualisieren“ nahe. Electron bleibt Web-Technologie, die Team bereits kennt – jedoch löst das nicht das Core-Problem der unabhängigen Codebasen und Pipelines.

Fazit: Jede Option für sich ist umsetzbar. Doch keine vereint Mobile, Desktop und CLI in einer durchgängigen Architektur.

Flutter als Multi-Platform-Kandidat: Eine gemeinsame Sprache (Dart), ein Framework, viele Targets

Braumanns Vorschlag: Flutter. Der Stand im Talk: Version 2.5, von Google entwickelt und „kostenlos“. Entscheidend ist nicht nur Cross-Platform, sondern Multi-Platform:

Mobile: Android und iOS
Desktop: macOS, Windows, Linux – inklusive GUI
CLI: Kein GUI nötig, aber via Dart-Libraries umsetzbar
Bonus: Web-Target möglich

Die Vision: Eine gemeinsame Codebasis für Authentifizierung, API-Key-Validierung und natürlich die Kernaction „Hintergrund entfernen“ – und drumherum Plattform-Shells, die sich in UI und Integrationspunkten unterscheiden dürfen, aber denselben Kern nutzen.

„Das wäre die Komponente, die gemeinsam für alle Plattformen ist: Authentifizierung, API-Key-Validierung und natürlich das Entfernen des Hintergrunds.“

CLI in Dart: Einfacher Startpunkt

Für die CLI schlägt Braumann einen pragmatischen Weg vor: eine Dart-Library. Einen Prototypen gibt es noch nicht. Grundlage wäre ein öffentliches Beispiel („Weather-CLI in Dart“). Die Erwartung: dies lässt sich für remove.bg vergleichsweise schnell adaptieren.

Mobile und Desktop: Ein UI-Code, unterschiedliche Look-and-Feels

Braumann zeigt einen Android-Prototypen in Flutter. Die App reagiert interaktiv, es gibt Menüs und Buttons – und es existiert eine rege Bibliothekslandschaft für Menükomponenten und Animationen.

Auf iOS sähe dieselbe App „sehr ähnlich“ aus – mit systemtypischen Unterschieden (z. B. Button-Stile). Für Desktop gilt dasselbe: „Einfach Flutter run macOS“ – analog für Windows und Linux – und der UI-Code läuft. Wenn gewünscht, kann die GUI für Desktop angepasst werden (z. B. weniger mobiltypische Seitenleisten), ohne den Kern anzutasten.

Bonus: Web-Build als Option

Als Zugabe erwähnt Braumann: derselbe Code lässt sich auch im Web deployen. Für remove.bg existiert bereits eine Website – aber wer neu startet, könnte sogar das Web-Frontend auf Flutter stützen. Für remove.bg ist das eher ein „nice to have“, zeigt aber die Reichweite des Ansatzes.

Pipeline, Tests und Assets: Was Konsolidierung praktisch bedeutet

Braumanns Ziele übersetzen sich in konkrete operative Vorteile – vorausgesetzt, die Architektur wird wirklich zentralisiert:

Ein Build-Prozess: Statt einzelner CircleCI-Pipelines pro Plattform ein konsolidierter Flow, der mobile, Desktop und CLI aus derselben Codebasis ableitet.
Gemeinsame Tests: Funktionale Kernprozesse – „Hintergrund entfernen“, Login, Key-Validierung – laufen als einheitliche Test-Suite für alle Targets. Tests müssen nicht in drei Technologien doppelt und dreifach erfunden werden.
Geteilte Assets und Komponenten: Logos, Icons, Styles, UI-Elemente – einmal definieren, überall nutzen. Rebranding wird zu einem kontrollierten Austausch weniger Artefakte, nicht zu einem parallelen Redesign in getrennten Projekten.
Fehlerbehebung aus einem Guss: „In Zukunft sollte eine Person den Bug fixen, bauen und ausliefern“ – statt dass drei Teams je eine eigene Variante reparieren.

Die harte Frage: Altes verwerfen und neu bauen – lohnt das?

Damit steht der Elefant im Raum: Soll die bestehende Funktionalität in Flutter neu entstehen? Jahre an Bugfixes, Spezialfällen und Integrationen stecken im Status quo.

Braumanns Zuspitzung: Alles einmal neu „from scratch“ – aber eben nur einmal. Danach zahlt sich die gemeinsame Basis aus, weil Neuerungen, Fixes und Tests für alle Plattformen gleichzeitig fließen.

Risiken gibt es dennoch:

Neue Tech-Stack: Das Team muss Dart und Flutter lernen – inklusive der Fallstricke, die heute noch unbekannt sind.
Desktop-Support: „In Beta“ – nach Braumanns Eindruck stabil, aber nicht final.

Pro und Contra Flutter – so fasst der Talk zusammen

Braumann liefert eine klare Pro/Contra-Übersicht:

Vorteile:

Multi-Platform statt nur Cross-Platform
Eine Codebasis für alle Targets
Native Apps (kein „Xamarin-ähnlicher Layer“ dazwischen)
Unterstützung durch Google
Entwicklung mit Android Studio (oder VS Code); Android Studio punktet beim Debugging

Nachteile:

Neuer Stack, wenige interne Erfahrungen
Unklare Risiken („was bricht auf welchen Geräten?“)
Desktop-Support noch „Beta“

Architektur-Skizze: Gemeinsamer Kern, dünne Plattform-Schichten

Auch wenn der Talk keine Diagramme zeigt, zeichnet sich das Zielbild ab:

Core-Library (Dart):
Authentifizierung
API-Key-Validierung
Kernfunktion „Hintergrund entfernen“
Gemeinsame Fehlerbehandlung und Logging
Gemeinsame Test-Suite
Plattform-Schichten:
CLI: Dart-Entry-Point ohne GUI; Ein-/Ausgabe über Terminal; Packaging pro OS
Mobile: Flutter-UI, Integrationen wie Android- und iOS-Sharing; perspektivisch In-App-Käufe auf iOS/Android
Desktop: Flutter-UI oder angepasste Desktop-Layouts; OS-typische Integrationen (Dateidialoge, Drag-and-Drop, Dateirechte)
Web (optional): falls sinnvoll, ein Build-Target für browserbasierten Zugriff
Asset- und Branding-Layer:
Logos, Farben, Typografie, Icons, UI-Komponenten – zentral verwaltet

Diese Struktur adressiert den heute beschriebenen Schmerz: drei Inseln mit eigenem Code und eigenen Artefakten.

Was bedeutet das für Batch, Photoshop-Export und Templates?

Die Desktop-App zeichnet sich durch Sonderfunktionen aus: Batch-Verarbeitung, Photoshop-Export, Design-Templates für Serienverarbeitung. Der Talk verspricht keine Details zur Umsetzung in Flutter – wohl aber den architektonischen Pfad:

Batch bleibt ein Anwendungsfall des gemeinsamen Kerns (API-Aufrufe, Dateihandling), UI-spezifisch auf Desktop priorisiert.
Photoshop-Export und Templates sind Spezialintegrationen, die sich über die Desktop-Schicht einklinken – mit dem Ziel, so viel wie möglich (Parsing, Validierung, Status) im Dart-Kern zu bündeln, die OS-spezifischen Hooks aber dort zu verankern, wo sie hingehören.

Entscheidend ist: Der Core muss die richtigen Abstraktionen definieren, damit diese Features nicht erneut zu Insellösungen werden.

Mobile-Lücken schließen: iOS und In-App-Purchases

Explizit genannt werden zwei Lücken:

Es gibt noch keine iOS-App.
Käufe passieren nicht in der App, sondern im Web.

Mit Flutter liegt beides in Reichweite derselben Codebasis. Der Talk enthält keine Implementierungsdetails; die Folgerung ist dennoch klar: Eine Mobile-Erweiterung wäre kein technischer Seitensprung mehr, sondern ein Ausbau entlang des gemeinsamen Stacks – mit geteilten UI-Bausteinen und Tests.

CLI realistisch denken: Einfach starten, sauber integrieren

Die CLI ist in produktiven Workflows wichtig. Braumann schlägt vor, sie in Dart zu implementieren und auf ein bestehendes Beispiel aufzusetzen. Das ist pragmatisch – besonders, weil es den gemeinsamen Kern unmittelbar mit einem „No-UI“-Target verbindet.

Praktische Leitplanken (aus dem Talk abgeleitet):

Keine GUI-Bedürfnisse, also schnelles Bootstrapping in Dart.
Fokus auf Batch und Automatisierung – dort, wo remove.bg stark ist.
Packaging pro OS, analog zum heutigen Homebrew-Ansatz.

Lessons Learned aus dem Talk

Aus technischer Sicht bleiben für uns drei prägnante Einsichten:

1) Multi-Platform heißt: Desktop und CLI sind Erstklassen-Bürger.

Wer nur Mobile zusammenführt, löst das remove.bg-Problem nicht. Desktop-Features wie Photoshop-Export und Batch-Templates sind zentral – und CLI ist für Automatisierer unverzichtbar.

2) Der Wert einer gemeinsamen Codebasis liegt in Tests, Assets und Pipelines – nicht nur im UI.

Das Ziel ist nicht „möglichst wenig UI doppelt schreiben“, sondern „Kernlogik, Branding und Qualitätssicherung zentralisieren“.

3) Flutter bietet heute den breitesten Zielkorridor – mit kalkuliertem Risiko.

Ein Stack für Mobile, Desktop, CLI (und optional Web) ist attraktiv. Das „Beta“-Label für Desktop und die Lernkurve für Dart/Flutter sind echte Faktoren – aber angesichts der fragmentierten Landschaft plausibel.

Offene Punkte und Community-Call

Braumann betont, dass die Entscheidung noch nicht gefallen ist. Der Aufruf ist offen formuliert:

Erfahrungen mit Flutter?
Alternativvorschläge (React Native mit Desktop-Support wird als „sehr frühes Stadium“ erwähnt)?
Interesse, die Umsetzung zu übernehmen?

Wer die remove.bg Apps oder die API ausprobieren will, kann das tun – Feedback ausdrücklich erwünscht. Der Talk endet mit einem augenzwinkernden Hinweis auf Hiring und einer Wiederholung des „Wir sind offen für Vorschläge“.

Fazit: Ein pragmatischer Weg zu Multi-Platform – mit dem Mut zur Konsolidierung

Unser DevJobs.at-Highlight aus „Multiplatform Strategy for the remove.bg Apps“ von Andreas Braumann (Canva Austria GmbH.): Die technische Vision ist bodenständig und ambitioniert zugleich. Bodeständig, weil sie die bestehenden Stärken (Batch, CLI, Desktop-Spezialitäten) achtet und eine schrittweise Zentralisierung über einen gemeinsamen Dart/Flutter-Kern vorschlägt. Ambitioniert, weil sie „Altes wegwerfen und neu bauen“ in Kauf nimmt – zugunsten eines Setups, das Fehlerbehebung, Rebranding, Tests und Delivery effizienter macht.

Damit wird aus Cross-Platform tatsächlich Multi-Platform – eine Codebasis, mehrere Targets, fokussiert auf das, was remove.bg ausmacht: schnelle, zuverlässige Hintergrundentfernung in jedem Kontext, ob als GUI, Mobile-App oder CLI. Der nächste Schritt ist eine Entscheidung. Die Weichen dafür sind in diesem Talk gestellt – mit Flutter als ernstzunehmendem Favoriten.

Weitere Tech Talks