Crash Course: Automating .xccrashpoint Exports in MacOS

As a developer, encountering crashes in your applications is inevitable, and efficiently handling these incidents is crucial for maintaining software quality. Recently, I found myself in a scenario where I needed to export and provide a .xccrashpoint file to a third-party company for further analysis. This requirement quickly turned into a technical adventure, leading me to explore the capabilities of Automator on MacOS to streamline this process.

In this blog post, I will guide you through the steps of creating an Automator script that simplifies the task of exporting .xccrashpoint files. Whether you're looking to enhance your workflow or just curious about automation in MacOS, this post will provide valuable insights into the power of Automator and how it can be applied to real-world development challenges.

What is a .xccrashpoint?

An .xccrashpoint file is an integral part of Apple’s Xcode development environment, specifically designed to capture detailed information about crashes that occur within iOS, macOS, tvOS, or watchOS applications. These files are generated automatically by Xcode when an app crashes during development or testing. They contain critical data such as the state of the application at the time of the crash, stack traces, and other diagnostic information that can be used to analyze and fix bugs.

You can export an .xccrashpoint directly from Xcode. If you open the contents of that folder you will see something like this.

As you can see there are a few .crash files inside the /Logs folder. These files can be read easily and are not dependant on an Xcode.

Bash script to extract those files

With the help of our good old ChatGPT we managed to create a bash script that will go inside an .xccrashpoint and extract/zip those files for us.

#!/bin/bash

# ANSI color codes for coloring the output
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m' # No Color, to reset to the default terminal color

# Verify that a directory has been provided as an argument
if [ $# -eq 0 ]; then
    echo -e "${RED}Usage: $0 <directory>${NC}"
    exit 1
fi

# Assign the first argument as the directory
DIRECTORY="$1"

# Make sure the directory path does not end with a slash for consistency
DIRECTORY="${DIRECTORY%/}"

# Extract the base name for the zip file without the .xccrashpoint extension
BASENAME=$(basename "$DIRECTORY")
BASENAME="${BASENAME%.xccrashpoint}"

# Define the output zip file's name, based on the modified base name
ZIPFILE="${BASENAME}.zip"

# Print the directory being searched
echo "Searching in: $DIRECTORY"

# List .crash files to be zipped
echo "Files found:"
find "$DIRECTORY" -type f -name '*.crash'

# Change to the directory where .crash files are found
cd "$DIRECTORY"

# Use find to locate all .crash files and zip them without the directory path
find . -type f -name '*.crash' -exec zip -j "../$ZIPFILE" '{}' +

# Check if the zip operation was successful
if [ -f "../$ZIPFILE" ]; then
    echo -e "${GREEN}All .crash files have been successfully zipped into ../${ZIPFILE}.${NC}"
else
    echo -e "${RED}No .crash files were found to zip or there was an error in zipping.${NC}"
fi

When you run this script you should end up with a zip file containing all the crash files.

Going a step further

Being able to run a script is fine, but what about going a step further and creating an automator workflow to simplify this process.

Overview of macOS Automator

Automator is a powerful tool included with macOS that allows users to automate repetitive tasks without the need for complex programming skills. It provides a simple, graphical user interface where you can build workflows using a variety of actions that perform specific tasks. These workflows can be saved as applications, services, or quick actions that can be triggered with a click or automatically in response to certain events.

Benefits of Using Automator

Efficiency and Time Savings: Automator significantly reduces the time required to perform routine tasks. By automating sequences of actions that you perform frequently, you can focus on more important aspects of your work.
Ease of Use: With its drag-and-drop interface, Automator makes it accessible for non-programmers to create complex automations. This simplicity empowers more users to take advantage of automation technologies.

Customization: Automator offers extensive customization options, allowing users to tailor actions according to their specific needs. Whether it's organizing files, resizing images, or automating backups, Automator can handle a wide range of tasks.
Integration with macOS: Since Automator is a native tool, it integrates seamlessly with other macOS applications and features. This integration enhances workflow compatibility and reliability across the system.

Cost-Effective: As a built-in feature of macOS, Automator comes at no additional cost to the user, making it a cost-effective solution for automation compared to third-party software.

Automating the zipping of an .xccrashpoint

You can create Quick Actions that can be used in finder to perform tasks.

The workflow will look something like this:

Make sure you set:

Workflow receives current: files or folders
In: Finder

Drag a Run shell script and enter the following code.

#!/bin/bash

# Log file location
LOGFILE="$HOME/Desktop/automator_log.txt"

# Write the date and time to the log file
echo "Running script at $(date)" >> "$LOGFILE"

# Initialize a variable to store file names
zipped_files=""

for f in "$@"
do
    echo "Received: $f" >> "$LOGFILE"
    if [[ -d "$f" && "$f" == *.xccrashpoint ]]; then
        DIRECTORY="$f"
        DIRECTORY="${DIRECTORY%/}"  # Remove any trailing slash

        BASENAME=$(basename "$DIRECTORY")
        BASENAME="${BASENAME%.xccrashpoint}"

        # Define the output zip file's name, saved in the same parent directory as the .xccrashpoint folder
        ZIPFILE="${DIRECTORY%/*}/${BASENAME}.zip"  # Modify this line

        echo "Zipping files from $DIRECTORY into $ZIPFILE..." >> "$LOGFILE"

        # Navigate to the directory where .crash files are found
        cd "$DIRECTORY"

        # Use find to locate all .crash files, add them to the zip, and collect their names
        file_list=$(find . -type f -name '*.crash' -exec echo '{}' \;)
        zipped_files+="$file_list\n"  # Append found files to the zipped_files string
        echo "$file_list" | xargs zip -j "$ZIPFILE"  # Zip the files

        # Check if the zip operation was successful
        if [ -f "$ZIPFILE" ]; then
            echo "Successfully zipped into $ZIPFILE" >> "$LOGFILE"
            echo "$ZIPFILE|$zipped_files"  # Output the zip path and zipped files for AppleScript
        else
            echo "Failed to create zip file" >> "$LOGFILE"
        fi

        # Change back to the original directory
        cd - > /dev/null
    else
        echo "Not a .xccrashpoint directory: $f" >> "$LOGFILE"
    fi
done

The code for LOGFILE is optional, I only used it so help me debug.

Once that workflow is saved you should now be able to use as a quick action.

Next steps

I believe the next step would be to create an SwiftUI Mac app to make this even better. Stay tuned for Part 2.

Navigating through the complexities of software crashes and ensuring the continuity of development processes can be daunting. With the Automator workflows outlined in this post, I hope to have demonstrated a straightforward and powerful method to not only manage but also automate the handling of .xccrashpoint files. This not only saves time but also enhances the efficiency of your development workflow.

Embracing automation in development isn't just about reducing manual effort; it's about empowering developers to focus more on creative solutions rather than repetitive tasks. As you incorporate these automation techniques into your own projects, I encourage you to explore further and customize them to better fit your needs.

I am eager to hear about your experiences and any additional tips or insights you might have on using Automator or handling .xccrashpoint files. Feel free to share your thoughts and feedback in the comments below. If there’s enough interest, I’ll consider expanding on this topic with a follow-up post or even starting a series on automation in development environments.

Thank you for reading, and happy automating!