Connect with us

Разработка

Что Swift Build означает для экосистемы Swift

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

Опубликовано

/

     
     

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

Это согласование должно было происходить на разных уровнях, от фреймворков до инструментария. Возможно, вы видели инициативу Apple по открытию исходного кода Foundation. Foundation является настолько «основополагающим» для создания программ на Swift, что Apple решила отделить его от платформ Apple и открыть исходный код.

Один из уровней согласования, которому потребовалось больше времени, чтобы привлечь внимание, — это система сборки. С недавним анонсом Swift Build компания Apple дала понять, что ситуация наконец-то меняется.

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

Системы сборки

Система сборки — это программное обеспечение, отвечающее за создание запускаемых или общих программных артефактов, таких как статические библиотеки или приложения для macOS. Каждый современный язык программирования поставляется с системой сборки, обычно интегрированной с другими инструментами, такими как прогонщики тестов, форматеры или менеджеры зависимостей. В Rust есть Cargo, в Elixir — Mix, а в Go — инструмент go. В экосистеме Apple есть два таких инструмента: xcodebuild и SwiftPM. Эта двойственность существует как следствие примирения двух миров.

Системы сборки требуют представления проекта, которое может быть кодифицировано в системе сборки с помощью соглашений, сериализуемых конфигурационных файлов, таких как Cargo.toml, или сочетания того и другого. В случае xcodebuild и SwiftPM проекты представлены в трудносериализуемом формате .pbxproj и файлах Package.swift, соответственно.

Инструменты сборки строят представления проектов, обычно напоминающие графы, в памяти. Имея в памяти этот граф, система сборки может не только скомпилировать проект, но и проанализировать его, оптимизировать или даже создать основу для нового опыта, например протоколов языкового сервера (LSP).

В экосистеме Swift долгое время существовало два графа, которые значительно пересекались: один был достаточно общим, чтобы работать во многих операционных системах, а другой был тесно связан с ОС Apple и Xcode. Это приводило к дублированию усилий и проблемам в обеспечении отличного опыта разработчиков (DX). В течение многих лет экосистема страдала от функций, которые либо не работали, либо работали ненадежно, либо были просто медленными.

Единый граф

С помощью Swift Build Apple объединяет систему сборки и графы, используемые как в Swift, так и в Xcode. Если набор инструментов представляет собой набор слоев, а система сборки находится в нижней части SwiftPM и Xcode, то такая унификация сродни перемещению этого слоя в самый низ, чтобы использовать его совместно с обоими инструментами. Мы считаем, что это отличная идея.

Обратите внимание, что форматы остаются разными — с одной стороны, у вас есть пакеты Swift, а с другой — проекты Xcode. Перед передачей в систему сборки они преобразуются в формат Project Interchange Format (PIF).

Влияние на опыт разработчиков

Для полной реализации этого объединения потребуется время, но мы считаем, что, как только это произойдет, улучшения в работе разработчиков станут беспрецедентными:

  • Более быстрое внедрение улучшений: новые функции и доработки нужно будет внедрять только один раз, что ускорит их доступность.
  • Повышенная надежность: Устранение части проблем, связанных с согласованием, должно привести к появлению более надежных функций, таких как детерминизм сборки или предварительный просмотр в SwiftUI.
  • Расширяемость: Новая система сборки спроектирована так, чтобы быть расширяемой, что упрощает для сообщества добавление поддержки новых платформ без непосредственного участия в репозитории системы сборки. Представьте, что вы выбираете WebAssembly в качестве цели для сборки непосредственно из пользовательского интерфейса Xcode.
  • Оптимизация времени сборки: Apple использует возможность оптимизации времени сборки, аналогичную Bazel. Первым шагом в этом направлении стали модули Explicit, а наличие CAS (адресуемого хранилища контента) в кодовой базе позволяет предположить, что на горизонте появятся новые возможности оптимизации.
  • Основа для новых возможностей в программировании: Эта унифицированная система сборки может послужить основой для инновационных разработок в области программирования, расширяя границы возможного в Xcode. Искусственный интеллект уже доказывает, что предоставление рынку или экосистеме возможностей для изучения новых идей может стать катализатором инноваций.

Мы настоятельно рекомендуем использовать Swift Build в своих проектах и сообщать о любых возникающих проблемах. Ваши отзывы помогут Apple усовершенствовать эту новую систему, создав нечто поистине невероятное.

Как это связано с нашими планами

Цель Tuist — улучшить опыт создания приложений, расширив инструментарий Apple. Расширяемая основа — это то, чему мы очень рады, потому что она открывает новые возможности, которые кажутся более зрелыми и соответствующими платформе.

Хотя доступный сейчас код предоставляет всю информацию, необходимую для понимания и оптимизации проектов, их улучшение часто требует более целостного взгляда на данные — как они изменяются со временем и как они связаны с работой, происходящей в таких местах, как GitHub. Именно в этом и заключается наша сила. Мы создаем серверную инфраструктуру, стандартизируем данные, делаем их доступными для вас и создаем на их основе полезные серверные функции. Это позволяет вам сосредоточиться на проверке кода и создании своих приложений с помощью Xcode — или, возможно, Cursor в будущем.

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

Перекрытие между Swift Packages и проектами Xcode

Вы, наверное, заметили, что, несмотря на унификацию системы сборки, все еще существуют два формата, которые частично пересекаются: проекты Xcode и пакеты Swift. У первого есть свои недостатки, которые позволили нам создать процветающее сообщество в Tuist вокруг этого. Второй формат используется многими командами для устранения недостатков проектов Xcode. Однако, поскольку пакеты Swift никогда не создавались для этой цели, опыт разработчиков начинает страдать при масштабировании.

Каким будет будущее? Это неясно, но мы сомневаемся, что два формата будут существовать вечно. Как и xcodebuild, формат проектов Xcode был разработан для платформ Apple и за долгие годы накопил много наследия, что превращает его в кошмар для поддержки в масштабе. С другой стороны, пакеты Swift, где манифесты должны быть скомпилированы и могут легко привнести побочные эффекты, тоже не кажутся идеальными — по крайней мере, без существенных изменений.

Возможно, мы увидим Swift Build DSL, похожий на Kotlin DSL из Gradle, специально разработанный для объявления графов сборки без побочных эффектов. С этим DSL можно будет работать так, чтобы изменения в нем почти мгновенно приводили к изменениям графа. Или, кто знает… возможно, таким языком станет PKL. Независимо от пути, мы в Tuist хотели бы видеть эту разработку в открытом доступе и даже хотели бы принять в ней участие, если это возможно. У нас есть много идей из нашего опыта, понимания и оптимизации проектов Xcode, которые мы хотели бы внести в экосистему.

Заключительные слова

Это шаг, который стоит отметить. Каждый новый компонент, который Apple делает открытым — это возможность для появления различных идей и улучшения всей экосистемы. Так что спасибо всем, кто сделал это возможным. Мы рады этому и с нетерпением ждем, что ждет Swift в будущем.

Источник

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Telegram

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: