Split does not currently provide native SDKs in iOS or Android. In our experience, it's better for mobile app developers to take a hybrid app approach whenever possible, placing Split's SDKs server-side and using the connection between your servers and the end-user's app to launch experiments, the same way they'd download new content.
Why take this approach? For one, the hybrid model puts less burden on each individual language. If you're building both an Android and iOS app, the more they can share common assets the better. Secondly, it's unclear what each marketplace's policies are around embedded a/b testing, experimentation and feature flag frameworks, and as of March 2017 some iOS developers have found their apps rejected from the App Store because of embedded, native-language third party feature switching platforms. Finally, installing and working with Split (or any other platform) on the server side is much easier—you can make changes when you want, and know that every user who logs in in the future will get them. If you make changes in the native language of the app, you have to wait for marketplace approval first, and for your users to download the new version of your app that includes the feature-controlling code second.
You can read more on our approach to mobile feature control in our Split for Mobile Feature Testing document, but don't hesitate to contact us at email@example.com to set up a demo or walk through how Split could work in your stack.