Мобильный трудоголик

🈸 Как изменится продвижение приложений в App Store с выходом iOS 27.

На WWDC26 компания Apple показала несколько обновлений, которые касаются не только разработчиков, но и тех, кто занимается продвижением приложений. Изменения в App Store и App Store Connect затронули визуальное оформление карточек, управление креативами и персонализацию рекомендаций.


Header вместо Feature Banner:

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

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

Хэдер можно использовать в нескольких местах: на главной странице приложения, в поисковой выдаче, на странице с товарами приложения и в рекламных объявлениях Apple Ads. Причем это один и тот же ассет, который загружается один раз и применяется в разных местах.

Те приложения, которые не внедрят качественные хэдер, рискуют потерять клики и установки на фоне конкурентов. Визуал в выдаче становится еще одним фактором конкуренции.


Библиотека ассетов:

Самое практичное изменение - появление Asset Library в App Store Connect. Теперь все медиа (скриншоты, проморолики, хэдер) хранятся в одном месте и организованы по платформам и размерам.

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

Загруженные ассеты можно переиспользовать в разделе с товарами приложения, In-App Events и рекламных кампаниях. Все из одной библиотеки, без дублирования загрузок.


Персонализированные рекомендации:

Apple анонсировала новый тип подборок - персонализированные коллекции. Они формируются не модераторами, а алгоритмами на основе поведения пользователя. App Store анализирует, какие приложения пользователь устанавливает и как использует, и на основе этого адаптирует рекомендации.

Коллекции будут появляться на вкладках «Приложения», «Игры» и в поиске. К каждому приложению будет выводиться объяснение, почему оно релевантно конкретному пользователю.

Для маркетологов это означает, что органический трафик станет качественнее, но менее предсказуемым. Алгоритмы - это черный ящик. Чтобы попадать в рекомендации, придется работать в тесной связке с разработчиками. App Intents теперь важны не только для Siri, но и для того, чтобы алгоритмы Apple Intelligence правильно считывали семантику приложения и понимали, кому его рекомендовать.


🔗 Читать подробнее


💡 Вывод:

WWDC26 принесла несколько полезных обновлений для тех, кто продвигает приложения в App Store. Хэдер добавляет новый визуальный слой в карточку приложения и поисковую выдачу. Библиотека ассетов убирает зависимость маркетинга от разработчиков при работе с визуалом. Персонализированные рекомендации открывают новые возможности для органического трафика, но требуют более тесной работы с семантикой приложения.

Самое важное изменение - маркетинг теперь может обновлять креативы независимо от релизов. Это серьезно упрощает работу с визуалом и ускоряет эксперименты. Если вы занимаетесь продвижением приложений, стоит изучить новые возможности до осеннего релиза iOS 27.


Подписаться на канал:
➡️ Telegram | Max

👣 GenUI в действии: команда Flutter раздала 3000 чашек кофе с ИИ-рисунками на пенке

Команда Flutter решила поделиться опытом создания необычного демо-проекта, который они показали посетителям Google Cloud Next и Google I/O. В статье разработчики рассказывают, как построили приложение для кофейни, где каждый посетитель мог заказать латте с изображением, сгенерированным нейросетью прямо на пенке. Проект назывался GenLatte. За два мероприятия команда раздала 3000 чашек.


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

На первый взгляд все просто. Посетитель подходил к киоску, открывал веб-версию Flutter-приложения и описывал свое место мечты. Это могло быть что угодно: домик у озера, снежный лес, закат на пляже. Промпт ограничивался 50 символами, чаще всего это было одно-два слова.

Дальше в дело вступала нейросеть Nano Banana. Система брала короткую фразу и разворачивала ее в полноценный промпт для генерации изображения. При этом создавалось сразу четыре варианта картинки, все разные по композиции и настроению. Пользователь выбирал понравившийся и изображение отправлялось на печать на пенке латте.


Персонализация через GenUI:

Самое интересное происходило после того, как пользователь видел сгенерированные изображения. Под каждой картинкой была кнопка Tweak - это была не просто доработка фильтра, а полноценная генеративная настройка через UI.

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

Это и есть GenUI в действии - интерфейс, который собирается на лету под конкретную задачу.

После того как пользователь отвечал на вопросы, система отправляла обновленный промпт обратно в Nano Banana и генерировалась новая версия изображения. Все это происходило в реальном времени.


Техническая архитектура:

Проект построен на Flutter и Firebase. Вся логика собрана в монорепозитории, где объединены Flutter-приложение, Firebase-бэкенд и общий код для бизнес-логики. Такой подход позволил избавиться от дублирования зависимостей, переиспользовать код и выполнять атомарные деплои.

Внутри самого Flutter-приложения было реализовано пять отдельных экранов:

🔵Экран заказа для посетителей.

🔵Экран бариста с актуальными заказами.

🔵Экран модератора для проверки безопасности контента.

🔵Экран очереди для ожидающих.

🔵Экран с недавними заказами в виде плавающих пузырьков.


🔗 Читать подробнее


💡 Вывод:

GenLatte - это не просто забавный демо-проект. Это показательный пример того, как Flutter, Firebase и генеративный ИИ работают вместе в реальных условиях. 3000 чашек кофе - это не шутка. Проект показал, что с помощью Flutter можно быстро собирать сложные мультиплатформенные приложения, а Firebase закрывает все вопросы с бэкендом и масштабированием. И главное - GenUI перестает быть абстрактной концепцией. Приложение само решало, какой интерфейс показать пользователю в ответ на его действия.

