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

🔢 Управление тулбарами на iPhone Duo.

На iPhone Duo элементы управления навигацией, действия тулбара и вкладки могут перемещаться в общую вертикальную панель, расположенную по краю экрана. Это освобождает больше пространства для контента. Приложения, собранные с iOS 27.1 SDK, получают эту адаптацию через стандартные контейнеры: NavigationStack, NavigationSplitView и TabView. Мы по-прежнему объявляем действия тулбара в привычных местах, а SwiftUI решает, как их показать в текущем контексте.


Управление осью элемента:

SwiftUI использует содержимое элемента, чтобы решить, может ли он переместиться в вертикальную панель. Стандартные элементы с символами участвуют автоматически. Текстовые элементы и сложное кастомное содержимое по умолчанию остаются горизонтальными. Модификатор axisBehavior(_:) позволяет переопределить это поведение для отдельных элементов тулбара.

Например можно создать меню с кастомной меткой, которая объединяет фигуру и текст. С автоматическим поведением SwiftUI оставит это меню в горизонтальной панели. Если метка достаточно маленькая, чтобы поместиться в вертикальную панель, можно применить .axisBehavior(.verticalPreferred) к элементу тулбара. Тогда меню присоединится к другим элементам вдоль правого края.

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


Адаптация содержимого под расположение панели:

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

Допустим, у нас есть элемент тулбара с настройкой .axisBehavior(.verticalPreferred), то есть он может переместиться в вертикальную панель. Его метка состоит из фигуры и текста. Мы хотим, чтобы в горизонтальной панели они стояли рядом, а в вертикальной - друг под другом.

Для этого проверяем toolbarVerticalEdge. Если он равен nil, располагаем элементы горизонтально. Если нет - вертикально.


Отключение вертикальных панелей:

Для интерфейсов, которым нужно больше горизонтального пространства, можно отказаться от вертикальных панелей с помощью модификатора toolbarVerticalBehavior(_:). Установка в disabled возвращает содержимое панели в стандартные горизонтальные верхнюю и нижнюю панели и восстанавливает горизонтальное расположение статус-бара.

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

Внутри окна SwiftUI использует поведение панели, указанное самым верхним представлением в NavigationStack, выбранной вкладкой в TabView или самой правой колонкой в NavigationSplitView.

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


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


💡 Вывод:

iPhone Duo приносит новые API для работы с тулбарами. axisBehavior(_:) управляет осью отдельного элемента. toolbarVerticalEdge показывает, используется ли вертикальная панель. toolbarVerticalCompressionBehavior(_:) задает приоритет между вкладками и действиями. toolbarVerticalBehavior(_:) позволяет отключить вертикальные панели там, где они мешают. Эти инструменты дают контроль над тем, как интерфейс адаптируется к складному устройству. Но Apple рекомендует не менять поведение слишком часто. Лучше один раз определить, как должны выглядеть панели, и придерживаться этого решения.


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

🔢 Новые возможности Hashable в Swift 6.4

В Swift 6.4 добавили Hashable для нескольких типов стандартной библиотеки. Раньше их можно было сравнивать, но нельзя было использовать как ключи словаря или элементы в Set. Изменения небольшие, но убирают лишние преобразования и упрощают несколько паттернов.


Dictionary.Keys стал Hashable:

Свойство keys у словаря возвращает представление Dictionary.Keys. Раньше его можно было перебирать и сравнивать, но не использовать в Set или как ключ словаря.

Теперь это работает напрямую:

var knownSchemas: Set<[String: Any].Keys> = []
knownSchemas.insert(payload.keys)

Тип значения словаря не обязан быть Hashable. Ключи словаря уже имеют это требование, поэтому [String: Any].Keys получает соответствие.


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

Два Dictionary.Keys равны, когда содержат одинаковые ключи. Значения словаря и порядок обхода не влияют на результат.

let first = ["id": 1, "name": 10]
let second = ["name": 20, "id": 2]

print(first.keys == second.keys) // true

