# Enabling Developers to Create SDKs for Transifex Native

**URL:** <https://community.transifex.com/t/enabling-developers-to-create-sdks-for-transifex-native/2006>\
**Category:** What's new?\
**Tags:** transifex-native\
**Created:** [August 31, 2020, 6:28am UTC](https://community.transifex.com/t/enabling-developers-to-create-sdks-for-transifex-native/2006 "2020-08-31T06:28:56Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![nina](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.transifex.com/nina/32/13_2.png) [@nina](https://community.transifex.com/u/nina)\
**Post date:** [August 31, 2020, 6:28am UTC](https://community.transifex.com/t/enabling-developers-to-create-sdks-for-transifex-native/2006/1 "2020-08-31T06:28:56Z")

</div>

Implementing a new Native SDK poses some interesting engineering challenges, in terms of designing a good architecture and creating highly usable APIs. Every such SDK has several required parts that are necessary for the solution to work and there are certain specifications that need to be followed, such as how to communicate with the Transifex [Content Delivery Service](https://docs.transifex.com/transifex-native-sdk-overview/hosting-translations) (CDS), or the kind of metadata that Native supports. Finally, there are particular challenges that are common to all Native SDKs, such as dealing with ICU Message Format, escaping strings, handling plurals, and generating unique keys.

In order to help developers create new SDKs, we decided to craft a _detailed guide_ with all the material that would make their work as straightforward as possible. This is how the [Native Specifications document](https://transifex.github.io/native-specs) came to life.

> **[Enabling Developers to Create SDKs for Transifex Native](https://www.transifex.com/blog/2020/developers-sdks-transifex-native/)**
>
> We made Transifex Native open-source to fully enable the wider open-source community to take advantage of our architecture and build on top of it via SDKs.