pub struct AppConfig {
pub windows: Vec<WindowConfig>,
pub security: SecurityConfig,
pub tray_icon: Option<TrayIconConfig>,
pub macos_private_api: bool,
pub with_global_tauri: bool,
pub enable_gtk_app_id: bool,
pub app_directories_override: Option<AppDirectoriesOverride>,
}Expand description
The App configuration object.
Fields§
§windows: Vec<WindowConfig>The app windows configuration.
§Example:
To create a window at app startup
{
"app": {
"windows": [
{ "width": 800, "height": 600 }
]
}
}If not specified, the window’s label (its identifier) defaults to “main”,
you can use this label to get the window through
app.get_webview_window in Rust or WebviewWindow.getByLabel in JavaScript
When working with multiple windows, each window will need an unique label
{
"app": {
"windows": [
{ "label": "main", "width": 800, "height": 600 },
{ "label": "secondary", "width": 800, "height": 600 }
]
}
}You can also set create to false and use this config through the Rust APIs
{
"app": {
"windows": [
{ "create": false, "width": 800, "height": 600 }
]
}
}and use it like this
tauri::Builder::default()
.setup(|app| {
tauri::WebviewWindowBuilder::from_config(app.handle(), &app.config().app.windows[0])?.build()?;
Ok(())
});security: SecurityConfigSecurity configuration.
tray_icon: Option<TrayIconConfig>Configuration for app tray icon.
macos_private_api: boolMacOS private API configuration. Enables the transparent background API and sets the fullScreenEnabled preference to true.
with_global_tauri: boolWhether we should inject the Tauri API on window.__TAURI__ or not.
enable_gtk_app_id: boolWhether the application identifier is used as the GTK application ID on systems that use GTK.
Setting the GTK application ID lets the desktop environment associate the app’s windows with
its .desktop entry of the same name, which is what makes Wayland compositors and GNOME show
the correct icon and application name, and group the windows in the dock or taskbar.
Defaults to false, because registering an application ID also makes GTK register the
application on the session bus under that ID, which prevents running more than one instance
of the app at the same time.
§Platform-specific
- Linux / FreeBSD / DragonFly / NetBSD / OpenBSD: The identifier must be a valid GTK application ID.
- Windows / macOS / Android / iOS: Unsupported.
app_directories_override: Option<AppDirectoriesOverride>Overrides the directories returned by the app_*_dir path APIs (app_config_dir, app_data_dir,
app_local_data_dir, app_cache_dir and app_log_dir) and the matching $APPCONFIG, $APPDATA,
$APPLOCALDATA, $APPCACHE and $APPLOG base directory variables.
This is useful for portable apps that keep all of their data next to the executable,
and for apps that want their app directories in a location they choose, such as $DOCUMENT/my-app.
Everything that resolves paths through these APIs follows the override, including Tauri itself
(the default webview data directory on Windows and Linux) and plugins,
so the storage locations do not need to be configured one by one.
The only exception is a window’s dataDirectory config, which is not affected.
It can also isolate the data of a development build from an installed version of the app,
though a distinct identifier for development builds achieves that while keeping the production directory layout.
The value is either a single path used as the root of every app directory
(config, data and local data resolve to the root itself, cache to <root>/caches and log to <root>/logs),
or an object that overrides individual directories (config, data, localData, cache and log),
each resolving to exactly the configured path. Directories that are not listed in the object keep their default location.
Each path is resolved as follows:
- A path starting with a base directory variable is resolved relative to that directory.
The supported variables are
$AUDIO,$CACHE,$CONFIG,$DATA,$LOCALDATA,$DESKTOP,$DOCUMENT,$DOWNLOAD,$HOME,$PICTURE,$PUBLIC,$TEMPand$VIDEO...components are kept, so$DATA/../my-apprefers to a sibling of the data directory. - An absolute path is used as is.
- Any other path is resolved relative to the directory containing the executable, which must be writable, see the platform-specific notes below.
§Examples
Keep all data in an app-data folder next to the executable, for a portable build:
{
"app": {
"appDirectoriesOverride": "./app-data"
}
}Only move the logs and the cache:
{
"app": {
"appDirectoriesOverride": {
"log": "$DATA/my-app/logs",
"cache": "$CACHE/my-app"
}
}
}Set the override at runtime, for instance from an environment variable, a command line flag
or a directory picked by the user, by modifying the config returned by tauri::generate_context!()
before building the app:
use tauri::utils::config::AppDirectoriesOverride;
fn main() {
let mut context = tauri::generate_context!();
if let Ok(data_dir) = std::env::var("MY_APP_DATA_DIR") {
context.config_mut().app.app_directories_override =
Some(AppDirectoriesOverride::Root(data_dir.into()));
}
tauri::Builder::default()
.run(context)
.expect("error while running tauri application");
}§Security
Scopes and permissions that use the $APPCONFIG, $APPDATA, $APPLOCALDATA, $APPCACHE and $APPLOG
variables follow the override, so the configured paths must be directories dedicated to the app.
A single root is used as is for the config, data and local data directories, so a root that is not dedicated
to the app, such as "./" or "$DOCUMENT", extends those scopes to everything it contains.
With "./", fs:default (which allows reading the app directories recursively) lets the webview read
every file next to the executable, including anything else in the folder the app was run from,
such as the downloads folder. If the app also grants write access to an app directory, a compromised webview
(e.g. through XSS) can replace files next to the executable, such as dropping a DLL that Windows loads
from the executable’s directory on the next launch, leading to code execution.
Always point the override to a subfolder owned by the app, such as "./app-data" or "$DOCUMENT/my-app".
§Platform-specific
A path relative to the executable only works where the executable’s directory is writable:
portable builds, tauri dev builds in the target directory and the cases listed below.
Everywhere else every write to an app directory fails at runtime, so installed apps should use
a base directory variable or an absolute path instead. Unless every distribution of the app is portable,
keep relative paths out of the shared configuration and apply them to the portable build flavor only,
for instance with the CLI’s --config flag, which accepts a JSON file or an inline JSON string:
tauri build --config '{ "app": { "appDirectoriesOverride": "./app-data" } }'- Linux: Relative paths only work for AppImages, where they are resolved relative to the AppImage file,
as long as it is kept in a writable directory.
.deband.rpmpackages install the executable to/usr/bin. - macOS: Relative paths are resolved next to the
.appbundle. This does not work for installed apps, since/Applicationsis not writable for standard users, nor for bundles downloaded from the internet, which run from a random read-only location (App Translocation) until the user moves them out of the quarantined folder. - Windows: Relative paths also work for per-user NSIS installers,
but not for per-machine installers in
Program Files. - Android / iOS: Relative paths are not supported, since there is no writable directory next to the executable.
Use a base directory variable or an absolute path instead.
$DESKTOPis not available on Android.