Чек-лист по созданию собственного SDK

Идея создания чек-листа пришла после созвона с клиентом. Пользователи его SDK жаловались на неочевидность подключения SDK к их проектам и неудобство API. Поскольку мы уже имели опыт создания платежных SDK, SDK для рекламы и чатов, перед нами была поставлена задача – найти решения, как сделать подключение SDK простым и очевидным, а API удобным.

Руководитель направления мобильной разработки SimbirSoft Ринат Шамшутдинов подготовил чек-лист, который поможет предусмотреть основные моменты при создании надежного SDK для приложений. Материал может быть полезен владельцам продуктов (product owner), техлидам и тем, кто задумывается о создании SDK для своего сервиса.

Преимущества создания собственного SDK (software development kit или «комплект для разработки программного обеспечения») неоспоримы: с его помощью вы можете существенно расширить вашу целевую аудиторию, как впрочем и целевую аудиторию ваших клиентов. Допустим, ваш сервис эквайринга до настоящего момента использовали только на сайтах. После создания SDK для мобильных приложений у вас появятся новые клиенты – аудитория пользователей мобильных приложений.

Разработка своего SDK – более сложная задача, чем разработка приложения. На это есть несколько причин:

1. Пользователи (другие разработчики), как правило, негативно воспринимают изменения SDK, которые могут затронуть их приложения. Вы не можете часто выкатывать новую версию, HotFix недопустимы. Как с этим быть, ниже.
2. Распространение новой версии SDK среди клиентов не происходит автоматически. Может возникнуть ситуация, что клиенты будут сидеть с версией SDK, выпущенной пару лет назад, так как она их устраивает и они не захотят тратить ресурсы для перехода на новую версию.
3. Трудно провести классическое A/B-тестирование. Из-за отсутствия автоматического обновления SDK у ваших клиентов вы не сможете быстро опробовать гипотезы через A/B-тестирование.
4. Поскольку работа SDK влияет на приложения клиентов и их пользователей, цена ошибки высока: пострадать могут миллионы человек, а бизнес – понести серьезные потери.

Если грамотно продумать следующие моменты, можно избежать большей части проблем в будущем. Итак, при создании SDK необходимо:

1. Выбрать технологию

Необходимо найти компромиссное решение между трудозатратами разработки SDK и поддержкой совместимости. 

SDK на чистой Java с потоками (Thread) может гарантировать 100% совместимость на долгие годы. Если используете самые последние технологии, нужно будет следить за обновлением версий этих технологий и выпускать новую версию SDK в соответствии с изменением технологий. Рекомендуем ограничиться использованием средств языков программирования и Android SDK/iOS SDK. Применяя дополнительные зависимости (например, RxJava/RxSwift), будьте готовы постоянно обновлять SDK при появлении новых версий.

Например, Apple не советует использовать библиотеки, так как может возникнуть несовместимость между версиями библиотек внутри SDK и внутри приложений клиентов. Для платформы iOS нельзя встроить XCFrameworks в другой XCFrameworks. В случае Objective-C могут возникнуть коллизии, так так все классы живут в одном namespace. Если вы пишите SDK на Swift, не забудьте использовать аннотации @objc для генерирования заголовочного файла. Это необходимо, чтобы приложения на Objective-C могли использовать ваше SDK.

2. Обеспечить гибкость API для клиентов

Предстоит выбор между простой настройкой и гибкостью.

Для платежных SDK можно предоставить клиентам только запуск экрана оплаты с передачей суммы, информации о получателе и метаданных платежа. Экран ввода номера банковской карты и  подтверждения платежа можно сделать внутри SDK. Для клиентов такой вариант API дает максимальную простоту настройки, а бизнесу – возможность безболезненно менять SDK. Гибкость настройки при этом страдает.

Другой вариант – дать прямой доступ к методам сервера, включая технологии подтверждения платежей, отмены и т.п. В этом случае клиенты далеко не всегда смогут корректно настроить работу с вашим сервисом, а значит высок риск перегрузки службы поддержки и рост числа негативных отзывов при возникновении любых ошибок, даже если ошибки будут в коде клиентов, а не вашем.

При разработке SDK важно сперва предоставить клиентам урезанный API. Впоследствии, когда работа будет отлажена, можно добавить опцию кастомизации для пользователей.

3. Провести тестирование на реальных данных

Для проверки SDK нужно свое пользовательское приложение, куда SDK сможет интегрироваться. Перед выкладыванием в публичный доступ всегда нужно проверять на реальных данных. Например, проводить платежи через настоящие карты разных банков. Также необходимо покрыть SDK модульными, интеграционными и сценарными автотестами, чтобы уменьшить вероятность пропустить ошибку при изменении SDK.

