TestsTested | ✗ |
LangLanguage | Obj-CObjective C |
License | MIT |
ReleasedLast Release | Dec 2014 |
Maintained by Jan Sabbe, Jorge Vallejos.
BuildEnvironment is a project that bundles a couple of build scripts and a bit of code I often use in new iOS projects. They allow you to:
I also provide an Xcode template that has most of this set up.
To quickly start a new Xcode project where BuildEnvironment has been integrated, you can use a custom Xcode template. To install, execute the following in your terminal:
curl -L https://github.com/cegeka/BuildEnvironment/raw/master/Template/install_template.sh |sh
In Xcode you will have a new Project template "Basic Application" in the "Cegeka" group. When you go through the wizard, it will ask you for the Hockey App ID and a Hockey API Token. You can also modify them when you go to your Target under Build Settings in the User-Defined settings.
The project comes with a Podfile, but you still need to run pod install
pod install
The template will setup everything except automatic deployment to HockeyApp. To set this up:
"${PODS_ROOT}/BuildEnvironment/update_version.sh"
and select your target in the Provide build settings dropdown."${PODS_ROOT}"/BuildEnvironment/upload_to_hockeyapp.sh
and select your target in the Provide build settings dropdown.Important
The project won't build until you manually create the project structure required by the localization scripts. To get more details about the required structure, or to remove the localization support, go to the Localization section.
If you already have a project, you can still use the build scripts.
In your application you might need different values depending on the build of your application. Imagine you are creating a test, an acceptance and a production build of your app. You might want to talk to different backends for each build.
You can set this up as follows:
BEConfiguration.plist
. Add a Debug
and a Release
property with type DictionaryBEConfig.configuration[@"key_in_configuration_plist"]
You can also add an extra configuration (eg Acceptance), by going to your Project settings and adding a configuration in the
Configurations section. You might need to rerun pod install
after this.
You can specify which configuration to use by editing your Scheme.
You could also duplicate a Scheme, set it up as an Acceptance build, and make sure the Scheme is shared. You can then set up your CI server to automatically build this scheme.
You can use update_version.sh to automatically increment the CFBundleVersion in your Info.plist. This script will put a timestamp in the version.
"${PODS_ROOT}/BuildEnvironment/update_version.sh"
You can use upload_to_hockeyapp.sh to automatically upload builds to HockeyApp (by running Archive locally or on your Xcode server).
"${PODS_ROOT}"/BuildEnvironment/upload_to_hockeyapp.sh
. If you want to see the log of this script, add exec > /tmp/log_hockeyapp.txt 2>&1
at the top. This will log it on your build server in /tmp/log_hockeyapp.txt
HOCKEYAPP_API_TOKEN
which should contain your Api token. Also add a HOCKEYAPP_APP_ID
user-defined setting which contains your App ID.If you have a build server available, these are the steps to take in order to set up automatic builds.
To automatically check the software licenses during your build, you can use check_licenses.sh
. This
will check your CocoaPods dependencies. If it finds a dependency that has something other than a MIT, BSD
or Apache license, it will fail the build.
"${PODS_ROOT}"/BuildEnvironment/check_licenses.sh
"${PODS_ROOT}"/BuildEnvironment/check_licenses.sh -l BSD
By default MIT, BSD and Apache are allowed."${PODS_ROOT}"/BuildEnvironment/check_licenses.sh -e AFNetworking
You can also check if all your cocoapod dependencies are outdated. Integrating check_outdated.sh
in your build will generate a build warning if a dependency has a newer version.
"${PODS_ROOT}"/BuildEnvironment/check_outdated.sh
This template automatically updates the files that need to be localized. This includes the files containing the translations required for the text found both in the source code and storyboards.
To automatically update the file contaning the translations required for the source code, you can use extract_source_translations.sh
. This script looks for invocations to NSLocalizedString in the code, collects the keys used in such invocations, and tries to match them with those specified in the Localizable.strings files as follows:
In order for this script to work the project needs to have a localized file, called Localization.strings in a Supporting Files directory.
To automatically update the file contaning the translations required for the source code, you can use extract_storyboard.sh
. This script looks for strings in the storyboard, collects the keys used by such strings, and tries to match them with those specified in the storyboard strings files as follows:
In order for this script to work the project needs a localized storyboard.
To deactivate any of the above localization script, you can remove the corresponding Update source translations and Update storyboard translations build phases from your project (automatically added by the template).
Developed in the Cegeka European App Factory
BuildEnvironment is available under the MIT license. See the LICENSE file for more info.