Encyclopedia · Subject area

Software development kits

A software development kit (SDK) is a packaged set of tools, libraries, documentation and samples that enables the development of software for a particular target. The term is used across subject areas that otherwise have little in common. This subsection distinguishes four types — developer SDKs, publishing SDKs, platform SDKs and hardware SDKs — describes each in a separate article and examines the points at which they interoperate.

By knowledge.aitechdoc.world · Last reviewed September 29, 2026

Articles

Scope and terminology

The four designations used in this subsection are descriptive categories, not standardized terms. They are distinguished by the target of the kit: a remote service or system (developer SDKs), structured content (publishing SDKs), a software platform that hosts extensions (platform SDKs) and a physical device (hardware SDKs). Individual products frequently combine several types; a cloud provider’s kit may contain client libraries and extension tools, and an IoT kit may contain device libraries and a cloud client.

Common characteristics

Despite their different subject areas, the four types share a common structure. Each packages an interface — an API, a content model, an extension point or a device register set — together with libraries that make the interface usable, tools for building and testing, documentation and samples. Each is a versioned artifact whose changes affect the software built on it, and each relies on documentation as an integral part of the kit rather than an addition to it.

Comparison

Comparison of the types of software development kit
Type	Target	Primary artifacts	Typical users	Direction of control	Examples
Developer SDKs	A remote service or system, addressed through its API	Language libraries, authentication, serialization, error handling, CLI	Application and integration developers	The application calls the service	Cloud provider SDKs, OpenTelemetry SDKs
Publishing SDKs	Structured content in a content model	Parsers, validators, transformers, renderers, pipelines	Information architects, content engineers, technical writers	The pipeline processes the content	DITA Open Toolkit, XSLT and XSL-FO processors, CCMS publishing engines
Platform SDKs	A software platform that hosts extensions	Extension APIs, manifests, plug-in frameworks, sandboxes, test instances	Partners and customers extending the platform	The platform calls or hosts the extension	Visual Studio Code Extension API, Atlassian Forge, SAP Cloud SDK
Hardware SDKs	A physical device, processor or sensor	Drivers, low-level libraries, toolchains, debug and flashing tools	Embedded, systems and application developers	Software drives the device through its drivers	CUDA Toolkit, OpenXR runtimes, Android NDK, IoT device SDKs

How the domains interoperate

Although the four types of SDK belong to different subject areas, they meet wherever software, content and devices form one system. The points of contact follow a recurring pattern: one kit produces an artifact or event that another kit consumes, and an interface description — an API specification, a content model, a manifest or a device description — defines what passes between them.

Developer SDKs and publishing SDKs

Publishing pipelines are controlled through developer SDKs and APIs: a content management system triggers a build, a continuous integration service runs the publishing engine, and the result is uploaded to a delivery platform through that platform’s API. In the opposite direction, the reference documentation of developer SDKs is generated from API descriptions and source code comments and then processed by publishing tools, so that the documentation of a kit follows each release of the kit.

Platform SDKs and publishing SDKs

Component content management systems and content delivery platforms are platforms in their own right. Their extension models allow custom output formats, metadata mappings and connectors to translation or product information systems to be added as plug-ins. Publishing functions thus become extensions of a content platform, and content becomes available inside other platforms through integration apps.

Hardware SDKs and publishing SDKs

The documentation of devices and of hardware SDKs — register descriptions, pin assignments, safety and installation information — is commonly authored as structured content and published for several audiences. Machine-readable delivery formats such as iiRDS packages and VDI 2770 containers carry this documentation together with metadata that identifies the product and the component to which it applies, so that it can be linked to the device data used by software.

Hardware SDKs and developer SDKs

Connected devices combine both types. Firmware built with a hardware SDK reports measurements to a gateway or directly to a cloud service, where applications access the data through developer SDKs. Device descriptions and information models, such as the digital twin of an asset, define the meaning of the data on both sides.

Platform SDKs and developer SDKs

Extensions built with a platform SDK frequently call external services through developer SDKs, and external applications call the platform through the same kinds of client library. Authentication based on OAuth 2.0, webhooks and event subscriptions are the mechanisms most commonly shared by the two.

Conditions for interoperation

Interoperation between the domains depends less on the kits themselves than on the interfaces between them. Stable, versioned interface descriptions, shared identifiers for products and content, agreed metadata vocabularies and documented authentication mechanisms allow artifacts to pass from one domain to another without manual conversion. Semantic interoperability — a shared understanding of what the exchanged data and content mean — is the precondition for automated exchange across subject areas; syntactic compatibility of formats alone is not sufficient.

Context cards

Glossary terms

Software development kit (SDK): In software engineering, a software development kit (SDK) is a collection of libraries, tools, documentation and samples that developers use to build applications for a specific platform, device, protocol or service.
Application programming interface (API): In software engineering, an application programming interface (API) is a defined set of functions, data structures, messages or endpoints through which one software component offers services to other components, together with the rules for using them. In industrial automation, APIs connect control software, engineering tools, MES, cloud services and custom applications.
Interoperability: In engineering and IT, interoperability is the ability of systems or components from different sources to exchange information and use it correctly, based on shared protocols, data models and semantics.
Semantic interoperability: In information exchange, semantic interoperability is the ability of different systems to exchange data with an unambiguous, shared meaning, so that the receiving system interprets and uses the data as the sender intended without manual translation. It builds on technical and syntactic interoperability and requires shared information models, vocabularies or semantic identifiers.
Interface definition: In systems engineering and integration, an interface definition is the description of an interface between two systems or components, stating the exchanged data, signals or services, their formats, timing, protocols and the behavior expected from each side.
iiRDS Package: In iiRDS (intelligent information Request and Delivery Standard), a Package is the information unit that represents the delivery package itself: a collection of information units bundled with their metadata, exchanged as a ZIP archive that contains the files and a metadata.rdf file.
Digital twin: In industry, a digital twin is a digital representation of a physical entity, such as a product, machine, process or plant, that is linked to it and synchronized with it at a defined frequency and fidelity, so that its state can be observed, analyzed or simulated. ISO/IEC 30173 covers digital twin concepts and terminology; ISO 23247 provides a framework for manufacturing.
Continuous integration (CI): In software engineering, continuous integration (CI) is the practice of merging developers' changes into a shared main line frequently, at least daily, with each merge triggering an automated build and test run so integration problems are detected early.