4. Обеспечить удобство API для клиентов – developer experience ваших клиентов

Попросите команды из других проектов вашей компании, знакомых разработчиков попробовать интегрировать SDK и оставить обратную связь об удобстве. Можно сделать выборку среди ваших клиентов и попросить их протестировать новую версию API, например, предложив им взамен скидку.

Выложите альфа-версию вашего SDK на GitHub и попросите сообщество оставить обратную связь, что можно или нужно изменить. В этом случае вы повысите уровень сопричастности клиентов к вам и вашему продукту.

5. Подготовить документацию

Как пользователь чужих SDK, могу с уверенностью сказать, документацию нужно писать понятно и подробно, чтобы можно было четко по инструкции, не думая, подключить SDK. В идеале – в документации должны быть примеры кода. В качестве хорошей документации стоит ориентироваться на Google.

При изменении SDK рекомендую написать примеры миграции со старого SDK на новое. Здесь тоже можно обратиться к опыту Google.

6. Сделать sample-проект

Для разработчиков, помимо документации, нужен sample-проект. Код лучше всякой документации расскажет, как использовать SDK. Для создания хорошего sample-проекта потребуются ресурсы – время разработчиков. Задокументируйте строчки, где осуществляется настройка и вызов SDK.

Также sample проект поможет вам понять, будет ли SDK удобен во встраивании и использовании.

7. Позаботиться о размере SDK

Поскольку любая зависимость транзитивно будет тянуться в приложение клиента SDK, повышая его конечный размер, не стоит добавлять в зависимости тяжеловесные библиотеки, например, на C++.

Некоторые клиенты чутко реагируют на изменение размера. Возможно проще и удобнее будет написать свою реализацию какого-либо инструмента.

8. Продумать, где будет работать SDK

Для Android еще стоит продумать, где будет работать SDK: в процессе приложения или в отдельном процессе.

По умолчанию SDK запускается в том же процессе, что и приложение клиента. Это несёт в себе главную опасность – при падении SDK «упадёт» и приложение клиента.

Есть примеры, когда SDK запускается в отдельном процессе. Однако тут стоит помнить, что для этого будет создан новый экземпляр класса Application, а это может нарушить работу SDK или приложения.

9. Подумать над путями распространения SDK

Передача клиенту лично, через Maven Central, GitHub и т.д.

Каждый из путей имеет свои плюсы и недостатки. Например, распространяя свою библиотеку через Maven без Internal Repositories, стоит быть готовым к тому, что ей сможет воспользоваться каждый. Продвижение через GitHub аналогично Maven. Если бесплатно публиковать — все смогут скачать. Платное распространение можно организовать через приватный репозиторий. Личная рассылка будет удобна только при небольшом количестве клиентов.

Для iOS желательно добавить поддержку стандартных менеджеров зависимостей библиотек – Cocoapods, Carthage, SPM. Также всегда остается вариант распространения через GitHub как подпроект.

10. Предусмотреть возможность наполнения SDK

При создании SDK лучше сразу подумать над тем, будете ли вы менять наполнение SDK в зависимости от клиента, который будет ей пользоваться.

Если планируете, необходимо тонко настроить product flavours/target, чтобы клиенту попала именно нужная сборка.

11. Лицензирование SDK

Если вы хотите воспользоваться помощью сообщества для улучшения SDK, лицензию на него стоит сделать свободной, выбрав, например MIT/Apache 2.0. Также внимательно изучите лицензии (краткая памятка – тут) библиотек, шрифтов, картинок, которые вы используете в своем SDK. Даже платный шрифт в дизайне мобильного SDK может нарушить лицензию.

12. Обеспечить безопасность SDK

При разработке SDK важно исходить из того, что потенциальные клиенты смогут прочитать ваш код, даже если он будет обфусцированный. Поэтому в плане безопасности, в первую очередь, необходимо обеспечить защиту на стороне сервера – от тех же DOS-атак. В рамках SDK нужно проследить, чтобы пользователю были доступны только методы и классы публичного API.

По соображениям безопасности Apple, например, рекомендует встраивать зависимости в SDK. Перед обновлением версии в крупных компаниях сотрудники, отвечающие за безопасность, повторно проверяют эти зависимости, чтобы автор сторонней библиотеки не добавил какой-либо компрометирующий код.

Итог

Разработка SDK имеет немало сложностей и требует от команды большого опыта, в этой области нужно постоянно учиться. В свою очередь, SDK помогает расширить вашу целевую аудиторию за счет пользователей мобильных устройств и в перспективе увеличить прибыль.