🍎 ИИ-провал Apple: Siri получит мозги Gemini от Google.

По данным Bloomberg, Apple ведет переговоры с Google о сделке на $1 ИИ-модели Gemini для обновленной Siri. Это одно из самых неожиданных технологических партнерств года.


Что происходит:

🔹 Apple будет использовать 1.2 триллионную модель Google Gemini для новых функций Siri.
🔹 Сумма контракта около $1 миллиарда в год.
🔹 Обновленная Siri с кодовым именем Linwood выйдет весной 2026 года в iOS 26.4.


Технические детали:

Gemini будет отвечать за две ключевые функции:

🔹 Суммаризация: сжатие и обобщение информации.
🔹 Планирование: выполнение сложных многошаговых задач.

При этом основные функции Siri останутся на собственных моделях Apple. Важно: все вычисления будут происходить на серверах Apple Private Cloud Compute без доступа Google к пользовательским данным.


Почему это важно:

🔹 Признание отставания: Apple официально признает, что отстала в ИИ-гонке.
🔹 Временное решение: это временное решение, пока Apple не догонит по качеству.
🔹 Стратегический ход: лучше временное партнерство, чем полная потеря рынка.


Что будет дальше:

Apple уже разрабатывает собственную модель на 1 триллион параметров и надеется заменить Gemini уже в 2026 году, но догнать Google, которая постоянно улучшает Gemini, будет непросто.


💡 Вывод:

Это напоминает ситуацию с поиском в Safari, где Google платит Apple миллиарды за статус поиска по умолчанию. Теперь роли поменялись: Apple платит Google. Для пользователей это в целом хорошая новость: Siri станет значительно умнее.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Swift Migration Tooling: правильная миграция Swift кода.

Добрый день! Сегодня поговорим о том, как правильно готовить проекты к будущим обновлениям Swift. Оказывается, многие до сих пор мигрируют вручную, хотя Apple давно предоставила удобные инструменты.


Зачем это нужно?

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


Как это работает:

В настройках сборки Xcode есть секция «Upcoming Features». Там можно включить режим миграции для конкретной фичи:

🔹 Выбираете фичу из выпадающего списка.
🔹 Включаете Migrate вместо Enabled.
🔹 Собираете проект и изучаете замечания.
🔹 Применяете автоматические фиксы.


Пример.

Допустим, у вас есть код:

class DataProcessor {
  func processData() async {
    // Какая-то логика
  }
}

После включения миграции Xcode покажет предупреждение и предложит добавить @concurrent:

class DataProcessor {
  @concurrent func processData() async {
    // Теперь код готов к будущим изменениям
  }
}

Почему опасно мигрировать вручную:

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


Преимущества автоматической миграции:

🔹 Безопасность: инструмент знает все нюансы изменений.
🔹 Скорость: минуты вместо дней/недель.
🔹 Обучение: каждое замечание содержит подробное объяснение.
🔹 Консистентность: правки в едином стиле по всему проекту.


Работает для Swift Package Manager.

Тот же подход работает и для пакетов через swift-settings в Package.swift:

.target(
  name: "MyLibrary",
  swiftSettings: [
    .enableUpcomingFeature("StrictConcurrency")
  ]
)

🔗 Ссылка на подробную статью


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 AutoreleasePool: когда ARC недостаточно для управления памятью.

Всем привет! Сегодня разберем механизм AutoreleasePool - наследие Objective-C, которое продолжает играть важную роль в управлении памятью Swift-приложений. Этот инструмент особенно актуален при работе с ресурсоемкими операциями.


Принцип работы AutoreleasePool:

AutoreleasePool функционирует как отложенный менеджер памяти. В отличие от немедленного освобождения объектов при выходе из области видимости, система собирает их в специальный пул. Очистка происходит при явном вызове drain() или по завершении текущего runloop-цикла.


Пример:

