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

🔢 WWDC26: AsyncImage наконец-то научился кэшировать загруженные изображения.

Всем привет! На WWDC26 показали то, о чем разработчики просили с момента появления AsyncImage в iOS 15 - поддержку кэширования.


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

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

В новой версии достаточно указать политику кэширования в URLRequest:

AsyncImage(request: URLRequest(
    url: imageURL,
    cachePolicy: .returnCacheDataElseLoad
))

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


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


💡 Вывод:

На WWDC26 наконец-то доделали то, что должно было работать с момента появления AsyncImage. Кэширование - базовая вещь, которую в UIKit завезли еще много лет назад. Все это время разработчикам приходилось решать задачу, которая вообще не должна была существовать. Но теперь эта проблема осталась в прошлом.

Седьмой год SwiftUI, а мы все еще радуемся базовым вещам. Но прогресс есть и это здорово.


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

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

📱 Почему менеджеры - главные вайбкодеры в ИТ.

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


Как это работало всегда:

Схема знакома каждому:

🔹Менеджер говорит: «Сделай фичу».

🔹Разработчик пишет код.

🔹Менеджер запускает приложение, жмет кнопки, но код не читает.

🔹Что-то работает не так. Менеджер говорит: «Тут баг».

🔹Разработчик чинит.

🔹Менеджер пробует снова, снова не вникая в код.

🔹«Норм, вливай. Вот тебе еще задача».

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


Почему это не замечали:

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

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


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


💡 Вывод:

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


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

🍎 WWDC 2026: Apple сделала ставку на ИИ. Что изменится в разработке приложений?

В этом году Apple наконец дала разработчикам прямой доступ к Apple Intelligence. Не через косвенные API, а полноценно. На WWDC26 показали новый ИИ-стек, пересобрали Xcode под работу с агентами и заодно обновили платформы.


Коротко про изменения в iOS:

iOS 27 поддерживает устройства от iPhone 11 и новее, приложения запускаются быстрее. Появились детские аккаунты с гибкими ограничениями. Siri получила отдельное приложение, больше контекста и Visual Intelligence. Apple Intelligence работает по смешанной схеме: легкие задачи решают модели прямо на устройстве, а для сложных запросов подключается Gemini в облаке. Shortcuts тоже прокачали - теперь не нужно вручную собирать цепочки действий, достаточно описать словами, что вы хотите сделать, и система сама сгенерирует готовый сценарий.


ИИ-инструменты для разработчиков:

Apple представила новые фреймворки для работы с ИИ.

🔵Foundation Models - расширенный фреймворк для работы с Apple Intelligence. Принимает текст и изображения, поддерживает кастомные ИИ-навыки. Единый Swift API дает доступ и к локальным моделям на устройстве, и к серверным. Пока приложение не стало популярным - пользоваться можно бесплатно.

🔵Core AI - новый фреймворк для запуска сторонних ИИ-моделей локально на Apple Silicon. С сохранением приватности, без отправки данных в облако. Плюс RAG на основе данных из Spotlight.

🔵Private Cloud Compute - для подписчиков iCloud+. Позволяет использовать более мощные серверные модели, сохраняя конфиденциальность.

🔵App Intents - теперь единственный способ подключить приложение к Siri. SiriKit официально объявили устаревшим. Достаточно описать entity и intent-схемы, дальше фреймворк сам мапит запросы пользователя на возможности приложения.


Xcode 27 - агент становится частью IDE:

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

Агент работает в несколько этапов:

🔵discovery - обсуждение идеи прямо в Xcode.

🔵plan - агент собирает контекст и создает Markdown-план. Код не меняется, можно править план руками.

🔵development - агент пишет код по согласованному плану.

🔵verification - тесты, API, пользовательские сценарии на симуляторе, отчет.

🔵crashes - анализ краша в проде, воспроизведение, описание и предложение фикса.

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


Другие изменения в Xcode 27:

🔵Device Hub заменил Simulator. Одно окно для симуляторов и физических устройств. Прямо из окна можно переключать тему, размер шрифта, accessibility-настройки.

🔵Умное автодополнение нескольких строк кода на локальной модели через Apple Silicon.

