Over time and over the span of multiple versions of an operating system, the Application Programming Interface (API) of the operating system changes. New APIs are added; existing APIs are deprecated and eventually removed. It becomes more difficult for a software developer to understand which APIs are available to an application when building an application for a specific version of the operating system. The developer would like to know whether a particular API is in, say, version N of the operating system.
Additionally, this issue is compounded when the operating system exists on multiple hardware platforms. A particular API, A, may have been introduced to platform X in operating system version R. But a different hardware platform Y might not introduce that same API (A) until version S.
Finally, the lifecycle of an API includes potentially deprecating and removing an API from an operating system. Even though an API may have been introduced first in platform X, and subsequently in platform Y, deprecation might occur in either platform first. Actual removal of the API may also occur in any platform in any order. Much depends on the relative release cycles of the platform and the relative importance of the API on each platform.
For merely one example, consider the case in which a developer may want to create a reusable library of functionality. This library should work on platform X releases R−1 through R+3. The developer may want it to work as well on platform Y releases S−2 though S+1. The developer should know what APIs are available to the library code. Currently, a developer typically reads the documentation and determines the intersection of platforms and versions for each API used in the library.
Attempts have been made to ease this developer burden. For C/C++ applications, an API vendor may insert conditional #ifdef's in the language header files. These #ifdef's would include the declaration of an API only if the proper C/C++ preprocessor symbol had been previously defined. A developer could, in effect, define a symbol to say, “I'm targeting version 5 of the operating system” and the C/C++ preprocessor would omit all API declarations that were not defined to be present in version 5 of that operating system. However, this approach gets unwieldy as the matrix of potential versions and platforms increases.
Additionally, this solution only supports developers using the C/C++ programming language. Developer using other languages do not reference and use C/C++ header files.
And finally, it may be challenging for an integrated development environment (IDE) to provide programming assistance as to which APIs are available using C/C++ header files. In effect, the IDE must reproduce the preprocessor's behavior to determine what API declarations are in scope. Additionally, the IDE should reproduce the C/C++ compiler parser's behavior to examine the source code from the header file to identify the APIs that the preprocessor included. This tends to place a burden on any IDE, especially so when the IDE is not C/C++ focused.