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…
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.
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…