Multiplatform Strategy for the remove.bg Apps: Why Flutter Might Be the Unifying Path

Context: One product, many surfaces — and the push for a unified stack

In “Multiplatform Strategy for the remove.bg Apps,” Andreas Braumann (Canva Austria GmbH.) lays out a familiar engineering bind: remove.bg runs as a desktop app, an Android app, and a command-line interface, each with its own technology, build, and testing ecosystem. Add in web components and specialized features like Photoshop export and batch-ready design templates, and you get a lot of value—along with growing maintenance overhead.

The goal is explicit: converge on a shared core, a single build process, shared assets, and coherent testing across all targets. What many organizations call “cross-platform” (one codebase for iOS and Android) isn’t enough here. The bar is “multi-platform”—covering desktop (macOS, Windows, Linux) and ideally the CLI, too.

Braumann walks through the current landscape, the evaluation (React Native, native, Node.js, Rust, Electron), and the conclusion: Flutter could become the common foundation, despite the learning curve.

The current remove.bg app landscape: Three apps, three stacks

Desktop app: Electron Forge, Vue.js, and batch-first features

The desktop app is optimized for heavy batch processing. Drag in thousands of images, replace backgrounds, run design templates—the workflows are built for speed and scale. Under the hood:

• Electron Forge handles packaging for macOS, Windows, and Linux.
• Vue.js powers the GUI, aligned with the website.
• Special features include Photoshop export (saving PSDs) and support for design templates in batch processing.

Android app: Native Kotlin wrapper with a WebView core

The Google Play app is currently a WebView with some native wrapping. It’s built natively in Kotlin (Android Studio). The key Android specifics:

• Share to the app (receive an image)
• Share from the app (send an image)

Two gaps remain: no iOS version yet, and no in-app purchases. Purchases happen on the web; users then log in on mobile to see their credits.

CLI: Go, open source, Homebrew

The CLI is open source (code on GitHub) and implemented in Go—what Braumann jokingly calls “an almost forgotten language.” It’s cross-OS and available via Homebrew. It’s also a natural fit for batch workloads.

The objectives: Build once, run everywhere — share code, pipelines, tests, and assets

Braumann distills the drivers into concrete targets:

• Share code instead of maintaining separate Go, JavaScript/TypeScript, and Kotlin bases.
• One build process instead of a separate pipeline per platform.
• Unified tests that exercise core functionality across all targets.
• Shared assets (logos, components, styles). Rebranding should be as simple as replacing a single image—propagating across apps, something the Kaleido rebrand made painfully clear.
• Fix bugs once. Today, fixes often require triaging three implementations, three test paths, and multiple people with different stacks.

The North Star is a single codebase, a single delivery/testing backbone, a common UI component library, and a cleaner path for future expansions.

Cross-platform vs. multi-platform: The crucial distinction

“Cross-platform” commonly means one codebase for iOS and Android. remove.bg needs more. “Multi-platform” here means:

• Mobile: iOS and Android
• Desktop: macOS, Windows, Linux
• CLI: no GUI, but part of the same code world

That difference matters: desktop is a first-class channel (batch workflows, Photoshop export, templates), and the CLI is already entrenched in automation-heavy operations. Unifying only mobile won’t solve the broader problem.

What was evaluated — and why it wasn’t enough on its own

Mobile: React Native (with Expo) vs. native

Two mobile paths were tested:

• A React Native prototype using Expo—“really nice” to develop with.
• A fully native approach replacing the WebView and integrating functionality natively.

Both worked as proofs of concept. But React Native would still be “a separate codebase,” not a solution for desktop and the CLI. Native would remain isolated by design.

CLI: Node.js packaging and Rust as an alternative

The CLI could be implemented in Node.js with packaging. The resulting binary is “quite big” (around 80 MB due to the embedded runtime), but viable and attractive for JavaScript-oriented teams. Rust was considered briefly but deemed “very exotic.”

Desktop: Modernize Electron

On desktop, “stick with Electron, but update” was the straightforward baseline. Still, that doesn’t address the core pain: separate stacks, pipelines, and tests.

