Fyne 2.8.1 uses one Go widget API across desktop and mobile
Fyne 2.8.1 gives Go developers a direct route to windows, layouts, widgets, dialogs, menus, preferences, and app packaging. The first README example is a complete window with a label and button, written in ordinary Go callbacks. The same project can target desktop systems and mobile devices, with a mobile simulation tag available during development. That is the appeal: you keep application logic and interface code in one language.
The consistency comes from Fyne's own Material-inspired toolkit rather than native operating-system controls. That makes a 2.8.1 app look related across platforms, but it also means your product inherits Fyne's rendering, input, and accessibility behavior. Teams choosing it should like that visual identity. If a macOS app must look and behave exactly like AppKit, or a Windows app must follow every native convention, the shared widget layer works against the requirement.
Go 1.22 and a C compiler sit behind the short starter app
The README requires Go 1.22 or later and a C compiler, though its starter program is small enough to understand in one sitting. You create an app, open a window, assign content, and call ShowAndRun. Adding the module uses standard Go commands, while the separate Fyne utility handles icons, installation, mobile packages, and store releases. The docs also point to a widget demo and a separate examples repository, which is more useful than a page of isolated API signatures.
That simple source file still relies on the development tools for the host system. Android and iOS add their own SDK, device, signing, and store requirements. The README also warns that the first Windows compilation can take up to 10 minutes. A team should prove the full release path early, not stop after a local desktop window opens.
What happened when we ran it
Our sandbox installed Fyne in 24 seconds and added 69 packages. We cloned commit a978f1c and built it in a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. The build succeeded in 37 seconds. The checkout contained 2,148 files and about 147,534 lines of source, so that clean build is a useful result for a toolkit that carries desktop, mobile, and web backends in one repository.
The test step failed with exit code 1 after 41 seconds. Go reported 76 passed and 25 failed out of 101 test packages. The supplied log tail lists successful packages such as layout, storage, theme, and widget, then ends with FAIL. It does not name the failed packages or show their errors, so we cannot assign a cause. The safe conclusion is narrower: commit a978f1c built, but its full test command did not pass in our stated sandbox.
The repository has 4 CI workflow files and a tests directory, but no Dockerfile. That fits a library whose real targets are host operating systems, though it leaves container users to assemble the C and graphics dependencies themselves. Our measurement covers repository setup and checks. It does not show whether a packaged window draws correctly, whether touch input feels right, or whether a signed mobile build reaches a store.
Cross-platform still means testing each target
Fyne's recent work shows why platform testing stays part of the job. Release v2.8.1 fixed Windows URI handling, Android keyboard input, macOS menu refreshes, KDE Wayland tray behavior, touchscreen taps, and several rendering cases. Those are practical fixes, and they also map the size of the compatibility surface. A shared API removes duplicate application code. It cannot make Windows, Wayland, Android, and iOS behave alike underneath.
Open reports remain specific. Issue 6540 describes a Wayland crash when the monitor holding a window disappears. Issue 6541 says a packaged web app calls preventDefault() for every key event, blocking shortcuts such as browser reload and numbered tab selection while the canvas is focused. On Android, issue 6527 reports a dialog recentering as the soft keyboard closes, which can move buttons during the tap meant to press them. These reports need reproduction before they become release blockers, but they are credible test cases to add.
Three open issues leave accessibility work for the application team
Open issues 6491, 6492, and 1515 leave concrete gaps in the macOS accessibility tree and keyboard behavior. Open issue 6491 reports that, on macOS with the accessibility build tag, labels inside widget.Card disappear from the Accessibility tree. Issue 6492 reports an unnamed system-tray item under the same setup. A longer-running keyboard-access issue still has unchecked behavior for accordions, tabs, and sliders.
Those gaps matter differently by product. An internal status panel used by a known team may be able to avoid the affected widgets. A public app subject to a screen-reader audit cannot accept that uncertainty. Build with the documented accessibility tag, inspect the resulting tree, and run VoiceOver plus keyboard-only tests on the shipping UI. The 25 failed test packages from our run make that independent check more important, even though the log does not connect those failures to accessibility.
Current maintenance is active, with a large open queue
GitHub showed 28,724 stars and 745 combined issues and pull requests when fetched. The last push was September 27, 2026, one day before this review, and recently reported defects were also being closed in September. Release v2.8.1 arrived on August 26 with performance changes and a long fix list. That is active maintenance, not a project coasting on an old tag.
The open queue is still substantial for a GUI foundation. Read it by target instead of treating 745 as a quality score. A Linux desktop team should filter for Wayland and X11, a mobile team for keyboard and touch reports, and a web team for the canvas backend. Fyne is a sensible choice when Go ownership and a shared interface outweigh native fidelity. The cost is a platform test matrix that your application still has to own.