This content originally appeared on Level Up Coding - Medium and was authored by Balraj Verma
Discover how to set up multiple variant of private Cocoapods
Most software products support multiple build settings or configurations. To align with this, your app should have build configurations for different environments—such as release, QA, and development.
However, let’s say you have a multi-module application with each feature broken down into smaller parts, such as cocoapods. In order to accommodate all of those configurations, they should follow a specific pattern when adopting the current configuration. Based on that pattern, they should include additional files, such as debug variants that may contain mock or stubbed JSON files and additional files that may have been written to test the QA variant of the app; for example, if the app is running in QA, only my micro-app should perform linting; in the production version, it should not download the swiftlint etc.
We’ll work to make it much easier to grasp, and as a bonus, I’ll share a script that might change the game. Let’s get the fun started....🤩
We will use a sample cocoapod that I made specifically to show you in order to fully comprehend it. Additionally, there is a sample app that downloads multiple variations of this sample pod on various settings. I will share those links at the end of the article.
1. Private pod configurations
After creating your private pod, you can download it as a dependency in your app by listing it like the one below here; I’m referring to one that I made for this example.
pod 'SampleDevpod', :git=> 'git@github.com:balrajverma/SampleDevpod.git', :tag=> '0.3.0'
The pod will be installed once you execute the pod install command. Assume this is the default and production version of this cocoapod or devpod. Now you have QA variant of same pod but with included extra dependencies like mocking framework you only need in QA variant. So i will modify the podspec with adding a subspec with all those dependencies which we only required at the time of QA variant of this pod. so our podspec will look like.
Pod::Spec.new do |s|
s.name = 'SampleDevpod'
s.version = '0.3.0'
s.summary = 'This description is used to generate tags and improve search results.'
s.description = "Sample application for creating a devpod which can be used in Sample application"
s.authors = "Sample author information added"
s.homepage = 'https://github.com/564100/SampleDevpod'
s.license = { :type => 'MIT', :file => 'LICENSE' }
s.source = { :git => 'https://github.com/564100/SampleDevpod.git', :tag => s.version.to_s }
s.ios.deployment_target = '15.0'
s.source_files = 'SampleDevpod/Classes/**/*'
#MARK: - QA/Debug varient of cocoapod
s.subspec 'QA' do |debug_varient|
debug_varient.source_files = ['SampleDevpod/Classes/QA/**/*']
debug_varient.depedency 'mockingbird'
debug_varient.depedency 'SwiftLint'
end
end
We have finished configuring a cocoapod to support two distinct variants when necessary after adding subspec, which specifies its own source path and dependencies only for the QA variant.
2. Main App Configurations
In order to make it functioning, we must configure our main application so that whenever developers alter the build configuration, our code will automatically recognize the differences between the previously chosen configurations and download the dependencies of the same build configuration. For example, if the configuration is debug, the debug flavor of the pod will be downloaded; if the configuration is release, the release flavor of the pod will be downloaded.
To do this, you must set up your primary application with the following changes.
- To enable our script to read data from the user’s chosen configuration, change your project to allow command-line build settings.
2. Update the pod file for the Main app to include a list of all the QA/Release versions of your pods, as shown below. Although we only have one pod here, depending on the condition of the app, there may be multiple.
install! 'cocoapods', :preserve_pod_file_structure => true
def install_pods
project_dir = File.dirname(__FILE__)
config_file_path = File.join(project_dir, 'current_config.txt')
if File.exist?(config_file_path)
file_content = File.read(config_file_path).strip
if file_content == 'Release'
pod 'SampleDevpod', :git => 'git@github.com:balrajverma/SampleDevpod.git', :tag => '0.3.0'
end
if file_content == 'QA'
pod 'SampleDevpod', :git => 'git@github.com:balrajverma/SampleDevpod.git', :tag => '0.3.0'
end
end
puts "Config file not found"
end
target 'MultipleVarientDevpodMainApp' do
use_frameworks!
install_pods
end
3. Include two text files that allow you to store the most recent settings you choose from your build configuration and the developer’s current configuration option, as shown below.
This is an optional step you can optimize it more and configure as per your requirement.
4. Include a script in the main application’s pre-build phase, as shown below. This way, when the project is compiled, it will determine whether the current configuration differs from the previous one and re-run the pod install with the dependencies needed for the chosen build configurations. And you yourself don’t need to open a terminal and run pod commands; script will take care of that.
#!/bin/bash
#constant
CURRENT_CONFIG_FILE="${SOURCE_ROOT}/current_config.txt"
LAST_CONFIG_FILE="${SOURCE_ROOT}/previous_config.txt"
PROJECT_PATH="${SOURCE_ROOT}/MultipleVarientDevpodMainApp.xcodeproj"
#Make sure to change them as per your app's name and configurations
if [!-f "CURRENT_CONFIG_FILE"]; then
exit 1
fi
if [!-f "LAST_CONFIG_FILE"]; then
exit 1
fi
echo "File are in the path move to next step"
BUILD_SETTINGS=$(xcodebuild -project "$PROJECT_PATH" -showBuildSettings)
BUILD_CONFIGURATION=$(echo "$BUILD_SETTINGS" | grep -i 'CONFIGURATION=' | awk -F' = ' '{print $2}' | head -n 1)
if [-z "$BUILD_CONFIGURATION"]; then
BUILD_CONFIGURATION=$(echo "$BUILD_SETTINGS" | awk '/CONFIGURATION/ {print $3}' | head -n 1)
fi
# if [-n "BUILD_CONFIGURATION"];then
# echo
if diff "$CURRENT_CONFIG_FILE" "$LAST_CONFIG_FILE" > /dev/null; then
#files are same
echo "4th step"
exit 0
else
echo "Files are different, run pod install"
echo "${BUILD_CONFIGURATION}" > "$LAST_CONFIG_FILE"
osascript <<END
tell application "Terminal"
if not (exists window 1) then reopen
activate
do script "cd ${SOURCE_ROOT};pod install" in window 1
end tell
END
fi
Once you’ve completed all of these configurations in your main application, you can simply choose the scheme and run your project. It will automatically determine whether the chosen scheme differs from the prior scheme and download all necessary dependencies in accordance with the set pod file.
here is the working link of above example
Code Links for above example
Sample pod:
https://github.com/balrajverma/SampleDevpod
Ref App Using Sample pod:
https://github.com/balrajverma/MultipleVarientDevpodMainApp
When working on a multi-module architecture with distinct pods for each of your functionalities, this is crucial. It’s possible that every pod has its own mock file, certificates, and other files that can serve as a QA variant. The aforementioned implementation might be quite beneficial in these usage scenarios. We can use this automated method to replace all manual tasks. Additionally, our devpods might be smaller and more specialized in terms of build configuration.
And that’s it. Thank you for reading my post. I really appreciate your time. If you think it’s helpful, please clap or comment. And in the next one, I see you. 🙌
Multiple Variants of Cocoapods for your Private pod was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Balraj Verma
Balraj Verma | Sciencx (2024-10-28T00:59:15+00:00) Multiple Variants of Cocoapods for your Private pod. Retrieved from https://www.scien.cx/2024/10/28/multiple-variants-of-cocoapods-for-your-private-pod/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.