Skip to main content
All CollectionsOnboarding & OffboardingSoftware installation
Installing Custom Software via Swif
Installing Custom Software via Swif
Updated this week

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, .arch or package manager

  • Package 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 /quiet or /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.

Linux using a .tar Archive

If you need to place files in specific system paths on Linux (for example, /etc/cups/ppd/ for printer drivers), simply including the directory structure in a tar archive will not suffice. Instead, there are 2 methods to copy the files to the desired location.

Method 1: With a Makefile

When installing custom software on Linux via Swif using a .tar archive, a Makefile can automate the installation process:

  1. Create a .tar archive that includes your software files along with a Makefile containing an install target that specifies the necessary installation commands.

  2. Upload the .tar archive to Swif.

  3. Swif extracts the archive and runs the make install command automatically on the target device.

  4. Swif automatically installs the make tool if it's not already available on the target device before executing any make commands.

3.1 Why a Makefile Is Necessary

When Swif installs custom .tar packages on Linux:

  • It unpacks the archive in a temporary directory.

  • It looks for a Makefile and runs make install.

If no Makefile (or install script) is present, the system won’t know how to handle the files beyond extracting them, and your files may never reach their correct destinations.

3.2 Example: Installing a PPD File to /etc/cups/ppd/

Suppose you have a PPD file named Epson-AM-C4000_Series_PS.ppd that must reside in /etc/cups/ppd/. Here’s how to set it up:

  1. Project Structure

    Epson-AM-C4000_Series_PS/ 
    ├── Makefile 
    └── Epson-AM-C4000_Series_PS.ppd

  2. Makefile Contents

    install: 
        # Create the target folder if it doesn't exist 
        mkdir -p /etc/cups/ppd/ 
        # Copy the PPD file into the correct directory 
        cp Epson-AM-C4000_Series_PS.ppd /etc/cups/ppd/

  3. Create the .tar Archive

    cd Epson-AM-C4000_Series_PS 
    tar -cvf Epson-AM-C4000_Series_PS.tar .

    This produces Epson-AM-C4000_Series_PS.tar, containing both the .ppd file and the Makefile.

When you upload this tar file to Swif, the PPD file is copied directly into /etc/cups/ppd/ on the Linux endpoint.

Method 2: Using a Pre-Install Script to Download & Install Manually

If you need even more control—for example, if the .tar file itself contains multiple components or you’d prefer to handle every step with your own script—Swif allows you to fetch the archive via a Pre-Install Script. This method leverages the {{URL}} placeholder, which Swif replaces with a signed download link to your .tar file.

  1. Add a Pre-Install Script in your custom software definition.

  2. In that script, reference {{URL}} to download the .tar file yourself (e.g., with curl or wget).

  3. Extract and run commands as needed (including make install if you still want to use the Makefile).

Example Pre-Install Script (Bash)
​

#!/bin/bash

# 1) Download the tar file
curl -L -o /tmp/mysoftware.tar "{{URL}}"

# 2) Extract it
tar -xvf /tmp/mysoftware.tar -C /tmp

# (You can do any other custom steps here.)

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 Path and Identifier.

  • 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:

  1. Go to the Swif Console.

  2. Navigate to Device Management > Applications > Add Custom Application.

  3. Upload your installer (.msi, .exe, .pkg, .deb, etc.).

  4. 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.

Troubleshooting Installation with Device Logs

If software installation encounters issues, you can review the device logs directly on your device for detailed debugging information.

Log File Locations:

  • Windows:
    ​C:\ProgramData\gorilla\gorilla.log

  • macOS:
    ​/Library/Managed Installs/Logs/ManagedSoftwareUpdate.log

  • Linux:
    ​/var/log/swif-agent.log

Reviewing these logs can help identify issues during software installations or updates managed through Swif.

Frequently Asked Questions (FAQ)

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

Related Articles
Installing Software from the Swif App Store
Deploy the Swif app via Intune by Powershell Script (Deprecated)
How to Enroll Linux Devices in Swif
Deploying Swif Silently on Mac/macOS Machines
Understanding Linux Software Update Policy in Swif
Did this answer your question?