The takeaway: each option works on its own, but none unifies mobile, desktop, and CLI under one architectural roof.

Flutter as the multi-platform candidate: One language (Dart), one framework, many targets

Braumann’s proposal: Flutter. In the talk, he cites version 2.5, developed and supported by Google and free to use. Crucially, it’s more than cross-platform—it’s multi-platform:

• Mobile: Android and iOS
• Desktop: macOS, Windows, Linux—with GUI
• CLI: no GUI needed, but enabled via Dart libraries
• Bonus: web target available

The vision: a shared component for authentication, API key validation, and the core background removal action, with platform-specific shells for UI and OS integrations.

CLI in Dart: a pragmatic entry point

For the CLI, Braumann suggests a Dart library approach. There’s no prototype yet. He references a public “weather CLI in Dart” as a starting point. The idea is to adapt that pattern for remove.bg with minimal friction.

Mobile and desktop: one UI codebase with platform-specific look-and-feel

Braumann shows a small Android prototype built in Flutter. It’s interactive with menus and buttons, and the Flutter ecosystem brings “a lot of libraries” for UI components and animations.

On iOS, the same code looks “quite similar,” with native styling differences. For desktop, the same code runs too: “Just say Flutter run macOS”—and analogously for Windows and Linux. If needed, the desktop GUI can diverge from mobile patterns (e.g., fewer mobile-specific side menus) without touching the shared core.

Bonus: build for the web

As a bonus, the same code can be deployed to the browser. remove.bg already has a website, but the point stands: Flutter’s reach includes the web, which underscores the breadth of the approach.

Pipeline, tests, and assets: what consolidation unlocks in practice

Braumann’s goals translate into operational wins—if the architecture truly centralizes the right parts:

• Single build process: rather than one CircleCI (or similar) pipeline per platform, a consolidated flow that produces mobile, desktop, and CLI from the same codebase.
• Shared tests: core capabilities—“remove background,” login, key validation—run as a unified test suite across targets. No need to reinvent tests in three stacks.
• Shared assets and components: logos, icons, styles, UI pieces—defined once and propagated everywhere. Rebranding becomes controlled updates of a small set of artifacts rather than parallel edits in siloed projects.
• One-pass bug fixing: “In the future, it would be nice to have only one person fixing the bug, building it, and shipping it”—instead of three teams patching three variants.

The hard question: throw away old code and rebuild once?

This is the crux: Should remove.bg re-implement existing functionality in Flutter? The current stacks already encapsulate years of bug fixes and edge cases.

Braumann’s framing: rewrite “from scratch,” but only once. The payoff is a future where enhancements, fixes, and tests flow to all platforms together.

Risks remain:

• New tech stack: the team would need to learn Dart and Flutter—including the unknown unknowns.
• Desktop support: marked “in beta”—by Braumann’s assessment stable, but not final.

Flutter’s pros and cons — as summarized in the talk

Braumann boils it down clearly:

Pros:

• Multi-platform, not just cross-platform
• Single codebase across targets
• Native apps (no Xamarin-like intermediary layer)
• Backed by Google
• Development in Android Studio (or VS Code), with Android Studio being excellent for debugging

Cons:

• New stack, limited team experience
• Unknown risks (“what breaks on which devices?”)
• Desktop support still “beta”

Architectural sketch: shared core with thin platform shells

While the talk doesn’t include diagrams, the intended shape is clear:

• Core library (Dart):
• Authentication
• API key validation
• Core background removal action
• Shared error handling and logging
• Unified test suite
• Platform shells:
• CLI: a Dart entry point without GUI; terminal I/O; per-OS packaging
• Mobile: Flutter UI plus OS integrations like Android/iOS sharing; in-app purchases on mobile as a future target
• Desktop: Flutter UI (optionally with desktop-specific layouts); OS-native integrations (file dialogs, drag-and-drop, filesystem access)
• Web (optional): a browser build when it adds value
• Asset and branding layer:
• Logos, colors, typography, icons, UI components—centrally managed

This addresses today’s pain: three islands of code with duplicated assets and divergent pipelines.

What about batch, Photoshop export, and templates?