Оба словаря содержат ключи id и name, поэтому их представления ключей равны.

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

Когда порядок важен, нужно использовать упорядоченную коллекцию:

let orderedKeys = dictionary.keys.sorted()

Когда это полезно:

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

struct PayloadSchemaRegistry<Value> {
    private var schemas: Set<Dictionary<String, Value>.Keys> = []

    mutating func register(_ payload: [String: Value]) {
        schemas.insert(payload.keys)
    }

    func contains(_ payload: [String: Value]) -> Bool {
        schemas.contains(payload.keys)
    }
}

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


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


💡 Вывод:

Dictionary.Keys: Hashable - самое полезное изменение. Оно позволяет представлениям ключей напрямую участвовать в Set, словарях и обобщенных API без промежуточных преобразований.

CollectionOfOne и EmptyCollection закрывают недостающие части обобщенной модели стандартной библиотеки.

UnownedTaskExecutor: Hashable решает более узкую задачу, но дает инфраструктуре конкурентности эффективный способ связывать ресурсы с идентификаторами исполнителей.

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


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

🔢 Приватные свойства больше не ломают memberwise инициализатор в Swift 6.4

Swift автоматически создает memberwise инициализатор для структуры, если мы не объявили его вручную. Это работает, пока в структуре нет приватных свойств. Добавление одного приватного свойства ломает инициализатор для всей структуры. В Swift 6.4 это наконец-то было исправлено.


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

Рассмотрим простую структуру:

struct Post {
    var title: String
    var body: String
}

Memberwise инициализатор создается автоматически, и мы можем инициализировать объем нашей структуры: Post(title: "Hello", body: "Hello, World!"). Но стоит добавить приватное свойство:

struct Post {
    var title: String
    var body: String
    private var id = UUID()
}

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

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


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

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

struct Post {
    var title: String
    var body: String
    private var id = UUID()

    // Создается автоматически в Swift 6.4:
    // internal init(title: String, body: String) { ... }
}

let post = Post(title: "Hello", body: "Hello, World!") // Теперь работает

id сохраняет свое значение по умолчанию, а инициализатор остается internal.


Когда это работает:

Свойство исключается из memberwise инициализатора, когда выполняются два условия. Оно менее доступно, чем максимальный уровень доступа инициализатора. И оно имеет значение по умолчанию.

Максимальный уровень доступа - это наивысший уровень среди свойств, которые могут быть включены в memberwise инициализатор, но не выше internal.

Значение по умолчанию - это либо явно указанное значение, либо значение, которое Swift присваивает автоматически. Например опциональное свойство получает nil по умолчанию.


Когда поведение не меняется:

Есть несколько случаев, когда все работает как раньше:

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

🔹Если все свойства приватные, максимальный уровень доступа тоже приватный. Ничего не исключается, и мы получаем приватный memberwise инициализатор для использования внутри.

🔹Если структура публичная, а свойство internal, ничего не исключается. Потому что максимальный уровень доступа memberwise инициализатора - internal, и свойство ему соответствует.


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


💡 Вывод:

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

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

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


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

👨‍💻 Почему разработчики ненавидят своих менеджеров.

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


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

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


Бесконечные созвоны и прерывания:

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


Это же просто кнопка:

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


Синдром невидимого инженера:

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


Воронка бесконечных встреч:

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


Театр обратной связи:

Годовое ревью от менеджера, которого ты почти не видел. Шаблонные фразы из HR-методичек. «Соответствует ожиданиям» - хотя ты в одиночку предотвратил три аварии. Повышение? «Может в конце года». А тот новый сотрудник с половиной твоего опыта, но вдвое большими коммуникативными навыками, только что получил повышение.


Неудобная правда:

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

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


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


💡 Вывод:

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


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

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

🔢 Релиз Swift 6.4: главные изменения для разработчиков.

Swift 6.4 вышел. Это обновление получилось насыщеннее, чем обычно. Язык продолжает выходить за пределы разработки под Apple: серверы, Android, WebAssembly, embedded и системный код.