🔵Выбор внешней ИИ-модели: встроенные интеграции с OpenAI, Anthropic Claude и Google Gemini.

🔵Интеграция с Figma и GitHub прямо из IDE.

🔵Локализация прямо в Xcode. Агент проходит по строкам, создает String Catalog, переводит UI с учетом контекста использования.

🔵Top Functions в Instruments - показывает, какие функции больше всего грузят систему.

🔵Обновленный Organizer - не просто показывает, что сломалось, а пытается подсказать, как чинить.


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


💡 Вывод:

WWDC 2026 задала направление: Apple окончательно открыла свой ИИ-стек разработчикам, перевела Siri на App Intents и встроила агентов в Xcode. Теперь не нужно гадать, как подключиться к Apple Intelligence - есть официальные API. Агент в Xcode не заменит разработчика, но возьмет на себя грязную работу. При этом Apple не забыла про производительность SwiftUI, работу с памятью и инструменты отладки. ИИ становится не фичей, а частью инструментария. И чем аккуратнее у вас проект, тем больше вы выиграете от нового Xcode.


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

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

🔢 Решение проблем при конфликтах жестов в SwiftUI.

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


Маска жеста - кто вообще имеет право слышать касание:

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

Тут вступает GestureMask. Это параметр модификатора .gesture(including:), который определяет, насколько глубоко в иерархии отслеживается ваш жест:

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

🔹.gesture - жест активен только на той вью, где его добавили. Дети и родители не реагируют. Это поведение по умолчанию.

🔹.subviews - жест срабатывает, только если касание началось в дочерних вью. Неожиданный сценарий, но иногда полезен.

🔹.none - все жесты глубже по иерархии отключаются.


Кто главный на сцене - приоритеты внутри одной вью:

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

Решение - highPriorityGesture(_:including:). Этот модификатор говорит: «Этот жест важнее всех остальных на этой вью». Как только он начал распознаваться, остальные отменяются.


Как переспорить системные жесты - свайп назад и другие навязчивые привычки iOS:

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

Модификатор .defersSystemGestures(on:) решает эту проблему. Он говорит системе: «Подожди, сначала пусть моя вью решит, что делать с этим свайпом». Если ваша вью не воспользовалась жестом (например, палец сместился меньше порога), тогда система запускает свой.


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


💡 Вывод:

GestureMask, highPriorityGesture и defersSystemGestures - нужны только тогда, когда стандартное поведение SwiftUI не справляется. Пока на экране один жест на одну кнопку, все работает и без них. Но как только появляются вложенные вью и конкурирующие жесты, начинается хаос. Здесь главное не переборщить. Не надо лепить .all и высокие приоритеты везде подряд, иначе жесты начнут срабатывать там, где не должны, а пользователь решит, что приложение глючит.


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

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

🔢 Swift 6.4: UniqueBox, Ref и MutableRef - новый взгляд на управление памятью.

В Swift 6.4 добавили три новых типа: UniqueBox, Ref и MutableRef. Раньше похожие задачи решались либо через классы с их счетчиками ссылок, либо через небезопасные указатели. Новые типы дают больше контроля над памятью и избавляют от лишних накладных расходов, оставаясь при этом в рамках стандартной модели безопасности Swift - без выхода в низкоуровневое программирование и без принудительного использования указателей.


Какая проблема была раньше:

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


UniqueBox - коробка с одним хозяином:

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


Ref - доступ на чтение:

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


MutableRef - доступ на запись:

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


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


💡 Вывод:

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

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


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

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

👨‍💻 Резюме больше не читают: как теперь ищут работу в ИТ.

Business Insider опубликовал неутешительную новость для тех, кто привык рассылать свое резюме на каждую открытую вакансию. Крупные компании открыто пишут в требованиях: «резюме не нужно, мы их не читаем». Причина банальна - ChatGPT сделал из всех кандидатов идеальных клонов. Рекрутеры тонут в одинаковых документах, а на собеседованиях выясняется, что за красивыми формулировками пустота. Доверие к резюме рухнуло окончательно.


Что пришло на смену:

Цифры говорят сами за себя: 70% работодателей уже перешли на найм, где оценивают только реальные навыки. Дипломы и громкие имена компаний в резюме больше не работают. Платформы подстраиваются, например LinkedIn теперь верифицирует навыки через интеграцию с реальными инструментами, а Indeed запустил мгновенные видеособеседования прямо в момент отклика.


Как теперь искать работу:

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

🔹Личный блог. Даже на 100-200 подписчиков. Это живое доказательство того, что вы разбираетесь в теме. Посты, разборы, кейсы - все это работает как портфолио, которое нельзя подделать.

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

🔹Прямые сообщения. Находите нанимающих менеджеров в социальных сетях и пишите им лично. Без спама, по делу, с конкретным предложением ценности.

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

🔹Активность на GitHub. Комментирование чужого кода, участие в open-source, пул-реквесты - все это видно. Рекрутеры сами находят таких разработчиков, потому что они не прячутся за резюме, а показывают себя в деле.


💡 Вывод:

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


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

🔢 Прекратите использовать .onAppear для вызовов запросов к API в SwiftUI.

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


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

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

Еще хуже с отменой задач. Когда вы пишете Task { await loadData() } внутри .onAppear, вы создаете неструктурированную задачу. Если пользователь закрыл экран до завершения запроса, задача продолжает висеть в памяти. Результат - утечки, лишний трафик, проблемы с батареей.

Можно добавить ручную отмену в .onDisappear, но это лишний код, который легко забыть. А еще классическая проблема - куча флагов isLoading, error, data. Они независимы, и интерфейс может перейти в противоречивое состояние: например, одновременно крутится лоадер и показывается ошибка.


Что использовать вместо этого:

Вместо трюков с флагами нужно ввести конечный автомат - перечисление, которое описывает все возможные состояния экрана:

🔹.idle - еще ничего не началось.

🔹.loading - идет загрузка.

🔹.loaded(User) - данные получены.

🔹.error(Error) - произошла ошибка.

Это гарантирует, что в каждый момент времени экран может находиться только в одном состоянии. Никакой путаницы. Бизнес-логику выносим в отдельную ViewModel (класс с @Observable). В ней один метод, который меняет состояние.


Почему .task лучше:

В представлении вместо .onAppear используем модификатор .task потому что он:

🔹Работает с async/await из коробки - не нужно вкладывать задачу в Task { }.

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

🔹Не требует ручной отмены в .onDisappear.


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


💡 Вывод:

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


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

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

🔢 Магия Pattern matching в Swift.

В Swift есть несколько способов работать с ассоциированными значениями enum, и if case let - один из самых полезных, но его синтаксис часто путают. Давайте разберемся, как он работает и в каких случаях помогает писать чище.


Что такое case let и зачем он нужен:

Обычный if проверяет булево условие. Но если у вас enum с ассоциированными значениями, просто проверить тип недостаточно - нужно еще достать эти значения. Для этого есть if case let. Это сокращенная форма switch, когда вас интересует только один кейс.

Синтаксис может показаться непривычным: сначала идет if case let, потом шаблон, потом знак равенства и значение, которое вы проверяете.


Связывание значений:

Самый простой случай - извлечь все ассоциированные значения:

if case let Puppy.mastiff(droolRating, weight) = fido {
    print("Рейтинг слюнявости: \(droolRating), вес: \(weight)")
}

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

if case Puppy.mastiff(let droolRating, let weight) = fido {
    print("Рейтинг слюнявости: \(droolRating), вес: \(weight)")
}

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

if case let Puppy.mastiff(characteristics) = fido {
    print(characteristics) // (droolRating, weight)
}

Работа с опционалами:

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

if case let Puppy.mastiff(droolRating, weight)? = optionalPuppy {
    // выполнится, только если optionalPuppy не nil и это кейс mastiff
}

Когда значения не нужны:

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

