Зависимости жизненно важны для большинства проектов iOS. Они позволяют нам ускорить разработку и не изобретать велосипед каждый раз, когда нам нужны такие компоненты, как работа в сети, рендеринг, чат, календарь и многие другие, которые могут быть общими для разных типов проектов. Это также эффективный способ передать обслуживание кода компании или сообществу разработчиков открытого исходного кода, поскольку они исправят ошибки, добавят новые функции и обновят код за вас. Используя зависимости, мы можем сосредоточить свое рабочее время на том, что отличает наше приложение iOS от всего остального.

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

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

Открытый исходный код или исходный код доступен

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

Зависимости с закрытым исходным кодом, распространяемые в скомпилированном формате, таком как .xcframework, представляют собой непрозрачный блок. Трудно сказать наверняка, что он делает. Какие данные он собирает? Что он отправляет на сервер? Может ли это привести к сбою моего приложения при определенных обстоятельствах, не зависящих от меня? Сколько времени потребуется сопровождающему, чтобы исправить ошибку?

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

Активное развитие

Прежде чем выбрать зависимость, проверьте, как давно были сделаны ее последние обновления. Если это дни или недели, скорее всего, он совместим с последними версиями iOS, и вы сможете рассчитывать на обновления какое-то время. Также более вероятно, что специалисты по сопровождению все еще готовы помочь, если у вас возникнут вопросы.

С другой стороны, если с момента последних обновлений прошли месяцы или годы, вам не следует использовать эту зависимость. Маловероятно, что он по-прежнему совместим с последними версиями iOS или Swift, и еще менее вероятно, что сопровождающий будет рядом, чтобы помочь вам или предоставить какие-либо новые обновления.

Неактивные проекты, как правило, содержат ошибки, и их следует избегать, но их все же можно использовать, если вы готовы их разветвить, исправить обнаруженные ошибки и стать сопровождающим. Однако в большинстве случаев создание необходимого компонента с нуля может оказаться более продуктивным.

Создан на Swift

Swift существует уже пять лет. Сейчас он считается зрелым языком и значительно повысил производительность и точность кода по сравнению с его предком, Objective-C. Не секрет, что эти улучшения перенесены на используемые вами зависимости. Зависимости, построенные с помощью Swift, вероятно, будут более стабильными и будут легко вписываться в шаблоны и функции Swifty, которые разработчики знают и любят, такие как протокольно-ориентированное программирование, опции, обобщения, типы коллекций, функции первого класса. ", и другие.

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

Если зависимость написана на Objective-C, это еще не значит, что она решает проблему, если она все еще активно поддерживается. Тем не менее, я обнаружил, что каждая зависимость Objective-C, которую я хотел использовать, имела отличную и новую альтернативу, написанную на Swift. Например, с годами я заменил SDWebImage на Nuke почти во всех своих проектах с большой пользой.

Компания обслуживается

Зависимости, поддерживаемые компанией, обычно более надежны по сравнению с зависимостями, поддерживаемыми сообществом. Маловероятно, что SDK или библиотека, поддерживаемая компанией, будут заброшены, если это жизненно важно для бизнеса компании.

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

Приветствуя Сообщество

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

Вывод

Это характеристики, которые я ищу при поиске библиотек и SDK для iOS. Сложно найти библиотеку, в которой отмечены все эти флажки, но их учет помогает сравнить варианты и выбрать тот, который доставит вам меньше проблем в будущем.