Упрощение повседневного кода:

Несколько изменений делают код чище и понятнее:

🔹Теперь можно писать some Rocket? вместо (some Rocket)?. Скобки для optional some и any больше не нужны.

🔹Появился атрибут @diagnose, который позволяет управлять предупреждениями компилятора прямо в коде: подавлять, повышать до ошибок или включать.

🔹Если два модуля экспортируют одно и то же имя, можно указать нужный через селектор модуля ::

🔹Асинхронные вызовы теперь разрешены внутри defer. А withTaskCancellationShield позволяет выполнить очистку, даже если задача была отменена.


Новые API для работы с памятью:

Swift 6.4 продолжает развивать тему владения и производительности:

🔹UniqueBox - умный указатель, который владеет значением в куче без подсчета ссылок.

🔹UniqueArray хранит некопируемые элементы без copy-on-write.

🔹Iterable позволяет перебирать элементы без копирования.

🔹Ref и MutableRef дают первоклассный контейнер для заимствования или изменения одного значения за раз.


Инструменты и сборка:

🔹Swift Build теперь используется по умолчанию в Swift Package Manager на Linux, macOS и Windows. Проекты собираются одинаково на всех платформах.

🔹Добавлена генерация SBOM - Software Bill of Materials.

🔹Отладка стала лучше. LLDB теперь импортирует модули через точное отслеживание зависимостей. Debug-сборки на Linux и Windows, а также dSYM-бандлы на Darwin значительно уменьшились.

🔹Расширение Swift для VS Code теперь доступно на Open VSX Registry. Оно работает в Cursor, Antigravity, Kiro и других инструментах.


Интероп и платформы:

🔹Интероп с C и C++ стал глубже. Span теперь напрямую работает с std::span из C++20.

🔹Swift/Java interop расширил поддержку асинхронных и throwing функций для протоколов и колбэков.

🔹WebAssembly: JavaScriptKit стал до 40 раз быстрее при bridging. Wasm SDK доступен прямо на swift.org.

🔹Android: Swift SDK построен на новом LTS NDK 30. Swift Build теперь поддерживает Android в SwiftPM.


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


💡 Вывод:

Swift 6.4 - насыщенное обновление. Язык становится удобнее для повседневной работы и одновременно расширяет границы: серверы, Android, WebAssembly, embedded. Embedded Swift получил поддержку any типов, untyped throws, метатипов и парсинга чисел с плавающей точкой. Новые API для работы с памятью позволяют писать быстрый код без потери безопасности. Инструменты сборки и отладки становятся лучше.


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

📱 Официальный симулятор iPhone Duo уже доступен в Xcode 27.1

В бета-версии Xcode 27.1 появился симулятор iPhone Duo. В Device Hub можно проверить, как приложение ведет себя в разных состояниях складного устройства: открытом, закрытом, повернутом и сложенном. Это позволяет оценить адаптацию интерфейса к внутреннему и внешнему экрану до официального старта продаж.


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


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

🔨 Xcode переходит на JSON-формат проектов.

В Xcode 27.2 компания Apple добавила новый формат конфигурации проекта. Внутри привычного .xcodeproj теперь может лежать project.xcproj вместо project.pbxproj. И это не просто смена расширения.

Формат .pbxproj годами был одним из самых неприятных файлов в iOS-проекте. Огромный плоский список объектов. Ссылки через непонятные ID, merge-конфликты после добавления одного файла. Ручное редактирование почти всегда с мыслями «только бы проект в Xcode открылся».


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

Новый .xcproj - это иерархический, самодокументируемый JSON. Структура файла становится ближе к тому, что мы видим в Xcode. Apple выделяет три причины перехода:

🔹Первая: diff теперь проще читать. Изменения в comparison view соответствуют действиям в Xcode.

🔹Вторая: merge-конфликтов должно стать меньше. JSON изолирует изменения конфигурации.

