Brett Owers
← All Projects

Flutter Plugins

Archived

May 1, 2019

A fork of the official Flutter plugins repository — the reason is lost to time, but the concept is not. A deep exploration of what plugins actually are, how they differ from packages, and why plugin development is a genuine avenue for creating value across every platform from VS Code to Slack to Maven.

Purpose

Forked the official flutter/plugins repo. Honestly, I do not remember exactly why. But the fork itself is less important than the world it points to: plugin development is one of the most underappreciated ways to create value in software. Understanding the plugin model — what it is, how it works, and where it applies — opens doors that pure application development does not.

Stack

FlutterDartPlugin ArchitecturePlatform ChannelsOpen Source

What I Learned

  • A plugin is not the same as a package. A package is pure code in the host language — a Dart package runs entirely in Dart, an npm package runs entirely in JavaScript. A plugin bridges the host language to native platform capabilities that the language cannot access on its own. A Flutter plugin contains Dart code on top plus native Kotlin/Swift code underneath, communicating through platform channels. A VS Code extension is a plugin that bridges TypeScript to the editor's internal APIs. The distinction matters: packages extend the language, plugins extend the platform.
  • Flutter's plugin system uses platform channels — a message-passing bridge between Dart and native code (Kotlin/Java on Android, Swift/Objective-C on iOS). You define a method channel with a name, send a message from Dart, receive it in native code, do the platform-specific work (access the camera, read GPS, trigger haptics), and send the result back. It is an RPC layer between two runtimes, and understanding it demystifies every Flutter plugin you will ever use.
  • VS Code extensions are plugins that run in a Node.js process alongside the editor. They access the VS Code API to add commands, language support, themes, debuggers, and UI panels. The extension manifest (package.json with special fields) declares activation events, contribution points, and capabilities. The barrier to entry is shockingly low — a working VS Code extension can be built and published in an afternoon.
  • Slack apps and bots are plugins for a communication platform. They use webhooks, slash commands, and the Slack API to add functionality directly into the workspace — automated standup reports, deployment notifications, approval workflows. Slack's Block Kit gives you a UI framework for building interactive messages. For a team-oriented brand, Slack plugins are a direct channel to where people already work.
  • IntelliJ/JetBrains plugins extend the IDE using Java and the IntelliJ Platform SDK. They can add inspections, refactorings, tool windows, language support, and integrations. The ecosystem is smaller than VS Code's but the audience (enterprise Java/Kotlin developers) has higher willingness to pay for productivity tools.
  • Maven plugins are a different beast entirely — they extend the build system, not a user-facing application. A Maven plugin defines goals (compile, test, package, deploy) that hook into the build lifecycle. Plugin management in Maven (the pluginManagement section of pom.xml) controls which versions of which plugins are used across a multi-module project. Gradle has the same concept. The lesson: plugins are not just for user-facing apps. Build tools, CI systems, and infrastructure are all plugin-driven.

Key Insights

  • Plugin development is a genuine avenue for creating value because plugins live where users already are. A standalone app asks users to change their behavior — download this, open this, learn this. A plugin meets them in their existing workflow — their editor, their chat tool, their browser, their build system. The adoption curve is fundamentally different. A VS Code extension that saves 30 seconds per hour does not need a landing page or a marketing budget. It needs to be in the marketplace with a clear description.
  • The plugin model shows up everywhere because it solves the same problem everywhere: a platform cannot anticipate every use case, so it exposes extension points and lets the community build what it cannot. Chrome extensions, WordPress plugins, Shopify apps, Figma plugins, GitHub Actions, Claude Code skills — they are all the same pattern. Learn the pattern once, apply it to any platform.
  • The business case for plugins is compelling: the platform handles distribution, updates, and often payments. The Shopify App Store, the VS Code Marketplace, the Chrome Web Store — these are storefronts where the platform does the marketing by recommending your plugin to users who need it. You build the thing, the platform finds the audience. This is the inverse of building a standalone product where distribution is the hardest part.
  • For someone looking to create their first piece of value as a developer, a plugin is the shortest path. Pick a platform you use daily, identify a friction point, build a plugin that removes it, publish it. You will learn the extension API, experience the publish process, and have a public artifact that demonstrates both technical ability and product thinking. It is a faster, more credible signal than a portfolio of tutorial projects.
#Flutter#plugins#VS-Code#Slack#IntelliJ#Maven#Chrome-extensions#plugin-architecture#platform-channels#open-source#value-creation#extensions

This post was composed through a conversation between Brett Owers and Claude Code (Anthropic). The content reflects Brett's recollection of each project and the lessons drawn from it. Some details may be approximate or omitted — the purpose is to paint an honest picture of a software engineer's development over time, not to serve as a precise historical record.