for i in 0..<5000 {
  // Data работает с байтами (UInt8)
  // Каждый элемент занимает 1 байт. 1024 * 1024 = 1 МБ
  let data = Data(repeating: 0, count: 1024 * 1024) // 1 MB
  processData(data)
}

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


Оптимизированный подход:

for i in 0..<5000 {
  autoreleasepool {
    let data = Data(repeating: 0, count: 1024 * 1024)  // 1 MB
    processData(data)
  }
}

Теперь каждый экземпляр Data уничтожается после итерации, сохраняя стабильное потребление памяти.


Исторический контекст и современность:

В Objective-C разработчики вручную управляли пулами через NSAutoreleasePool. Swift сохранил эту функциональность через синтаксис autoreleasepool {}, хотя в большинстве сценариев ARC успешно справляется самостоятельно.


Критические сценарии применения:

🔵Пакетная обработка медиафайлов: при последовательной обработке изображений или видео создание отдельных пулов для каждого файла предотвращает кумулятивное потребление памяти.
🔵Фоновые операции: в кастомных thread-ах, где отсутствует автоматический runloop, необходимо ручное управление пулами.
🔵Работа с Legacy-кодом: при интеграции старых Objective-C библиотек, активно использующих autorelease.


Подробные статьи:

🔵NSAutoreleasePool
🔵Управление памятью в Swift
🔵Что такое autoreleasepool?


💡 Вывод:

AutoreleasePool остается специализированным инструментом для оптимизации пикового потребления памяти. Его разумное применение особенно важно в высоконагруженных приложениях, где контроль за памятью напрямую влияет на производительность и стабильность приложения.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Новые возможности UIColorPickerViewController в iOS 26.

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


HDR-цвета в стандартных компонентах:

Одним из наиболее значимых обновлений стала поддержка HDR-цветов в UIColorPickerViewController и UIColorWell. Новое свойство maximumLinearExposure позволяет задавать максимальную яркость для цветов с расширенным динамическим диапазоном. Значение больше 1 активирует дополнительный слайдер «HDR Boost», дающий пользователям возможность тонко настраивать экспозицию выбранного цвета.

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

Пример:

// Настройка пикера для профессиональной работы с цветом
let colorPicker = UIColorPickerViewController()
colorPicker.supportsEyedropper = true
colorPicker.maximumLinearExposure = 2.0  // Расширенный диапазон яркости

// Для UIColorWell в кастомных интерфейсах
let colorWell = UIColorWell()
colorWell.supportsEyedropper = true
colorWell.maximumLinearExposure = 1.8

Пипетка становится публичным API:

Свойство supportsEyedropper, ранее доступное только как приватный API в iOS 18, теперь официально документировано и доступно для использования. Эта функция позволяет включать или отключать инструмент «пипетка» в интерфейсе выбора цвета. При активации пользователи могут выбирать цвета напрямую с экрана своего устройства, что значительно ускоряет рабочий процесс и повышает точность подбора цветов.

Пример:

// В фоторедакторе быстрый захват цвета с изображения
func setupColorPickerForPhotoEditing() {
  let picker = UIColorPickerViewController()
  picker.supportsEyedropper = true
  picker.maximumLinearExposure = 1.5
  present(picker, animated: true)
}

// В дизайнерском инструменте точный подбор цветов
func createDesignColorWell() -> UIColorWell {
  let well = UIColorWell()
  well.supportsEyedropper = true
  well.maximumLinearExposure = 1.2
  return well
}

Практическая значимость для разработчиков:

Эти обновления демонстрируют тенденцию к унификации инструментов выбора цвета между платформами. Теперь UIKit предлагает функциональность, сравнимую с современными веб-решениями и нативными инструментами других операционных систем.

Для разработчиков это означает сокращение необходимости в создании кастомных решений для работы с цветом. Стандартные компоненты теперь покрывают большинство сценариев использования, включая профессиональные задачи, связанные с точным подбором и настройкой цветов.


🔗 Ссылка на подробную статью


💡 Вывод:

Новые возможности UIColorPickerViewController и UIColorWell в iOS 26 значительно расширяют инструментарий разработчика для работы с цветом. Поддержка HDR-цветов через maximumLinearExposure и официальный доступ к инструменту «пипетка» через supportsEyedropper превращают стандартные компоненты в профессиональные решения для современных приложений.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Обновленное автодополнение кода в Swift.

Сегодня поговорим о важном обновлении в экосистеме Swift, которое существенно улучшит повседневную работу каждого разработчика.

SourceKit-LSP получил серьезные улучшения в системе автодополнения кода. Теперь при написании кода вы видите не просто названия методов, а полноценную документацию с примерами использования и всеми доступными перегрузками.


Что такое SourceKit-LSP:

SourceKit-LSP - это реализация протокола Language Server Protocol (LSP) для языков Swift и C. Если говорить простыми словами, это мост между Swift и различными редакторами кода, который обеспечивает умные возможности в любой среде разработки.


Как это работает:

Представьте: вы начинаете писать метод, и система сразу показывает все возможные варианты его использования с полным описанием параметров. Не нужно переключаться в браузер для поиска документации, вся информация доступна прямо в редакторе. Это работает не только в Xcode, но и в VS Code, Neovim и других популярных средах разработки.


Почему это важно:

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


🔗 Ссылка на подробную статью


💡 Вывод:

Обновления в SourceKit-LSP - это не просто новые фичи, а качественное улучшение процесса разработки. Они делают работу со Swift более комфортной и эффективной, экономя время и уменьшая количество ошибок.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Новый Mutex в Swift: современный подход к блокировкам.

Привет! Сегодня разберем новый инструмент для работы с многопоточностью в Swift: фреймворк Synchronization и его основной элемент Mutex. Этот подход предлагает современную альтернативу традиционным блокировкам и особенно полезен в контексте Swift Concurrency.


Что представляет собой новый Mutex:

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

Рассмотрим классический пример с потокобезопасным счетчиком:

final class Counter {
  private let count = Mutex<Int>(0)
  
  var currentCount: Int {
    count.withLock { $0 }
  }
  
  func increment() {
    count.withLock { $0 += 1 }
  }
  
  func decrement() throws {
    try count.withLock {
      guard $0 > 0 else { throw Error.reachedZero }
      $0 -= 1
    }
  }
}

Ключевой метод withLock обеспечивает атомарный доступ к защищаемым данным, автоматически управляя блокировкой.


Интеграция с Swift Concurrency:

Особенность нового Mutex: безусловное соответствие протоколу Sendable, что позволяет безопасно использовать его в асинхронном коде. Это решает проблему работы с не Sendable типами в конкурентных контекстах:

final class PathStorage: Sendable {
  let path = Mutex<NSBezierPath>(NSBezierPath())
  
  func addPoint(_ point: CGPoint) {
    path.withLock { path in
      path.move(to: point)
    }
  }
}

Сравнение с акторами:

Возникает закономерный вопрос: зачем использовать Mutex, если существуют акторы? Ответ лежит в специфике задач:

🔵Акторы идеальны для логической изоляции состояния в асинхронных сценариях.
🔵Mutex эффективен когда требуется синхронный доступ без накладных расходов.
🔵Mutex незаменим при работе с legacy-кодом и API, не поддерживающими Swift Concurrency.


Важные преимущества:

Новый подход предлагает несколько значимых улучшений:

🔵Безопасность типов: Generic-параметризация обеспечивает строгую типизацию.
🔵Интеграция с ошибками: поддержка throwing-операций в блокировках.
🔵Производительность: минимальные накладные расходы по сравнению с традиционными решениями.
🔵Совместимость: беспроблемная работа в синхронных и асинхронных контекстах.


🔗 Ссылка на подробную статью


💡 Вывод:

Synchronization framework и Mutex представляют собой сбалансированное решение для управления многопоточностью в Swift. Они заполняют важный пробел между традиционными блокировками и современными акторами, предлагая инструмент, который одновременно мощный, типобезопасный и эффективный.