Конечно, код проекта доступен в репозитории flutter/demos, но авторы предупреждают: он не поддерживается и предназначен только для вдохновения. А вдохновения там действительно много. Когда в ближайшее время задумаетесь о том, как можно применить генеративный ИИ в своем проекте - вспомните историю о латте с нейросетевым рисунком. Это хорошая иллюстрация того, насколько широко могут разойтись технологии, которые вчера казались просто игрушками.


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

🍎 Apple купила Play: Create Better Apps - приложение, которое помогало создавать прототипы интерфейсов приложений на SwiftUI.

Apple продолжает приобретать инструменты для разработчиков. Вслед за Swift Package Index компания купила Rabbit 3 Times - создателей приложения Play. Это визуальный конструктор для iOS и macOS, который позволял быстро создавать прототипы на SwiftUI.


Что такое Play:

Play - это бесплатный инструмент, в котором разработчики и дизайнеры могли собирать интерфейсы с помощью SwiftUI-фреймворков и сразу видеть, как они будут выглядеть на устройстве. Готовые проекты можно было экспортировать в Xcode через платный сервис Play to Xcode.

В июне 2025 года Play получил Apple Design Award в номинации «Инновации». Apple тогда написала: «Play - это продуманный и доступный инструмент, который позволяет создавать интерактивные прототипы с использованием SwiftUI-фреймворков».


Что известно о сделке:

Apple сообщила о сделке в Европейскую комиссию в феврале 2026 года. В документах указано, что Apple приобретает активы компании Rabbit 3 Times и получает право нанять часть сотрудников. Это типичная схема acquihire - покупка не столько продукта, сколько команды.

Условия сделки не раскрываются. Но уже в апреле 2026 года компания Rabbit 3 Times объявила о прекращении поддержки Play для iPhone и Mac. Приложения исчезли из App Store. Платный сервис Play to Xcode стал бесплатным для облегчения перехода. На сайте компании осталось только сообщение: «Мы работаем над чем-то новым».


Зачем это Apple:

Вариантов несколько:

🔹Первый: Apple купила Play ради сотрудников. Команда Rabbit 3 Times - опытные разработчики, которые уже доказали, что умеют создавать сложные инструменты на SwiftUI. Такие люди всегда нужны.

🔹Второй: Apple хочет использовать наработки Play для улучшения Xcode. Визуальный конструктор, который генерирует SwiftUI-код, может лечь в основу нового инструмента внутри Xcode.

🔹Третий: Play может стать основой для визуального Xcode - альтернативы Swift Playground, но для взрослых разработчиков. Сейчас в экосистеме Apple есть пропасть между Playground (для обучения) и полноценным Xcode. Play как раз закрывал этот промежуток.


🔗 Читать подробнее


💡 Вывод:

Apple продолжает собирать инструменты для разработчиков. Play - вторая крупная покупка за последнее время. Как и в случае с Swift Package Index, компания забирает то, что уже работает в сообществе.

Play был удобным инструментом для быстрого прототипирования на SwiftUI. Теперь его больше нет в открытом доступе. Остается надеяться, что наработки не пропадут, а появятся в Xcode в том или ином виде.


Подписаться на канал:
➡️ Telegram | Max

🔢 Что нового в Swift 6.4. Разбираем изменения с WWDC26.

На WWDC26 компания Apple представила Swift 6.4 - очередное обновление языка, которое делает повседневный код чище и выразительнее. В этом материале - самое важное из того, что появилось в новой версии.


anyAppleOS - теперь доступность проще:

Раньше, чтобы указать, что API доступен на всех платформах Apple, приходилось перечислять каждую ОС отдельно. В Swift 6.4 это можно сделать одной строкой.

// Было
@available(macOS 27, iOS 27, watchOS 27, tvOS 27, visionOS 27, *)
func showStatus() { ... }

// Стало
@available(anyAppleOS 27, *)
func showStatus() { ... }

Если для одной платформы нужно другое поведение, можно комбинировать anyAppleOS с переопределением. Тот же токен работает внутри #if os(anyAppleOS).


@diagnose - точное управление предупреждениями:

Новый атрибут @diagnose позволяет управлять предупреждениями на уровне отдельных объявлений. Можно подавить предупреждение, превратить его в ошибку или оставить как есть.

@diagnose(DeprecatedDeclaration, as: ignored, reason: "Миграция постепенно")
func makeApolloMission() -> Mission {
    CrewedMission(rocket: makeSaturnIRocket(), ...)
}

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


Что нового в работе с Sendable:

В Swift 6.4 исправили несколько мелких неудобств.

weak var раньше требовал @unchecked Sendable. Теперь можно писать weak let и это проходит обычную проверку Sendable.

final class Spacecraft: Sendable {
    weak let dockedAt: SpaceStation?
}

Если класс должен явно отказаться от Sendable, теперь это можно указать через ~Sendable.

class Mission: ~Sendable { ... }

Async внутри defer:

Раньше вызвать асинхронную функцию из блока defer было нельзя - приходилось писать обходные решения. В Swift 6.4 это ограничение убрали.

defer {
    await logger.flush()
}

Защита от отмены задачи:

withTaskCancellationShield создает участок кода, где Task.isCancelled всегда возвращает false. Это нужно для операций, которые должны завершиться даже после отмены задачи - например, сброс буфера файла, чтобы избежать повреждения данных.

extension EmergencyTransponder {
    func sendSOS() {
        withTaskCancellationShield {
            radio.send(makeSOSPacket())
        }
    }
}

mapKeyedValues для словарей:

Существующий mapValues передает в замыкание только значение. Новый mapKeyedValues дает и ключ и значение.

let displayNames = missions.mapKeyedValues { mission, window in
    makeDisplayName(for: mission, in: window)
}

FilePath в стандартной библиотеке:

Тип FilePath переехал из Swift System в стандартную библиотеку. Он корректно обрабатывает различия в представлении путей между платформами и парсит компоненты единообразно.

