Suppose *Apple* 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.
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.
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.
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:
error: module file's minimum deployment target is ios9.3 v9.3
Jane now has a set of bad choices:
1. She can not use my framework at all
2. She can drop support for <9.3 entirely from her application in order to use my framework
3. She can convince me to support iOS 8, when I don't want to invest in the QA and test time.
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.
This is too hard. IMO Jane should be able to use my "9.3+" frameworks as easily as she can use Apple's.
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.
There may be some subtle additional details because I don't know exactly the implementation of these features, but that's the general idea.