Taking a Flutter invoice tool for small shops from mobile to Windows and macOS, what breaks beyond the UI, and how do you package it for each OS?

## What breaks first: plugins A Flutter plugin has a Dart API and a separate native implementation per platform. A mobile app's plugins may have no Windows or macOS implementation at all. The failure is quiet at build time and loud at runtime: the app compiles, and the first call into the plugin typically throws **`MissingPluginException`**, because no native code answered its method channel (some plugins throw an `UnimplementedError` from their platform interface instead). Before promising a desktop release: 1. List every plugin in `pubspec.yaml`, including transitive ones. 2. Check each one's supported platforms, and whether its desktop implementation covers the features you use. 3. For gaps, pick an alternative package, write the native code yourself, or disable the feature on desktop behind a platform check. 4. Run the app on each desktop OS and exercise every plugin-backed feature, since unit tests on one machine will not reveal a missing implementation. For the invoice tool, printing, file export, secure credential storage and barcode scanning are the likely gaps. ## What breaks next: platform rules - **macOS sandbox.** The template enables App Sandbox; network calls need `com.apple.security.network.client`, and saving user-chosen files needs `files.user-selected.read-write`, in both entitlement files. - **Window defaults.** The runner's initial size (1280 by 720 on Windows, 800 by 600 on macOS) rarely fits a data-entry tool; adjust it in the runner. - **Input expectations.** Hover, right-click menus and a menu bar are expected on desktop, and file paths, fonts and scaling differ by OS. ## Packaging for Windows `flutter build windows` produces a **directory**, not a single file: `build\windows\x64\runner\Release` containing - the app's `.exe`, named by `BINARY_NAME` in `windows/CMakeLists.txt`; - `flutter_windows.dll` and any plugin DLLs; - the `data` directory with the compiled app and assets. Copying only the `.exe` fails. A zip must include all of it plus the **Visual C++ redistributable** DLLs (`msvcp140.dll`, `vcruntime140.dll`, `vcruntime140_1.dll`) or an installer that brings them. The modern installer format the Flutter docs describe is **MSIX**: | Channel | Signing | |---|---| | Microsoft Store | the Store creates and manages the certificate | | Your own website | a certificate from a certificate authority Windows trusts | | Internal testing | a self-signed `.pfx` installed as trusted on test machines | The Flutter docs point to the community `msix` pub package, configured through an `msix_config` section in `pubspec.yaml`. The version in `pubspec.yaml` flows into the executable: the build name becomes the first three parts of the file version and the build number the fourth. Validate packages with the Windows App Certification Kit before submitting to the Store. ## Packaging for macOS `flutter build macos` produces an `.app` bundle. For the Mac App Store, register the app in App Store Connect, keep App Sandbox on, then archive and upload from Xcode. Outside the store, the app must be signed and notarized under Apple's rules so Gatekeeper lets users open it. ## Linux, briefly The Flutter docs describe a **snap**: a `snap/snapcraft.yaml` with `plugin: flutter`, the `gnome` extension for the GTK libraries, and `confinement: strict` with plugs such as `network` for each resource the app needs. ## A checklist for the invoice tool 1. Plugin audit per OS, with replacements for gaps. 2. Entitlements for network and user-selected files on macOS. 3. Runner window size and title on both platforms. 4. MSIX with the right certificate for the chosen Windows channel. 5. Release builds tested on clean machines without developer tools installed.