➡️ Подписаться на канал
Мобильный трудоголик

✨ Добро пожаловать в мир Swift от Дена!

Хочешь быть в курсе самых свежих новостей, полезных советов и уникального контента? Тогда наш канал — именно то, что тебе нужно!

Что ты найдёшь в нашем канале:

✅ Полезные статьи и новости из мира технологий и IT.
✅ Уникальные видеоуроки и гайды по программированию.
✅ Обсуждения актуальных тем с нашими подписчиками.
✅ Развлекательный контент, который поможет расслабиться и отдохнуть!

Присоединись к нашему дружному сообществу и будь на шаг впереди! Подписывайся на Swift от Дена и открывай новые горизонты вместе с нами!

Не упустите шанс стать частью нашей команды! ✨

👨‍💻 Мини-приложения в App Store: революция монетизации.

Всем привет! На сайте Apple Developer появился пост о новом API для приложений, которое предлагает расширенные возможности управления встроенными покупками. Речь идет о партнерской программе для мини-приложений в App Store - шаге, который открывает новые возможности для разработчиков крупных платформ.


Суть программы и основные требования:

Apple официально анонсировала программу для мини-приложений: встроенных компонентов, созданных на HTML5, JavaScript и других одобренных языках. Ключевое условие: эти мини-приложения не должны контролироваться разработчиком основного приложения, что предполагает создание открытых экосистем.

Для участия необходимо соответствие нескольким требованиям:

🔵Интеграция Advanced Commerce API для управления покупками.
🔵Использование Declared Age Rating API для возрастной классификации контента.
🔵Обязательное применение встроенных покупок Apple.
🔵Отправка Consumption Information через App Store Server API.


Преимущества для разработчиков:

Основной бенефит программы: сниженная до 15% комиссия за встроенные покупки в мини-приложениях. Это существенно ниже стандартных 30% и создает экономические стимулы для развития платформенных решений.

Программа открывает возможности для:

🔵Создания маркетплейсов мини-приложений.
🔵Развития игровых платформ с пользовательским контентом.
🔵Построения экосистем с сторонними разработчиками.
🔵Легализации существующих моделей с мини-играми и ботами.


Бизнес-перспективы:

Пример Tencent с WeChat демонстрирует потенциал таких экосистем. Программа Apple позволяет легализовать подобные модели в iOS-экосистеме, создавая новые монетизационные каналы. Это может стимулировать появление суперапов - приложений-платформ с множеством встроенных сервисов.


Технические аспекты реализации:

Разработчикам необходимо предусмотреть:

🔵Механизмы изоляции мини-приложений.
🔵Системы модерации контента.
🔵Инфраструктуру для распространения и обновления.
🔵Интеграцию с Apple's Commerce API.


🔗 Подробнее здесь


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Как сделать всю область View кликабельной в SwiftUI.

Сталкивались с ситуацией, когда в SwiftUI кнопка или любая другая View выглядит кликабельной, но не реагирует на нажатия? Это частая проблема, и решение проще, чем кажется.


В чем проблема:

SwiftUI по умолчанию определяет область нажатия только по видимому контенту. Если у вас:

🔵Прозрачные элементы.
🔵View с отступами.
🔵Кастомные фигуры без заливки.
🔵Текст без фона.

То интерактивная область может быть меньше, чем сама View.


Простое решение:

Добавьте модификатор .contentShape() чтобы явно задать область нажатия:

// Было: не работает
Rectangle()
  .stroke(Color.blue, lineWidth: 2)
  .frame(width: 100, height: 50)
  .onTapGesture {
    print("Тап!")
  }

// Стало: работает
Rectangle()
  .stroke(Color.blue, lineWidth: 2)
  .frame(width: 100, height: 50)
  .contentShape(Rectangle())
  .onTapGesture {
    print("Тап!")
  }