🔹Третья: агенты смогут безопаснее менять настройки проекта. Раньше агенты упирались в задачу «добавь target, framework и build setting в .pbxproj», и на этом месте начиналась лотерея. Теперь Apple явно делает конфигурацию проекта более удобной не только для людей, но и для Xcode Intelligence и других агентов.


Как перейти на новый формат:

В Xcode 27.2 новые проекты по умолчанию уже используют JSON. Старые можно перевести вручную.

Нужно выбрать проект в навигаторе, открыть инспектор файла и в разделе документ проекта выбрать JSON из меню формат проекта. После этого внутри .xcodeproj файл project.pbxproj удаляется и появляется project.xcproj.

Сам .xcodeproj никуда не исчезает. Schemes, Package.resolved, user data и остальная структура остаются как были. Это не новый способ описывать проект вроде Tuist или XcodeGen. Это тот же Xcode project model, просто в более удобном формате.


Совместимость:

Новый формат поддерживается всеми версиями Xcode 27 и новее. Для перехода не обязательно одновременно обновлять всю команду до 27.2.

Если что-то пошло не так, миграция обратима через git: вернуть project.pbxproj и удалить .xcproj.


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


💡 Вывод:

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

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

Миграция не обязательна, но если вы уже на Xcode 27, стоит попробовать. Особенно если работаете в команде, где merge-конфликты стали постоянной болью.


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

👨‍💻 ИИ-агент не сделает из вас разработчика, если у вас нет базовых знаний.

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

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


В чем здесь главная ловушка:

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

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


Где место вайбкодингу:

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

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


💡 Вывод:

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


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

🔢 ArrangementView в SwiftUI: новый способ компоновки для складных устройств.

С выходом iPhone Duo компания Apple добавила не только новый форм-фактор, но и новые API для работы с двумя экранами.


Режимы совместимости:

Приложение будет работать на iPhone Duo, даже если оно не собрано с использованием iOS 27 SDK. Но в режиме совместимости от статус-бара появится черный отступ. Это значит, что интерфейс не будет занимать весь экран.

С новым SDK iOS 27.1 приложение займет все доступное пространство. Поэтому если вы планируете поддержку iPhone Duo, стоит обновиться до iOS 27.1 SDK.


Что такое ArrangementView:

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

Вместо ручного переключения layout при изменении геометрии вы описываете роли контента. SwiftUI сам определяет, как их показать.

NavigationStack {
    ArrangementView {
        PlayerView()
    } secondary: {
        UpNextView()
    }
}

Стили компоновки:

Есть два встроенных стиля: split и overlay.

Split - для контента, который должен оставаться видимым независимо. Основное и дополнительное представления разделяют доступное пространство. Если контейнер широкий, SwiftUI предпочитает горизонтальное разделение, иначе - вертикальное.

ArrangementView {
    PlayerView()
} secondary: {
    TranscriptView()
}
.arrangementViewStyle(.split)

Можно ограничить разделение конкретной осью:

.arrangementViewStyle(
    .split.axes(.horizontal)
)

Overlay - для контента с отношением «передний план - задний план». Одно представление может располагаться поверх другого.

ArrangementView {
    ContentView()
} secondary: {
    ControlsView()
}
.arrangementViewStyle(.overlay)

Дочернее представление может узнать, находится ли оно поверх другого, через environment-значение overlayArrangementZIndex.

struct ControlsView: View {
    @Environment(\.overlayArrangementZIndex)
    private var zIndex

    var body: some View {
        Controls(compact: zIndex > 0)
    }
}

ReservedRegion:

iPhone Duo вводит ReservedRegion - области, которые представляют аппаратные части, влияющие на доступный контент. SwiftUI может запрашивать их через GeometryProxy.

GeometryReader { proxy in
    let regions = proxy.reservedRegions(kind: .division)
}

Division regions разделяют доступные области, например вокруг шарнира. Occlusion regions описывают аппаратные части, которые закрывают часть дисплея.


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


💡 Вывод:

iPhone Duo приносит новые API для адаптивной компоновки. Режимы совместимости дают время на миграцию. ArrangementView позволяет описывать роли контента, а не жестко задавать layout.

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


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