var path: FilePath = "/Users/khoa/Documents"
path.components.append("Projects")
path.components.append("app")
print(path.components)
// [ "Users", "khoa", "Documents", "Projects", "app" ]

🔗 Читать подробнее


💡 Вывод:

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

Из новинок стоит обратить внимание на anyAppleOS, @diagnose, улучшения при работе с Sendable и новые типы для работы с памятью.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔢 Инструменты отладки в Swift, которые часто используют сеньоры.

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


assert - ловим логические ошибки на этапе разработки:

assert проверяет условие и, если оно ложно, останавливает выполнение программы. Работает только в дебаг-сборке - в релизе эти проверки просто вырезаются.

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

func calculateSquare(x: Double) -> Double {
    assert(x != 0, "Число не может быть нулем")
    return x * x
}

Если кто-то случайно вызовет calculateSquare(x: 0), приложение упадет с сообщением об ошибке. И вы сразу увидите проблему, а не будете полдня выяснять, почему результат не сошелся.

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


file, function, line - добавляем контекст в логи:

Обычный print выводит просто сообщение. Чтобы понять, откуда оно пришло, приходится лезть в код. Есть способ лучше - использовать литералы #file, #function и #line. Они подставляют имя файла, функции и номер строки прямо во время компиляции.

Оборачиваем print в удобную функцию:

func log(_ message: String,
         file: String = #file,
         function: String = #function,
         line: Int = #line) {
    print("[\(file):\(line)] \(function) - \(message)")
}

Теперь вместо print("Ошибка") пишем log("Ошибка"), и получаем в консоли что-то вроде:

[ViewController.swift:42] updateUser() - Ошибка

Никакого копирования имен функций и номеров строк руками. Все само подставляется.


CustomDebugStringConvertible - настраиваем вывод своих типов:

Когда вы пишете print(user), Swift выводит стандартное представление: User(name: “Artem”, age: 33, role: "Admin"). Для маленьких структур ок, но когда полей много - в консоли каша.

Протокол CustomDebugStringConvertible позволяет переопределить этот вывод:

extension User: CustomDebugStringConvertible {
    var debugDescription: String {
        "👤 \(name), роль: \(role)"
    }
}

Теперь print(user) покажет: "👤 Artem, роль: Admin". Коротко и понятно. Часто используемые типы данных можно снабдить такими расширениями - и отладка станет намного приятнее.


🔗 Читать подробнее


💡 Вывод:

Сеньоры используют эти пять инструментов не потому, что они умнее, а потому что так быстрее. assert, литералы #file, #function и #line, протокол CustomDebugStringConvertible, тип Mirror и функция dump встроены в стандартную библиотеку Swift и доступны без подключения дополнительных зависимостей. Перестаньте терять часы на однообразный print и просто начните применять то, что уже есть под рукой. Отладка станет чище, а логи - понятнее.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👨‍💻 Эпоха дешевых токенов заканчивается. Что делать обычным пользователям?

Компании Anthropic и Microsoft ужесточают условия для бизнес-клиентов: фиксированные подписки уходят в прошлое, компаниям придется платить за реально потребленные токены. Индивидуальных пользователей пока не трогают, но тренд очевиден: дешевые токены заканчиваются. И тот, кто сейчас не пользуется возможностью учиться на топовых моделях за копейки, рискует оказаться в сильном отставании.


Как меняется рынок:

Раньше компании массово покупали подписки Claude за 200 долларов на каждого сотрудника и радовались. Теперь Anthropic переводит корпоративных клиентов на оплату по факту. Microsoft сделала то же самое. В отчетах стартапов Кремниевой долины видны траты в сотни тысяч долларов в месяц на ИИ-подписки. При этом Дарио Амадей из Anthropic признал: пользователи Max-подписки тратят токенов на 5000 долларов, платя при этом всего 200.


Почему это важно для новичков:

Пока есть возможность пользоваться топовыми моделями за 20-200 долларов - ее нужно использовать. Тренировать навыки, нарабатывать опыт, учиться правильно формулировать запросы. Потому что когда цены вырастут, учиться будет поздно - разрыв между теми, кто уже умеет эффективно работать с ИИ, и теми, кто только начинает, станет критическим.


🔗 Читать подробнее


💡 Вывод:

Если вы сейчас пользуетесь бесплатными или дешевыми версиями ИИ - вы делаете ошибку. Сейчас уникальный момент, когда можно получить доступ к топовым технологиям за копейки. Упустите его - будете догонять тех, кто успел. И догонять будет сложно, потому что разрыв в навыках нарастает экспоненциально. Платите пока можно и тренируйтесь, пока есть время.


Подписаться на канал:
➡️ Кот Денисова

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔢 SwiftUI теперь умеет скрывать навигационную панель при скролле.

Раньше, чтобы скрыть или показать навигационную панель при скролле, нужно было отслеживать позицию прокрутки вручную. Слушать изменения scroll offset, вычислять направление, анимировать изменение состояния навбара. Это работало, но требовало лишнего кода и было не всегда предсказуемо.

В iOS 27 появился новый модификатор, который делает все это стандартными средствами, без костылей.


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

Модификатор toolbarMinimizeBehavior позволяет указать, как должна вести себя панель инструментов при прокрутке содержимого.

ScrollView {
    ContentView()
}
.toolbarMinimizeBehavior(.onScrollDown, for: .navigationBar)

Когда пользователь скроллит вниз, навигационная панель минимизируется, освобождая больше места для контента. Все, что нужно было сделать разработчику - добавить одну строчку кода. Без UIScrollViewDelegate, без GeometryReader, без onPreferenceChange.


Когда это может пригодиться:

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


