{"id":1343,"date":"2015-04-17T07:12:22","date_gmt":"2015-04-17T13:12:22","guid":{"rendered":"http:\/\/dev.iachieved.it\/iachievedit\/?p=1343"},"modified":"2019-12-22T10:59:23","modified_gmt":"2019-12-22T16:59:23","slug":"multiple-build-schemes-with-apple-watch","status":"publish","type":"post","link":"https:\/\/dev.iachieved.it\/iachievedit\/multiple-build-schemes-with-apple-watch\/","title":{"rendered":"Multiple Build Schemes with Apple Watch"},"content":{"rendered":"

I frequently use Xcode schemes<\/i> and configurations<\/i> to manage building iPhone applications for specific environments. For example, let’s say you’re integrating with an API from another team, and they’ve set up two instances of the API: staging<\/i> and production<\/i>. Furthermore, you want to have two sets of builds for those environments: debug<\/i> and release<\/i>. All of this can be accomplished with Xcode and Swift, with details outlined in a previous blog post<\/a>.<\/p>\n

In this post I’ll show you how to extend this paradigm to work with an Apple Watch target that you’ve added to your project. We’ll start with an application that is already configured to support two schemes: debug and release, where the debug scheme enables logging. Download the starter project watchschemes<\/b><\/a>. To ensure things are working properly, download the zip file and open the watchschemes.xcodeproj<\/b> project, and then run the Debug Application<\/b> scheme. You should get a nice log in the console:<\/p>\n

\n2015-04-16 21:47:30.056 [Info] : watchschemes Version: 1.0 Build: 1 PID: 51960\n2015-04-16 21:47:30.056 [Info] : XCGLogger Version: 1.8.1 - LogLevel: Debug\n2015-04-16 21:47:30.059 [Debug] [AppDelegate.swift:27] application(_:didFinishLaunchingWithOptions:): ENTRY\n<\/pre>\n
Before we add the Apple Watch target, note our two files that facilitate logging:  XCGLogger.swift<\/code> and LogUtils.swift<\/code>.  They are currently grouped under Supporting Files<\/code> of our watchschemes<\/code> folder.  When we add the Apple Watch target we’ll reorganize these files to highlight the fact that they are shared between the iPhone application and watch extension.  If you haven’t had the pleasure of working with XCGLogger, see our post on using XCGLogger instead of Lumberjack<\/a> for your Swift projects.<\/p>\n
Now, let’s add our Watch target.  Go to Xcode File – New – Target<\/b> and select the Apple Watch “WatchKit App” template.  Uncheck Include Notification Scene<\/b> as we won’t be creating one.<\/p>\n
\"watchkitapptarget\"<\/a><\/p>\n
You will notice that Xcode has created a new scheme<\/b> titled watcheschemes WatchKit App<\/b>.  Xcode may ask if you want to activate that new scheme:<\/p>\n
\"activatescheme\"<\/a><\/p>\n
Click Activate<\/b>.<\/p>\n
You will also notice if you edit the scheme you will find that the Run<\/b> action is associated with the Debug<\/b> build configuration.<\/p>\n
\"watchkitscheme\"<\/a><\/p>\n
What we would like is to have two schemes for our WatchKit App, similar to the two schemes we have for the iPhone application.  Let’s do that then by going to the Manage Schemes<\/b> page.  To get there, select the Scheme in Xcode and go down to Manage Schemes<\/b>.<\/p>\n
\"manageschemes_selection\"<\/a><\/p>\n
You should see the three schemes in the project:<\/p>\n
\"schemelist\"<\/a><\/p>\n
The first thing we’ll do is rename the default WatchKit application scheme to Debug WatchKit Application<\/b> and mark it as a shared scheme (sharing the scheme allows for multiple developers to share the scheme in their workflow, allow them to use all of the build configuration defines, optimizations, etc.).  Then, we will duplicate that scheme and rename it to Release WatchKit Application<\/b>.<\/p>\n
\"duplicatescheme\"<\/a><\/p>\n
When duplicating the scheme, rename it to Release WatchKit Application<\/b> and change the build configuration for the Run<\/b> action from Debug<\/b> to <\/b>Release<\/b>.  After duplicating the scheme mark the scheme as Shared<\/b>.<\/p>\n
Now that we have a Debug and Release WatchKit Application, let’s instrument logging into the WatchKit extension such that Debug has meaning.  Open the InterfaceController.swift<\/code> file (in the extension group) and ensure it looks like this:<\/p>\n
\nimport WatchKit\nimport Foundation\n\nlet log = XCGLogger.defaultInstance()\n\nclass InterfaceController: WKInterfaceController {\n  \n  override func awakeWithContext(context: AnyObject?) {\n    super.awakeWithContext(context)\n    \n    #if Debug\n      log.setup(logLevel: .Debug, showLogLevel: true, showFileNames: true, showLineNumbers: true, writeToFile: nil)\n      #else\n      log.setup(logLevel: .Severe, showLogLevel: true, showFileNames: true, showLineNumbers: true, writeToFile: nil)\n    #endif\n    \n    ENTRY_LOG()\n\n    EXIT_LOG()\n  }\n  \n  override func willActivate() {\n    ENTRY_LOG()\n    super.willActivate()\n    EXIT_LOG()\n  }\n  \n  override func didDeactivate() {\n    ENTRY_LOG()\n    super.didDeactivate()\n    EXIT_LOG()\n  }\n  \n}\n<\/pre>\n
Out of the box, with no changes to the extension target, this code will not compile.  The WatchKit extension has no knowledge of the XCGLogger.swift<\/code> and LogUtils.swift<\/code> code that is a part of the iOS application.  So let’s add them.<\/p>\n
Tip:<\/b>  If you interested in how the ENTRY_LOG()<\/code> and EXIT_LOG()<\/code> routines work, see the LogUtils.swift<\/code> file.<\/p>\n
Go to the watchschemes WatchKit Extension<\/b> target’s Build Phases<\/b> pane and under the Compile Sources<\/b> section add both XCGLogger.swift<\/code> and LogUtils.swift<\/code>.  This simply instructs Xcode to consult these files when compiling the WatchKit extension.<\/p>\n
Before adding the two Swift files you should see only the InterfaceController.swift<\/code> file as a member of the Compile Sources<\/b> list:<\/p>\n
\"watchschemes_compile_sources_default\"<\/a><\/p>\n
After adding you should have 3 files:<\/p>\n
\"watchkitextension_w_compile_sources\"<\/a><\/p>\n
Although we’ve added our logging files to the extension target, and we’ve specified the Debug and Release build configuration for the two schemes, one still must configure the build configurations for the extension target.  To put another way:  Xcode does not<\/i> copy the build configuration flags and settings from the iOS target to the extension target when it is created.  You can verify this by looking at the Swift Compiler – Custom Flags<\/b> for the WatchKit extension.  Whereas our original application has -DDebug<\/code> set for the Debug<\/b> build configuration, the extension target does not<\/i>.  You should keep this in mind when creating your first Apple Watch target:  if you have compile-time flags configured for your iOS build configurations, you’ll need to reproduce them in your extension target flags.  This is what we have done here:<\/p>\n
\"watchkit_custom_flags\"<\/a><\/p>\n
Once your build configuration flags have have been set you should be able to Run<\/b> either the Debug or Release WatchKit Application.  For instant gratification, select the Debug Watchkit Application<\/b> scheme and run.  You should<\/i> see<\/p>\n
\n2015-04-16 21:19:49.364 [Info] : watchschemes WatchKit Extension Version: 1.0 Build: 1.0 PID: 51664\n2015-04-16 21:19:49.364 [Info] : XCGLogger Version: 1.8.1 - LogLevel: Debug\n2015-04-16 21:19:49.372 [Debug] [InterfaceController.swift:24] awakeWithContext: ENTRY\n2015-04-16 21:19:49.373 [Debug] [InterfaceController.swift:26] awakeWithContext: EXIT\n2015-04-16 21:19:49.374 [Debug] [InterfaceController.swift:30] willActivate(): ENTRY\n2015-04-16 21:19:49.374 [Debug] [InterfaceController.swift:32] willActivate(): EXIT\n<\/pre>\n
in the console log for the Debug WatchKit Application<\/b> scheme.<\/p>\n
As you continue development of your WatchKit application you can use the debug configuration.  Once you are ready to run the release version with no logging, switch over to the Release WatchKit Application<\/b> scheme you created.<\/p>\n
Tip:<\/b>  With the two build configurations and schemes you can build either a WatchKit application that includes debug logging, or one that doesn’t.  I personally prefer to have additional configurations and schemes for targeting various installations of APIs or other backend services; the approach outlined above can be extended to accomplish this so you can support variations such as Debug Staging<\/b> or Release Beta<\/b>.<\/p>\n
Tip:<\/b>  Don’t forget your Archive<\/b> scheme actions!  I frequently upload archive builds to either TestFlight or TestFairy<\/a> that have logging instrumentation, test API keys, or are utilizing staging servers.  You will want to ensure the Archive<\/b> action for your scheme has the correct build configuration set.<\/p>\n
Organizing Common Swift Files<\/h3>\n
As mentioned above, our XCGLogger.swift<\/code> and LogUtils.swift<\/code> files are utilized by both the iOS application and WatchKit extension.  To facilitate making this explicitly obvious in the project, I’ve started to add a Common Sources<\/code> group to my Xcode projects and placing the shared files there.  In this project this looks like:<\/p>\n
\"commonsources\"<\/a><\/p>\n
Getting the Code<\/h3>\n
The final version of the code for this tutorial is on the watchschemes<\/b> branch of the BitBucket repository<\/a>.  To download a copy, grab this zip<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
I frequently use Xcode schemes and configurations to manage building iPhone applications for specific environments. For example, let’s say you’re integrating with an API from another team, and they’ve set up two instances of the API: staging and production. Furthermore, you want to have two sets of builds for those environments: debug and release. All […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,16,2],"tags":[],"class_list":["post-1343","post","type-post","status-publish","format-standard","hentry","category-apple","category-apple-watch","category-xcodetips"],"_links":{"self":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/1343"}],"collection":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/comments?post=1343"}],"version-history":[{"count":33,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/1343\/revisions"}],"predecessor-version":[{"id":3933,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/1343\/revisions\/3933"}],"wp:attachment":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/media?parent=1343"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/categories?post=1343"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/tags?post=1343"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}