👣 Как Dart и Flutter смотрят на ИИ в 2026 году

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


Цифры, которые объясняют все:

Согласно опросам, 84% разработчиков в целом используют ИИ-инструменты в своей работе. Среди Flutter-разработчиков этот показатель чуть ниже - 79%, но все равно впечатляет. Однако есть проблема: 46% не доверяют точности ИИ при решении критических задач. Это тратит лишнее время на проверку сгенерированного кода.


Главные принципы:

Команда декларирует несколько ключевых правил, которым следует при развитии ИИ-направления:

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

🔵Добавлять, а не заменять. ИИ-инструменты должны дополнять опыт разработки, а не вытеснять разработчика. Каждый сам решает, использовать ИИ или нет и в каком объеме. При этом документация и базовые инструменты остаются источником истины.

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

🔵Доверие через качество. Главная проблема ИИ-генерации - затраты времени на проверку. Команда работает над тем, чтобы сгенерированный код был точным, идиоматичным и соответствовал стандартам проекта. Для этого сотрудничают с Google Deepmind и Antigravity по оценке моделей.


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


💡 Вывод:

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


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

🔨 Отладка неочевидного EXC_BAD_ACCESS с помощью LLDB.

Всем привет! Наткнулся на интересную статью, в которой автор рассказывает про поиск причины падения приложения при сворачивании на одном из экранов. В краш-логе не было ни одной строчки кода приложения, только системные фреймы QuartzCore, UIKit и Core Animation. Address Sanitizer ничего не показывал, а воспроизвести проблему без долгих танцев с бубном не получалось.


Что предложил автор:

Вместо того чтобы гадать, он взялся за LLDB. Сначала посмотрел bt (backtrace) - стек вызовов в момент падения. Анализируя его снизу вверх, стало ясно: приложение сворачивалось, система делала снимок экрана, обходила иерархию вьюх и у одной из них запрашивала superview. Именно там и происходил краш.