Что важно знать:

При минимизации навбара безопасная область (safe area) автоматически корректируется. Контент не перекрывается, отступы сохраняются. Это поведение работает по умолчанию и в большинстве случаев его достаточно.

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


🔗 Читать подробнее


💡 Вывод:

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

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


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🍎 iOS 27: iPhone больше не нужно подключать к компьютеру для восстановления.

Apple добавила в iOS и iPadOS 27 режим восстановления, который работает прямо на устройстве. Раньше при серьезных сбоях или неудачном обновлении нужно было подключать iPhone к компьютеру, переводить в специальный режим и восстанавливать прошивку через Mac или ПК. Теперь часть проблем можно решить прямо на устройстве, без помощи компьютера.


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

Все достаточно просто. Выключаете устройство. Затем удерживаете боковую кнопку. После появления логотипа Apple продолжаете держать кнопку. Система показывает индикатор загрузки и переходит в меню дополнительных инструментов.


Что доступно в меню:

В режиме восстановления доступны несколько опций:

🔹Помощник восстановления.

🔹Утилита для обновления системы.

🔹Режим диагностики.

🔹Форматирование и сброс до заводских настроек.

🔹Восстановление с помощью компьютера.

Также отображается заряд аккумулятора и статус подключения к известным Wi-Fi сетям.


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

Раньше при серьезных проблемах iPhone превращался в кирпич и нужно было искать кабель, компьютер и использовать iTunes или Finder. Теперь достаточно запустить новый режим восстановления на iPhone и выбрать нужный инструментами.

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

Режим диагностики - отдельный плюс. Можно проверить устройство на аппаратные проблемы без посторонних приложений. Это экономит время и нервы.

Wi-Fi в режиме восстановления - умное решение. Устройство может скачать свежую прошивку прямо из меню восстановления. Не нужно качать IPSW на компьютер и заливать через кабель.


🔗 Читать подробнее


💡 Вывод:

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

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

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


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🍏 Apple Container: нативный инструмент для запуска контейнеров на macOS.

Apple выпустила Container 1.0 - собственный инструмент для работы с Linux-контейнерами на macOS. Это не просто очередной фреймворк. Это попытка Apple изменить подход к изоляции, управлению средами и рабочим процессам разработчиков. Давайте разберем, что это такое и почему важно.


Что такое Apple Container:

Apple Container - это CLI-инструмент для создания и запуска Linux-контейнеров в виде легких виртуальных машин на Mac. Он написан на Swift и оптимизирован для Apple Silicon.

В отличие от Docker, где все контейнеры работают внутри одной общей Linux-виртуальной машины, Apple Container запускает для каждого контейнера отдельную легкую виртуальную машину. Это дает аппаратный уровень изоляции для каждого контейнера и обеспечивает более высокую безопасность.

Основные характеристики:

🔹Нативная работа на Apple Silicon: никаких затрат на Rosetta.

🔹Легкость: запуск контейнеров происходит за доли секунды.

🔹Полная совместимость с OCI-образами: можно использовать стандартные образы из любых реестров.

🔹Интеграция с macOS: доступ к домашней папке через монтирование.


Container Machine - новая концепция:

В версии 1.0 появилась концепция Container Machine - контейнеров с сохранением состояния. Это позволяет останавливать и перезапускать контейнеры, сохраняя файловую систему внутри . По сути, они работают как обычные виртуальные машины, но с легкостью и скоростью контейнеров.

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


Почему это важно для iOS-разработчиков:

Казалось бы, iOS-разработчикам не нужны контейнеры. Но современная разработка все чаще требует локальных бэкендов - базы данных, сервисов аутентификации, API для тестирования . С Apple Container можно поднять все эти зависимости локально, не засоряя систему и не беспокоясь о совместимости версий.


Что можно делать с Apple Container уже сейчас:

🔹Поднимать локальные базы данных и сервисы для разработки.

🔹Изолировать тестовые среды для проверки приложений.

🔹Создавать воспроизводимые окружения для CI/CD.

🔹Запускать Swift-приложения на сервере в контейнерах.

🔹Тестировать код в среде, близкой к проду.

Все это без необходимости использования Docker и оплаты лицензии.


🔗 Читать подробнее


💡 Вывод:

Apple Container - это не просто клон Docker. Это попытка Apple переосмыслить контейнеризацию на macOS, сделав ее нативной и безопасной. Контейнеры запускаются в отдельных виртуальных машинах, что дает лучшую изоляцию. Они написаны на Swift и интегрируются с системой. Технология еще на раннем этапе, но у нее большой потенциал.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👨‍💻 Конвейер подготовки джунов сломан. И чинить его никто не собирается.

Средний срок работы разработчика в крупной ИТ-компании - 2–3 года. Чтобы вырастить из джуна самостоятельного мидла, нужно 2–4 года. От мидла до сеньора - еще 3–5 лет. Итого: чтобы получить сеньора из новичка, требуется 5–9 лет. Это просто арифметика.

Если индустрия сокращает найм джунов три года подряд (2024, 2025, 2026), эффект проявится не сразу. Он ударит в 2029–2033 годах, когда иссякнет поток мидлов, и в 2032–2036 годах, когда иссякнут сеньоры. Компании, которые сейчас экономят на джунах, будут биться за оставшихся опытных инженеров и жаловаться на дефицит талантов. Но винить будут кого угодно, только не себя.


Почему это происходит:

Логика проста и на первый взгляд убедительна. Джуниор стоит компании 90-120 тысяч в месяц и требует 3-6 месяцев менторства, прежде чем начнет приносить реальную пользу. GitHub Copilot - 10 долларов в месяц. Claude Code и Cursor - 20 долларов. Сеньор с ИИ делает всю ту работу, ради которой раньше держали штат новичков. Марк Бениофф объявил, что компания Salesforce не будет нанимать новых инженеров, сославшись на ИИ. Сундар Пичаи из Google заявил, что ИИ позволяет делать больше тем же составом. Многие компании отказываются от джунов в пользу ИИ.


Но проблема глубже:

Джуны - это не просто расходы. Они тестируют документацию. Если новичок не может поднять окружение по README, значит, онбординг сломан. ИИ такого сигнала не даст. Джуны задают неудобные вопросы, которые вскрывают скрытые допущения. «Почему мы вообще делаем это так?» - это вопрос, который чаще всего задают те, кто еще не привык к костылям кодовой базы. И самое главное, джуны - это конвейер будущих сеньоров. Сокращение найма сегодня - это пустота на старших позициях через 5–9 лет.


А что с ИИ?

Компании заявляют о 25-процентном росте производительности от ИИ. Реальные измерения показывают около 2% на каждые 25% внедрения. Разрыв между ожиданиями и реальностью - примерно 12-кратный. ИИ пишет шаблонный код на 55% быстрее. Но шаблонный код никогда не был узким местом.


Спираль выгорания сеньоров:

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


🔗 Читать подробнее


💡 Вывод:

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


➡️ Кот Денисова

🔢 Новые возможности UIKit в iOS 27.

На WWDC26 компания Apple показала обновления и для UIKit. Не радикальные, не революционные, но заметные. И главное - они подтверждают: UIKit никуда не уходит. SwiftUI будет на первых ролях, это очевидно. Но UIKit остается надежным фундаментом и Apple продолжает его развивать.

В этом году изменений не так много и почти ничего из добавленного не выглядит эффектно. Но в каком-то смысле это справедливо и для iOS 27 в целом. Основной фокус - Siri и ИИ. А UIKit получил точечные улучшения, которые делают его более гибким и адаптивным.


Навигация и кнопки:

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

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

Пример использования:

navigationItem.barMinimizeBehavior = .onScrollDown
navigationItem.barMinimizationSafeAreaAdjustment = .enabled

Также появилась возможность ранжировать кнопки в панели. UIKit теперь знает, какие действия важнее сохранять на экране, когда места становится мало. Адаптивные интерфейсы - iPad, Stage Manager, изменяемые окна - везде, где ширина панели постоянно меняется, это становится критичным.

Пример использования:

saveItem.visibilityPriority = .high
shareItem.visibilityPriority = .standard

Еще одно небольшое, но полезное изменение - возможность убрать стандартный отступ у кнопки на панели инструментов:

colorItem.isPaddingRemoved = true

Сцены, окна и ориентация:

Apple продолжает двигаться в сторону многооконных приложений с изменяемыми размерами. И здесь тоже есть подсказки: все это особенно актуально для грядущих складных устройств.

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

Пример использования:

windowScene.closureConfirmation = UISceneClosureConfirmation(
    title: “Несохраненные данные",
    message: "Закрыть несохраненные данные?",
    actions: [...]
)

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

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

Пример использования:

func supportedInterfaceOrientations(
    for windowScene: UIWindowScene
) -> UIInterfaceOrientationMask {
    .landscape
}

Таббары и сайдбары:

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

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

Пример использования:

tabBarController.prominentTabIdentifier = "compose"

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

Пример использования:

tabBarController.mode = .tabSidebar
tabBarController.sidebar.preferredPlacement = .sidebar

🔗 Читать подробнее


💡 Вывод:

Еще несколько лет назад можно было задаваться вопросом, не собирается ли Apple отказаться от поддержки UIKit. Сейчас это выглядит маловероятным. SwiftUI становится лучше каждый год и будет на первом место, но UIKit остается надежным фреймворком и продолжает быть важной частью экосистемы.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🐥 Swift Package Index теперь часть Apple.

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


Что такое Swift Package Index:

Это поисковая система и индексатор метаданных для Swift-пакетов с открытым исходным кодом. Разработчики используют Swift Package Index, чтобы находить пакеты, проверять их совместимость с платформами и версиями Swift, смотреть документацию, оценивать активность авторов и состояние пакета в целом.

Одна из главных фишек сервиса - автоматическое тестирование каждого пакета на поддерживаемых платформах и версиях Swift. Это дает уверенность перед тем, как добавить зависимость в проект. Сейчас в индексе уже больше 10 тысяч пакетов. Только за прошлый год было обработано более 3,5 миллиона билдов на совместимость.


Что изменится для разработчиков прямо сейчас:

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

Так что если вы пользуетесь Swift Package Index сегодня - завтра все будет работать точно так же.


Что изменится в будущем:

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

Это может означать, что Swift Package Index постепенно превратится из удобного поисковика в более официальный слой доверия вокруг Swift-зависимостей. Возможен сценарий, когда Xcode позволит искать и добавлять пакеты прямо из IDE, без необходимости вручную вставлять URL репозитория. Управление зависимостями станет проще и удобнее.


🔗 Читать подробнее


💡 Вывод:

Присоединение Swift Package Index к Apple - это хорошая новость для Swift-сообщества. Сервис получит больше ресурсов для развития, оставаясь при этом открытым проектом. А главное - Apple прямо говорит о планах улучшить безопасность и надежность экосистемы пакетов.

Для разработчиков это значит, что в будущем управление зависимостями станет проще, а доверие к пакетам - выше. Пока все остается как есть. Но следующие месяцы должны показать, каким будет новый Swift Package Index под крылом у Apple.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔨 Apple окончательно отказалась от Intel в Xcode 27.

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


Почему Apple отказалась от Intel:

Переход на собственные процессоры Apple начался еще в 2020 году и с тех пор компания последовательно двигалась к полному отказу от Intel. Причин несколько. Процессоры Apple Silicon обеспечивают значительно лучшую производительность на ватт - они быстрее и при этом потребляют меньше энергии. Это особенно заметно при работе с тяжелыми задачами вроде компиляции крупных проектов.

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

Когда я впервые перешел с MacBook с процессором Intel на MacBook с M1, я был в полном восторге. Ноутбук работал бесшумно, совершенно не грел колени, не включал вентиляторы при работе и работал без подзарядки значительно дольше. При этом он справлялся с компиляцией проектов в разы быстрее. Разница была заметна с первых минут и стало очевидно, что процессоры Apple - это не просто переход от стороннего производителя чипов к собственному производству, а совершенно иной подход к тому, как должен работать современный ноутбук.


Что изменилось в Xcode 27:

Помимо изменения системных требований, Xcode 27 получил несколько заметных улучшений. Проекты теперь открываются быстрее - это результат оптимизаций под Apple Silicon и изменений во внутренней архитектуре IDE.

Настройки синхронизируются через iCloud, что удобно для тех, кто работает на нескольких устройствах. Можно не тратить время на перенос конфигураций между машинами.

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

Появилась поддержка тем, которые меняют оформление не только редактора кода, но и всего приложения. Это мелочь, но визуально приятная.

Самое заметное изменение - Device Hub, который заменил привычный Simulator. Теперь симуляторы и физические устройства собраны в одном окне. Управление стало удобнее, а переключение между устройствами быстрее.


🔗 Читать подробнее


💡 Вывод:

Apple окончательно завершила переход на собственную архитектуру в инструментах разработки. Xcode 27 - еще один шаг в этом направлении. Для разработчиков это означает более быструю работу, лучшее энергопотребление и доступ к новым возможностям IDE. Но и обязательство обновить железо тем, кто все еще использует технику на Intel.

Переход на Apple Silicon оказался не просто маркетинговым ходом. Разница в производительности и комфорте работы действительно заметна. И Xcode 27 - еще одно подтверждение того, что будущее экосистемы Apple - за собственными процессорами.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔢 SwiftUI научился перетаскивать любые контейнеры в iOS 27.

Раньше в SwiftUI была четкая граница. Если вы хотели реализовать перетаскивание с помощью стандартных средств ваш выбор был List с его onMove. Для LazyVStack, HStack, Grid или кастомных макетов приходилось писать решение вручную. Не было никакого готового функционала для этого.

В iOS 27 это изменилось. SwiftUI получил новый API: reorderable() и reorderContainer. Теперь любой контейнер может поддерживать перетаскивание и перестановку элементов.


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

Новый API состоит из двух частей. Первая - reorderable(). Она ставится на динамический контент, который может участвовать в перетаскивании. Чаще всего это ForEach.

ForEach(items) { item in
    ItemRow(item: item)
}
.reorderable()

Вторая - reorderContainer(for:). Она определяет родительский контейнер, внутри которого разрешена перестановка.

.reorderContainer(for: Item.self) { difference in
    items.apply(difference: difference)
}

Этот подход хорошо ложится в логику SwiftUI. Поведение элемента живет с динамическим контентом. Границы взаимодействия - с контейнером. Разделение четкое и предсказуемое.


Простой пример:

Допустим, у вас есть плейлист в виде кастомного вертикального списка. Раньше пришлось бы реализовывать перетаскивание вручную. Теперь это всего лишь несколько строк кода:

struct PlaylistView: View {
    @State private var items: [PlaylistItem] = [...]

    var body: some View {
        ScrollView {
            LazyVStack(alignment: .leading, spacing: 8 ) {
                ForEach(items) { item in
                    Text(item.title)
                        .padding()
                        .background(.thinMaterial)
                        .clipShape(RoundedRectangle(cornerRadius: 12))
                }
                .reorderable()
            }
            .padding()
            .reorderContainer(for: PlaylistItem.self) { difference in
                items.apply(difference: difference)
            }
        }
    }
}

reorderable() ставится на ForEach, reorderContainer - на LazyVStack. SwiftUI берет на себя всю логику жестов, а вы только обновляете данные в замыкании.


Модель данных остается за вами:

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

.reorderContainer(for: PlaylistItem.self) { difference in
    items.apply(difference: difference)
}

Можно применить apply(difference:) к массиву. А можно обработать вручную, если логика сложнее: проверка прав на перемещение, обновление sortIndex в базе данных, синхронизация с сервером. API не навязывает конкретный способ.


Управление доступностью перетаскивания:

У reorderContainer есть параметр isEnabled. Это удобный способ включать и выключать перестановку без условной логики на уровне жестов.

.reorderContainer(
    for: PlaylistItem.self,
    isEnabled: isEditing
) { difference in
    items.apply(difference: difference)
}

Как только isEditing становится true, reorder активируется. Контейнер по-прежнему управляет областью взаимодействия, а состояние решает, активно ли оно.


🔗 Читать подробнее


💡 Вывод:

SwiftUI в iOS 27 наконец-то избавился от ограничения, которое долго раздражало разработчиков. Теперь перетаскивание работает в любом контейнере, а не только в List. Можно использовать reorderable() и reorderContainer с LazyVStack, HStack, Grid и кастомными макетами. API оставляет контроль над моделью данных за разработчиком, что важно для сложных приложений. И поддерживает перемещение между разными коллекциями.

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


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👣 Почему Flutter - идеальный выбор для разработки с ИИ-агентами

