@_spi - атрибут для тех, кто пишет фреймворки.

Как вы добиваетесь того, чтобы ваша библиотека содержала и общедоступный, и приватный код? Под приватным я имею ввиду ту часть кода, которая доступна «особым» пользователям библиотеки, например сервисные функции для дебага, не нужные обычному пользователю, или какие-то скрытые функции, которые нужны вам в своем проекте, но не должны быть доступны сторонним пользователям.

Обычно используют следующие варианты решения:
1) «Нет никаких приватных функций, пусть все функции будут общедоступными». Но так вы перегружаете список доступных функций, окно автодополнения и вызываете у пользователя библиотеки вопросы.
2) «Сервисные функции начинаются с _», вроде _enableDebugMode(). Итог как и в пункте 1.
3) Самый радикальный, но наиболее безопасный - выпуск нескольких версий библиотеки, одна со скрытым функционал, и одна только с общедоступным.

Но есть и другой способ - атрибут @_spi, который позволяет скрывать часть функционала вашего фреймворка и делать его доступным только при определенных условиях.

Так например вы можете пометить любые функции, методы, а возможно и свойства (не знаю, не проверял) с помощью @_spi(имя), и данный элемент станет доступным пользователю только если он импортирует библиотеку с помощью конструкции ```@_spi(имя) import ВашаБиблиотека```.

Пример смотрите в картинке ниже поста.

Количество различных имен внутри @_spi атрибута не ограничено. Вы можете делить таким образом функциональность на блоки и передавать пользователям те имена, которые им требуются.

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

SPI - System Programming Interface. Это тот же API, только «системный» или «сервисный».

Почитать можно тут. Так же обратите внимание на @_spiOnly и @_spi_available по той же ссылке.

🎧🎙️Подкаст Кофе и Код с моим участием «ушел на золото».

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

Спасибо, что пишите и даете обратную связь по вашим успехам.

https://coffeecodepodcast.mave.digital

Тут ссылки на все доступные подкастерские платформы

📕 LLVM: Инфраструктура для разработки компилятора

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

Компилятор Swift основан на проекте LLVM. Это целая инфраструктура программных решений, на ее основе существуют решения для C, C++, Objective-C, JavaScript, Kotlin и многих других языков.

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

VK ✕ Coffee&Code

🏙Москва
📆5 июня (Понедельник)
⏰19:30
📱iOS

Место: VK
Адрес: Ленинградский проспект, 39с79, БЦ SkyLight

Встречаемся в офисе компании VK для просмотра WWDC. Смотрим конференцию, обсуждаем новые технологии и отлично проводим время.

Необходима предварительная регистрация

VK — это более 200 технологичных проектов, больше 10 000 сотрудников и миллион возможностей проявить себя.

💻 О многомодульных приложениях

Делить проект на модули - довольно популярный подход при разработке приложений, особенно когда MVP выпущен, а приложение начинает неконтролируемого обрастать межмодульными зависимостями. Сперва модули выделяют в отдельные классы/структуры, реализуя взаимодействия через интерфейсы, на втором этапе часть модулей переезжают в отдельные таргеты, и используются в составе проекта, как фреймворки. И т.д.

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

Довольно интересный опыт есть у ребят в СберЗдоровье, их лид Кирилл Смирнов делится им в своих статьях (первая, вторая) на Хабре. Советую к прочтению.

Кстати, года три назад я выкладывал пост про ортогональность ваших проектов, и как наследование способно сделать вам плохо.

Друзья, рады объявить тайминг нашего Mobile-Митапа Дзен х Coffee&Code, который пройдет 15 июля

16:00 - сбор гостей
17:00 - «Что такое Дзен для IT?» (Алексей Федотов, Дзен)
17:15 - Паблик-ток «Разработка и блоггинг - как совмещать и зачем?» с Алексеем Гладковым (Mobile Developer) и Кириллом Розовым (Android Broadcast)
19:00 - «Технический долг: что это такое и как с ним работать» (Владислав Марков, iOS Techlead в Дзене)
19:30 - «Как корутины входят в жизнь разработчиков?» (Василий Усов - iOS Разработчик в VK , автор книг по Swift, создатель телеграм канала Dev Channel)
20:00 - нетворкинг, свободное общение
21:00 - завершение мероприятия

Количество мест ограничено, регистрация - по ссылке
Всех ждем!

С осторожностью совмещайте новый Concurrency и старую асинхронность.

В данном случае показан пример, что использование коллбеков вместо async/await может привести к потере @MainActor.

Вроде бы Controller наследован от UIViewController, который @MainActor. Да и метод для надежности помечен, как @MainActor. Но при передаче в качестве коллбека @MainActor отбрасывается и функция выполняется на произвольном потоке (может на мэйне, а может и не на мэйне, смотря что свободно).