The First Kin Client SDKs Are Live

We are very happy to publish our first open source Kin SDKs (kin-sdk-core-android and kin-sdk-core-ios).

The purpose of these projects is to significantly lower the barrier for Kin integration in mobile apps. The goal of these SDKs is for developers and digital services to easily add Kin wallet capabilities into mobile apps and for their users to be able to seamlessly earn and spend Kin on the Ethereum blockchain. These SDKs are crucial building blocks for the IPLV2 project.

The iOS and Android client SDKs provide a simple API to connect to the Ethereum blockchain. Digital services create a Kin account, display a user’s balance and send on-chain transactions. Internally, the SDK uses the go-ethereum mobile client, but the burdensome implementation details are abstracted from the end developers (i.e., you don’t have to deal with them).

When we started the project, we weren’t sure if another Ethereum SDK was really required. We could’ve just chosen a working mobile Ethereum client, added it to Kik and done all of the IPLV2 requirements internally (i.e., not open source). However, as I wrote in my previous blog post, we want to be open and transparent, share our process and get feedback from the community. Building the Kin SDK as open source from day one allows us (and forced us) to be loosely coupled and highly aligned with the different teams within Kik and other digital services going forward.

In addition, we found out that building a high-scale consumer application that interacts with the Ethereum network is not a straightforward task. During the project we had to build, test and compare several Ethereum clients on iOS and Android (such as web3.js and web3j.io to name a few). We ended up choosing go-ethereum mobile client.

Go-ethereum is considered to be well maintained and a solid project. We also prefer to use the same native solution on both platforms. However, development was not entirely smooth as we encountered a few critical problems that my team had to tackle and fix ASAP (see Oren Zakay’s blog post, with more posts coming soon). We consider these challenges a positive sign, demonstrating that our work and contributions are needed as we bring blockchain into mainstream consumers products. Another “glass half-full” positive is that once we fixed a problem on one platform, it was also fixed in the other since we’re using the same underlying solution for both.

During this process we also gained better opinions and approaches to open questions we recently asked ourselves. For example:

1. Open source from day one: We strongly believe that future projects need to be considered open source from day one. We might need to start with a private repo for the first few weeks, enabling us to tests, experiment and run proof of concepts while providing a solid foundation. However, the goal is to make the repo public as soon as possible. Our state of mind should be, “Is there a good reason not to make the repo public today?”
2. Project management: We are used to rigours development cycles with weekly sprints and releases. We collaborate between different teams, and our project managers and team leaders need to have a good overview on the progress and help out, if necessary. Jira is a great tool that helps us coordinate the project. However, we also acknowledge that it is a complex system, less transparent, and we shouldn’t force contributors (or digital service developers) to jump through this hoops. On the other hand, GitHub Issues is very simple, easy to use, well known and useful, but it lacks the advanced features we rely on. We decided to take the middle ground — tasks and bugs are added in the details of GitHub Issues, open and transparent to all. In addition, we open a Jira ticket with the link to the specific GitHub Issue and add some metadata that will help us monitor the progress and prioritize tasks. We are still experimenting with this approach but believe we are on the right track.

The last few months were extremely enlightening and refreshing. We have many years of experience in developing and continuously shipping mobile apps to our users, but we have found that building an open source project requires an additional set of expertise, especially different points of view. We really like the fact that our work is open, and that we can share it with the world. Developers can get instant acknowledgment for their contributions, not only based on written code, but also by sharing the process, problems and achievements in blog posts (like this one). In addition, we’re eager to contribute to the other open source projects we used, making the world just a little bit better :)

We’d appreciate your feedback and suggestions to help us further along this amazing path.

Check our repos ask questions and even open GitHub Issues.