<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 <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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> ships a framework that is only supported in iOS 9.3. 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. The deployment target for her application *can be any value*. 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. 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. And I'm not in the habit of shipping code that wasn't even tested on my machine. 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. She weakly links it and uses availability checks just like she did with the Apple framework. 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: module 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. She can not use my framework at all</div><div class="">2. She can drop support for <9.3 entirely from her application in order to use my framework</div><div class="">3. 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. 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. Spoiler alert: that's what I did all afternoon.</div><div class=""><br class=""></div><div class="">This is too hard. 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>