Недавно пользователи iPhone заметили странное: некоторые приложения получили обновления, но в описании указано не имя разработчика, а Apple. Текст гласит: «Это обновление от Apple улучшит функциональность этого приложения. Новые функции не добавлены».
Какие приложения пострадали:
В списке приложений: Candy Crush Soda Saga, Sentry Mobile, Catan Universe, Bluetti, Mortal Kombat, Duet Display, VLC и многие другие. Категории приложений совершенно разные: игры, утилиты, медиаплееры. Что их объединяет - непонятно.
Что говорят разработчики:
Один из разработчиков на Reddit сообщил, что Apple выпустила обновление его приложения с тем же номером версии и тем же содержимым, что и предыдущее. То есть технически ничего не изменилось, а обновление вышло.
Эксперты проанализировали код одного из таких приложений - и не нашли никаких изменений. Никаких исправлений уязвимостей, никаких новых функций, никаких правок.
Догадки:
Разработчики выдвигают несколько предположений:
Apple тихо, но уверенно обновляет приложения в App Store от своего имени. Что именно она меняет - неясно. Разработчики, чьи приложения попали под это, похоже, тоже не в курсе. Пока это выглядит как техническая необходимость, а не как злоупотребление. Но сам прецедент заставляет задуматься: Apple может влиять на приложения на вашем телефоне даже без участия их создателей.
Мобильный трудоголик
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯19🤔8👍4👀3❤1🙏1
Привет! Наткнулся на статью, где автор разбирает, почему List подходит не для всех случаев. Да, для однородных данных (например списка писем или задач) List незаменим. Но когда интерфейс становится сложнее - появляются разные типы карточек, нестандартные отступы, кастомные фоны - List начинает мешать. Специфичные модификаторы вроде listRowBackground или listRowInsets работают только внутри List и не дают гибкости.
Автор предлагает альтернативу - ScrollView с ленивыми стеками (LazyVStack / LazyHStack). За последние годы SwiftUI значительно подтянул их производительность. Если вы не отображаете сотни тысяч однородных строк, ScrollView - отличный выбор.
Что предлагает автор статьи:
Как это собирается вместе:
В итоговом экране автор использует ScrollingSurface как корневой контейнер, внутри - SectionedSurface с секциями, а внутри секций - DividedCard с NavigationLink. Все это покрывается кастомным стилем кнопки. API получается очень похожим на стандартный List, но с полным контролем над внешним видом.
Отказываться от List не нужно - он хорош для своих задач. Но когда интерфейс становится сложным и неоднородным, современный SwiftUI дает инструменты, чтобы построить свою замену. ScrollView с ленивыми стеками и Container View API позволяют создавать переиспользуемые компоненты, которые не уступают List в производительности, но дают полный контроль над дизайном. Если ваш интерфейс перерос стандартный List - присмотритесь к этому подходу.
Мобильный трудоголик
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17
В будущей версии Swift появится официальный API для деманглинга - преобразования страшных имен вроде $sSS7cStringSSSPys4Int8VG_tcfC в читаемый вид Swift.String.init(cString: Swift.UnsafePointer<Swift.Int8>) -> Swift.String. Это важное изменение для всех, кто пишет инструменты для отладки, профилирования или анализа кода.
Как это работает сейчас:
Сейчас, чтобы получить человеческое имя символа, приходится либо запускать внешний процесс swift-demangle, либо использовать неофициальные внутренние API рантайма. Первый вариант медленный, второй - ненадежный и может сломаться в любой момент.
Решение:
Новый модуль Runtime получит функцию demangle(_:), которая принимает искаженное имя и возвращает строку в читаемом виде или выбрасывает ошибку, если символ невалиден.
Для высокопроизводительных сценариев (например профайлеры, которые обрабатывают тысячи символов в секунду) добавлен второй вариант - запись результата в заранее выделенный буфер через UTF8Span. Это позволяет избежать лишних аллокаций и копирований.
Важное предупреждение:
Формат деманглинга не гарантирует стабильности. В следующих версиях Swift вывод может измениться - добавится больше информации, уберется что-то неважное, изменится порядок слов. Полагаться на точный формат вывода нельзя. Использовать деманглинг можно только для отображения человеку, но не для автоматической обработки результатов.
Кому это может пригодиться:
Разработчикам инструментов статического анализа, профилировщиков, логгеров и систем сбора ошибок. Всем, кто сейчас вынужден запускать внешние процессы или дергать нестабильные внутренние API.
Официальный деманглинг в рантайме - давно назревшее изменение. Оно упростит жизнь создателям инструментов и уберет необходимость в хаках. Но использовать его нужно с осторожностью: формат вывода может меняться от версии к версии, и полагаться на него как на стабильный API не стоит.
Мобильный трудоголик
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12
Forwarded from Кот Денисова
Мы живем в эпоху, когда искусственный интеллект перестал быть лабораторной диковинкой и стал рабочим инструментом. Но вместе с этим изменилась и роль разработчика, который работает с ИИ. Сегодня «ИИ-разработчик» - это не тот, кто мастерски формулирует запросы к ChatGPT. Это инженер, способный превращать исследовательские модели в надежные, масштабируемые системы, которые работают в реальных условиях и приносят бизнес-ценность.
Если раньше разработчик писал четкие правила и алгоритмы, то теперь он проектирует условия, в которых модель принимает правильные решения. Это смена парадигмы: от детерминированного программирования к вероятностному системному мышлению.
Системный промптинг - не искусство, а инженерия:
Многие ошибочно считают промтинг чем-то вроде магии или искусства общения. На самом деле, это инженерная дисциплина. Хороший промпт - это не просто вопрос, это структурированное техническое задание для модели. Разница между любителем и профессионалом видна в подходе к формулировкам.
Новичок попросит: «Напиши код кнопки». Результат будет случайным - где-то SwiftUI, где-то UIKit, с разной логикой.
Инженер строит систему взаимодействия. Он определит роль: «Ты - senior iOS-разработчик».
Задаст формат ответа: «Верни только код SwiftUI без пояснений».
Укажет требования: «Используй модификатор .accessibilityLabel и предусмотри состояния .disabled».
И добавит ограничения: «Не используй устаревшие API iOS 14».
Такая спецификация превращает генерацию из лотереи в предсказуемый процесс. Ключевой навык здесь - умение декомпозировать задачу и формализовать требования так, чтобы их мог выполнить не человек, а статистическая модель.
Архитектура контекста:
Работа с контекстом - это проектирование информационного пространства. Представьте, что модель это новый сотрудник. Можно бросить его в опенспейс с криками «разберись сам», а можно подготовить рабочее место: положить на стол инструкции, повесить на стену схемы процессов, выделить наставника.
Для ИИ это выглядит как структурирование данных перед отправкой. Вместо свалкой истории переписки инженер отправляет четкие блоки: системную инструкцию с ролью, правила безопасности, профиль пользователя, релевантные данные из базы знаний, историю сессии в формализованном виде.
Стратегия адаптации:
Перед ИИ-инженером всегда стоит выбор: как адаптировать модель под конкретную задачу. Здесь нет серебряной пули, есть компромиссы.
Выбор зависит от ответов на вопросы: Как часто меняются данные? Насколько критичны ошибки? Каков бюджет?
Защитные барьеры:
Модель может сгенерировать что угодно: от гениального кода до опасного совета. Инженер обязан построить систему безопасности. Это не доверие, а верификация.
На практике барьеры работают как фильтры. Валидация вывода: перед применением сгенерированного кода он проверяется компилятором или линтером. Модерация контента: текст анализируется на предмет токсичности. Ограничение домена: модель явно инструктируют не отвечать на вопросы вне своей компетенции.
Эволюция от пользователя ИИ к ИИ-инженеру - это путь от тактики к стратегии, от единичных запросов к проектированию целых экосистем. Ключевой навык нового времени - не умение «договориться с моделью», а способность создавать среды, где эти модели работают предсказуемо, безопасно и эффективно.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14💯11👍4🤔1👀1🤝1
В последнее время все больше 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 пытается ужесточить требования, но процесс отладки новых правил занимает время. Разработчикам остается только закладывать больше времени на публикацию новых приложений и готовить максимально полную документацию заранее.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13👍11🙏3🤯1👀1
На первый взгляд, 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 вдруг не сбрасывается или, наоборот, сбрасывается не вовремя. Разные контейнеры ведут себя по-разному и это нужно тестировать, а не гадать.Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13
Всем привет! Наткнулся на статью, где автор подробно разбирает механизм Copy-on-Write (COW) в Swift. Это та самая технология, благодаря которой массивы, строки и словари ведут себя как типы значений, но при этом не создают полные копии больших объемов данных при каждом присваивании.
Что такое COW простыми словами:
Когда вы присваиваете массив другой переменной, Swift не создает полноценную копию. Обе переменные ссылаются на одни и те же данные в памяти. Только когда одна из них начинает изменяться, Swift создает уникальную копию для нее. Отсюда и название - копирование при записи.
Это позволяет Swift сохранять семантику значений (изменение одной копии не влияет на другую) без дорогостоящего копирования больших объемов данных.
Как это работает под капотом:
Тип-значение (например ваш массив) хранит ссылку на объект-хранилище (класс). При присваивании копируется ссылка, а не само хранилище. При попытке изменения вызывается метод isKnownUniquelyReferenced(_:), который проверяет, есть ли у хранилища другие ссылки. Если есть - создается новое хранилище с копией данных, и только потом происходит изменение.
Проверить уникальность можно и в своем коде, если вы пишете кастомную COW-структуру.
Как реализовать свой COW-контейнер:
Автор приводит пример SharedBuffer<Element>:
Простой, но эффективный паттерн.
Распространенные заблуждения:
Copy-on-Write - один из ключевых механизмов, позволяющих Swift сочетать производительность и безопасность. Понимание того, как он работает, дает вам инструмент для проектирования эффективных структур данных и помогает писать более производительный код.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Flutter & Dart | Мобильный трудоголик
Всем привет! Сегодня хочу разобрать интересную статью про судьбу 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 может и дальше снижаться.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12👍12🗿3🙏1🫡1
Apple официально представила новый тип автоматически продлеваемых подписок - годовое обязательство с ежемесячными платежами. Пользователь подписывается на 12 месяцев, но платит не сразу всю сумму, а каждый месяц. Это не рассрочка в привычном смысле, а именно подписка с фиксированным сроком и разбивкой платежей.
Как это работает:
Пользователь оформляет подписку на год, но деньги списываются небольшими суммами каждый месяц. Отменить подписку можно в любой момент, но она не прекратится сразу - она просто не продлится после того, как пользователь выплатит все оставшиеся платежи по обязательству. То есть, если отменить подписку через три месяца, придется доплатить еще девять, и только потом подписка закончится.
Apple добавила прозрачности: в аккаунте пользователя будет видно, сколько платежей уже прошло и сколько осталось. Также будут приходить email и push-уведомления перед очередным списанием.
Почему это интересно для разработчиков:
Можно сделать годовую подписку с ежемесячным платежом, которая выглядит дешевле для пользователя (например, 500 рублей в месяц вместо 5000 рублей сразу), но при этом гарантирует доход на год вперед. Это снижает порог входа - пользователю психологически легче согласиться на небольшие ежемесячные списания, чем на крупную сумму сразу.
Появляется новый инструмент для A/B-тестов и ценовых стратегий. Можно комбинировать с классическими годовыми подписками и месячными без обязательств.
На что обратить внимание:
Нужно аккуратно объяснять пользователю условия в интерфейсе. Если не предупредить, что «отменить подписку» не означает «прекратить платить прямо сейчас», можно получить негативные отзывы, споры и возвраты.
Пользователь платит каждый месяц, а не сразу. Это меняет флоу оплаты - деньги будут поступать равномерно в течение года, а не единым платежом.
Новый тип подписки - компромисс между годовым контрактом (высокий порог входа, но предсказуемый доход) и ежемесячной подпиской (низкий порог, но нестабильные оттоки). Для некоторых категорий приложений, особенно с высокой ценой годовой подписки, это может стать золотой серединой. Главное - честно и понятно объяснять пользователям условия, чтобы не получить волну негатива в отзывах.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍13🔥10❤3🤯1🙏1
В обновлении приложения Apple Support (версия 5.13) пользователи обнаружили файлы
claude.md. Разработчики быстро это заметили и в следующем обновлении файлы убрали, но интернет все помнит.Что это за файл:
Данный файл обычно содержат инструкции для ИИ: правила оформления кода, архитектурные ограничения, команды сборки, известные проблемы. Это не сам код, а подсказки для нейросети, чтобы она генерировала код в нужном стиле.
Что это значит для Apple:
Самое интересное - не то, что Apple использует ИИ для разработки (это уже никого не удивляет), а то, что они используют Claude от Anthropic, а не свои внутренние наработки. Это сигнал: даже в Apple предпочитают готовые решения от сторонних разработчиков, когда речь заходит о современных ИИ-инструментах.
Файлы оказались базовыми и не содержали никаких секретов или инсайтов. Но сам факт их наличия в релизной сборке говорит о том, что внутри компании активно используют агентную разработку с привлечением Claude.
Почему это обсуждают:
Сообщество разделилось. Одни видят в этом доказательство того, что Apple все активнее использует ИИ для написания кода. Другие считают, что файлы попали в релиз случайно и не отражают реальную картину. Третьи просто смеются над тем, что даже у Apple бывают такие ошибки.
Новость интересная, но не сенсационная. Apple использует современные инструменты разработки, включая ИИ от Anthropic. Это подтверждает, что даже гиганты индустрии не гнушаются готовыми решениями, когда они эффективны. А забытый файл в релизе - лишнее напоминание, что разработка - это живой процесс, и ошибки случаются у всех.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16💯10🔥3❤1🤯1👀1
Наткнулся на статью, где автор рассказывает о наборе Agent Skills для оптимизации времени сборки Xcode. Понимаю, что к ИИ-инструментам многие относятся скептически, но здесь речь не о написании кода за вас, а об экономии времени.
Почему это важно:
Автор приводит простую математику. Если вы делаете 50 сборок в день и ускоряете каждую на 5 секунд, это около 5 минут в день. В год - 30 часов. Один из первых пользователей сэкономил 20 секунд на каждой сборке. Для больших проектов разница может быть еще заметнее.
Что такое нулевая сборка и почему это показатель:
Отдельное внимание уделено сборке без изменений (zero-change build). Это когда вы ничего не меняли в коде, а Xcode все равно что-то пересобирает. У одного из проектов такая сборка занимала 70 секунд. После оптимизации - 9 секунд. Разница в 87%.
Как устроен скилл:
Это не один инструмент, а целый оркестр из шести специализированных скиллов:
Что можно оптимизировать:
Скилл проверяет:
Результаты на реальных проектах:
Автор приводит данные трех приложений:
Даже если вы не используете ИИ для написания кода, такие инструменты не про замену программиста. Они про конкретную, измеримую помощь в рутинных задачах. Экономия времени на сборках - это не гипотетическое преимущество, а реальные часы, которые можно потратить на разработку, а не на ожидание.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👍12🔥4💯1👀1🗿1
Forwarded from Кот Денисова
Вокруг ИИ-агентов для разработки сформировался странный парадокс. Одни заявляют, что не писали код руками полгода и полностью делегируют задачи машине. Другие клянутся, что агенты глупые и не способны на что-то сложнее «Hello World». Оба мнения честны и оба - об одном и том же инструменте. Разрыв в результатах говорит не о качестве технологии, а о катастрофической разнице в подходе к ее использованию. Успех определяет не сам агент, а навык, стоящий за промптом.
Проблема не в инструменте, а в операторе:
Ключевое заблуждение - ожидать от агента волшебства. Это не искусственный общий интеллект, который читает мысли. Это сложный, но ограниченный инструмент, который действует строго по инструкции. Разница между командами «напиши код» и «напиши на Swift функцию, которая асинхронно загружает JSON по URL, обрабатывает ошибки сети и парсит результат в структуру User с полями id и name, используя современный async/await синтаксис» - это разница между хаотичным выводом и рабочим решением.
Главный навык - умение формулировать, а не писать код:
Роль разработчика трансформируется. Если раньше ценность заключалась в умении писать код, то теперь возрастает цена умения его описывать. Это смежная, но иная дисциплина. Требуется:
Провальные паттерны коммуникации:
Большинство неудач происходят по шаблонным сценариям:
Стратегия эффективного промптинга:
Вместо расплывчатых пожеланий нужен структурированная задача:
Именно такой подход позволяет опытным инженерам в самых сложных облостях получать качественный результат. Они не просят «написать код для банка», а описывают все требования.
Агент не заменит инженерное мышление. Он его усилит. Он снимет с вас рутину, если вы сможете ее четко описать. Но он не сформулирует за вас требования, не выберет архитектуру и не примет ключевое решение. Ваша ценность теперь определяется не столько умением транслировать мысль в синтаксис языка, сколько способностью мыслить системно и доносить эти мысли с беспрецедентной точностью. Если агент вас не слушается - это не его баг. Это фича, указывающая на пробел в самом фундаментальном и востребованном сейчас навыке.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14💯9👍3👀1🫡1🗿1
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% случаев встроенных средств достаточно.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
До WWDC остались недели, и появляется все больше слухов о том, как Apple планирует встраивать ИИ в свои платформы. Одна из ключевых и самых щепетильных тем - допуск в App Store агентов, способных автономно выполнять действия за пользователя. С одной стороны, тренд игнорировать нельзя. С другой - правила App Store не резиновые.
В чем проблема:
ИИ-агенты (например те, что могут сами управлять приложениями, удалять письма, совершать покупки) - это вызов для Apple. Правила App Store строго запрещают приложениям выполнять код, который меняет их функциональность или функциональность других приложений. Агенты как раз этим и занимаются.
Кроме того, есть риск обхода комиссии и потери контроля над монетизацией. Если агент может создать приложение на лету и запустить его, минуя App Store, Apple теряет и деньги и возможность проверить, что этот код безопасен.
Что предложит Apple:
По данным источников, компания разрабатывает специальную систему, которая позволит агентам работать в рамках экосистемы, но под строгим контролем. Основная цель - предотвратить хаотичное поведение, когда агент выходит из-под контроля (например как в случае с OpenClaw, где бот удалял всю почту пользователя).
Новая система должна гарантировать, что агент не сможет делать то, что не предусмотрено правилами: обходить комиссии, выполнять вредоносный код, нарушать приватность.
Ожидается, что подробности появятся на WWDC в июне. Но источники допускают, что компания может быть еще не готова к полноценному анонсу.
Apple не хочет оставаться в стороне от бума ИИ-агентов, но и не готова жертвовать принципами. Новая система - это компромисс. Если она сработает, разработчики получат доступ к новой аудитории, пользователи - полезных помощников, а Apple сохранит контроль. Но все решит то, насколько жесткими окажутся ограничения. Если они будут слишком строгими, агенты могут так и остаться за пределами App Store, либо перейти на другие платформы, где жестких правил меньше.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤8👍3👀1🫡1
Всем привет! Нашел интересную статью, где автор делится опытом использования Time Profiler в связке с ИИ-агентами. Устройства сейчас действительно быстрые чем раньше и потребность в профилировании снизилась. Но это не значит, что проблем с производительностью больше нет. Просто мы перестали их замечать.
Кейс - ускорение в 25 раз:
Автор взял конкретную задачу - загрузку accessibility-элементов в RocketSim. На одном экране с 70+ элементов это занимало 12 секунд. Вместе с ИИ-агентом они прошли несколько итераций:
Ключевой момент: если бы остановились на первой итерации, решив, что «и так неплохо», результат был бы в 25 раз хуже.
Как это работает:
У автора уже был CLI для RocketSim. ИИ-агент мог запускать его до и после изменений, сравнивать результаты и отменять правки, если стало хуже. Для анализа использовался Time Profiler с добавленными signpost (чтобы код был виден в инструменте).
Процесс выглядит так:
Кому может быть полезно:
Instruments не умерли. Они просто стали реже нужны - но когда они нужны, без них никуда. А с ИИ-агентами процесс становится еще эффективнее: вы не тратите часы на анализ стеков, а просто даете агенту данные и получаете готовый план оптимизаций. И да, 25-кратное ускорение - не предел. Все упирается в то, как часто вы готовы запускать этот цикл.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍7🗿2❤1🙏1💯1
Forwarded from Flutter & Dart | Мобильный трудоголик
Начиная с релиза 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 окончательно отключат.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👍9🗿3👏2🔥1👀1
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 подходит:
Когда не подходит:
NSCache - отличный базовый инструмент для некритичного кэширования в памяти. Он не требует сложных настроек, не боится проблем с памятью и хорошо вписывается в архитектуру, где отсутствие данных в кэше - это просто небольшая задержка, а не ошибка. Но важно помнить про его ограничения: ключи и значения - только классы, лимиты нужно задавать явно, а для постоянного хранения нужны другие механизмы.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12
Всем привет! Сегодня хочу обсудить статью, в которой автор делится подходом к организации зависимостей в крупных проектах с помощью локальных SPM-пакетов. Когда проект вырастает из пары десятков файлов, монолитный таргет начинает болеть. Сборки замедляются, изменение в одном месте перекомпилирует половину проекта, любой файл может импортировать что угодно.
Три слоя, один поток зависимостей:
Автор делит все приложение на три уровня:
Зависимости текут строго снизу вверх. Модуль может зависеть только от того, что лежит под ним.
Как это выглядит в Package.swift:
В манифесте все зависимости объявляются явно, с помощью удобного dot-синтаксиса. Каждый таргет знает, от кого он зависит. Если кто-то попытается импортировать модуль сетевого слоя прямо из фичи - проект просто не соберется. Компилятор не даст нарушить архитектуру.
Что в каждом модуле:
ServiceEnvironment для массовой инъекции:
Когда сервисов становится больше двух, можно использовать контейнер ServiceEnvironment, который собирает все сервисы в одну структуру. Через кастомный модификатор все прокидывается в окружение одной строкой. Превью используют .mock, приложение - .live.
Модуляризация через локальные SPM-пакеты - это не про идеальную архитектуру ради архитектуры. Это про скорость и масштабируемость. Начинать лучше с малого: вынести сначала Domain, потом API, а фичи - по мере роста. Результат - приложение, где новый разработчик за пять минут понимает структуру, а CI не ждет десять минут на сборку.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14
Привет! Многие команды до сих пор внедряют сложные архитектуры вроде VIPER или Clean Architecture, считая их стандартом индустрии. Проблема в том, что эти решения часто не закрывают реальные проблемы проекта, зато увеличивают объем кода, замедляют сборку и усложняют онбординг новых разработчиков. Автор статьи проанализировал 147 проектов и результаты этого анализа выглядят довольно интересно.
Что говорят цифры:
Распределение архитектур среди проектов выглядит так: MVVM лидирует с 41%, MVC на втором месте с 34%, VIPER и Clean Architecture занимают 18%, TCA - 5%.
Главная проблема в том, что 73% проектов используют архитектуры, которые не решают их реальных проблем. Внедрение Clean Architecture в средних командах приводит к росту кода на 143%, замедлению разработки на 67% и увеличению времени онбординга новых разработчиков до трех недель.
Архитектуры и их зоны ответственности:
Как не ошибиться с выбором:
Автор статьи рекомендует придерживаться такой формулы при выборе верной архитектуры:
Лучше сделать нормально на простой архитектуре, чем на коленке на сложной. Архитектура сама по себе не гарантирует успеха. Важнее чистота кода, регулярные ревью и тесты. Сервисы, координаторы и внедрение зависимостей не требуют перехода на сложную архитектуру. Их можно добавлять в проект по мере необходимости, не меняя всю архитектуру. Не гонитесь за модными решениями - решайте реальные проблемы.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
💯14👍10❤7🔥1🙏1
Forwarded from Кот Денисова
Пока одни рисуют мрачные картины массовых увольнений и всесильного ИИ, другие уже используют его как рычаг для карьерного роста. Паника о «конце ИТ» - это маркетинг, страх и непонимание того, как на самом деле работает индустрия. История повторяется: каждый новый технологический прорыв вызывал аналогичные предсказания, но вместо исчезновения профессии мы получали её трансформацию. ИИ - не исключение.
Миф о замене - почему ИИ не станет вашим начальником:
Основное заблуждение - что ИИ сможет полностью автономно решать сложные бизнес-задачи. В реальности ИИ, особенно LLM (Large Language Models) - это продвинутый статистический инструмент, который генерирует вероятные последовательности слов на основе обученных данных. Он не понимает контекст, не обладает критическим мышлением и не может заменить человеческую способность к коммуникации, выявлению скрытых потребностей и творческому решению проблем.
Ключевая проблема, которую не решает ИИ: уточнение нечетких требований. Когда клиент говорит «сделайте красиво» или «нужна интеграция», за этим стоят десятки нюансов, которые выявляются только в диалоге. ИИ даст усредненный, шаблонный ответ, но не задаст уточняющих вопросов, не прочитает невербальные сигналы и не поймет бизнес-контекст.
Эволюция, а не революция:
ИИ повторяет этот путь: он становится новым инструментом в арсенале профессионала, а не его заменой. Художник с ИИ создаст больше концептов, копирайтер - больше вариантов текста, а программист - прототипирует быстрее. Но качественный, итоговый результат по-прежнему требует эксперта.
Парадокс спроса - почему автоматизация создает больше рабочих мест:
Логика «один программист с ИИ сделает работу пяти, значит, программистов нужно в пять раз меньше» - ошибочна. Экономика работает иначе:
Проще говоря, ИИ не сокращает количество работы, он увеличивает объем работы, которую бизнес готов и может заказать.
Новая карта компетенций:
В новой реальности ценность смещается:
ИИ не отбирает работу у программистов. Он отбирает работу у тех, кто отказывается меняться. Это естественный эволюционный фильтр.
Вместо того чтобы бояться, стоит спросить себя: вы используете ИИ, чтобы стать в 10 раз продуктивнее? Умеете ли вы делать то, что ИИ не может - понимать людей, принимать решения в условиях неопределенности, мыслить стратегически?
Будущее принадлежит не тем, кто пишет больше строк кода, а тем, кто становится архитектором решений, используя ИИ как мощный, но подконтрольный инструмент.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16❤9🗿3🔥2🙏1🤝1
Всем привет! Сегодня хочу поговорить о Metal шейдерах в SwiftUI. Это код, который выполняется прямо на графическом процессоре и определяет цвет каждого пикселя. В отличие от обычных анимаций (которые работают на уровне вьюх), здесь управление идет попиксельно. Звучит сложно, но разобраться можно довольно быстро. Есть отличная статья на эту тему, предлагаю остановиться на ней подробнее. В ней объясняют основы Metal шейдеров в SwiftUI с простыми и понятными примерами.
Подробнее о шейдерах:
Шейдер выполняется для каждого пикселя на экране. Если у вас прямоугольник 300×300 пикселей, шейдер вызовется 90 000 раз. GPU справляется с этим легко, потому что он создан для параллельных вычислений.
В SwiftUI вы просто говорите «сделай этот прямоугольник синим», и фреймворк сам решает, как закрасить пиксели. С Metal вы сами пишете код, который определяет цвет каждого пикселя. Сложнее, но зато вы контролируете каждый пиксель.
Как это работает в SwiftUI:
Процесс простой:
Никакой ручной связки не нужно - 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-подобном языке. Но результат того стоит: вы получаете контроль над каждым пикселем и возможность создавать визуальные эффекты, которые невозможно повторить стандартными средствами. А главное - порог входа не такой высокий, как кажется. Достаточно одного работающего примера, чтобы понять принцип и начать экспериментировать.
Подписаться на канал:
Закрытый канал:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13