Как это работает:

Модификатор .contentShape() явно задает область, в которой должны распознаваться жесты, независимо от визуального представления. Модификатор принимает несколько вариантов значений:

.contentShape(Rectangle())  // Прямоугольная область
.contentShape(Circle())  // Круглая область
.contentShape(Capsule())  // Капсульная область

// Разные стили для разных случаев
.contentShape(Rectangle(), style: FillStyle())

Параметры FillStyle:

🔵eoFill: Bool - использование правила чет-нечет для сложных фигур.
🔵antialiased: Bool - сглаживание границ.


Пример:

VStack {
  Text("Первый элемент")
  Text("Второй элемент")
}
.contentShape(Rectangle())  // Общая кликабельная область для всего стека
.onTapGesture {
  print("Тап по любой части VStack")
}

Path { path in
  path.addRect(CGRect(x: 0, y: 0, width: 100, height: 100))
  path.addRect(CGRect(x: 25, y: 25, width: 50, height: 50))
}
.stroke(Color.blue, lineWidth: 2)
.contentShape(
  Rectangle(),
  style: FillStyle(eoFill: true)  // Только внешний прямоугольник кликабелен
)
.onTapGesture {
  print("Тап по внешней области")
}

💡 Вывод:

Модификатор contentShape() - это надежное решение проблем с интерактивностью в SwiftUI. Он позволяет точно контролировать, какая область View должна реагировать на жесты, что особенно важно при работе с кастомными фигурами и сложными layout.


➡️ Подписаться на канал
Мобильный трудоголик

💚 Дарим три подписки на полгода в приложении «Счетчик дней: вредные привычки» - помощника в борьбе с вредными привычками для поддержания здорового образа жизни!

Чтобы принять участие, нужно:
🔹Подписаться на канал.
🔹Нажать кнопку «Участвую!».

🔢 Эффективная работа с данными в Swift: Sequence и Collection.

Привет! Сегодня поговорим об архитектурных основах Swift, которые формируют фундамент работы с данными в наших приложениях. Речь пойдет о протоколах Sequence и Collection, тех строительных блоках, которые мы используем ежедневно, но чьи глубинные механизмы часто остаются за пределами нашего внимания.

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


Sequence:

Sequence представляет собой базовую концепцию последовательности элементов. Его философия проста: объект должен уметь предоставлять элементы один за другим, без обязательств по сохранению состояния или возможности повторного прохода.

Когда мы говорим о Sequence, мы имеем в виду контракт: «я могу дать вам итератор, который будет возвращать элементы до тех пор, пока они не закончатся». Именно эта простота делает Sequence идеальным для:

🔵Работы с потоками данных в реальном времени.
🔵Ленивых вычислений.
🔵Генераторов последовательностей.
🔵Обработки данных, которые доступны только для однократного чтения.


Collection:

Collection - это эволюция Sequence, добавляющая строгие гарантии и дополнительные возможности. Если Sequence - это поток, то Collection - это структурированное хранилище. Ключевые преимущества Collection включают:

🔵Гарантированную возможность многократной итерации.
🔵Стабильность порядка элементов (где это применимо).
🔵Эффективный доступ по индексам.
🔵Предсказуемую производительность операций.


Механика итерации:

То, что выглядит как простой синтаксический сахар:

for element in collection {
  // обработка элемента
}

На самом деле преобразуется в полноценный механизм итерации:

var iterator = collection.makeIterator()
while let element = iterator.next() {
  // обработка элемента
}

Такой подход обеспечивает несколько важных преимуществ:

🔵Безопасность: итератор работает с моментальным снимком состояния, защищая от изменений коллекции во время обхода.
🔵Гибкость: разные типы могут предоставлять специализированные итераторы.
🔵Производительность: компилятор может оптимизировать итерацию на основе знаний о конкретном типе.


Асинхронная революция: AsyncSequence