🍎 Официальные макеты iPhone Duo и iPhone 18.

Компания Apple опубликовала официальные макеты iPhone Duo и iPhone 18. Они доступны в разделе Product Bezels и предназначены для использования в маркетинговых материалах, дизайне и разработке. При работе с макетами Apple рекомендует сверяться с Marketing Resources и Identity Guidelines.

Размер экрана iPhone 18 не изменился - существующие layout-решения продолжат работать без адаптации. iPhone Duo, как первое складное устройство Apple, требует нового подхода: у него два экрана, и макеты позволяют увидеть устройство в открытом, закрытом и сложенном состояниях.


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


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

🍎 Руководство по адаптации приложений под iPhone Duo.

Apple выпустила руководство по адаптации приложений под iPhone Duo - свой первый складной смартфон. Главная новость: отдельного FoldableKit нет. Apple просто продолжает двигать разработчиков в сторону адаптивных интерфейсов.


С чего стоит начать:

Приложение будет работать на iPhone Duo, даже если оно не собрано при помощи iOS 27 SDK. Но чтобы использовать все возможности, нужно обновление.

В режиме совместимости, как iPhone-приложение на iPad, все будет работать не очень красиво. Если собрать с iOS 27 SDK, появится полноэкранный режим с черным статус-баром. С iOS 27.1 SDK можно сделать полноценную поддержку.

Для тестирования нужно скачать Xcode 27.1 и выбрать симулятор iPhone Duo в Device Hub. Там можно открыть, закрыть, повернуть и сложить устройство, чтобы посмотреть, как ведет себя layout.


Как работает адаптация:

На внешнем экране iPhone Duo все выглядит как на обычном iPhone: regular для вертикального положения, compact для горизонтального. На внутреннем экране - regular и по горизонтали и по вертикали. Это позволяет показывать sidebar и больше контента.

Внутренний экран не обязан соблюдать supportedInterfaceOrientations. Apple прямо говорит: не проверяйте ориентацию для layout-решений. Используйте size classes.


Проблема с UIScreen.main:

У iPhone Duo два дисплея, поэтому понятие UIScreen.main становится неоднозначным. Apple объявила такие обращения устаревшими.

Если действительно нужен экран конкретного окна, его можно получить через UIWindowScene:

window?.windowScene?.screen

Но лучше вообще работать через environment, traits и размеры самой scene.


Асимметричные safe areas:

Safe area теперь может быть асимметричной. Формула width - leftInset * 2 больше не гарантирует правильный результат. Левый и правый inset могут отличаться из-за формы устройства, камеры и системного UI.

Apple советует считать каждую сторону отдельно. Весь интерактивный UI держать внутри safe area, а фон растягивать edge-to-edge.


Автоматическая адаптация:

Если вы используете стандартную навигацию, большая часть адаптации произойдет автоматически. NavigationSplitView, UISplitViewController, TabView, UITabBarController, sheets, popovers и alerts уже умеют адаптироваться к разным положениям Duo.

На внутреннем экране tab bar можно автоматически превратить в sidebar. Для SwiftUI это настройка default tab bar placement, для UIKit - preferred placement.


ReservedRegion:

В iOS 27.1 появилась новая возможность - ReservedRegion в SwiftUI и UIViewReservedRegion в UIKit. Она нужна кастомному edge-to-edge UI, чтобы сказать системе: дай максимум пространства, но не залезай туда, где уже живет системный интерфейс.

Это полезно для собственных баров и сложных лайаутов.


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


💡 Вывод:

iPhone Duo не приносит отдельный фреймворк. Apple просто продолжает давить в сторону адаптивного интерфейса. Не определять устройство. Не ориентироваться на конкретную ширину. Не считать, что экран один. Не ожидать симметричные safe areas. Если вы уже следовали этим правилам, у вас будет минимум работы по адаптации.


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

👨‍💻 Apple может изменить App Store, чтобы увеличить доходы.

Apple рассматривает возможность изменений в App Store. Главная цель - увеличить доход, который компания получает от своей платформы. Инициативу продвигают новый генеральный директор Джон Тернус и старший вице-президент по сервисам Эдди Кью. Конкретные изменения пока не определены, но речь идет о поиске способов повысить маржу и увеличить долю повторяющихся поступлений.


Почему ушел Фил Шиллер:

Новый курс стал одной из причин, по которой Фил Шиллер покинул руководство App Store. 66-летний топ-менеджер хотел уделять больше времени семье и благотворительности, но, по информации Bloomberg, одновременно опасался, что попытка извлечь из магазина еще больше денег усилит противостояние Apple с разработчиками и государственными регуляторами.

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


Как Шиллер относился к разработчикам:

Бывший глава отдела проверки приложений Apple Филлип Шумейкер, напротив, рад уходу Шиллера. Его мнение: «У него не было ни малейшего желания садиться за стол с разработчиками и модернизировать правила. Не из злого умысла, а из убеждения, что правила пишет Apple, а разработчики должны им следовать - и точка».


Что может измениться:

Есть несколько потенциальных способов увеличить прибыльность App Store.

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

🔹Второй вариант: повысить стоимость участия в Apple Developer Program. Сейчас она составляет $99 в год. Многие независимые разработчики уже тратят сотни долларов в месяц на инструменты вроде Claude и Cursor. Теоретически Apple могла бы повысить ежегодный взнос без потери значительной части разработчиков.

🔹Третий вариант: взимать с крупных разработчиков дополнительную плату в зависимости от объема трафика. Так Apple могла бы переложить часть расходов на инфраструктуру App Store на наиболее крупные приложения.


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


💡 Вывод:

Конкретных изменений Apple еще не объявляла. Пока это лишь возможные варианты. Но ясно одно: новое руководство Apple рассматривает App Store не только как платформу распространения приложений, но и как направление, из которого можно получать больше регулярной выручки и более высокую прибыль.

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


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

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

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


Почему раньше пет-проекты делали не все:

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


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

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


Но есть нюанс - цены на агентов растут:

Сейчас модели и подписки на них стоят относительно недорого. Можно пользоваться Claude Code, Cursor, ChatGPT с полным функционалом за разумные деньги. Но этот период не вечен. Компании, предоставляющие ИИ-инструменты, ужесточают условия для бизнес-клиентов, переводят их на оплату по факту. Индивидуальных пользователей пока не трогают, но тренд очевиден: дешевые токены заканчиваются. Рано или поздно подписки подорожают, либо функционал в дешевых тарифах урежут.


Что будет, если подождать:

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


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


💡 Вывод:

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


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

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

🔢 Как добиться стабильного выполнения фоновых задач в iOS.

Казалось бы, у вас в кармане суперкомпьютер. Он точно должен уметь выполнять рутинные задачи в фоне, пока вы занимаетесь своими делами. Как cron в Unix, который отлично работает с 1970 года. Но реальность iOS оказалась сложнее.

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


Типы фоновых задач в iOS:

Есть три основных типа фоновых задач:

🔵BGAppRefreshTask: короткая задача для обновления. Предназначена для поддержания контента приложения в актуальном состоянии.

🔵BGProcessingTask: для более тяжелой работы, которая может занимать минуты.

🔵BGContinuedProcessingTask: появился в iOS 26. Запускается на переднем плане и может продолжать работу в фоне. Для автоматической синхронизации бесполезен.

Apple не публикует точных числовых ограничений. Реальные лимиты приходится выяснять вручную.


Как запланировать задачи:

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

let refresh = BGAppRefreshTaskRequest(identifier: "com.app.refresh")
refresh.earliestBeginDate = lastRun.addingTimeInterval(30 * 60)
try BGTaskScheduler.shared.submit(refresh)

let processing = BGProcessingTaskRequest(identifier: "com.app.process")
processing.earliestBeginDate = lastRun.addingTimeInterval(60 * 60)
try BGTaskScheduler.shared.submit(processing)

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

BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.app.process") { task in
    task.expirationHandler = {
        cancelWork()
        task.setTaskCompleted(success: false)
    }
    
    Task {
        let ok = await doWork()
        task.setTaskCompleted(success: ok)
    }
}

Точность планирования:

BGTaskScheduler не похож на cron. Задача может запуститься на несколько часов позже запрошенного времени. На устройстве автора processing задачи чаще запускались ночью на зарядке, а refresh днем, когда телефон активно использовался.

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

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


Подводные камни планирования:

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

static func shouldSkipSubmit(existingEarliest: Date?, desiredEarliest: Date) -> Bool {
    guard let existingEarliest else { return true }
    return existingEarliest <= desiredEarliest.addingTimeInterval(5)
}

Важно вычислять время от фиксированной точки, а не от текущего момента.

let desiredEarliest = max(
    now.addingTimeInterval(60),
    lastRun.addingTimeInterval(interval)
)

earliestBeginDate - это нижняя граница, а не расписание. iOS не гарантирует запуск в указанное время.


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


💡 Вывод:

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


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

🔨 Agent Skills в Xcode 27: актуальные навыки от Apple.

В Xcode 27 появилась новая концепция - Agent Skills. Это наборы инструкций, которые обучают ИИ-агента выполнять конкретные задачи. В комплекте идет семь навыков от Apple: от работы со SwiftUI до аудита безопасности и взаимодействия с симулятором.


Что такое Agent Skills:

Agent Skill - это многократно используемый набор инструкций. Он объясняет агенту, как подходить к задаче: что проверять, какую последовательность действий соблюдать, какие ограничения учитывать и какие справочные материалы использовать.

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


Семь навыков Xcode 27:

Apple включила в Xcode 27 семь готовых навыков:

🔵SwiftUI Specialist: базовый навык для работы с SwiftUI. Содержит рекомендации по структуре вью, потокам данных, environment values, модификаторам, локализации, анимациям и идентичности элементов. Помогает агенту избегать устаревших API даже без формальной депрекации.

🔵SwiftUI What's new in iOS 27: навык про новые API в iOS 27: макрос @State, reorderable контейнеры, жесты свайпа, кэширование AsyncImage и другие изменения. Решает проблему, когда модель обучена на старых данных и не знает о свежих API.

🔵UIKit App Modernization: помогает адаптировать UIKit-приложения к современным многоконным средам. Заменяет устаревшие проверки вроде UIScreen.main на локальную информацию из сцены и окна.

🔵Test Modernizer: обновляет тесты. Мигрирует XCTest-код на Swift Testing, заменяет ассерты на #expect и #require, перестраивает структуру тестов.

🔵C Bounds Safety: для проектов с C и Objective-C. Объясняет, как использовать расширение -fbounds-safety для защиты от выходов за границы массивов.

🔵Audit Xcode Security Settings: проверяет настройки безопасности проекта: предупреждения компилятора, статический анализ, укрепление бинарника, pointer authentication и другие опции.

🔵Device Interaction: позволяет агенту взаимодействовать с симулятором или физическим устройством. Делать скриншоты, анализировать UI-иерархию, тапать, скроллить, вводить текст.


Как использовать навыки:

Навыки можно экспортировать в Markdown-файлы командой:

xcrun agent skills export ~/.agents/skills

После этого их можно использовать с любым агентом, поддерживающим Skills. Это означает, что одни и те же инструкции от Apple могут работать с Codex, Claude, Cursor и другими инструментами.


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

У LLM есть ограничение: они обучены на данных, которые на момент тренировки были актуальны. Новые API, изменения в iOS 27 и свежие рекомендации могут отсутствовать в знаниях моделей.

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


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


💡 Вывод:

Agent Skills в Xcode 27 - это шаг к тому, чтобы ИИ-агенты могли работать с Apple-экосистемой на уровне экспертов. Вместо общих знаний модели агент получает актуальные инструкции от Apple.

