SDK
Software Development Kit
What is an SDK?
- A toolkit for developing on a specific platform
- Makes APIs easier
- A bundle of code, docs, and examples
Once you decide to adopt an SDK, the dev team's job shifts from 'building' to 'choosing and vetting'. The time spent hand-coding payment approval flows, map tile loading, and voice streaming from scratch disappears; what remains is deciding which SDK to use, and which version. The change you feel is in the schedule. An integration that took 2–3 weeks from API docs alone often takes 2–3 days with an official SDK. But there is a price: your product becomes tied to that service's design and release cycle.
Even the same SDK behaves differently depending on where it runs. A client SDK inside an app or browser handles display and user authentication, while a server SDK handles anything involving money and permissions, such as payment approval, refunds, and settlement. If a library is one chunk of functionality, an SDK is a box that adds docs, examples, debugging tools, and sometimes a test sandbox. A framework, by contrast, puts your code inside its own structure. You should also distinguish an official SDK from a wrapper written by an individual, and it is safer to drop any SDK with no commits in the last 6 months from your shortlist.
There are generally four things to check before integrating: supported languages and minimum OS version, the major-version release cycle, the increase in app size, and the data the SDK collects. A major version bump often changes function names and calling conventions wholesale, so set aside time at least once a year to update. On mobile, a single SDK can add 2–5MB to the app, and if you add ads, analytics, and payments, you reach a point where install abandonment rises noticeably.
The most common mistake in the field is hard-coding a secret key into a client SDK. App packages can be unpacked and their strings read as-is, so the key leaks, API calls are made under someone else’s account, and you get the bill. Another common misconception: “we installed the SDK, so the rest is the vendor’s responsibility.” In practice, an analytics SDK may collect device identifiers while the app omits the required notice about sharing personal data with third parties, and the app is rejected in review. When an end-of-support notice appears, calls to old versions are usually blocked 6–12 months later, so factoring in the cost of removal is part of the adoption decision.
Seolyeong ParkGenerative AI and AX training expert with 17 years of hands-on experience and 200+ lectures, who gets non-specialists using AI right away
John KimJohn Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”A bundle of tools that supports development for a specific platform or device. SDKs have existed since the early days of software and became widespread with the growth of mobile, cloud, and AI services.
Let’s look at a hypothetical case. Company A is a home-appliance distributor with 140 employees and annual revenue of about KRW 90 billion (≈ US$67,335,000). Abandonment at the payment step of its app had reached 18%, so it decided to add mobile pay, but it had only 3 developers. They tried building it directly from the payment provider’s API docs, got stuck on the card issuer’s identity-verification redirect, and the launch had already slipped by 6 weeks.
- Mr. Kim, the development lead, said, “Just wiring up the back-and-forth of the authentication screens would take another 2 weeks.” He dropped the direct build and proposed switching to the payment provider’s official iOS and Android SDKs plus a server SDK.
- Ms. Lee, the security manager, insisted that “the secret key must never live in the app.” So the team split the roles: the app holds only the public key to open the payment window, while the server SDK handles approvals, cancellations, and refunds.
- They pinned the SDK version to 2.4.x and ran 40 card, bank-transfer, and mobile-pay transactions in the sandbox, covering partial-cancellation and duplicate-payment scenarios, so they could check failure cases before launch.
- During QA, three Android 9 devices fell below the SDK’s minimum supported spec and the payment window would not open. The team added a branch that routes just those devices to web payment and fixed the problem in a day.
- The payment integration, delayed by 6 weeks, was finished in 9 days, and two months after launch, abandonment at the payment step fell from 18% to 11%. The app grew by 4.2MB, and the team added SDK version checks to the schedule as a quarterly routine task.