<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 4, 2016, at 4:48 PM, Drew Crawford via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Suppose *<b class="">Apple*</b>&nbsp;ships a framework that is only supported in iOS 9.3. &nbsp;As a direct consequence, the framework is only #available in iOS 9.3 or later.</div><div class=""><br class=""></div><div class="">Suppose Jane links this framework into her iOS application. &nbsp;The deployment target for her application *can be any value*. &nbsp;She sets the framework to be weakly linked, and as long as the code that uses the Apple framework is guarded by a 9.3 availability check, she can deploy back to 8.0, 7.0, etc.</div><div class=""><br class=""></div><div class="">Suppose *I* ship a custom framework that I only want to bother supporting for iOS 9.3 users. &nbsp;I'm not testing on old OS, I don't have CI on old OS, and quite frankly I have no idea if it works. &nbsp;And I'm not in the habit of shipping code that wasn't even tested on my machine. &nbsp;As a direct consequence, I set my framework deployment target to 9.3.</div><div class=""><br class=""></div><div class="">Now Jane links this framework into her "deployment target 8.0" application. &nbsp;She weakly links it and uses availability checks just like she did with the Apple framework. &nbsp;But this time the compiler says no:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">error:&nbsp;module&nbsp;file's minimum deployment target is ios9.3 v9.3</div></blockquote><div class=""><br class=""></div>Jane now has a set of bad choices:<div class=""><br class=""></div><div class="">1. &nbsp;She can not use my framework at all</div><div class="">2. &nbsp;She can drop support for &lt;9.3 entirely from her application in order to use my framework</div><div class="">3. &nbsp;She can convince me to support iOS 8, when I don't want to invest in the QA and test time.</div><div class="">4. &nbsp;She can convince me to set my deployment target to 8, try to find all my public APIs, sprinkle `@available(iOS 9.3, *)` everywhere and hope I didn't miss any. &nbsp;Spoiler alert: that's what I did all afternoon.</div><div class=""><br class=""></div><div class="">This is too hard. &nbsp;IMO Jane should be able to use my "9.3+" frameworks as easily as she can use Apple's.</div><div class=""><br class=""></div><div class="">IMO, when Jane imports a "DT 9.3" framework, into her "DT 8.0" application, it should A) import successfully, B) link weakly, and C) have `@availability(9.3, *)` overlayed on the interface.</div></div></div></blockquote><br class=""></div><div>I would not want this to be implicit behavior: it should be recorded in the source with, e.g.,</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>@availability(iOS: 9.3) import YourCustomFramework</div><div><br class=""></div><div>so that it is clear that the imported declarations are only available on iOS 9.3 or newer.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div><div><br class=""></div><br class=""></body></html>