Typically when I see acronyms in docs I do one of two things: either "ignore complexity" like I've been learning to do with most concepts, or just altogether dissociate.
Neither of these actions are really helpful, and the second option is usually pretty disruptive of my workflow so recently, I've started allowing myself a strict, alarm-set 5 minutes to google something, and then make assumptions as to what it could really mean. It's not that I don't want to know what literally every single one of these acronyms means, but when I'm on insane deadlines, stopping active work to take on Zelda-like side-quests is a sure-fire recipe for an Alice-like rabbit hole.
But sometimes, just like in Alice's case, some of these (acronym) side-quests are absolutely worth going on. Take "SDK" for an example, a perfectly good acronym in which I was more than happy to ignore the complexity of, but little did I know I would be completely immersed in it for a project that I was about to begin working on.
After a click or two around Wikipedia, I was happy to discover that I didn't actually have to go that deep into the rabbit hole to find out what SDKs are all about, and was even more psyched to learn that they're really not all that complex or scary as I thought.
During an app's planning stages, one of the first things to consider is what platform it will utilize. Whether it's an mobile or web application, the development requirements will be different and will require different tools to implement functionality. Luckily, when utilizing an SDK in development, a lot of these concerns are abstracted away by the out-of-the-box functionalities that SDKs provide.
A Software Development Kit, better known as an SDK, is a collection of tools that allows programmers to build apps for specific operating systems or devices. Regardless of what operating system or device an SDK is for, all the best ones come equipped with the same base ops that include:
- Documentation
- Code examples
- Libraries
- Tutorials
- API's
- IDE capabilities
- Tools for testing and debugging
These kits aid developers throughout an app's construction and provides a way to utilize a number of languages, services, and functionalities that developers would typically have to pull from external API's and other services across the web. Most applications include a number of SDKs, with the average being between 15-18. Similar to npm, SDKs also have management systems that keep packages organized like "NVIDIA" or "SDKMAN!"
A few examples of SDKs are:
- Expo
- Flutter
- Windows SDK
- iOS SDK
- Android Studio
note: Android Studio is interesting because it is actually an IDE for developing Android apps, but actually comes with the SDK built in.
In the aforementioned project above, my team and I used the Expo SDK build a native audio recording app with React Native. Expo is a great SDK to utilize when first starting out. It has a lot of built in API's that can be accessed and once the I got the hang of it, I found myself really enjoying the experience.
Another huge benefit of Expo is that it's a multi-platform SDK, meaning underneath the hood, it's handling the functionality for developing in both Android, which is written in Java, and iOS, which is not. Either way it's complexity we can ignore, which is awesome.
Like a good SDK, there was clear and up-to-date documentation whenever platform differences needed a tweak here and there, as well as a plethora of built-in API's to choose from to suit our app's needs.
Also, like all SDKs it was easily installed in one package:
//make a new directory to create an expo project
mkdir my-expo-project
//cd into the project
cd my-expo-project
//install the expo client with npm
npm install -g expo-cli
//initialize an expo project
expo init
//follow the directions that appear in in the console to create your project!
Expo is just one of many SDKs to choose from, and choosing the "right" one is solely built on the needs of the app. Occasionally, SDKs
may prove to be not the right fit for development, and this can happen early on our even in the middle of development. While Expo provides the ability to "eject" from the SDK to revert to native code from any standpoint without extreme overhaul, others may not, and therefore it's important to read any initial documentation before settling on an SDK for your app.
In conclusion, SDKs are just a collection of software development tools that are used to build apps for specific platforms or operating systems.
What are your best and worst experiences working with SDKs?
Thanks for reading!
Top comments (0)