The shinyelectron package (GitHub, documentation) exports a Shiny application as a standalone desktop application for Windows, macOS, and Linux. The core entry point is export(appdir, destdir): it autodetects the app type, defaults to the shinylive strategy, and wraps the result in an Electron shell, so a minimal call needs no other arguments. Depending on the runtime strategy you choose, the people you hand the installer to may not need R or Python installed at all.

This release grows shinyelectron from an R shinylive exporter into a general Shiny-to-desktop toolkit, adding Python apps, five runtime strategies, and multi-app suites.

That one line covers a lot of ground, and I wrote up the full story in reintroducing shinyelectron. The short version: v0.1.0 could take an R Shiny app, compile it to WebAssembly with webR, and package the result. v0.2.0 keeps that path as the default and builds four more around it. Python Shiny apps are now first-class citizens alongside R, autodetected from appdir. The runtime_strategy argument decides how an app runs, and all five options work in both languages: shinylive compiles to WebAssembly and runs offline in the bundled browser, bundled embeds a portable R or Python runtime, system uses an interpreter already installed on the machine, auto-download fetches the runtime on first launch and caches it, and container runs the app in Docker or Podman. If you have several apps to ship, a multi-app suite bundles them into a single Electron shell with a launcher.

The other headline addition is signing. export() and build_electron_app() gained a sign argument that turns on macOS Developer ID signing and Apple notarization along with Windows Authenticode, driven by the usual CSC_* and APPLE_* environment variables. Paired with the new shiny-to-electron GitHub Action, you can build and sign installers for every platform in CI. That is exactly how the prebuilt demo installers in the new Download Prebuilt Demos article are produced, and the macOS demos launch without a Gatekeeper warning as a result. Signing needs a certificate, which on macOS means an Apple Developer Program membership; the Code Signing article covers the full setup.

Installation

shinyelectron is available now from GitHub:

# install.packages("remotes")
remotes::install_github("coatless-rpkg/shinyelectron")

For details, see the shinyelectron news file entry below:

`shinyelectron` news file entry for version 0.2.0

Breaking changes

app_type now takes only "r-shiny", "py-shiny", or NULL (autodetected), and shinylive is a runtime_strategy rather than an app type. The old "r-shinylive" and "py-shinylive" values still work with a deprecation warning and will be removed in a future release.

New features

Python Shiny apps are supported alongside R. app_type autodetects "r-shiny" or "py-shiny" from appdir, so export(appdir, destdir) works with no other arguments.
runtime_strategy selects how an app runs, and all five strategies work with both languages: shinylive (the default; compiled to WebAssembly and run offline in the browser), bundled (embeds a portable R or Python runtime), system (uses an installed interpreter), auto-download (fetches the runtime on first launch), and container (runs in Docker or Podman).
Multi-app suites bundle several apps into one Electron shell with a launcher. An apps array in _shinyelectron.yml lists them, and each app can set its own runtime_strategy.
export() and build_electron_app() gain a sign argument for macOS signing and notarization and Windows Authenticode, driven by the usual CSC_* and APPLE_* environment variables.
enable_auto_updates(), disable_auto_updates(), and check_auto_update_status() manage electron-updater configuration.
install_r_portable(), install_python_standalone(), and install_nodejs() download and cache portable runtimes, and cache_dir(), cache_info(), and cache_remove() inspect and prune the cache.
dependencies.r.version, dependencies.python.version, and dependencies.electron.version pin the versions a build uses; each accepts null, "latest", or an exact version.
App dependencies are detected automatically for native, bundled, and container builds, from library() and require() calls for R and requirements.txt or pyproject.toml for Python.
A configurable lifecycle splash and preloader report startup progress, and a system tray and application menu are set through _shinyelectron.yml.
The Electron shell streams the renderer console (webR, Pyodide, and Shiny output) into the app log, so browser-side messages and errors appear alongside the main-process logs.
app_check() validates an app before building, wizard() generates a config interactively, show_config() prints the merged configuration, and available_examples() and example_app() browse the bundled demos.
app_dependencies() reports the R or Python packages a Shiny app or multi-app suite uses, which helps install an app’s dependencies before a shinylive build.
Apps can supply a Posit _brand.yml for theming.
Prebuilt demo installers are published for every strategy and platform, listed in the new Download Prebuilt Demos article.

Minor improvements and fixes

The runtime_strategy argument overrides a suite’s build.runtime_strategy for apps that set no per-app strategy, so a suite built as shinylive really is shinylive rather than falling back to the config default.
A _brand.yml that names palette colors (for example primary: plum) resolves those references before theming the shell.
Error screens allow selecting and copying the message and log details.
Building with the shinylive strategy checks that the app’s R packages are installed and names any that are missing, since shinylive::export() compiles the WebAssembly bundle from installed packages.
build_electron_app() refuses to overwrite protected directories such as ~, /, and R.home().
export() cleans up partial output when a build fails, so a retry no longer needs overwrite = TRUE, for both single apps and multi-app suites.
run_electron_app() reports the real exit code and stderr on failure.
sitrep_shinyelectron() also checks the Python shinylive CLI and shiny package.
The system strategy checks for R >= 4.4.0 or Python >= 3.9.0 and fails with an actionable message.
Downloaded runtimes are verified against upstream SHA-256 checksums before extraction.
Vignettes cover getting started, configuration, runtime strategies, multi-app suites, code signing, containers, security, and auto-updates.

GitHub Repository

References