Swif simplifies software deployment across Windows, macOS, and Linux by allowing you to upload custom installers or scripts directly within the Swif console. This article provides detailed steps, supported formats, silent installation options, validation rules, and useful script examples.
Supported Package Formats
Windows
.msi,.ps1,.exe,.nupkg(Chocolatey packages)
macOS
.pkg,.dmg,.zip,.app
Linux
Package Formats:
.deb,.rpm,.tar,.zip,.archor package managerPackage Managers: APT, DNF, Flatpak, Pacman, RPM, Snap, YUM, Zypper
macOS Installation Options
Install on Logged-In Users Only
When uploading custom packages for macOS, you have the option to enable "Install on logged-in user accounts only". When enabled, the custom package will only install on macOS devices where a user is actively logged in. This option is recommended for installations that require user-specific settings or inputs.
ZIP and APP Files with Pre-Install Scripts
Swif supports uploading .zip and .app files directly for macOS. When using these file types, a pre-install script is required. The script supports the {{URL}} template variable, which Swif automatically replaces with the installer path once uploaded.
Example usage in a script:
Silent Installation (Windows)
Silent installation helps deploy software without user interaction. The specific silent-install arguments depend on your installer type:
MSI Installers typically use arguments like
/quietor/qn.EXE Installers vary widely; check your software documentation for supported silent install arguments (examples:
/s,/silent,/quiet).Chocolatey packages by default install silently.
You can specify multiple arguments by typing each into the Arguments field and pressing Enter.
Note: If no silent arguments are provided or supported, the installer will run visibly and require manual user interaction.
Linux External Repository URL
For Linux software installations using a package manager, you can optionally specify an External Repository URL to add external software repositories directly within Swif:
Repository URL: URL of the repository hosting the software.
Distribution (DEB only): Specify the Linux distribution name when using DEB repositories (e.g., stable).
Components (DEB only): Define repository components (e.g., main, universe) for DEB repositories.
Arch: Optional architecture specification (e.g., amd64).
Repo ID (ARCH only): Provide the repository identifier specifically for ARCH-based Linux distributions.
Key Source: URL for the GPG key server.
Received Keys: Optional GPG keys to verify packages.
This feature allows Swif to securely access and install packages directly from external repositories.
Pre-install and Post-install Scripts
Pre-Install Command Script: Pre-install script performs an action before installation occurs.
Post-Install Command Script: Post-install script runs after the installation.
Example install Pre-Install Command Script for Windows:
# Pre-Install Command Script Example
if (Test-Path "C:\Program Files\App\app.exe") {
exit 0
} else {
exit 1
}
Using Installer URL for Scripting
After uploading a custom package, Swif provides an S3 URL on the package details page. This URL ({{URL}}) can be used directly in your pre-install script to reference the uploaded installer dynamically. This simplifies script creation and allows automation of installer retrieval and execution.
Example usage in a script:
#!/bin/sh
curl {{URL}} -o /tmp/installer.zip
unzip /tmp/installer.zip -d /Applications
Windows Validation Rules
Swif verifies successful installation through these validation rules:
File Check:
Path: C:\Program Files\MyApp\app.exe
Registry Check:
You can find Name and Version from Registry Key: HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\MyApp
Name: DisplayName
Version: DisplayVersion
Script (Install Check Script):
The script runs before the pre-install command script. If you want to indicate that the application is installed, return the value 1, and to indicate that it is not installed, return 0.
Script example:
if (Test-Path "C:\Program Files\MyApp\app.exe") {
exit 1
} else {
exit 0
}
macOS Validation Rules
Swif validates custom installations on macOS using four types of rules:
Application: Swif checks installation using the app's
PathandIdentifier.
Bundle: Validates the existence of the app bundle.
File: Checks for specific file presence.
Script: Executes custom scripts for validation.
Install Check Script:
The script runs before the pre-install command script. If you want to indicate that the application is installed, return the value 1, and to indicate that it is not installed, return 0.
Script example:
#!/bin/sh
version=\"$(python -c 'import argparse;print argparse.__version__' 2>/dev/null)\"
if [ ${version:-0} < 1.2.1 ]; then
exit 0
else
exit 1
fi
Uninstall Script:
The script will be used to remove the application.
Script example:
#!/bin/bash # Sample Uninstall Script
/usr/bin/sudo rm -rf /Applications/MyApp.app
exit 0
Uninstall Check Script
The script determines whether or not an application should be removed. In this case, the script would provide an exit code of 0 to indicate that the item is currently installed and that removal should occur. All non-zero exit codes indicate that the item in question is not installed.
Script example:
#!/bin/sh
if [ -e "/Applications/OneDrive.app" ]; then
exit 0
else
exit 1
fi
Linux Validation Rules
Swif validates custom installations on Linux has these options:
Path: Specify the exact file location. Swif checks this location to confirm if the file exists, indicating a successful installation.
Hash: Provide the file's hash value. Swif compares this value to the file located at the specified path to verify that the correct version or file is installed.
Install Check Script:
The script runs before the pre-install command script. If you want to indicate that the application is installed, return the value 1, and to indicate that it is not installed, return 0.
Script example:
#!/bin/sh
version=\"$(python -c 'import argparse;print argparse.__version__' 2>/dev/null)\"
if [ ${version:-0} < 1.2.1 ]; then
exit 0
else
exit 1
fi
Uninstall Script:
The script will be used to remove the application.
Script example:
#!/bin/bash # Sample Uninstall Script
/usr/bin/sudo rm -rf /Applications/MyApp.app
exit 0
Deploying Custom Software
Simply follow these steps:
Go to the Swif Console.
Navigate to Device Management > Applications > Add Custom Application.
Upload your installer (
.msi,.exe,.pkg,.deb, etc.).Assign directly to selected device(s) or groups.
Swif handles distribution automatically.
Checking Installation Status
Go to Devices > Select the desired device > Installed Applications to confirm successful installation.
Updating or Removing Software
Updates: Upload a new installer version directly to Swif.
Removal: Use an uninstall script or remove software manually via Swif Console.
Frequently Asked Questions
Can I host installers externally?
No. Installer files must be uploaded directly to Swif.
What happens with non-silent installers?
Installers without silent flags will launch on user devices, prompting users for manual confirmation.
Do I need different installers for 32-bit and 64-bit?
Yes. Provide separate installers as needed and clearly specify architectures.
Additional Tips
Always test installers with silent flags before deployment.
Use validation scripts to ensure accurate installation tracking.
Need Help?
For assistance or further information, please contact Swif Support or visit our Help Center.
Last Updated: March, 2025