Привет. В последнее время все только и говорят о разработке с помощью ИИ-агентов. Кто-то в восторге, кто-то скептичен. Но мало кто задумывается, как выбор технологий влияет на эффективность работы с LLM. Майкл Томсен, инженер из команды Flutter, выпустил разбор на эту тему. Он объясняет, почему мультиплатформенная архитектура Flutter дает неожиданные преимущества в эпоху агентской разработки. Основная мысль простая: одна кодовая база вместо трех - это не только удобно для людей, но и критически важно при работе с ИИ.


В чем была ценность Flutter раньше:

Еще до эры агентов Flutter решал классическую проблему: вместо трех команд (iOS, Android, веб) можно иметь одну, которая пишет код на Dart и запускает его везде. От 95% до 99% кода в реальных проектах переиспользуется. Это давало:

🔵Быстрый выход на рынок на всех платформах.

🔵Гарантированную консистентность фич и дизайна.

🔵Нативную производительность (компиляция в машинный код).

🔵Безопасность благодаря строгой типизации Dart.


Что изменилось с приходом ИИ-агентов:

Когда разработкой занимаются агенты, нативный подход (Swift под iOS, Kotlin под Android, JavaScript под веб) начинает пробуксовывать. Агенту нужно сгенерировать одну и ту же логику трижды, на разных языках, с разными нюансами. Это приводит к трем проблемам.

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


Почему Flutter решает эти проблемы:

Flutter предлагает единую кодовую базу на Dart. Агент пишет все один раз, а не три. Токенов тратится меньше, генерация быстрее, логика не расходится.

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


🔗 Читать подробнее


💡 Вывод:

Flutter был удобен для команд, которые хотят поддерживать несколько платформ без тройного объема работы. В эпоху ИИ-агентов этот подход становится еще более актуальным. Меньше кода - меньше токенов. Одна логика - нет платформенного различия. Сильная типизация - меньше галлюцинаций. Горячая перезагрузка - быстрая проверка.

Для агентской разработки Flutter выглядит прагматичным выбором.


➡️ Flutter & Dart | Мобильный трудоголик

📱 Код Telegram считают эталоном, но почему он лагает на топовых устройствах?

Telegram для iOS - это технически сложный продукт. В кодовой базе 2.1 миллиона строк, 700+ модулей, 86% написано на Swift. Проекту больше 13 лет. Но при этом приложение регулярно лагает на флагманских устройствах, открывает по несколько дублей окон и годами крешится при редактировании изображений.

Почему так происходит, если код считается одним из лучших в индустрии?

Ответ звучит неожиданно: разработчики пишут на Swift, но мыслят в парадигме объектно-ориентированного программирования, как будто работают с Java. А Swift для этого не предназначен.


В чем проблема ООП в Swift:

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

Но когда разработчики используют классы и иерархии наследования так, как это делают в Java, компилятор не может применить эти оптимизации. Каждый вызов метода идет через виртуальную таблицу, а это в 3-4 раза медленнее прямого вызова.


Цена ООП-подхода в Swift:

На небольших проектах разница незаметна. Но на масштабах Telegram она становится критичной. По оценкам, из-за ООП-подхода приложение теряет от 10% до 25% производительности CPU. Лишние 20-30% памяти уходят на аллокации в куче там, где можно было использовать структуры.

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


Типичные симптомы ООП-мышления в коде Telegram:

В кодовой базе есть классы на 11 тысяч строк. Например, ChatControllerImpl. Это прямой результат парадигмы, которая поощряет концентрацию логики в одном месте.

Постфикс Impl - еще один характерный признак. Это наследие Java 90-х, где один интерфейс равнялся одной реализации. В Swift протокол - это описание способности, а не место в иерархии. Когда у протокола есть ровно одна реализация с суффиксом Impl, это почти всегда симптом: протокол создан по привычке, а не осознанно.

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


🔗 Читать подробнее


💡 Вывод:

Telegram - это огромный и сложный проект. Его разработчики проделали колоссальную работу. Но архитектурный подход, выбранный много лет назад, сегодня тормозит приложение. ООП в Swift - это не просто устаревший стиль. Это потерянная производительность.

Swift дает возможность писать почти так же быстро, как на C, но только если использовать его правильно. Protocol Oriented Programming - это не просто модный термин, а путь к реальной оптимизации. И чем крупнее проект, тем заметнее разница.

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


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

🔢 @State в SwiftUI стал macro. Синтаксис не изменился, но поведение стало лучше.

На WWDC26 компания Apple перевела @State с property wrapper на macro. Для разработчиков это значит, что код останется таким же, как и раньше, но внутри все работает иначе. Основное изменение касается ленивой инициализации observable-объектов, хранящихся в @State.


Что изменилось:

Раньше @State был property wrapper. Теперь это attached macro. В документации указано:

@attached(accessor, names: named(init), named(get), named(set))
@attached(peer, names: prefixed(`_`), prefixed(__), prefixed(`$`))
macro State()

На практике синтаксис не меняется. Код, который вы писали раньше, продолжает работать. Разница только в том, как SwiftUI управляет хранением состояния.


Изменения на практике:

Самое важное - ленивая инициализация для observable-классов в @State.

Раньше, если вы писали так:

@Observable
class ViewModel {
    var index = 0

    init() {
        print("Init")
    }
}

struct MyView: View {
    @State private var viewModel = ViewModel()

    var body: some View {
        Button("Index: \(viewModel.index)") {
            viewModel.index += 1
        }
    }
}

Инициализатор ViewModel мог вызываться каждый раз, когда SwiftUI пересоздавал структуру вью. Даже если сам объект хранился и не терялся, его инициализация все равно выполнялась. Это приводило к лишней работе, особенно если в инициализаторе были тяжелые операции.

Теперь, с macro версией @State, объект создается один раз - когда SwiftUI создает хранилище состояния для вью. И больше не пересоздается при каждом обновлении родителя.


