🌳 Branching Model for iOS development. Continuous Integration with Bitrise

When I started working at my current company, the setup we had for our iOS platform was hosted completely locally: Bitbucket Server for the repo, Jenkins as build platform and an own implementation of Hockeyapp for the distribution (as far as I understood, from the old days when Hockeyapp was an open source project). All that was run by an external agency (the one who had developed our app).

Dynamic App icon generation with Xcode

When working in a corporate environment, you will easily find yourself building several variances of the same app, targeting different configurations (debug, beta, release), different environments (staging, production) and different versions.

It can be messy if there is no clear way to differentiate them at a glance, i.e. with the app icon, and can potentially lead to situations where testers insert test data into production or try to QA a feature in the wrong app version.

Our first approach at Cluno was to generate different icons for different versions and include all of them in the assets catalog. This methods works straightforward but has two problems. First of all, it is not very flexible. The icons needs to be designed, attached to the project, and mapped to each configuration:

App Icons in Build Settings section

App Icons in Build Settings section

You have to ship you app with more icons than it should, increasing as well the binary size.

The second problem is that you lose the capability to include in the icons dynamic information such as version, build number, commit hash, etc.

Generating iOS app icons with ImageMagick

There are several tutorials, on how to generate the app icon using ImageMagick, running a script in a build phase and replacing it in the app package.

As of iOS 11 that method doesn’t work anymore. Apparently Xcode creates a copy of the app icon in a separate private file and that’s the one being used.

A new approach

Digging into StackOverflow I found several people facing the same issue until this answer pointed us in the right direction: accessing directly the icon in the asset catalog, performing the needed modifications before copying the bundle resources and reverting all the modifications at the very end, in order to leave the project in a clean state (with an unmodified app icon).

Show me the code!

In our project folder we created two scripts that are called during the build phases:

Icon generation script:

This script has to be called before the Copy Bundle Resources step. It can be pasted directly or called in the following way:

"${SRCROOT}/Scripts/IconVersioning.sh"

It embeds configuration, version and build number information to the icon. The band is tinted red in the case of production configurations, to make the tester aware of being in a production environment.

The second script needs to be placed as last step during the build phases and is responsible for reverting the changes, checking out the unmodified version of the icon:

Revert script:

if [ "${CONFIGURATION}" != "ReleaseProduction" ]; then
IFS=$'\n'
git checkout -- `find "${SRCROOT}/${PRODUCT_NAME}" -name AppIcon.appiconset -type d`
fi

… and then the final result 🎉

Final result

Final result

Now is super convenient to work with different configurations, knowing that the icons are going to be up to date 😎.

I set up a test project with the basic implementation: https://github.com/gmoraleda/Xcode-Dynamic-Icon-Generation

Pagination


© 2021. All rights reserved.

Powered by Hydejack v9.1.6