С приходом Swift Concurrency модель итерации получила развитие в виде AsyncSequence. Этот протокол расширяет знакомые концепции для работы с асинхронными потоками данных:

for try await event in eventStream {
  await processEvent(event)
}

AsyncSequence становится особенно важен в контексте:

🔵Сетевых операций.
🔵Обработки реального времени.
🔵Работы с внешними источниками данных.
🔵Реактивного программирования.


Рекомендации:

Когда выбирать Sequence:

🔵Данные генерируются на лету.
🔵Требуется ленивая загрузка.
🔵Работа с потоками в реальном времени.
🔵Необходим единоразовый доступ к данным.

Когда выбирать Collection:

🔵Необходим многократный доступ к данным.
🔵Важна стабильность порядка.
🔵Требуется эффективный доступ по индексу.
🔵Данные фиксированы или изменяются редко.


Производительность:

Глубокое понимание иерархии протоколов позволяет писать более эффективный код. Компилятор Swift использует знания о соответствии типов этим протоколам для применения агрессивных оптимизаций:

🔵Специализация generic-функций.
🔵Предварительное выделение памяти.
🔵Оптимизация доступа по индексу.
🔵Устранение избыточных проверок.


🔗 Ссылка на подробную статью


💡 Вывод:

Sequence и Collection - это фундаментальные подходы к работе с данными в Swift. Понимание их различий позволяет выбирать оптимальные решения для конкретных задач, предвидеть проблемы производительности и создавать эффективные кастомные реализации.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Владение данными в Swift: Как ~Copyable делает код безопаснее.

Всем привет! Сегодня поговорим о протоколе ~Copyable. Данный протокол позволяет запретить неявное копирование структур, что особенно полезно при работе с ресурсами вроде файлов или сетевых соединений.


Проблема, которую решает ~Copyable:

Представьте, что у вас есть структура для работы с файлом:

struct FileHandler: ~Copyable {
  private var fileDescriptor: Int32
  
  init(path: String) {
    fileDescriptor = open(path, O_RDWR)
  }
  
  consuming func close() {
    close(fileDescriptor)
  }
}

// Временный доступ для чтения
func readFromFile(_ handler: borrowing FileHandler) {
  let buffer = UnsafeMutableRawBufferPointer.allocate(byteCount: 1024, alignment: 1)
  defer { buffer.deallocate() }
  
  let bytesRead = read(handler.fileDescriptor, buffer.baseAddress, 1024)
  if bytesRead > 0 {
    print("Прочитано \(bytesRead) байт")
  }
}

// Передача владения
func takeOwnership(of handler: consuming FileHandler) {
  print("Закрываем файл с дескриптором \(handler.fileDescriptor)")
  handler.close()
}

// Изменение без передачи владения  
func modifyFile(_ handler: inout FileHandler) {
  let data = "Новые данные".data(using: .utf8)!
  _ = data.withUnsafeBytes { buffer in
    write(handler.fileDescriptor, buffer.baseAddress, buffer.count)
  }
  print("Данные записаны в файл")
}

let file = FileHandler(path: "data.txt")
readFromFile(file) // borrowing: file остается доступен
modifyFile(&file) // inout: изменяем, но владение не передается
takeOwnership(of: file) // consuming: передача владения, file больше не доступен
// file.close() // Ошибка компиляции! file уже недоступен

Без ~Copyable можно случайно создать копию структуры и получить две независимые переменные, работающие с одним файловым дескриптором. Это может привести к:

🔵Попытке двойного закрытия файла.
🔵Конфликтующим операциям чтения/записи.
🔵Трудноотлавливаемым багам.


Как это работает:

После добавления ~Copyable компилятор начинает следить за перемещением экземпляров структуры. Теперь нужно явно указывать:

🔵borrow: для временного доступа без передачи владения.
🔵consume: для полной передачи владения.
🔵inout: для временного изменения.


Когда это может быть полезно:

~Copyable особенно пригодится при:

🔵Работе с файлами, сокетами, внешними ресурсами.
🔵Использовании низкоуровневых API через указатели.
🔵Создании библиотек, где важно контролировать жизненный цикл объектов.
🔵Разработке высокопроизводительного кода.


🔗 Ссылка на подробную статью


💡 Вывод:

~Copyable - это не просто очередная фича языка, а важный шаг к более безопасному и предсказуемому коду. Хотя подход требует некоторого переосмысления работы со структурами, результат стоит того: многие потенциальные ошибки переносятся из времени выполнения в время компиляции, что экономит часы отладки.


➡️ Подписаться на канал
Мобильный трудоголик

🔢 Swift Profile Recorder: профилирование Swift-приложений выходит на новый уровень.

Apple продолжает радовать сообщество open-source инициативами, выпустив Swift Profile Recorder - мощный инструмент для профилирования производительности Swift-приложений. Давайте разберемся, что это за инструмент и как он может упростить жизнь разработчикам.


Что такое Swift Profile Recorder:

Это профилировщик, который работает прямо внутри вашего приложения. Ему не нужны дополнительные системные компоненты или специальные права доступа. Если говорить проще: теперь вы можете добавить профилирование в свои Swift-проекты, просто подключив библиотеку как зависимость.


Преимущества:

🔵Работает в ограниченных средах: не требует root-прав или специальных разрешений.
🔵Кроссплатформенность: поддерживает macOS и Linux.
🔵Простая интеграция: достаточно добавить пакет как зависимость.
🔵Стандартные форматы: поддерживает perf, pprof, flame graphs.
🔵HTTP-интерфейс: сбор данных через простые curl-запросы.


Практическое применение:

Добавление в проект занимает минимум усилий:

// Package.swift
dependencies: [
  .package(url: "https://github.com/apple/swift-profile-recorder.git", from: "0.3.0")
]

// В коде приложения
import ProfileRecorderServer

@main
struct MyApp {
  func run() async throws {
    async let _ = ProfileRecorderServer(
      configuration: .parseFromEnvironment()
    ).runIgnoringFailures(logger: logger)
    
    // Основной код приложения
  }
}

Сбор профиля через curl:

curl --unix-socket /tmp/app-samples-12345.sock \
   -sd '{"numberOfSamples":1000,"timeInterval":"10ms"}' \
   http://localhost/sample > profile.perf

Визуализация результатов:

Собранные данные можно анализировать в популярных инструментах:

🔵Speedscope - интерактивные flame graphs.
🔵Firefox Profiler - детальный анализ временных линий.
🔵FlameGraph - классические флеймграфы.
🔵Любые инструменты, поддерживающие форматы .perf или .pprof


Отличие от других решений:

В отличие от swift-parca, который использует eBPF и требует специальных привилегий, Swift Profile Recorder работает на уровне приложения. Это делает его идеальным для:

🔵Контейнеризированных сред (Kubernetes, Docker).
🔵Облачных окружений с ограниченными правами.
🔵Быстрого прототипирования и отладки.


🔗 Ссылка на подробную статью


💡 Вывод:

Swift Profile Recorder - это серьезный шаг в развитии инструментов для Swift-разработки. Он демократизирует доступ к продвинутому профилированию, делая его доступным для проектов любого масштаба.

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


➡️ Подписаться на канал
Мобильный трудоголик

🔢 SQLiteData: элегантная альтернатива SwiftData для работы с базой данных.

Всем привет! Сегодня поговорим про библиотеку для работы с данными - SQLiteData, которая сочетает проверенную надежность SQLite с современным Swift-подходом. В основе библиотеки лежит идея предоставить разработчикам привычные инструменты, подобные тем, что есть в SwiftData, но с более предсказуемым поведением.


Модели данных:

Модели данных описываются с помощью структур и перечислений, что делает код интуитивно понятным и соответствующим духу Swift. Это обеспечивает:

🔵Естественную работу с типами данных.
🔵Безопасность на этапе компиляции.
🔵Простоту в сопровождении и расширении.


Работа с запросами:

Для выборки данных предлагаются типобезопасные запросы, которые интегрируются в интерфейс через property wrappers. Важно, что эти обертки работают не только в SwiftUI, но и в любых @Observable моделях, а также в контроллерах UIKit, что обеспечивает универсальность подхода.


Интеграция с CloudKit:

Библиотека включает прямой доступ к возможностям CloudKit, обеспечивая:

🔵Синхронизацию данных между устройствами.
🔵Функцию совместного использования с другими пользователями.

Это избавляет от необходимости самостоятельной интеграции сторонних решений.


Технологическая основа:

В качестве основы используется SQLite через драйвер GRDB, что гарантирует высокую производительность и отказоустойчивость. Такой выбор технологии означает полный контроль над схемой данных и процессами миграции.


Пример:

// Модель
@Table
struct Task: Identifiable {
  let id: UUID
  var title: String
  var isCompleted: Bool
}

struct TasksView: View {
  // Запрос
  @FetchAll(Task.where { !$0.isCompleted }) 
  var pendingTasks
  
  var body: some View {
    List(pendingTasks) { task in
      Text(task.title)
    }
  }
}

🔗 Подробнее по ссылке


💡 Вывод:

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


➡️ Подписаться на канал
Мобильный трудоголик

Привет! Хочу порекомендовать канал практикующего staff инженера из Т-Банка.

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

➡️ Подписывайтесь на @ios_broadcast

🔢 SwiftUI Canvas: революция при работе с графикой в iOS.

В SwiftUI есть мощнейший инструмент для работы с графикой - Canvas API. Этот инструмент кардинально меняет подход к созданию сложных визуальных эффектов и кастомной графики в приложениях.


Проблемы до Canvas:

До появления Canvas разработчики сталкивались с серьезными ограничениями:

🔵Path и Shape: слишком примитивны для сложной графики.
🔵UIKit и Core Graphics: требовали императивного подхода.
🔵Metal: избыточно сложен для большинства задач.
🔵Производительность: кастомные решения часто работали с просадками FPS.

Фактически, для любой нетривиальной графики приходилось покидать комфортную декларативную среду SwiftUI.


Что такое Canvas API:

Canvas - это View в SwiftUI, предоставляющая прямой доступ к низкоуровневому рендерингу:

Canvas { context, size in
  // Рисуем эллипс
  context.fill(
    Path(ellipseIn: CGRect(origin: .zero, size: size)),
    with: .color(.blue)
  )
  
  // Добавляем текст
  context.draw(Text("Hello Canvas"), at: CGPoint(x: size.width/2, y: size.height/2))
}

Ключевые возможности:

🔹 GraphicsContext: сердце Canvas, предоставляет:

🔵Рисование примитивов (линии, фигуры, текст).
🔵Работу с трансформациями и наложениями.
🔵Поддержку градиентов и теней.
🔵Высокопроизводительный рендеринг через Metal.

🔹 Производительность: Canvas работает напрямую с GPU, обеспечивая 60 FPS даже при сложных вычислениях.

🔹 Интеграция с SwiftUI: полная совместимость с анимациями, жестами и системой layout.


Ограничения:

🔵Только с iOS 15+
🔵Требует понимания основ компьютерной графики.
🔵Для сверхсложной 3D-графики все еще нужен Metal.
🔵Отладка может быть сложнее стандартных View.


🔗 Ссылка на подробную статью


💡 Вывод:

Canvas API - это не просто рядовая фича в SwiftUI, а фундаментальное расширение возможностей фреймворка. Разработчики могут создавать сложную графику и визуальные эффекты, не покидая декларативной парадигмы.

Для проектов, где важна визуальная составляющая: анимированные onboarding-экраны, кастомные графики, интерактивные элементы - Canvas становится обязательным инструментом в арсенале разработчика.


➡️ Подписаться на канал
Мобильный трудоголик