Дальше - frame select 0 и register read. В регистре x15 отладчик показал символ CrashExample.PlayerView - намек, что проблема связана с плеерным view. А падающая инструкция (ldr x8, [x8, #0x8]) указала, что регистр x8 был нулевым. Чтение по адресу 0x8 и вызывало EXC_BAD_ACCESS.


К чему это привело:

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

Исправление оказалось простым: вместо ручного удаления слоя вызывать playerView.removeFromSuperview().


💡 Вывод:

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


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

🔢 Transferable в iOS: как научить ваши данные drag&drop и шерингу.

Задумывались ли вы, как разные приложения на вашем iPhone так легко обмениваются данными? Вы копируете текст из Safari и вставляете его в Notes, перетаскиваете файл из Finder в Telegram или скидываете фото через AirDrop. Эта магия кажется пользователю простой, но для разработчика за ней стоит сложная задача: как объяснить системе, что ваши кастомные данные тоже умеют «путешествовать»? В iOS 16 компания Apple представила ответ - протокол Transferable, ставший основой фреймворка Core Transferable. Это не просто еще один API, а декларативный мост, который навсегда меняет подход к реализации drag&drop, шеринга и других операций передачи данных.


Эволюция обмена данными:

До появления Transferable реализация перетаскивания или копирования кастомных объектов была квестом. Разработчику приходилось вручную работать с низкоуровневыми API вроде NSItemProvider, конвертировать свои модели в примитивные типы (String, Data, URL), писать кучу императивного кода для экспорта и импорта, а также обрабатывать множество состояний и ошибок.

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


TransferRepresentation: язык, на котором ваши данные говорят с системой:

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

🔵CodableRepresentation: идеально для передачи структурированных данных между приложениями. Если ваш тип соответствует Codable, вы легко получаете сериализацию/десериализацию в JSON или Property List. Вы определяете кастомный UTType (как UTType.note), и система понимает, как с этим работать.

🔵FileRepresentation: для всего, что является или может быть представлено как файл. Вы указываете content type (например, .image, .pdf) и замыкания для экспорта (например, сохранение временного файла) и импорта (загрузка полученного файла). Система автоматически управляет файлами во временной директории.

🔵ProxyRepresentation: мост к уже существующим, системным типам. Если ваша модель содержит текст, ссылку или изображение, вы можете экспортировать это свойство. Это позволяет, например, перетащить объект Note в TextField, и вставится только его текстовое содержимое.


Один раз объявил - получил все:

После того как вы реализовали Transferable, ваша модель автоматически получает суперспособности во всех контекстах, где SwiftUI или система используют этот протокол:

🔵Drag & Drop в SwiftUI: модификатор .draggable(YourModel()) для перетаскивания и .dropDestination(for: YourModel.self) для приема работают из коробки.

🔵Кнопка «Поделиться» (ShareLink): в SwiftUI вы можете создать ShareLink("Поделиться", item: yourModelInstance). Система сама построит интерфейс шеринга со всеми доступными опциями (Messages, Mail, AirDrop и т.д.).

🔵Интеграция с системой: ваши данные автоматически начинают работать с NSItemProvider под капотом, что открывает совместимость с UIKit и даже другими платформами.


🔗 Ссылка на документацию Apple


💡 Вывод:

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

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


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

👨‍💻 ChatGPT не заменит твой мозг: как сохранить экспертизу в эпоху ИИ.

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

Споры об ИИ в разработке часто скатываются в крайности: от «он все сделает за меня» до «это полная ерунда». Давайте разберемся, как на самом деле стоит использовать эти инструменты, чтобы они стали рычагом для роста, а не костылем, ведущим к профессиональной деградации.


Сценарий 1 - ИИ как супер поисковик и генератор гипотез:

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

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


Сценарий 2 - ИИ как черная дыра для вашей экспертизы:

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


Золотые правила работы с ИИ для разработчика:

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

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

🔹Задавайте сложные вопросы. Вместо «напиши код» спрашивайте: «Какие есть архитектурные подходы для реализации offline-режима в iOS-приложении? Опиши плюсы и минусы каждого». ИИ отлично структурирует знания.

🔹ИИ - твой подчиненный, а не начальник. Выдал решение? Спроси: «В чем слабые места этого подхода?», «Где здесь могут быть проблемы с производительностью?». Заставляйте его критиковать собственную работу.


Что остается неизменным:

🔹Критическое мышление. Способность подвергать сомнению любой, даже самый красивый, сгенерированный код.

🔹Глубокое понимание фундаментальных принципов. Паттерны, структуры данных, принципы ООП и протокольно-ориентированного программирования не устаревают. ИИ просто манипулирует ими.

🔹Коммуникация и софт-скиллы. Объяснить сложную концепцию продукт-менеджеру или помочь джуну - это то, что ИИ не сделает за вас. Ваша ценность в команде - это не только код.


💡 Вывод:

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


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

🔢 ARC: компилятор против рантайма, кто что делает на самом деле.

Управление памятью в Swift - одна из тех тем, которую все проходят, но немногие действительно понимают. Особенно это касается Automatic Reference Counting (ARC). Мы привыкли думать о нем как о волшебном сборщике мусора, который где-то там, в недрах системы, следит за нашими объектами. Но реальность намного интереснее и прозаичнее. ARC - это не рантайм-система, а компиляторная технология, и именно в этом кроется большинство недоразумений.


Компилятор как главный архитектор памяти:

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

class User {
  let name: String
  init(name: String) { self.name = name }
}

func createUser() {
  let user = User(name: "Алексей")
  // что-то делаем с user
}

ARC на этапе компиляции анализирует этот код и вставляет инструкции управления памятью. Грубо говоря, после компиляции код выглядит примерно так (в псевдокоде):

func createUser() {
  let user = User(name: "Алексей") // objc_retain(user)
  // что-то делаем с user
  // objc_release(user) - здесь, при выходе из области видимости
}

Ключевой момент: ARC не следит за объектами во время выполнения программы. Он не активный участник рантайма. Вся его работа заканчивается в момент компиляции. Он просто расставляет вызовы функций retain и release в правильных местах.


Рантайм - слепой исполнитель:

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

Когда рантайм видит objc_retain(ptr), он увеличивает счетчик ссылок в заголовке объекта. Когда видит objc_release(ptr) - уменьшает. Когда счетчик достигает нуля - немедленно вызывает деструктор и освобождает память.

Важное уточнение: счетчик ссылок - это не абстракция Swift. Это физическое поле в заголовке объекта в куче памяти. Вы не можете получить к нему доступ из Swift-кода, потому что это низкоуровневая деталь реализации Objective-C runtime, который Swift использует под капотом на Apple-платформах.


Autorelease - не то, что вы думаете:

Слово autorelease вызывает самые странные ассоциации. «Автоматическое освобождение»? «Отложенный сборщик мусора»? На самом деле, это просто еще одна инструкция, которую ARC может вставить.

Autorelease не освобождает память. Он говорит: «Не делай release сейчас, сделай его позже, когда завершится текущий autorelease pool».


Это нужно в двух основных случаях:

🔵Переходы между Swift и Objective-C: когда объект передается в Objective-C код, и момент окончания владения неясен на этапе компиляции.

🔵Возврат значений из методов: особенно в Objective-C-стиле, где принято возвращать autoreleased объекты.

Но вот что действительно важно: autorelease pool - это не магический контейнер, который хранит объекты. Это просто очередь release-операций, выполнение которой отложено.

В чистом Swift-коде autorelease используется все реже. Компилятор становится умнее и может определить момент release точнее. Но он все еще нужен для совместимости с Objective-C и некоторых случаях.


💡 Вывод:

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

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


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

🔨 Как работает Compilation Cache в Xcode 26.

Разработчики под iOS хорошо знают: чем серьезнее проект, тем дольше он собирается. Добавил пару строк - жди. Запустил сборку на CI - опять жди. В Xcode 26 появился механизм, который пытается разорвать этот порочный круг - Compilation Cache.


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

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

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


Что предлагает Compilation Cache:

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

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


Как включить:

Достаточно добавить в настройки сборки:

COMPILATION_CACHE_ENABLE_CACHING = YES

После этого кэш будет накапливаться по мере компиляции.


Где разница будет заметна:

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

🔵Чистые сборки. Раньше clean build означал полную перекомпиляцию. Теперь, если кэш сохранен на диске, можно переиспользовать уже собранные артефакты.

🔵CI с высоким потоком пул-реквестов. Если настроить сохранение кэша между запусками, повторная работа сокращается значительно.


Почему не всем станет сильно быстрее:

Компиляция - не единственная стадия сборки. Обработка ассетов, копирование файлов, скриптовые фазы (линтеры, генерация кода), линковка и встраивание - все это может оставаться узким местом. Если сборка тормозит из-за них, кэш компиляции не поможет.


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


💡 Вывод:

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


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

🔢 Гибридная архитектура на основе MVVM и TCA для iOS.

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


Что взяли за основу:

Из MVVM оставили Model, View, ViewModel. Из TCA добавили State, Action и Reducer.

🔵State - центральное хранилище состояния всей иерархии View. Все UI-параметры, которые раньше лежали во ViewModel, вынесены сюда. State - класс, всегда один экземпляр, удобно передавать между компонентами.

🔵View может читать State и менять его через Binding. Если изменение не через Binding (например, нажатие кнопки) - обновление идет через ViewModel, но без прямого доступа к ней. Вместо этого используется Reducer.

🔵Reducer - вспомогательный класс, который скрывает асинхронность ViewModel (она сделана актором). Вместо Task { await viewModel.handle(...) } - просто передача Action. Код становится чище.

🔵Action - enum, описывающий все возможные взаимодействия View с ViewModel. View не вызывает методы ViewModel напрямую, только отправляет Action.

🔵ViewModel - бизнес-логика, сервисы, роутер. Единственный публичный метод - handle(_ action: Action). Все остальное приватное.

🔵Module - файл, где собраны все протоколы модуля.


Как упростили работу с дочерними вью:

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

Аналогично с замыканиями: вместо десятка отдельных замыканий - один enum Action и одно замыкание onAction. Внутри вью просто вызывается onAction с нужным кейсом.

Для списков с разными ячейками - передают в List сразу весь State и Reducer. Внутри уже выбирают нужные данные для каждой ячейки.

Архитектура работает и со SwiftUI, и с UIKit - разница только в механизме отслеживания изменений State.


💡 Вывод:

Автор предлагает гибридный подход, который сочетает простоту MVVM и стройность TCA. Основные плюсы: чистый код, отсутствие лишних асинхронных конструкций, удобная работа с дочерними вью и поддержка обеих UI-фреймворков (UIKit и SwiftUI). Полный код можно посмотреть на GitHub.


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

👨‍💻 Big O нотация: почему ваш код может работать медленно в 100 раз при росте данных в 10 раз.

В мире разработки часто возникает дискуссия: как оценить эффективность алгоритма? Можно измерить время выполнения на конкретных данных, но эти цифры будут относительными - зависеть от мощности железа, текущей нагрузки и множества других факторов. Существует более фундаментальный способ, который абстрагируется от конкретных измерений и описывает суть поведения алгоритма. Этот язык называется Big O нотация, и его понимание - не академическое упражнение, а практический навык, который отделяет хаотичное написание кода от осознанного проектирования систем.


Суть нотации - описываем не секунды, а характер роста:

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

Big O - это именно про характер роста требуемых ресурсов (времени или памяти) при увеличении объема входных данных. Обозначение O(n) говорит: время работы растет пропорционально n. O(1): время не зависит от размера данных. Нотация игнорирует константы (O(2n) это O(n)) и менее значимые слагаемые, фокусируясь на доминирующем факторе при стремлении n к бесконечности.


От простого к сложному - иерархия сложностей в действии:

🔹O(1) - константное время: доступ по индексу в массиве. Независимо от того, массив из 10 или 10 миллионов элементов, операция array[42] выполняется за одно и то же время. Это идеал, но не всегда достижимый.

🔹O(log n) - логарифмическое время: бинарный поиск. Каждый шаг алгоритма отбрасывает половину оставшихся вариантов. Увеличение данных в 1000 раз увеличит время работы лишь в ~10 раз (log₂(1000) ≈ 10). Невероятно эффективно для больших объемов.

🔹O(n) - линейное время: поиск элемента в неотсортированном массиве. В худшем случае придется проверить каждый элемент. Увеличение данных в 10 раз - в 10 раз больше операций. Предсказуемо и часто приемлемо.

🔹O(n log n) - линейно-логарифмическое время: эффективные алгоритмы сортировки (Merge Sort, Quick Sort). Хуже, чем линейный рост, но значительно лучше квадратичного. Фактический стандарт для сортировки.

🔹O(n²) - квадратичное время: пузырьковая сортировка, два вложенных цикла. Увеличение данных в 10 раз увеличивает время работы в 100 раз. На больших n это катастрофа. Классический маркер неоптимального алгоритма.

🔹O(2ⁿ), O(n!) - экспоненциальное и факториальное время: решение некоторых задач перебором (например задача коммивояжера). Практически неприменимы для реальных данных, кроме самых маленьких n.


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


💡 Вывод:

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

Она отвечает на критически важный вопрос: «Что произойдет с моим приложением, когда данных станет в 100, 1000 или 1000000 раз больше?» Пренебрежение этим анализом ведет к созданию систем, которые корректно работают на тестовых данных, но непредсказуемо ведет себя при реальной работе, создавая инциденты, которые невозможно быстро разрешить простым добавлением ресурсов на сервере.


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

🔢 Плавные expandable-ячейки в SwiftUI List.

В SwiftUI раскрывающиеся списки - штука коварная. В обычном VStack или LazyVStack анимация работает как по маслу: нажал - контент плавно появился, исчез - так же плавно скрылся. Но стоит положить такую конструкцию в List, и анимация начинает дергаться. Контент просто выскакивает, а высота ячейки меняется рывками.


Почему в List анимация ломается:

Проблема в том, что List по-своему управляет переиспользованием ячеек и вычислением их высоты. Когда внутри ячейки появляется или исчезает условный блок с if, List не всегда корректно анимирует изменение размера. SwiftUI просто не понимает, как плавно перейти от одного состояния к другому.

DisclosureGroup - встроенное решение от Apple. Оно работает плавно, но не дает кастомизировать анимацию. Если вам нужен свой дизайн (своя иконка, свои тайминги), DisclosureGroup не подходит.


Как это можно обойти:

Есть способ, который заставляет List анимироваться так, как нужно. Идея в том, чтобы анимировать не появление/исчезновение контента, а его высоту. Для этого используется протокол Animatable, который анимирует одно числовое значение от 0 до 1. В зависимости от этого значения меняется высота блока, а сам контент всегда присутствует в иерархии, но его прозрачность и положение привязаны к анимируемому значению.


Основные шаги:

🔵Измерить высоту заголовка и высоту раскрывающегося контента (через GeometryReader и PreferenceKey).

🔵Вычислить общую высоту ячейки как высота_заголовка + высота_контента * прогресс.

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

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


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


💡 Вывод:

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


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

🔢 iOS 26: SwiftUI наконец-то стал таким же быстрым как UIKit?

Нашел интересную статью, в которой автор провел сравнение производительности SwiftUI и UIKit в iOS 26. На WWDC25 компания Apple уверяла, что с производительностью в SwiftUI стало в разы лучше. Но так ли это на практике? Чтобы проверить, он создал максимально сложную ленту и сравнил, как с ней справляются оба UI-фреймворка.


Что тестировали:

Лента содержала следующие элементы:

🔵Изображения высокого разрешения.

🔵Сложную иерархию элементов, текстов и градиентов.

🔵Постоянно анимирующиеся гифки.

🔵Ячейки переменной высоты.

🔵Жесты, которые в реальном времени обновляют состояние.

Все это заставляло экран работать на 120 кадрах в секунду, давая на каждый кадр всего 8 миллисекунд.


Результаты тестов:

🔵Память. SwiftUI использовал около 250 МБ памяти, в то время как UIKit - примерно 90 МБ. Разница почти в три раза.

🔵Hitches (пропущенные кадры). У SwiftUI было около 3,4 хитча в секунду, у UIKit - 0,7. В пять раз меньше.

🔵CPU и батарея. В состоянии покоя SwiftUI загружал процессор на 100%, постоянно. UIKit - опускался до 11%. Энергопотребление у SwiftUI было очень высоким, у UIKit - просто высоким. Термальный профиль SwiftUI быстро полз вверх, и в какой-то момент приложение просто было убито системой из-за перегрева.


💡 Вывод:

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

Интересно, что SwiftUI List внутри использует не обычный UICollectionView, а некую UpdateCoalescingCollectionView, что, видимо, и дает такую разницу. Плюс сама архитектура SwiftUI с пересчетом тела вьюх, диффингом и пересчетом layout добавляет накладные расходы, которых UIKit лишен.

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


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

🍎 Тим Кук уходит. Новая эра Apple - с надеждой на инновации.

Apple официально объявила о смене руководителя. Тим Кук, возглавлявший компанию с 2011 года, с 1 сентября передаст пост CEO Джону Тернусу, который сейчас отвечает за разработку аппаратного обеспечения. Кук останется председателем совета директоров.


Кто такой Джон Тернус:

Тернус пришел в Apple в 2001 году в команду продуктового дизайна. За 25 лет он прошел путь от инженера до старшего вице-президента по аппаратной инженерии. Под его руководством создавались iPad, AirPods, iPhone, Mac и Apple Watch. Он также отвечал за внедрение новых материалов, повышение надежности устройств и снижение углеродного следа.


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

Тернус - инженер до мозга костей. Его назначение сигнализирует, что Apple делает ставку на инновации в аппаратной части. При нем вышли MacBook Neo, iPhone Air, были внедрены 3D-печать титана и новые композитные материалы. В отличие от Кука, который был операционным гением, Тернус - инженер, прошедший все стадии создания продуктов.


Мое мнение:

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


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


💡 Вывод:

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


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

👨‍💻 Apple может удалить ваше приложение без объяснения причин.

Суд в США постановил: Apple имеет право удалять приложения из App Store с указанием причины или без нее. Речь идет о деле стримингового сервиса Musi, который загружал музыку с YouTube, показывал свою рекламу и брал 5,99 доллара за ее отключение. Apple удалила приложение в 2024 году. Musi подала в суд, но проиграла - и не просто проиграла, а с запретом на повторное обращение и с оплатой судебных издержек Apple.


Что решил суд:

Судья отклонил иск с формулировкой, которая теперь станет прецедентом: лицензионное соглашение Apple прямо говорит, что компания может прекратить распространение приложения в любое время, по любой причине или без нее, направив уведомление. Musi не оспаривала, что уведомление получила. Значит, все законно.

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


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

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

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


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


💡 Вывод:

Apple может удалить ваше приложение без объяснения причин. Это законно. Это закреплено в соглашении, которое вы подписали. И теперь это подтверждено судом. Не нравится - не публикуйтесь в App Store. Но других легальных способов установить приложение на iPhone у вас нет.

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


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

👣 Как удалить все неиспользуемые импорты во Flutter-проекте

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


Одна команда, которая все решает:

В корне проекта достаточно выполнить:

dart pub get && dart fix --apply

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

Если хочется сначала посмотреть, что именно будет удалено, можно выполнить dart fix --dry-run. Покажет список изменений, но ничего не тронет.


Почему об этом вообще стоит думать:

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

dart fix решает эту проблему мгновенно. Инструмент официальный, встроенный в экосистему Dart, так что никаких сторонних зависимостей тащить не нужно.


Что важно помнить:

Перед массовой чисткой лучше сделать коммит - мало ли что. Сгенерированные файлы (.g.dart) dart fix трогать не должен, они все равно перезапишутся при следующей сборке. И всегда после чистки стоит прогнать dart analyze && flutter test, чтобы убедиться, что ничего не сломалось.


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


💡 Вывод:

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


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

👨‍💻 Некоторые приложения для iPhone получили загадочное обновление «от Apple».

Недавно пользователи iPhone заметили странное: некоторые приложения получили обновления, но в описании указано не имя разработчика, а Apple. Текст гласит: «Это обновление от Apple улучшит функциональность этого приложения. Новые функции не добавлены».


Какие приложения пострадали:

В списке приложений: Candy Crush Soda Saga, Sentry Mobile, Catan Universe, Bluetti, Mortal Kombat, Duet Display, VLC и многие другие. Категории приложений совершенно разные: игры, утилиты, медиаплееры. Что их объединяет - непонятно.


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

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

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


Догадки:

Разработчики выдвигают несколько предположений:

🔵Технические правки со стороны Apple (например переподпись сертификатами).

🔵Исправление критических уязвимостей, о которых не говорят вслух.

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


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


💡 Вывод:

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


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

🔢 Полный контроль над списками: создаем свою замену List в SwiftUI.

Привет! Наткнулся на статью, где автор разбирает, почему List подходит не для всех случаев. Да, для однородных данных (например списка писем или задач) List незаменим. Но когда интерфейс становится сложнее - появляются разные типы карточек, нестандартные отступы, кастомные фоны - List начинает мешать. Специфичные модификаторы вроде listRowBackground или listRowInsets работают только внутри List и не дают гибкости.

Автор предлагает альтернативу - ScrollView с ленивыми стеками (LazyVStack / LazyHStack). За последние годы SwiftUI значительно подтянул их производительность. Если вы не отображаете сотни тысяч однородных строк, ScrollView - отличный выбор.


Что предлагает автор статьи:

🔵ScrollingSurface - простая обертка над ScrollView и ленивым стеком. Позволяет задать направление прокрутки и выравнивание. Автор использует ее как корневой контейнер для всех экранов своего приложения CardioBot.

🔵DividedCard - карточка с разделителями между дочерними элементами. Использует Group(subviews:) из Container View API, чтобы разобрать переданное содержимое, добавить Divider между элементами и обернуть все в фон с закругленными углами.

🔵SectionedSurface - обрабатывает секции внутри переданного содержимого. Использует ForEach(sections:), чтобы извлечь заголовки, контент и футеры, отфильтровать пустые секции и добавить отступы.

🔵NavigationButtonStyle - кастомный стиль кнопки, который добавляет шеврон справа, как в стандартном NavigationLink внутри List. Это мелочь, но без нее навигация выглядит неполноценно.


Как это собирается вместе:

В итоговом экране автор использует ScrollingSurface как корневой контейнер, внутри - SectionedSurface с секциями, а внутри секций - DividedCard с NavigationLink. Все это покрывается кастомным стилем кнопки. API получается очень похожим на стандартный List, но с полным контролем над внешним видом.


💡 Вывод:

Отказываться от List не нужно - он хорош для своих задач. Но когда интерфейс становится сложным и неоднородным, современный SwiftUI дает инструменты, чтобы построить свою замену. ScrollView с ленивыми стеками и Container View API позволяют создавать переиспользуемые компоненты, которые не уступают List в производительности, но дают полный контроль над дизайном. Если ваш интерфейс перерос стандартный List - присмотритесь к этому подходу.


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

🔢 Новая фича Swift: деманглинг прямо в рантайме.

В будущей версии Swift появится официальный API для деманглинга - преобразования страшных имен вроде $sSS7cStringSSSPys4Int8VG_tcfC в читаемый вид Swift.String.init(cString: Swift.UnsafePointer<Swift.Int8>) -> Swift.String. Это важное изменение для всех, кто пишет инструменты для отладки, профилирования или анализа кода.


Как это работает сейчас:

Сейчас, чтобы получить человеческое имя символа, приходится либо запускать внешний процесс swift-demangle, либо использовать неофициальные внутренние API рантайма. Первый вариант медленный, второй - ненадежный и может сломаться в любой момент.


Решение:

Новый модуль Runtime получит функцию demangle(_:), которая принимает искаженное имя и возвращает строку в читаемом виде или выбрасывает ошибку, если символ невалиден.

Для высокопроизводительных сценариев (например профайлеры, которые обрабатывают тысячи символов в секунду) добавлен второй вариант - запись результата в заранее выделенный буфер через UTF8Span. Это позволяет избежать лишних аллокаций и копирований.


Важное предупреждение:

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


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

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


💡 Вывод:

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


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

📱 ИИ-инженер: почему недостаточно просто уметь общаться с ChatGPT.

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

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


Системный промптинг - не искусство, а инженерия:

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

Новичок попросит: «Напиши код кнопки». Результат будет случайным - где-то SwiftUI, где-то UIKit, с разной логикой.

Инженер строит систему взаимодействия. Он определит роль: «Ты - senior iOS-разработчик».
Задаст формат ответа: «Верни только код SwiftUI без пояснений».
Укажет требования: «Используй модификатор .accessibilityLabel и предусмотри состояния .disabled».
И добавит ограничения: «Не используй устаревшие API iOS 14».

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


Архитектура контекста:

Работа с контекстом - это проектирование информационного пространства. Представьте, что модель это новый сотрудник. Можно бросить его в опенспейс с криками «разберись сам», а можно подготовить рабочее место: положить на стол инструкции, повесить на стену схемы процессов, выделить наставника.

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


Стратегия адаптации:

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

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

🔹RAG (Retrieval-Augmented Generation) - это когда к модели подключают внешнюю память. Представьте врача, который перед ответом листает вашу медицинскую карту. Этот подход нужен, когда важна актуальность данных или работа с приватной информацией - документацией компании, персональными данными пользователя.

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

Выбор зависит от ответов на вопросы: Как часто меняются данные? Насколько критичны ошибки? Каков бюджет?


Защитные барьеры:

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

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


💡 Вывод:

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


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

👨‍💻 Почему ревью в App Store Connect стало занимать недели.

В последнее время все больше iOS-разработчиков сталкиваются с зависшими ревью. Приложения ждут неделями, а то и дольше. Причем проблема носит массовый характер. Разбираемся, что происходит и почему Apple не справляется с потоком.


Почему ревью зависли:

Основная причина - резкий рост числа запросов на проверку. В 2025 году App Store получил около 557 тысяч новых заявок, что на 24% больше, чем в 2024-м. Это первый сильный рост с 2016 года. За первый квартал 2026-го уже 235 тысяч новых приложений. Пользователей больше не стало, а вот приложений - да.


Почему так много новых приложений:

Благодаря ИИ-инструментам порог входа в разработку резко упал. С помощью Claude Code, Codex и аналогичных решений даже непрофессионалы могут создавать рабочие приложения, просто формулируя задачи на естественном языке. На рынок теперь выходят не студии, а одиночные разработчики. Сделать MVP стало дешевле, проверить спрос - проще, а выход на аудиторию через соц. сети - доступнее. Подписочная модель монетиации превращает даже небольшое приложение в полноценный источник дохода.


Что изменилось в процессе ревью:

Apple официально заявляет, что 90% заявок рассматриваются менее чем за 24 часа. Опытные разработчики говорят что доходит до 48 часов. Но часть разработчиков сталкивается с ожиданием в недели. Среднее время остается быстрым, но в сложных или подозрительных приложениях резко увеличивается.


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

Раньше App Review в основном отсеивал баги, приватные API и контентные нарушения. Теперь появилась новая головная боль: приложения, которые с помощью ИИ генерируют или исполняют код, меняющий функциональность после публикации. Это прямое нарушение Guideline 2.5.2. Проверить такое приложение вручную - задача нетривиальная и очень ресурсоемкая.


Что требуют сейчас:

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

🔹Запись видео с реального устройства.

🔹Описание смысла приложения и реальной ценности.

🔹Инструкции по получению доступа к основным функциям.

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


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


💡 Вывод:

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


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

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

🔢 Жизненный цикл SwiftUI View: когда onAppear вызывается не так, как ожидали.

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


Две разные системы:

Чтобы понять, что происходит, нужно разделить два понятия: время жизни узла (node lifetime) и видимость на экране (visibility). Узел живет, пока существует идентичность вью. К узлу привязаны @State и @StateObject. А видимость - это то, видит ли пользователь вью сейчас. onAppear и onDisappear реагируют именно на видимость, а не на создание или уничтожение узла.

В простых случаях эти две шкалы совпадают. Но в сложных контейнерах - расходятся.


TabView - узлы живут, видимость меняется:

Когда вы переключаете вкладки, узлы вью не уничтожаются. Они остаются в памяти, меняется только флаг видимости. Поэтому onAppear срабатывает при каждом переключении на вкладку, но @State сохраняет свое значение.

Нюанс: на iOS 17 TabView создавал все вкладки сразу при запуске. На iOS 18+ - только при первом открытии. Один и тот же код может вести себя по-разному на разных версиях.


NavigationStack - при возврате узел уничтожается:

В навигационном стеке при возврате назад (pop) узел детальной вью уничтожается, а @State сбрасывается. При повторном переходе создается новый узел. В отличие от TabView, здесь данные не сохраняются между показами.


List и LazyVStack - узлы создаются и уничтожаются при скролле:

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


Главное правило - body выполняется до onAppear:

body вычисляется до того, как сработает onAppear или .task. Нельзя полагаться на то, что в onAppear данные подгрузятся до первого вызова body. Нужно всегда предусматривать начальное состояние.


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


💡 Вывод:

onAppear в SwiftUI - это не «вью создана», а «вью стала видимой». Время жизни узла и видимость - это две независимые шкалы. Понимание этого спасает от багов, когда @State вдруг не сбрасывается или, наоборот, сбрасывается не вовремя. Разные контейнеры ведут себя по-разному и это нужно тестировать, а не гадать.


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

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

🔢 Copy-on-Write в Swift: как массивы экономят память.

Всем привет! Наткнулся на статью, где автор подробно разбирает механизм Copy-on-Write (COW) в Swift. Это та самая технология, благодаря которой массивы, строки и словари ведут себя как типы значений, но при этом не создают полные копии больших объемов данных при каждом присваивании.


Что такое COW простыми словами:

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

Это позволяет Swift сохранять семантику значений (изменение одной копии не влияет на другую) без дорогостоящего копирования больших объемов данных.


Как это работает под капотом:

Тип-значение (например ваш массив) хранит ссылку на объект-хранилище (класс). При присваивании копируется ссылка, а не само хранилище. При попытке изменения вызывается метод isKnownUniquelyReferenced(_:), который проверяет, есть ли у хранилища другие ссылки. Если есть - создается новое хранилище с копией данных, и только потом происходит изменение.

Проверить уникальность можно и в своем коде, если вы пишете кастомную COW-структуру.


Как реализовать свой COW-контейнер:

Автор приводит пример SharedBuffer<Element>:

🔹Публичная структура-обертка.

🔹Внутренний класс Storage, хранящий массив элементов.

🔹Метод ensureUniqueStorage(), который копирует хранилище, если на него есть другие ссылки.

🔹Все мутирующие методы сначала вызывают ensureUniqueStorage()

Простой, но эффективный паттерн.


Распространенные заблуждения:

🔹«Структуры автоматически используют COW». Нет. COW - это стратегия реализации конкретных типов (Array, String, Dictionary). Ваши структуры по умолчанию копируются целиком.

🔹«COW рекурсивно копирует все вложенные объекты». Нет. Копируется только само хранилище контейнера. Если внутри лежат ссылочные типы, их изменение не триггерит COW.


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


💡 Вывод:

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


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

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

👣 Два года спустя: как увольнения повлияли на Flutter

Всем привет! Сегодня хочу разобрать интересную статью про судьбу Flutter после увольнений в Google. В апреле 2024 года Google уволил инженеров из команд Flutter, Dart и Python - за несколько недель до Google I/O, где традиционно анонсировали светлое будущее. Тогда было много паники и постов «Flutter умер». Прошло два года. Flutter не умер. Но и не остался прежним. Пора без истерик разобраться, что на самом деле изменилось.


Что тогда произошло:

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


Что случилось потом:

Flutter продолжил выпускать релизы. Impeller стал стабильным. Дорожная карта 2024 года выполнена. BMW, Alibaba и eBay все еще используют Flutter на проде. Опрос Stack Overflow 2024 показал 46% использования среди кроссплатформенных фреймворков - больше, чем у React Native (35%).

Но вот что важно: Тим Снит (многолетний руководитель разработки Flutter, лицо проекта на I/O) ушел в Apple в 2023 году. Брэндон ДеРозье (создатель Impeller) в 2025 году перешел в команду Android XR. Это не увольнения. Это добровольные уходы ключевых людей. И они сигнализируют о том, что даже внутри Google самые талантливые инженеры перестали видеть будущее за Flutter.


Почему я все еще использую Flutter:

Фреймворк работает. Для 90% задач кроссплатформенной разработки - стабильно, быстро, предсказуемо. Сообщество огромное, уже более 50 000 пакетов на pub.dev. Релизы выходят четыре раза в год. С точки зрения инженерной реальности Flutter не стал хуже.

Но соотношение затрат и выгод изменилось. Теперь нужно задавать себе другие вопросы.


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


💡 Вывод:

Используйте Flutter там, где он подходит. Понимайте свои зависимости и риски. Не принимайте архитектурные решения по звездам на GitHub и по рекомендациям от ИИ. Релевантный показатель один: решает ли фреймворк вашу проблему сегодня и есть ли у него разумный путь поддержки на три года вперед. По этому показателю Flutter проходит проверку. Не на отлично. Не так уверенно, как в 2021 году. Но проходит. Те, кто ожидает немедленного краха, ошибаются. Те, кто утверждает, что все осталось по-прежнему, тоже ошибаются. Правда, как обычно, посередине: Flutter - рабочий инструмент, но теперь его стоит выбирать с открытыми глазами, понимая, что уровень поддержки со стороны Google может и дальше снижаться.


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