
Although the app was now set to try to run on El Capitan, Xcode was stupidly still using all the hooks and features for Sierra. I went back to Xcode to look for clues, and discovered that there was a second setting which I needed to change, controlling the Base SDK. Within a few minutes I got the first response: this new version crashed on starting up on El Capitan, before it had even got to any of my code. When I posted it on my blog, I pointed out that I had not tested it on El Capitan, and invited users to try it and report back. Only being able to test this new version on Sierra, I put it through its paces, and updated its documentation. I set that to 10.11 for El Capitan, and rebuilt my app. Up popped choices ranging from 10.6 (back in 2009) to the latest 10.12. From among the scores of different switches and options, I found the one which claimed to set the macOS deployment target.

My mistake was to assume that I could make this new backward-compatible version by changing a single setting in Apple’s Xcode development environment.


#Cannot download xcode 8.2 how to#
As much of it works by running shell commands, and I developed it partly as an example of how to script in Swift 3, it looked fine. It took me a little while to check that my code didn’t do anything specific to Sierra. It wasn’t a particularly demanding request: someone wanted a version of my little security tool LockRattler which runs on El Capitan, rather than Sierra.
