#Xcode project build settings plus
When you click on the plus button, you’ll have the opportunity to clone one of your existing configurations. If you’re in the right place, you’ll see your current Configuration list. Then click on your project to show your project settings. You do this by going to the project settings for your project. The first thing I did was to create a third build configuration, QA, so that we’d have a separate build configuration for each build type. Those hints may be enough to set you on your way, but just in case you need a bit more, I’ll explain how I used those bits of knowledge to solve my problems. Xcodebuild can set both the scheme and build configuration to use.There is a setting that is honored by Xcode but is not set or shown by default that allows you to exclude specific files for particular configurations.It is possible to define and set user-defined settings.Settings set at the both the project and target levels can be different for each build configuration.But the part that’s interesting here is that settings made at the project level are available for every target. Any good Xcode book will give you the complete list. There are a number of places where you can set build settings. Xcode build settings are hierarchical.
When you create a project in Xcode, it automatically generates two build configurations for you: Debug and Release.There are six things you need to know about how Xcode settings work: Is it possible, then, to handle all of this in Xcode settings? Yeah, pretty much. And each should get used at the appropriate time.
Have two settings bundles, one for Development/QA and one for Release. Have specific profiles that automatically get used for each of the builds. Separate bundle IDs and display names that don’t need to be changed. Have one place to enter the version and build numbers that get used for all targets (app, watch app, watch extension). Working through all that left me with a wish list like this: It was natural, then, that I should do some poking around with Xcode to see if I could simplify the build script by making Xcode settings do more of the heavy lifting – which should also result in builds done from the IDE matching better to the terminal builds for QA and Release. So, we had a build script that was non-trivial and our development builds done under Xcode had little relation to the QA and Release builds done from the terminal. Finally, our app has a separate settings bundle for Development/QA vs. Apple also requires that build and version numbers have to match up for all three. Each build also needs its own Provisioning Profile (Development, Store, and an Ad Hoc version for the QA build).ĭid I mention that the app in question also has a watch component? And, as you may know, WatchOS apps and extensions each have their own bundle ID – which have to match up with each other and the iPhone app. We do this so that QA engineers can have both QA and Release versions of our app on their devices. We have separate builds for QA and Release, which have separate bundle IDs and display names. The existing build script did a fair amount of work to tweak the project as necessary for the given build targets. And the tweaks I made along the way simplified our build process and increased confidence that our dev builds would more accurately mirror our production builds. And the process of researching build script improvements led me to wonder if Xcode couldn't be persuaded to do more of the build process heavy lifting. Since I had to make changes to the build scripts anyway, I started looking at how they could be improved. Changes to Xcode last year led to our then-current build scripts becoming dysfunctional.
0 kommentar(er)