The desktop app’s special strengths include batch processing, Photoshop export, and template-driven bulk transformations. The talk doesn’t detail the Flutter implementation. It does indicate the architectural path:

• Batch remains a concern of the shared core (API calls, file handling), with desktop UI optimized for those flows.
• Photoshop export and templates would anchor in the desktop layer where OS-specific hooks are needed, while keeping as much logic (parsing, validation, status) centralized in Dart as feasible.

The key is defining the right core abstractions so these features don’t become platform silos again.

Closing the mobile gaps: iOS and in-app purchases

Two explicit gaps today:

• No iOS app.
• No in-app purchases; purchases happen on the web.

Under Flutter, both are within reach in the same codebase. The talk doesn’t prescribe implementation details; the direction is clear: mobile expansion becomes an extension of the shared stack, reusing UI components and tests.

Thinking pragmatically about the CLI

The CLI matters in automation-heavy workflows. Braumann’s Dart-first suggestion is pragmatic—especially because it immediately ties the shared core to a no-UI target.

Operational guardrails (as implied by the talk):

• No GUI needs; quick bootstrapping in Dart
• Focus on batch and automation—where remove.bg shines
• Per-OS packaging, aligning with today’s Homebrew distribution

Lessons we took from the session

From an engineering standpoint, three points stood out:

1) Multi-platform means desktop and CLI are first-class.

• Consolidating mobile alone won’t meet remove.bg’s needs. Desktop features like Photoshop export and batch templates are central—and CLI is vital for automation.

2) The real payoff of a shared codebase is tests, assets, and pipelines—not just shared UI.

• The target isn’t “write less UI twice,” it’s “centralize core logic, branding, and quality assurance.”

3) Flutter offers the broadest target surface today—with calculated risks.

• One stack for mobile, desktop, CLI (and optionally web) is compelling. The “beta” label on desktop and the Dart/Flutter learning curve are real, but the trade-off is justified by the current fragmentation.

An open invitation and next steps

Braumann emphasizes that no final decision has been made. The call is open:

• Do you have Flutter experience?
• Alternative frameworks to consider (React Native desktop support is mentioned as “very early stage”)?
• Interested in implementing the strategy?

You can explore the apps and the API—feedback is welcome. The talk signs off with a light-hearted hiring note and a reiteration: ideas and contributions are invited.

Conclusion: A pragmatic path to multi-platform — with the courage to consolidate

Our DevJobs.at takeaway from “Multiplatform Strategy for the remove.bg Apps” by Andreas Braumann (Canva Austria GmbH.): the vision is both pragmatic and ambitious. Pragmatic, because it respects today’s strengths (batch, CLI, desktop specialties) and channels them through a shared Dart/Flutter core. Ambitious, because it accepts a rebuild—“write it once”—in exchange for a setup where fixes, rebrands, tests, and releases flow across all platforms together.

That shift turns cross-platform into multi-platform: one codebase, multiple targets, focused on what makes remove.bg valuable—fast, reliable background removal across contexts, whether as a GUI, a mobile app, or a CLI. The next step is a decision. This session sets the table—with Flutter as a serious front-runner.

• 

  

  Visual AI Made Simple

  René Koller von kaleido erläutert in seinem devjobs.at TechTalk, wie das Devteam das Konzept von MVC auf MVVC erweitert hat und wie es zum Einsatz kommt.

  Watch now
• 

  

  Integrating Lorem Picsum into Canva

  Andreas Braumann von Kaleido demonstriert in seinem devjobs.at TechTalk in einer Live Coding Session, wie man das Tool Lorem Picsum als eine Content Extension in Canva integriert.

  Watch now
• 

  

  DALL·E 2: Image generation with visual AI

  David Estévez von kaleido spricht in seinem devjobs.at TechTalk über die Funktionsprinzipien von Visual AIs – und welche neuen Möglichkeiten immer leistungstärkere Tools mit sich bringen.

  Watch now
• 

  

  Software Engineering at kaleido.ai

  Riccardo Porrini von kaleido spricht in seinem devjobs.at TechTalk darüber, wie sich die Devteams während des Wachstums des Unternehmens organisiert haben.

  Watch now