As a healthcare platform that's now ubiquitous in operating rooms worldwide, our development team has to be able to detect issues early, react quickly, and make rapid changes to solve any problems. This requires adaptability, creativity, and agility - skills that enable us to tackle challenges head-on. Recently, we faced unique challenges after Apple updated XCode and released a new iOS version. In this open-source case study, our developers May Chehab and Hamza Jadid showcase how they expertly navigated the transition to XCode 16.
The Challenge
As an iOS team, we're no strangers to the challenges that come with new XCode and iOS releases. Apple regularly introduces updates that bring exciting new features and improvements, but these updates often disrupt existing workflows - particularly in CI pipelines. Our recent experience was no exception. The transition to XCode 16 and the upgrade of our device farm posed a unique challenge.
The Solution
One critical issue caught us off guard: the deprecation of functionalities in xcresultparser, a tool we relied on for test result processing. We used this tool to extract test result data from XCode's .xcresult format and convert it into an XML format. After extracting the data, we uploaded it to GitHub Actions, where we used a GitHub Action called dorny/test-reporter. This action took the JUnit XML format and generated a visually clear report, summarizing the results of the tests.
Building Our Own Tool
When none of the existing tools fit our needs, we decided to build our own tool. We discovered that the .xcresult bundle contains an SQLite database containing test results to the very last detail. By running a schema visualizer on the database and writing queries accordingly, we were able to extract the test results in our pipeline.
Overcoming "Worked on My Machine" Issues
We encountered the infamous "worked on my machine" issue when we added the tool to our CI. It couldn't find the database file until we manually opened the .xcresult bundle with XCode. To automate this process, we initially added a step in our CI to open the .xcresult bundle with XCode, run the SQL query to retrieve the data, and then close XCode after finishing.
Simplifying the Process
However, this approach required additional functions to manage XCode's process lifecycle, which introduced unnecessary complexity. To streamline the process, we used the built-in xcrun tool, which provided us with the database without requiring XCode to be opened manually. This eliminated the dependency on XCode's UI and significantly reduced the overhead involved in accessing the test results database.
Extracting Meaningful Data
Once we gained access to the database, understanding its structure and extracting meaningful data became a significant challenge. The database was complex, with numerous tables and intricate relationships between them. It contained a large amount of data, much of which was not immediately relevant, making it difficult to pinpoint the information we needed.
Enhancing Feedback
We made our tool reliant on the Handlebars template engine to generate the output. This allowed us to create templates for specific use cases and never be limited to a specific format. Currently, we've created two templates: one is a Markdown template that we can use in our CI summary, and the other is a Slack template that uses the Slack Build.
By building our own tool and leveraging XCode's built-in xcrun command, we were able to navigate the challenges of swift app development and unlock new levels of developer agility.