I recently created a new project and had to reevaluate which way I wanted to go in terms of multiple configurations, to lets say communicate with different server endpoints or to show different app icons based on build type.
My approach so far, which by the way worked well, was to have multiple targets and each target had the specific plist files assigned which contained the configuration. This works well, but as your project grows it also comes with a burdon.
Our POS at 9Cookies has around 1k source files and comes with 6 different targets, this actually leads to a massive project file since all entries are in there 6 times, for each target once. We rarely have merge conflicts, but if we have them, you always have to hope that the diff can actually be produced on your Mac, since it immediately starts beachballing. …
We have our nice little Mac Pro in the office which serves as a build server / Jenkins slave for us. It runs multiple virtual machines, which help us to run tests in parallel.
Since we are running multiple VMs and not everyone is working from the office in Berlin, everyone accesses them via some remote software like VNC or TeamViewer. Which worked great, up until we upgraded to 10.11.1 and this would have been unnoticed, if we wouldn’t have to mess around with certificates.
I exported some certificates on my development machine and tried to add it to the Keychain of one of the remote machines. Turns out Apple introduced a new security feature. It detects that you’re using some remote software to move the mouse and doesn’t allow you to click certain things, like the `Allow` or `Always Allow` button in the Keychain dialog. …
Earlier this week I realised that we had no new builds for our Driver.app for quite a while. Checking the Jenkins logs, revealed that suddenly we had code signing problems.
Before the builds started to fail, one small change with big impact was made. We started to use use_frameworks! with Cocoapods.
Further the log revealed that there were problems with code signing the libraries which we added via Cocoapods. Checking the Pods.xcproject file, showed that the code sign identity for debug and release builds is iOS Developer, which doesn’t make that much sense.
Interestingly it was working on my local machine, since it used a wild card provisioning profile, which was not available on our Jenkins slave. …