You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I manage my personal Xcode projects using the CLI xcodegen, which allows to configure the most important fields of an Xcode project in a YAML configuration file, which then generates the .xcodeproj based on that.
Main reason to use it: less merge conflicts as .xcodeproj are quite complex files.
Details
I believe this improvement would require 3 steps:
1. Detect external Xcode project management
I believe there could be multiple approaches in detecting if xcodegen is actually used:
Option 1A: Detect if xcodgen is installed on the system
Not reliable, as an installed CLI does not mean it is used for this project.
Option 1B: Detect if a file named project.yml is in the project directory
Most likely a good indicator as it is the default configuration file name used by xcodegen and could be implemented similar to searchXcodeProject(at:).
But there is a caveat, as the configuration file could also be named differently. Furthermore, it is also possible to have multiple YAML files which are then merged using include: in the document (similar to Typescript configuration files, see docs).
Option 1C: Lookup all YAML files recursively in project
The ProjectSpec defines the name: String field to be a required configuration value. Iterating all YAML files and filtering for the ones which could be xcodegen configuration files could increase the chance of finding the correct file. This combined with an interactive prompt for the wizard user to select the correct project file could work.
Option 1D: Add a CLI parameter --xcodegen-project-file path/to/project.yml
This approach is the most deterministic option, as the user will directly point to the correct configuration file, which is also a clear indicator that xcodegen should be used.
But, requiring the user to know and provide the parameter will reduce the user experience and even cause most users to not use it.
Option 1E: Add step to wizard and ask user if they use Xcode management utils
Add a step to the wizard and simply ask the user if they use an external tool to manage their Xcode project.
Here are some additional candidates to consider:
targets:
MyApp:
postBuildScripts:
- name: Upload Debug Symbols to Sentry
inputFiles:
- ${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${TARGET_NAME}
script: |
# This script is responsable to upload debug symbols and source context for Sentry.
if which sentry-cli >/dev/null; then
export SENTRY_ORG=<YOUR_ORG>
export SENTRY_PROJECT=<YOUR_APP>
ERROR=$(sentry-cli debug-files upload --include-sources "$DWARF_DSYM_FOLDER_PATH" 2>&1 >/dev/null)
if [ ! $? -eq 0 ]; then
echo "warning: sentry-cli - $ERROR"
fi
else
echo "warning: sentry-cli not installed, download from https://github.com/getsentry/sentry-cli/releases"
fi
3. Trigger the project generator
To allow users to continue the setup of Sentry in their project, it should ask the user in an additional step if the external tool should be triggered, i.e. if xcodegen should generate the project.
This could be quite complicated and part of a larger code generation toolkit, so instead it might also be a possibility to simply inform wizard users to regenerate their project before continuing with the Sentry setup.
The text was updated successfully, but these errors were encountered:
Motivation
I manage my personal Xcode projects using the CLI
xcodegen
, which allows to configure the most important fields of an Xcode project in a YAML configuration file, which then generates the.xcodeproj
based on that.Main reason to use it: less merge conflicts as
.xcodeproj
are quite complex files.Details
I believe this improvement would require 3 steps:
1. Detect external Xcode project management
I believe there could be multiple approaches in detecting if xcodegen is actually used:
Option 1A: Detect if
xcodgen
is installed on the systemNot reliable, as an installed CLI does not mean it is used for this project.
Option 1B: Detect if a file named
project.yml
is in the project directoryMost likely a good indicator as it is the default configuration file name used by xcodegen and could be implemented similar to
searchXcodeProject(at:)
.But there is a caveat, as the configuration file could also be named differently. Furthermore, it is also possible to have multiple YAML files which are then merged using
include:
in the document (similar to Typescript configuration files, see docs).Option 1C: Lookup all YAML files recursively in project
The ProjectSpec defines the
name: String
field to be a required configuration value. Iterating all YAML files and filtering for the ones which could be xcodegen configuration files could increase the chance of finding the correct file. This combined with an interactive prompt for the wizard user to select the correct project file could work.Option 1D: Add a CLI parameter
--xcodegen-project-file path/to/project.yml
This approach is the most deterministic option, as the user will directly point to the correct configuration file, which is also a clear indicator that xcodegen should be used.
But, requiring the user to know and provide the parameter will reduce the user experience and even cause most users to not use it.
Option 1E: Add step to wizard and ask user if they use Xcode management utils
Add a step to the wizard and simply ask the user if they use an external tool to manage their Xcode project.
Here are some additional candidates to consider:
xcodegen
tuist
(I have not used this one before)fastlane
with XcodeprojThis could be implemented in two steps:
For this improvement request let's focus on xcodegen but keep other options in mind.
2. Patch the configuration file
To add a Swift Package via xcodegen, couple changes need to be done, similar to the modification of the
.xcodeproj
in the existing wizard:Define the Swift Package
The swift package is defined in a root-level field called
packages
and uses similar syntax to thePackage.swift
syntax. See documentation and example:Add the Swift Package to the target
Now the package needs to be added as a dependency to the target. See documentation and example:
Enable settings for debug information
Add the
DEBUG_INFORMATION_FORMAT
andEANBLE_USER_SCRIPT_SANDBOXING
to the base settings:Add script to upload debug symbols to sentry
See the documentation for details.
3. Trigger the project generator
To allow users to continue the setup of Sentry in their project, it should ask the user in an additional step if the external tool should be triggered, i.e. if xcodegen should generate the project.
This could be quite complicated and part of a larger code generation toolkit, so instead it might also be a possibility to simply inform wizard users to regenerate their project before continuing with the Sentry setup.
The text was updated successfully, but these errors were encountered: