<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jul 20, 2015, at 2:44 PM, Jake Petroules <<a href="mailto:jake.petroules@petroules.com">jake.petroules@petroules.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">4. Don't use specific versions of OS X SDKs. Have all targets always use the latest OS X SDK available on the build machine.</div></blockquote><br></div><div>To be fair, you can’t really win here: specifying “latest SDK” is a recipe for having your build break with every Xcode update, while on the other hand, Apple is removing previous SDKs versions with each Xcode update.</div><div><br></div><div>Despite using only published API, my experience is that keeping a project like PLCrashReporter building reliably across just a couple versions of Xcode requires code changes for every single Xcode release, which means that tagged releases tend to have a binary lifetime of years[1], and a source build lifetime of 6-12 months.</div><div><br></div><div>Specifying your target SDK explicitly at least advertises that a tagged release may very well not work with your latest version of Xcode, and what SDK/Xcode releases it *will* build with.</div><div><br></div><div>-landonf</div><div><br></div><div>[1] Indefinite, actually; pretty much the only time stable code has to change is when Apple themselves breaks API invariants, or we need to support a new architecture.</div></body></html>