Когда это особенно заметно:

Это изменение особенно полезно, когда вы храните в @State тяжелые объекты: модели с подписками, кэшами, сетевыми запросами при инициализации. Раньше приходилось использовать обходные пути - например, хранить опциональный объект и создавать его в .task.

// Раньше приходилось делать так, чтобы избежать повторной инициализации
@State private var viewModel: ViewModel?

var body: some View {
    MyView(viewModel: viewModel)
        .task {
            viewModel = ViewModel()
        }
}

Теперь это больше не нужно. Можно просто писать:

@State private var viewModel = ViewModel()

И быть уверенным, что объект создастся только один раз.


🔗 Читать подробнее


💡 Вывод:

Apple сделала @State macro, чтобы улучшить производительность в типичных сценариях. Синтаксис остался прежним, код не требует изменений, но observable-объекты в @State теперь инициализируются один раз. Это избавляет от лишнего кода и делает поведение более предсказуемым.

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


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👨‍💻 Управление многозадачностью при работе с ИИ-агентами

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


Параллельная работа - это не всегда хорошо:

Автор честно признается: он пробовал запускать несколько агентов одновременно в разных проектах. И называет это ошибкой. Постоянное переключение между контекстами выматывает и снижает эффективность. Его текущая стратегия - работать не более чем с 1–2 проектами одновременно, причем либо близкими по смыслу, либо, наоборот, настолько разными, что они требуют разного типа энергии.


Почему не нужно хвататься за все подряд:

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

Автор предупреждает: новый open-source проект или приложение - это не только радость от запуска, но и месяцы поддержки. Быстрый старт оборачивается долгим финишем, когда на последние 20% работы уходит столько же времени, сколько на первые 80.


Что должно двигать решениями:

Внутренняя мотивация. Если вы горите идеей - делайте. Но не потому, что «могу», и не только ради денег. Стоит браться за то, что вы готовы развивать месяцы или годы. Иначе оно того не стоит.


🔗 Читать подробнее


💡 Вывод:

Возможностей у агентов много, но и рисков не меньше. Автор сравнивает это с Лигой чемпионов: нужны фокус, дисциплина и постоянное самосовершенствование. Не стоит распыляться. Лучше делать меньше, но доводить до конца, чем хвататься за все подряд и не завершать ничего.


➡️ Кот Денисова

🔨 В Xcode наконец-то появилась возможность удаления Derived Data.

У каждого iOS-разработчика был момент, когда Xcode вдруг начинал вести себя странно: код не менялся, но сборка падала, SwiftUI Preview выдавал ошибку вместо интерфейса, зависимости переставали подключаться. В подобных случаях часто помогает удаление Derived Data.

Раньше приходилось вручную искать папку Derived Data, но в Xcode 27 это можно сделать прямо из выпадающего меню. Мелочь, а для тысяч разработчиков - это целое событие.


Что такое Derived Data:

Derived Data - это папка, куда Xcode складывает все, что генерирует в процессе сборки: скомпилированные модули, индексы, кэши пакетов, логи и прочие промежуточные артефакты. Это ускоряет повторные сборки.

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

Причина почти всегда одна: Xcode держится за устаревшее состояние. И единственный способ сбросить его - удалить Derived Data.


Как это работало раньше:

Самый простой способ удалить Derived Data - выполнить в терминале команду:

rm -rf ~/Library/Developer/Xcode/DerivedData

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


Что изменилось в Xcode 27:

В бете появился пункт в меню Product -> Delete Derived Data. Он удаляет кэш только для текущего проекта. Чисто, быстро, безопасно для других проектов.

Для CI и автоматизации по-прежнему есть командная строка:

xcodebuild -workspace App.xcworkspace -scheme App -derivedDataPath .build/DerivedData clean build

Но для локальной разработки новая возможность облегчает жизнь разработчиков.


🔗 Читать подробнее


💡 Вывод:

Новый пункт меню Delete Derived Data в Xcode 27 - это не революция, но очень полезное дополнение. Apple наконец-то официально признала: кэш сборки - это техническая деталь, а не часть проекта. Его можно и нужно сбрасывать, когда он начинает мешать.

Но главное здесь не переборщить. Если вы удаляете Derived Data каждый день, проблема не в кэше. Он всего лишь маскирует реальную причину, которая прячется в конфигурации проекта, зависимостях или процессах сборки. Удаление кэша - это временное решение. Найдите и устраните корень проблемы, и тогда новый пункт меню понадобится вам гораздо реже.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO

👨‍💻 Apple обновила правила App Store: теперь приложения могут удалять, если они не привлекают пользователей и не обновляются.

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


Кого коснется новая политика:

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

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


Что грозит разработчикам:

Самый неприятный момент касается не только отдельных приложений. Apple предупредила, что разработчики, которые неоднократно отправляют низкокачественные или клонированные приложения, могут полностью потерять доступ к программе Apple Developer Program. То есть лишиться возможности публиковать что-либо в App Store в принципе.

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


🔗 Читать подробнее


💡 Вывод:

Apple наконец-то взялась за порядок в App Store. Удалять будут не только новые приложения-клоны, но и старые, которые годами не обновлялись и никому не нужны. Под раздачу попадают фонарики, обои, таймеры, гадания и подобные. Разработчикам, которые специализируются на таких приложениях, стоит задуматься. Повторные нарушения могут стоить не только отдельных приложений, но и всего аккаунта. С одной стороны, это ужесточение правил. С другой - давно назревшая чистка, которая пойдет на пользу и пользователям и добросовестным разработчикам.


Подписаться на канал:
➡️ Telegram | Max

Закрытый канал:
🚀 Мобильный трудоголик PRO