Семь навыков покрывают основные сценарии: SwiftUI, UIKit, тесты, безопасность, C-код и взаимодействие с устройством. Их можно экспортировать и использовать с любым агентом.

Пока это только начало. Но направление ясно: Apple готовит Xcode для эры, когда код будет писать не человек, а агент. А навыки - это способ контролировать качество его работы.


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

🧭 Podlodka iOS Crew: разработка с AI

С 14 по 18 сентября пройдет новый сезон Podlodka iOS Crew. В этот раз в центре внимания авторов конференции то, как AI меняет iOS-разработку.

Что ждёт участников:

• Стратегия внедрения терминальных ИИ-агентов и MCP-интеграции в ежедневную iOS-разработку

• AI как экзокостюм мобильного разработчика: harness, skills, CLI, orchestration, validation и evals

• Знания о том, как запускать локальные модели на Apple Silicon

• Готовые скрипты, которые можно забрать в свой проект: шаблон рабочего пространства агента, примеры скиллов и MCP, пайплайн от Jira-задачи до Merge Request.

И это ещё не всё! Подробности о сезоне смотрите на сайте, и там же есть билеты по early-bird цене.

👉 Билеты на Podlodka iOS Crew

А по промокоду hardworkerIT получите скидку🎁

👣 Почему primary constructors в Dart сложнее, чем кажется

В Dart 3.13 появилась фича, которую ждали годами - primary constructors. Теперь класс с полями и конструктором можно объявить в одну строку. Но путь к этому решению был долгим. Команда Dart потратила много времени на обсуждение деталей и принятие компромиссов. Боб Нюстром написал большой разбор о том, через что пришлось пройти. Давайте разберем самые важные моменты из данного разбора.


Почему синтаксический сахар важен:

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

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

🔹Первый - когда новый способ просто лучше старого. Например, в Dart 2.0 сделали необязательным ключевое слово new при создании объектов. Старый синтаксис остался для совместимости, но никто его не использует.

🔹Второй - когда синтаксис сильно упрощает частый сценарий. В Dart изначально не было enum. Их эмулировали через классы с константами. Когда добавили настоящие enum, код стал не только короче, но и понятнее.

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


Зачем нужен primary constructors:

Primary constructors решают конкретную проблему: объявление класса с конструктором, который просто сохраняет параметры в поля.

Без primary constructors код выглядит так:

class Point {
  final int x;
  final int y;
  Point(int x, int y) : x = x, y = y;
}

С использованием initializing formals:

class Point {
  final int x;
  final int y;
  Point(this.x, this.y);
}

Но разработчики хотели еще короче. Чтобы можно было просто написать так:

class Point(final int x, final int y);

Основная проблема:

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

Например, у класса есть primary constructor с кучей параметров. Потом нужно добавить логирование в конструктор. Если primary constructor не поддерживает тело, придется переписать все обратно на старый синтаксис.

Чтобы избежать этого, в Dart добавили блоки this { ... } внутри класса. Они позволяют добавить тело или инициализатор для primary constructor без переписывания всего.

class FormatterOptions(
  final int indent = 0,
  final int pageWidth = 80,
) {
  this {
    log.write('Created options.');
  }
}

Новый синтаксис конструкторов:

Еще одно изменение касается объявления конструкторов. Раньше нужно было повторять имя класса:

class LongClassName {
  LongClassName(); // безымянный
  LongClassName.create(); // именованный
}

Теперь можно использовать ключевое слово new:

class LongClassName {
  new(); // безымянный
  new create(); // именованный
}

Для фабричных конструкторов:

class AnotherLongClass {
  factory () { ... } // фабричный
  factory create() { ... } // именованный фабричный
}

Это короче, особенно для длинных имен классов. И решает проблему с typedef и расширениями, где имя класса не всегда доступно.


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


💡 Вывод:

Primary constructors в Dart 3.13 - это не просто очередной синтаксический сахар. Это результат долгого размышления о том, как сделать язык удобнее и проще.

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

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


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