if case Puppy.mastiff = fido {
    print("Это мастиф, какая разница какой?)
}

Добавление условий:

С помощью запятой можно добавить дополнительные проверки:

if case let Puppy.mastiff(droolRating, _) = fido, droolRating > 8 {
    print("Диван пропал")
}

То же работает с guard:

guard case let Puppy.mastiff(droolRating, _) = fido, droolRating < 10 else {
    print("В дом не пущу")
}

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


💡 Вывод:

if case let - мощный инструмент для работы с enum, который делает код короче и понятнее, чем вложенные switch. Он особенно полезен, когда нужно обработать один конкретный кейс из нескольких, связать его значения и добавить условия. Освоив этот синтаксис, вы перестанете писать лишние switch для простых проверок.


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

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

🖼 Первые шаги в освоении шейдеров Metal.

Всем привет! Сегодня хочу поговорить о Metal шейдерах в SwiftUI. Это код, который выполняется прямо на графическом процессоре и определяет цвет каждого пикселя. В отличие от обычных анимаций (которые работают на уровне вьюх), здесь управление идет попиксельно. Звучит сложно, но разобраться можно довольно быстро. Есть отличная статья на эту тему, предлагаю остановиться на ней подробнее. В ней объясняют основы Metal шейдеров в SwiftUI с простыми и понятными примерами.


Подробнее о шейдерах:

Шейдер выполняется для каждого пикселя на экране. Если у вас прямоугольник 300×300 пикселей, шейдер вызовется 90 000 раз. GPU справляется с этим легко, потому что он создан для параллельных вычислений.

В SwiftUI вы просто говорите «сделай этот прямоугольник синим», и фреймворк сам решает, как закрасить пиксели. С Metal вы сами пишете код, который определяет цвет каждого пикселя. Сложнее, но зато вы контролируете каждый пиксель.


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

Процесс простой:

🔹Создаете .metal файл в проекте.

🔹Пишете функцию шейдера с атрибутом [[ stitchable ]].

🔹Xcode сам генерирует ShaderLibrary.

🔹Применяете шейдер через .colorEffect().

Никакой ручной связки не нужно - Xcode все делает автоматически.


Первый пример - сплошной цвет:

#include <metal_stdlib>
#include <SwiftUI/SwiftUI.h>
using namespace metal;

[[ stitchable ]] half4 basicColor(float2 position, half4 currentColor) {
    return half4(0.2, 0.6, 0.9, 1.0);
}

Функция получает координаты пикселя и текущий цвет, но игнорирует их и возвращает один и тот же синий для всех пикселей. В SwiftUI это применяется одной строкой: .colorEffect(ShaderLibrary.basicColor()).


Второй пример - градиент от позиции:

[[ stitchable ]] half4 gradient(float2 position, half4 currentColor) {
    float normalizedX = position.x / 300.0;
    float normalizedY = position.y / 300.0;
    
    half r = half(normalizedX);
    half g = half(normalizedY);
    half b = half(1.0 - normalizedX);
    
    return half4(r, g, b, 1.0);
}

Здесь координаты пикселя нормализуются (приводятся к диапазону 0-1), а затем используются как цветовые компоненты. Красный растет слева направо, зеленый - сверху вниз, синий убывает слева направо. Получается красивый градиент.


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


💡 Вывод:

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


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

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

👨‍💻 Конец паники: почему ИИ не убьет ИТ, а сделает его сильнее.

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


Миф о замене - почему ИИ не станет вашим начальником:

Основное заблуждение - что ИИ сможет полностью автономно решать сложные бизнес-задачи. В реальности ИИ, особенно LLM (Large Language Models) - это продвинутый статистический инструмент, который генерирует вероятные последовательности слов на основе обученных данных. Он не понимает контекст, не обладает критическим мышлением и не может заменить человеческую способность к коммуникации, выявлению скрытых потребностей и творческому решению проблем.

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


Эволюция, а не революция:

🔹CASE-инструменты (вроде Rational Unified Process) обещали генерацию кода из диаграмм. Итог: их используют как вспомогательные средства, а код все равно пишут люди.

🔹SQL создавался для бухгалтеров, чтобы они сами делали запросы. Итог: SQL стал инструментом программистов.

🔹Конструкторы сайтов (вроде WordPress) не уничтожили веб-разработку, а создали огромный рынок для кастомизации, плагинов и сложных интеграций.

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


Парадокс спроса - почему автоматизация создает больше рабочих мест:

Логика «один программист с ИИ сделает работу пяти, значит, программистов нужно в пять раз меньше» - ошибочна. Экономика работает иначе:

🔹Снижается порог рентабельности задач. То, что раньше было невыгодно автоматизировать (слишком дорого), с ИИ становится целесообразным.

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

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

Проще говоря, ИИ не сокращает количество работы, он увеличивает объем работы, которую бизнес готов и может заказать.


Новая карта компетенций:

В новой реальности ценность смещается:

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

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

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


💡 Вывод:

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

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

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


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

🔢 Как выбрать архитектуру для iOS-проекта и не совершить ошибку.

Привет! Многие команды до сих пор внедряют сложные архитектуры вроде VIPER или Clean Architecture, считая их стандартом индустрии. Проблема в том, что эти решения часто не закрывают реальные проблемы проекта, зато увеличивают объем кода, замедляют сборку и усложняют онбординг новых разработчиков. Автор статьи проанализировал 147 проектов и результаты этого анализа выглядят довольно интересно.


Что говорят цифры:

Распределение архитектур среди проектов выглядит так: MVVM лидирует с 41%, MVC на втором месте с 34%, VIPER и Clean Architecture занимают 18%, TCA - 5%.

Главная проблема в том, что 73% проектов используют архитектуры, которые не решают их реальных проблем. Внедрение Clean Architecture в средних командах приводит к росту кода на 143%, замедлению разработки на 67% и увеличению времени онбординга новых разработчиков до трех недель.


Архитектуры и их зоны ответственности:

🔹MVC отлично подходит для команд из 1-3 человек и простых приложений. Проблема массивного контроллера возникает не из-за самой архитектуры, а из-за неумения выделять сервисы - в 89% проблемных приложений причина именно в этом.

🔹MVVM - золотая середина для команд 3-10 человек, особенно в связке с SwiftUI. Покрытие тестами вырастает до 67% (против 23% в MVC) при умеренном росте кодовой базы (+35%).

🔹VIPER и Clean Architecture оправданы только для команд от 15 человек, особенно в финансовых или медицинских приложениях, где цена ошибки измеряется миллионами. Плата за это - избыточный код: одна фича может занимать 7 файлов и 730 строк кода против 3 файлов и 260 строк в MVVM.

🔹TCA подходит для команд уровня Senior, которым нужна 100% тестируемость и предсказуемое состояние. Но порог входа высок - 2-3 месяца обучения, плюс возможные проблемы с производительностью.


Как не ошибиться с выбором:

Автор статьи рекомендует придерживаться такой формулы при выборе верной архитектуры:

🔹Для стартапа или MVP (1-3 разработчика) - SwiftUI с простым MVVM. Приоритет на скорость.

🔹Для среднего приложения (4-8 разработчиков) - MVVM + Coordinator + DI.

🔹Для корпоративных приложений (10+ разработчиков) - Clean Architecture или модульный MVVM. Приоритет на масштабируемость.


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


💡 Вывод:

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


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

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

🔢 Модуляризация iOS-приложений через SPM: как навести порядок в зависимостях.

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


Три слоя, один поток зависимостей:

Автор делит все приложение на три уровня:

🔹Common - самые низовые утилиты: логгеры, расширения, хелперы. Не зависят ни от чего внутри проекта.

🔹Services - два подмодуля: API (сетевые модели и эндпоинты) и Domain (бизнес-логика, сервисы, моки). Domain зависит от API и Common.

🔹Features - экраны на SwiftUI. Импортируют только Domain и Common. Никогда - API.

Зависимости текут строго снизу вверх. Модуль может зависеть только от того, что лежит под ним.


Как это выглядит в Package.swift:

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


Что в каждом модуле:

🔹API - только модели, которые зеркалируют ответ сервера, и типизированные эндпоинты.

🔹Domain - здесь происходит основная работа: модели предметной области, маппинг из API-моделей в доменные, сервисы (closure-based, без протоколов) и моки. Моки тоже живут здесь, потому что они возвращают доменные модели, а не API-шные.

🔹Features - чисто UI. Импортируют только Domain, используют моки для превью. Никакого сетевого слоя внутри.


ServiceEnvironment для массовой инъекции:

Когда сервисов становится больше двух, можно использовать контейнер ServiceEnvironment, который собирает все сервисы в одну структуру. Через кастомный модификатор все прокидывается в окружение одной строкой. Превью используют .mock, приложение - .live.


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


💡 Вывод:

Модуляризация через локальные SPM-пакеты - это не про идеальную архитектуру ради архитектуры. Это про скорость и масштабируемость. Начинать лучше с малого: вынести сначала Domain, потом API, а фичи - по мере роста. Результат - приложение, где новый разработчик за пять минут понимает структуру, а CI не ждет десять минут на сборку.


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

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

🔢 NSCache в Swift: как правильно кэшировать и не бояться утечек памяти.

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


В чем подвох:

NSCache пришел из Objective-C, поэтому и ключи, и значения должны быть ссылочными типами (AnyObject). String и Int так просто не положить - нужно оборачивать в NSString или NSNumber. На практике это неудобно, но решается оберткой.


Как сделать удобную обертку:

Можно написать generic-класс Cache<Key: Hashable, Value>, который внутри хранит NSCache<WrappedKey, Entry>. WrappedKey - класс-обертка для ключа, Entry - для значения. Благодаря этому можно будет работать с обычными типами (String, Int и другими структурами).


Важные ограничения:

На проде почти всегда нужно задавать countLimit и totalCostLimit. Иначе кэш может незаметно разрастись и занять всю память. totalCostLimit - примерная граница суммарного размера объектов. cost при вставке - абстрактная метрика. Для изображений можно использовать width * height, для текста - count (length). Главное, чтобы более объемные объекты удалялись из кэша в первую очередь.


Когда NSCache подходит:

🔹Кэширование изображений в таблицах и коллекциях.

🔹Результаты разбора Markdown в NSAttributedString.

🔹Тяжелые вычисления (фильтры, предикты).

🔹Результаты парсинга, которые не критично потерять.


Когда не подходит:

🔹Данные, которые должны переживать перезапуск приложения (здесь нужно сохранять в память).

🔹Кэш с TTL (временем жизни).

🔹Сетевые ответы с управлением через заголовки (для этого есть URLCache).


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


💡 Вывод:

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


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

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

👣 Flutter отказывается от CocoaPods в пользу Swift Package Manager

Начиная с релиза Flutter 3.44, Swift Package Manager (SwiftPM) заменяет CocoaPods как стандартный менеджер зависимостей для iOS и macOS. Это означает, что больше не нужно возиться с установкой Ruby или настройкой CocoaPods, чтобы просто запустить приложение.


Почему CocoaPods уходит:

CocoaPods официально переведен в режим поддержки без активного развития. Его реестр станет доступен только для чтения 2 декабря 2026 года. Существующие сборки продолжат работать, но новые версии пакетов добавляться уже не будут. Flutter переходит на решение, которое официально поддерживает Apple, чтобы приложения продолжали получать обновления зависимостей и имели доступ к экосистеме Swift-пакетов.


Что будет с приложениями:

Flutter CLI автоматизирует переход. При сборке или запуске iOS / macOS приложения CLI сам обновит Xcode-проект для использования SwiftPM. Если приложение использует плагины, которые еще не перешли на SwiftPM, Flutter выдаст предупреждение и временно использует CocoaPods для таких плагинов.

В случае критических проблем можно временно отключить SwiftPM в pubspec.yaml:

flutter:
  config:
    enable-swift-package-manager: false

Но компания просит сообщать о таких проблемах, чтобы успеть их исправить до полного удаления CocoaPods.


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


💡 Вывод:

Переход на SwiftPM - неизбежный шаг. CocoaPods устарел, и поддержка его заканчивается. Для разработчиков приложений процесс в основном автоматический. А вот авторам плагинов предстоит работа - иначе их пакеты станут несовместимыми и потеряют позиции на pub.dev. Лучше заняться этим сейчас, а не ждать, когда CocoaPods окончательно отключат.


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

🔨 Time Profiler: повышение производительности с помощью ИИ.

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


Кейс - ускорение в 25 раз:

Автор взял конкретную задачу - загрузку accessibility-элементов в RocketSim. На одном экране с 70+ элементов это занимало 12 секунд. Вместе с ИИ-агентом они прошли несколько итераций:

🔹12 с -> 4 с (в 3 раза быстрее).

🔹4 с -> 2,5 с (еще в 2 раза).

🔹2,5 с -> 525 мс (в 23 раза).

🔹525 мс -> 485 мс (финальные 25 раз).

Ключевой момент: если бы остановились на первой итерации, решив, что «и так неплохо», результат был бы в 25 раз хуже.


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

У автора уже был CLI для RocketSim. ИИ-агент мог запускать его до и после изменений, сравнивать результаты и отменять правки, если стало хуже. Для анализа использовался Time Profiler с добавленными signpost (чтобы код был виден в инструменте).


Процесс выглядит так:

🔹Агент вносит изменения в код.

🔹Разработчик запускает приложение в Instruments с шаблоном Time Profiler и signpost.

🔹Копирует результаты (интервалы signpost и глубокую копию Time Profiler).

🔹Отдает агенту с запросом: «Проанализируй и предложи план дальнейших оптимизаций».

🔹Цикл повторяется, пока агент не скажет, что быстрее уже не сделать.


Кому может быть полезно:

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

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

🔹Разработчикам инструментов и SDK, где важна скорость работы (CLI, accessibility, обработка больших объемов данных).


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


💡 Вывод:

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


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

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

👨‍💻 ИИ-агенты в App Store: Apple ищет компромисс между трендом и безопасностью.

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


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

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

Кроме того, есть риск обхода комиссии и потери контроля над монетизацией. Если агент может создать приложение на лету и запустить его, минуя App Store, Apple теряет и деньги и возможность проверить, что этот код безопасен.


Что предложит Apple:

По данным источников, компания разрабатывает специальную систему, которая позволит агентам работать в рамках экосистемы, но под строгим контролем. Основная цель - предотвратить хаотичное поведение, когда агент выходит из-под контроля (например как в случае с OpenClaw, где бот удалял всю почту пользователя).

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

Ожидается, что подробности появятся на WWDC в июне. Но источники допускают, что компания может быть еще не готова к полноценному анонсу.


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


💡 Вывод:

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


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

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

🔢 MapKit: работа с картами в SwiftUI.

SwiftUI и MapKit постепенно сближаются. Если раньше для работы с картами приходилось писать код на UIKit и оборачивать его в UIViewRepresentable, то теперь для этого есть нативный Map view. Разбираем, какие возможности появились и как их использовать.


Базовое отображение:

Самый простой способ - добавить карту одной строкой: Map(). Она автоматически заполнит доступное пространство. Ее можно оформлять как любой другой SwiftUI-компонент: добавлять скругление углов через .cornerRadius, ограничивать размер через .frame, настраивать отступы.


Настройка камеры:

Управлять тем, что видит пользователь, можно через MapCameraPosition. Камеру можно задать один раз при создании карты (параметр initialPosition) или связать с @State через двухсторонний биндинг (position), чтобы менять положение динамически.

Камера настраивается через MKMapCamera: указывается центр, расстояние, угол наклона (pitch) и направление (heading). Все это упаковывается в MapCamera, затем в MapCameraPosition.camera.


Ограничение видимой области:

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


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

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


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


💡 Вывод:

Работа с картами в SwiftUI стала гораздо удобнее. Нативный Map view покрывает большинство сценариев: от простого отображения до управления камерой и ограничения видимой области. Если нужны совсем экзотические возможности, можно опуститься до UIKit-оберток, но в 90% случаев встроенных средств достаточно.


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

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

👨‍💻 Почему агенты пишут плохой код.

Вокруг ИИ-агентов для разработки сформировался странный парадокс. Одни заявляют, что не писали код руками полгода и полностью делегируют задачи машине. Другие клянутся, что агенты глупые и не способны на что-то сложнее «Hello World». Оба мнения честны и оба - об одном и том же инструменте. Разрыв в результатах говорит не о качестве технологии, а о катастрофической разнице в подходе к ее использованию. Успех определяет не сам агент, а навык, стоящий за промптом.


Проблема не в инструменте, а в операторе:

Ключевое заблуждение - ожидать от агента волшебства. Это не искусственный общий интеллект, который читает мысли. Это сложный, но ограниченный инструмент, который действует строго по инструкции. Разница между командами «напиши код» и «напиши на Swift функцию, которая асинхронно загружает JSON по URL, обрабатывает ошибки сети и парсит результат в структуру User с полями id и name, используя современный async/await синтаксис» - это разница между хаотичным выводом и рабочим решением.


Главный навык - умение формулировать, а не писать код:

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

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

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

🔹Предвосхищение: прогнозирование потенциальных недопониманий и упреждающее их устранение в формулировке задачи.


Провальные паттерны коммуникации:

Большинство неудач происходят по шаблонным сценариям:

🔹Слишком абстрактно: «Сделай красивый интерфейс». Агент не понимает, что такое «красивый» в вашем контексте.

🔹Без контекста: «Пофикси баг». Агент не знает кодобазы, архитектуры и истории проблемы.

🔹Противоречиво: «Код должен быть быстрым и читаемым, но еще и очень компактным». Это взаимоисключающие требования на этапе реализации.


Стратегия эффективного промптинга:

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

🔹Роль: «Ты senior iOS-разработчик, специализирующийся на оптимизации производительности».

🔹Цель: «Мне нужно реализовать фичу А в контексте Б для достижения цели В».

🔹Контекст: «Вот текущая архитектура проекта, вот основные принятые в проекте требования».

🔹Ограничения: «Нельзя использовать библиотеку X, минимальная версия iOS - 15, код должен проходить линтер с настройками Y».

🔹Критерии успеха: «Код считается успешным, если он покрыт unit-тестами на 90%, не вызывает ошибок и соответствует всем указанным требованиям».

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


💡 Вывод:

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


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

🔨 Agent Skills для ускорения сборки Xcode.

Наткнулся на статью, где автор рассказывает о наборе Agent Skills для оптимизации времени сборки Xcode. Понимаю, что к ИИ-инструментам многие относятся скептически, но здесь речь не о написании кода за вас, а об экономии времени.


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

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


Что такое нулевая сборка и почему это показатель:

Отдельное внимание уделено сборке без изменений (zero-change build). Это когда вы ничего не меняли в коде, а Xcode все равно что-то пересобирает. У одного из проектов такая сборка занимала 70 секунд. После оптимизации - 9 секунд. Разница в 87%.


Как устроен скилл:

Это не один инструмент, а целый оркестр из шести специализированных скиллов:

🔹Оркестратор запускает весь процесс и направляет.

🔹Бенчмарк делает три чистые и три инкрементальные сборки, сохраняет результаты в JSON.

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

🔹План оптимизации формируется на основе анализа и представляется разработчику для утверждения.

🔹Применение изменений происходит автоматически, но только после вашего согласия.

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


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

Скилл проверяет:

🔹Настройки компилятора и линкера.

🔹Конфигурацию Swift Package Manager.

🔹Build phases (скрипты, копирование ресурсов).

🔹Сложность кода (например долгие компиляции конкретных файлов).

🔹Включение кэширования компиляции (Compilation Caching).


Результаты на реальных проектах:

Автор приводит данные трех приложений:

🔹Helm: чистая сборка почти без изменений (в пределах погрешности), инкрементальная ускорилась на 87% (с 70 до 9 секунд).

🔹Stock Analyzer: чистая сборка быстрее на 20%, инкрементальная - на 32%.

🔹Enchanted: чистая сборка быстрее на 14%, инкрементальная - на 12%.


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


💡 Вывод:

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


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

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

🍏 Разработчики Apple забыли удалить инструкции для ИИ перед релизом приложения.

В обновлении приложения Apple Support (версия 5.13) пользователи обнаружили файлы claude.md. Разработчики быстро это заметили и в следующем обновлении файлы убрали, но интернет все помнит.


Что это за файл:

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


Что это значит для Apple:

Самое интересное - не то, что Apple использует ИИ для разработки (это уже никого не удивляет), а то, что они используют Claude от Anthropic, а не свои внутренние наработки. Это сигнал: даже в Apple предпочитают готовые решения от сторонних разработчиков, когда речь заходит о современных ИИ-инструментах.

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


Почему это обсуждают:

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


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


💡 Вывод:

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


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

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