Hacker News Digest

bigarrow — это macOS-утилита, позволяющая AI-агентам визуально указывать на элементы интерфейса: рисует стрелку и подпись поверх всех окон, при этом клики проходят сквозь неё к приложению underneath, фокус клавиатуры не меняется, а стрелка исчезает после действия. Работает как одна Swift-бинарка без разрешений, демонов или телеметрии, совместима с Claude Code и Codex через навык в формате Agent Skills.

Основное применение — направление человека в моменты, когда агент не может или не должен действовать самостоятельно: подтверждение разрешений macOS, ввод 2FA-кодов, выбор окна среди множества, голосовое напоминание через --say или пошаговое обучение интерфейсу (например, как разрешить запись экрана). Agent может найти элемент по тексту (--element "Allow"), приложению (--app "System Settings") или окну (--window "Chrome:Pull request"), построить команду и нарисовать указатель. Инструмент проверен на разных конфигурациях: множественные дисплеи, Spaces, отключение монитора во время работы. Лицензия MIT.

Визуальные подсказки типа bigarrow облегчают обучение, помощь пожилым и отладку агентов, но вызывают вопросы безопасности и злоупотребления. Они могут скрывать кнопки отказа, позволяя злоумышленникам подменять действия пользователя. Полезны для пожилых и тех, кто нуждается в простом визуальном руководстве, особенно в учебных материалах и документации, где скриншоты не показывают, куда кликать. Для повышения доверия рекомендуется добавлять текстовое объяснение действия рядом со стрелкой. Визуальные аннотации упрощают отладку нескольких агентов, заменяя громоздкие логи. Простые стрелки отвечают на «куда кликнуть», но не на «нужно ли это действие» — решение остаётся за пользователем. Для диалоговых окон согласия следует сочетать визуальное указание с описанием последствий нажатия. Некоторые сравнивают bigarrow с лазерными указками в телеприсутствии — механизм давно востребован. Текущие стрелки выглядят неестественно и могут раздражать — нужен учёт эстетики. Инструмент работает без дополнительных разрешений macOS, что привлекательно для разработчиков. Для надёжного применения рекомендуется добавить отключение кликов‐сквозь. Визуальные подсказки могут стать стандартом в будущих UI, заменяя сложные меню, но требуют совместимости с языками и платформами — иначе полезность ограничена macOS. Общее настроение: интерес к идее, но нужны доработки для практичности и безопасности.

Я пережил внутренний кризис, не взрывной, а скорее медленное разрушение уверенности и мотивации — как будто ткань твоего я превратилась в мокрую бумагу после стирки. Причина — генеративный ИИ, который обесценивает труд творцов, превращая их работу в продукт подписки, будто птенца кормят из клюва. В искусстве я всё ещё верю, что ИИ-искусство — это анти-искусство, бездушное и стыдное, но в программировании ситуация тревожнее: почти все инженеры, которых я знаю, сошли с ума за последние годы. Ремесло переживает сдвиг, и каждому приходится выбирать, как реагировать, без подсказок из будущего. Давление сверстников и реальная мощь LLMs делают сопротивление ощущением гонки с движущейся финишной чертой.

Лично мне не нравится программировать с ассистентом: это не весело, результат не кажется своим, и я не горжусь им. Раньше я мог укрыться в своих маленьких проектах — например, в интерактивном переключателе веток git, которым гордился и которым пользовался ежедневно. Теперь такой инструмент можно получить одним запросом, и никто не ценит ручную работу. Мне нужны эти «похлопывания по плечу» от коллег, чтобы чувствовать себя реализованным — и их лишиться больно. То же самое происходит в играх: пост Зака Гейджа о том, что разработка становится похожа на музыку, разрушил меня — годы обучения кажутся напрасными. Потом я поговорил с Шэдом, создателем Uncamera — красивого приложения для iOS, имитирующего плёнку через сенсорные данные и LUT, без ИИ. Его мотивы совпадают с моими: радость в процессе, а не в результате. Он продолжает работать несмотря на сомнения; я же ушёл в саможалость. Но я понял: есть три пути — использовать ИИ и потерять удовольствие, бросить творить (невозможно для творца) или продолжать делать вещи сложным способом, просто потому что это нравится. Я выбрал последнее. Потому что мы делаем игры — и всё остальное — не для результата, а для самого дела.

AI не убивает творчество, а перераспределяет его: кто-то теряет радость от кода, кто-то находит её в новом ритме работы, а другие переходят от написания кода к проектированию систем и управлению сложностью. Многие отмечают, что AI снимает рутину, позволяя сосредоточиться на архитектуре, дизайне и решении сложных проблем, а не на шаблонном коде. Опыт @user43928 показывает ускорение разработки в 10–20 раз: 200k LOC + 100k тестов за 4 месяца без потери качества, опровергая миф о несопровождаемости AI-кода. Спор: @goonersallofyou считает использование AI для генерации кода обманом, как называть себя шефом после заказа еды; @abstractcontrol утверждает, что суть — в понимании проблемы, а не в ручном написании строк. @x3haloed считает, что автор боится изменений и «отстаёт»; @sicktriple и @standfest утверждают, что AI ускоряет рутину, но не заменяет творческое решение сложных задач — в этом и суть. По опыту @blahgeek, AI разделил работу и хобби: на работе он вынужден использовать AI, но только в хобби чувствует радость от чистого творчества — общая тенденция в треде. @Tade0 подтверждает, что полная передача понимания кода AI ухудшает качество: его ревьювер нашёл избыточные переменные, которые AI не смог упростить — необходим человеческий контроль. @saejox и @Aeolun отмечают, что радость от программирования исчезла не из-за AI как инструмента, а потому что «1000 строк кода теперь — это один промпт», убивая ощущение личного вклада. @guiloj использует AI не для замены себя, а для создания инструментов, которые делают его лучше — AI как расширение разработчика, а не замена. @djha-skin использовал AI для документации и скучных функций в проекте на Janet, что усилило его понимание: он бы не написал эти части без AI — инструмент расширил возможности, а не заменил. @rikroots создаёт нишевые инструменты без ожидания коммерческого успеха — мотивация смещается от признания к личному удовлетворению, особенно при перенасыщенности рынка AI-продуктами. @realaleris149 сталкивается с ограничениями AI в интеграции кода и визуальных активов: генерация изображений — одно, их адаптация под игровые механики — другое, и это остаётся человеческой задачей. @wartywhoa23 описывает конфликт между Eros (наслаждение процессом) и Thanatos (желание результата), объясняя, почему одни теряют радость, а другие — находят её в новом ритме. @theplumber отмечает, что AI работает лучше при чётких ограничениях: его инструментарий даёт AI качественные входные данные, делая его эффективным, но не заменяющим разработчика. @ultamatt указывает, что для многих радость от работы — роскошь: реальные проблемы — аренда, здоровье, выживание — и разговоры о «творческом кризисе» звучат как привилегия. @t43562 сравнивает программирование с литературой: если Tolkien писал бы с AI, он бы потерял глубину — ценность в личном, медленном, осознанном творчестве, а не в скорости.

Shopify переходит обратно на нативную разработку мобильных приложений после пяти лет успешного использования React Native. В 2020 году выбор фреймворка был обусловлен необходимостью избегать дублирования функций, расширить круг разработчиков и снизить затраты на поддержание паритета между iOS и Android. Эти преимущества реализовались: команда экономила время, привлекала специалистов без мобильного опыта и сосредотачивалась на доставке ценности. Однако к концу 2025 года фундаментальное предположение о стоимости дублирования труда изменилось благодаря прогрессу больших языковых моделей (LLM). Shopify начал использовать ИИ с 2021 года, и к 2025-м агенты стали способны не только ускорять написание кода, но и выполнять перевод функций между платформами, помогать в наboardingе разработчиков и обеспечивать проверку кода и тестов на основе общих спецификаций. Это снизило нагрузку по поддержанию паритета до уровня, когда нативная разработка перестала быть непрактичной.

Теперь Shopify считает, что преимущества нативной разработки — близость к платформенным возможностям, доступ к первым-party инструментам и меньшее количество абстракционных слоёв — вновь перевешивают выгоды от共享 кода. Компания не отказывается от React Native резко: она планирует чистый переход, продолжая поддерживать свои открытые библиотеки (например, Reanimated и React Native Skia), которые стали лидерами в своих нишах. Одновременно Shopify активно нанимает мобильных инженеров и специалистов на стыке ИИ и разработки. Переход не отрицает прошлых успехов: React Native был правильным выбором в 2020 году благодаря усилиям сотен инженеров и поддержке сообщества, включая Meta, Software Mansion и Уильяма Кандильона. Накопленный опыт и инструменты останутся фундаментом для будущей мобильной стратегии Shopify.

Переход Shopify на нативную разработку обусловлен ростом сложности React Native, нестабильностью библиотек, проблемами с обновлениями и несоответствием с платформенными фреймворками, что повышает стоимость поддержки. LLM значительно снижают стоимость генерации и поддержки нативного кода, делая миграцию экономически целесообразной даже для крупных продуктов — даже без глубокого знания Swift или Kotlin. Нативная разработка обеспечивает лучшую производительность, стабильность и контроль над платформой, особенно в сложных сценариях отладки. Отказ от React Native устраняет угрозы цепочек поставок npm. Даже без LLM миграция оправдана из-за высокой стоимости поддержки абстракции, что подтверждается опытом команд до 2026 года. Споры остаются: отказ от OTA-обновлений критичен для быстрорастущих компаний; сложность отладки крашей в JS, C++ и нативных потоках не устраняется LLM и может быть дороже поддержки двух кодбаз. Рекомендации: стартапам React Native и Flutter остаются разумными для MVP; после зрелости — переход на нативный код для контроля качества и производительности. При миграции важно отделить бизнес-логику от UI, чтобы LLM могли тестировать состояние через CLI. Использование агентов требует строгого контроля зависимостей и тестов — иначе компания рискует стать зависимой от нестабильных LLM. Нативные инструменты (Jetpack Compose, SwiftUI) становятся более предсказуемыми, а LLM эффективнее работают с прямым доступом к платформе, чем через слои абстракции. Ранее привлекательный аргумент «React Native для веб-разработчиков» устарел: LLM позволяют генерировать нативный код без знания платформенных языков. Опыт показывает, что React Native-проекты часто превращаются в «junk show» из-за нестабильности и низкого качества библиотек. Снижение стоимости генерации кода LLM меняет баланс: дублирование кода теперь дешевле, чем поддержка абстракции без полного контроля. Индустрия движется к отказу от высокоуровневых абстракций в пользу нативного кода.

Desert Ant Labs запускает набор из 18 специализированных моделей для работы на устройстве — в аудио, зрении и тексте — каждая из которых отвечает за миллисекунды и работает бесплатно, без токенов и облачных вызовов. Эти модели достаточно малы, чтобы работать на пятилетнем смартфоне, и достаточно быстры, чтобы обрабатывать каждый кадр видео или каждое нажатие клавиши, превосходя по скорости и качеству существующие API-решения. Например, модель Voz транскрибирует 10 минут аудио за две секунды на iPhone — в 4,7 раза быстрее Whisper — с временными метками для каждого слова. Clear, весом всего 9 МБ, превращает пятиминутную запись в студийное качество за одну секунду. Redact маскирует персональные данные (имена, адреса, номера карт) в реальном времени на 27 языках, достигая 88,8% точности при размере всего 12 МБ — близко к результатам 2,3 ГБ модели GLiNER-PII. Tongue идентифицирует 84 языка по трём словам с точностью 0,933 при размере 2 МБ, обгоняя 293 МБ детектор с показателем 0,887.

Все модели доступны через единый SDK для Swift, Kotlin и JavaScript, с бесплатным использованием до 100 тыс. ежемесячно активных устройств. Desert Ant Labs, основанный в Европе, делает ставку на суверенный подход: данные никогда не покидают устройство пользователя, что исключает зависимость от облака и защищает от принудительного изъятия информации. Лаб вырос из внутренней потребности команды Detail — их видео-приложения, где функции вроде Auto Edit и аудио-улучшения изначально требовали облачных API, prowadząc к росту инфраструктурных расходов. Обучив собственные модели, команда достигла превосходства над Dolby, Whisper и Claude Sonnet по скорости, качеству и стоимости, при этом модели оказались значительно меньше. Первые 18 моделей — это «маленький мозг» (мозжечок) системы: они выполняют рутинные, всегда включённые задачи, освобождая ресурсы для высшего уровня обработки. В будущем планируется добавить «кору» — динамическую селекцию моделей: локальные сначала, крупные при необходимости, облако — только если данные должны покинуть устройство. Появление более мощных чипов и открытых исследований позволит постепенно увеличивать размер и возможности локальных моделей, строя frontier-интеллект снизу вверх. SDK и документация доступны на GitHub, а модели можно протестировать через CLI или в браузере на Hugging Face.

Обсуждение подтверждает потенциал локальных моделей для снижения задержек и расходов, но выявляет практические проблемы: неясная бизнес‐модель после бесплатного порога, ограниченная поддержка только Apple‐устройств, отсутствие Python‐SDK и вопросы качества и лицензирования моделей. Автор поста считает модель бесплатной до 100 k MAU, но пользователи спорят о дальнейшей монетизации: один аргументирует, что без облачных вызовов нет оснований для оплаты, другой указывает на типичный enterprise‐подход с гибкой лицензией. Пользователь @momojo подтверждает, что небольшие модели (≈50 MB) запускаются на ноутбуке без дискретного GPU для биоинформатики, что поддерживает обещанную эффективность on‐device. Многие комментаторы отмечают, что модели доступны только через CoreML — только на iOS/macOS — и выражают недовольство отсутствием поддержки Android, Windows и Linux. Для расширения аудитории рекомендуется выпустить Python‐SDK или pip‐пакет для интеграции в серверные и кроссплатформенные проекты. После бесплатного уровня цены не раскрыты; участники указывают на «contact sales», что типично для корпоративного ПО с гибкой ценой и риском доли от доходов приложения. Стоит явно указывать, какие модели оригинальные, а какие — переупакованные открытые (например, Voz = Parakeet v3), чтобы избежать недоразумений. Маленькие on‐device модели могут использоваться для автодополнения текста и UI‐подсказок, особенно ценно на старых смартфонах с ограниченными ресурсами. Есть опасения по поводу on‐device модерации контента (hate‐speech triage): без постоянных обновлений риск ложных срабатываний высок, поэтому требуется тщательная валидация. Для выхода за пределы экосистемы Apple стоит добавить поддержку TensorFlow Lite, ONNX Runtime или ML Kit, чтобы запускать модели на Android и других платформах. Демонстрация модели Clear (улучшение аудио) не произвела ощутимого различия в звучании, вызывая сомнения в реальном качестве улучшения.

Swiftlet — это рантайм на Swift + Metal, позволяющий запускать гибридные модели Qwen3‑Next и Qwen3.5/3.6 MoE на обычных iOS‑устройствах. Вместо того, чтобы держать весь параметр в памяти, в RAM остаётся лишь небольшая плотная «ядровая» часть, а остальные эксперты потоково читаются из хранилища, что делает возможным работу 35‑B и даже 80‑B моделей на iPhone 17 (примерно 2,5 ГБ RAM, 1 токен/сек).

Ключевые приёмы: чтение экспертов через pread в ограниченный пул слотов, выгрузка по LFU + recency, фиксированный stride‑пакетный ввод‑вывод и мгновенная компиляция шейдеров. Архитектурно проект поддерживает альтернативные схемы внимания (Gated DeltaNet, gated GQA), int4/int8‑квантование в Metal и полную систему установки, кэширования и обработки разговоров. В результате на Mac‑е 35‑B модель потребляет лишь 2,6 ГБ RAM и генерирует 7‑11 токен/сек, а 80‑B — 4,3 ГБ и 4,5‑5 токен/сек.

Тред обсуждает запуск крупных моделей на устройствах с ограниченными ресурсами — iPhone и Mac. По опыту @leonickson, на Mac с 32 ГБ RAM увеличение кэша до 8 ГБ не ускоряет работу — узкое место — GPU, а не RAM. @adrianco советует увеличивать RAM-кэш на устройствах с 24–32 ГБ RAM — это может значительно ускорить работу. @dghlsakjg видит в этом прогресс и предполагает будущее запуска моделей на дешёвом оборудовании, например, SSD за $200. @jarek83 и @arjie спорят о реалистичности запуска 1T-параметровых моделей на таком оборудовании, указывая на ограничения и стоимость. @throwawayffffas и @leonickson обсуждают износ SSD при использовании для моделей; @throwawayffffas отмечает, что у него SSD работает долго без проблем.

Запуск модели Gemma 4 26B‑A4B в памяти около 2 ГБ позволяет выполнять её на любом Apple Silicon‑Mac, даже с 8 ГБ ОЗУ. TurboFieldfare использует собственный Swift‑Metal‑рантайм, который хранит общий ядро объёмом 1.35 ГБ и кэш KV в FP16, а остальные эксперты потоково читает с SSD, делая возможным работу 14.3‑ГБ модели без полной загрузки. Рунтайм, установщик, командная строка и нативное приложение написаны на Swift 6.2 и Metal 4, поддерживают macOS 26+ и не являются обёрткой вокруг MLX или llama.cpp; в открытом экспериментальном журнале собрано 103 измерения по ядрам, кэшу, вводу и декодированию, а также ссылки на быстрый старт, локальный сервер, бенчмарки, вкладки сообщества, дизайн системы и список экспериментов.

Лицензия – Apache 2.0, а веса модели скачиваются отдельно с Hugging Face и находятся под собственными условиями, проект не связан с Google. Назван в честь дрозда‑певчего, автор Andrey Mikhaylov посвящает его жене‑птицеводке и призывает поддерживать местную дикую природу, напоминая, что иногда просто прикоснуться к траве и послушать птиц – самое красивое, что можно сделать. Эти результаты подтверждают, что даже на устройствах с ограниченной памятью можно достичь почти полной производительности, а поддержка местных сообществ помогает сохранять природу для будущих поколений.

Тред описывает опыт запуска модели Gemma 4 26B на Apple Silicon Mac — от MacBook Air с 8 ГБ ОЗУ до MacBook Pro с 64 ГБ. Модель умещается в ~2 ГБ памяти, что позволяет запускать её даже на устройствах с ограниченной памятью, что полезно для локального AI-использования. При наличии 64 ГБ ОЗУ и быстрого SSD достигаются высокие скорости обработки даже при нагрузке на систему. Некоторые сомневаются в целесообразности такого подхода при достаточном объёме ОЗУ, опасаясь замедления. Для macOS 15 требуется удалить или изменить строки кода, связанные с языковой версией, чтобы избежать ошибок компиляции.

Разработчик mgreenwood1001 создал классический медиаплеер Winamp на Swift для macOS. Проект воссоздает знакомый интерфейс и функциональность культового плеера 90-х, адаптируя его под современные стандарты Apple. Клон поддерживает основные возможности оригинала, включая визуализацию, плейлисты и эквалайзер.

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

• Re:AMP и Foobar2000 упоминаются как лучшие альтернативы Winamp для macOS, но Re:AMP не обновлялся с 2020 года.
• Пользователи выражают ностальгию по Winamp, особенно по визуализаторам (Geiss) и эпохе локальных коллекций музыки.
• Критика текущего клона включает технические недочеты (отсутствие библиотеки, проблемы с FLAC, несоответствие гайдлайнам Apple).
• Предупреждения о юридических рисках из-за использования названия Winamp (товарный знак).
• Запросы на кроссплатформенность (Windows, Linux) и интеграцию со стриминговыми сервисами.

Автор делится своим опытом работы с различными языками программирования, объясняя, почему OCaml стал его любимым языком. Он начал с Haskell, который оценил за функциональное программирование и статическую типизацию, но столкнулся с его сложностью и медленной компиляцией. Позже он попробовал Go, который понравился своей простотой, скоростью компиляции и хорошими инструментами, но разочаровал многословностью обработки ошибок и отсутствием функциональных возможностей. OCaml, по мнению автора, сочетает в себе лучшее из обоих миров: функциональные конструкции, статические гарантии, быструю компиляцию, простую семантику выполнения и отличную документацию. Особо отмечается, что OCaml компилируется в один статический бинарный файл, как Go, но при этом имеет более мощную систему типов и REPL. Автор считает, что создатели OCaml обладают хорошим вкусом, а язык представляет собой идеальный баланс между простотой и выразительностью.

• OCaml не стал мейнстримом из-за синтаксиса, отсутствия нативных библиотек и слабой экосистемы, но его идеи (pattern-matching, type inference, algebraic data types) уже давно живут в Rust, Swift, TypeScript и даже Go.
• Фактически OCaml — это «нативный» вариант F#, но без .NET-экосистемы, а F# — это OCaml без его синтаксиса и с .NET вместо OCaml-стандартной библиотеки.
• Попытка ReasonML привнести более C-подобный синтаксис вместо ужасающего синтаксиса OCaml закончилась тем, что Facebook забросил проект, а вся индустрия JS-инструментов осталась без единого стандарта.
• Попытка Facebook-а внедрить Reason вместо TypeScript внутри Facebook показала, что даже если синтаксис и не является проблемой, то отсутствие единого стандарта для сборки и пакетов в JS-мире оставляет язык без шанса.
• Несмотря на то, что OCaml — это язык с 25-летней историей, он не имеет ни мультиплатформенной сборки, ни нормального менеджера пакетов, ни нормального REPL, что делает его неподготовленным к работе вне Unix-подобных систем.

Команда Swift представила предварительную версию инструментария для FreeBSD 14.3+, доступную для архитектуры x86_64. В комплекте компилятор и рантаймы Swift, необходимые для разработки. Для работы требуются зависимости: zlib-ng, python3, sqlite3, libuuid и curl. Разработчики предупреждают, что компилятор всё ещё находится в разработке и не является частью официального релиза.

Существует несколько известных проблем: некорректные отчёты Thread Sanitizer, неспособность LLDB выполнять Swift-выражения, зависание плагинов в SwiftPM, проблемы с C++ interop. Для FreeBSD 15 требуется временный workaround через установку пакета compat14x-amd64. Команда работает над добавлением поддержки aarch64 и распространением пакета для всех минорных версий FreeBSD 14. Пользователям рекомендуется сообщать о найденных ошибках на GitHub.

• Swift на FreeBSD — давно ожидаемое событие, но вопросы остаются: кто будет поддерживать порт, какие зависимости потребуются и какие части стека (например, SwiftUI) останутся проприетарными.
• Появление Swift на FreeBSD подчеркивает, что язык выходит за пределы экосистемы Apple, но при этом неясно, насколько он может быть полезен вне iOS/macOS-разработки.
• Обсуждение также затрагивает, что Swift в отличие от .NET или JVM не имеет полноценной кроссплатформенной стратегии, что ограничивает его применимость.
• Участники обсуждения отмечают, что язык не предоставляет официальной поддержки для серверной разработки, что делает его менее привлекательным для бэкенда.
• Наконец, обсуждение поднимает вопрос о том, что Swift в отличие от .NET или JVM не имеет полноценной кроссплатформенной стратегии, что ограничивает его применимость.

Эксперименты — основа хорошего вкуса в программировании. Автор признается, что в детстве пробовал многое (гитару, боевые искусства), но с программированием не экспериментировал, хотя и восхищался играми. Позже он понял, что эксперименты — ключевой элемент его обучения. Примеры экспериментов: настройка чувствительности мыши в играх, конфигурация Linux, кастомизация механических клавиатур. Цитируется мнение: «Когда ты экспериментируешь и выбрасываешь результаты — это практика, которая должна быть мимолетной, исследовательской и частой».

Хороший вкус формируется через использование разных инструментов, отбор подходящих и отказ от неподходящих. Автор подчеркивает, что «никакое время, потраченное на обучение, не пропало зря». Он призывает сомневаться в общепринятых нормах, экспериментировать и ломать вещи. Важно найти баланс: автор не тратит все время на настройку neovim, но регулярно пробует новые технологии (GLSL, Rust, Swift), чтобы расширить кругозор и развить способность отличать посредственность от мастерства.

• Обсуждение свелось к тому, что «taste» и «tinkering» — это не про элитарность, а про любознательность и готовность экспериментировать.
• Участники обменялись историями о том, как раньше они тоже «игрались» с настройками, но со временем пришли к минимализму и перестали это делать.
• Поднялась тема о том, что «taste» в разработке ПО — это не про эстетику, а про умение выбирать правильные инструменты и не тратить время на бессмысленные оптимизации.
• Некоторые участники выразили обеспокоенность тем, что статья не раскрывает, что именно делает «taste» важным и почему он важен.
• В итоге обсуждение сошлось на том, что «taste» — это не врождённое качество, а навык, который развивается с опытом и вовремя отпускает человека от бессмысленных занятий.

Swift.org анонсировали выпуск Swift SDK для Android, открывая новые возможности для кроссплатформенной разработки. Этот релиз стал результатом многолетних усилий сообщества и работы Android workgroup, которая расширяет возможности Swift за пределы традиционных платформ. SDK доступен в виде nightly preview релизов и может быть получен вместе с установщиком Windows или скачан отдельно для Linux и macOS.

Уже опубликовано руководство по началу работы и примеры приложений, демонстрирующие end-to-end рабочие процессы. Проект swift-java обеспечивает взаимодействие между Java и Swift, автоматически генерируя безопасные и производительные привязки. Интересно, что более 25% пакетов в Swift Package Index уже поддерживают Android, что упрощает перенос существующих проектов на новую платформу. Команда также работает над документом видения для будущих разработок Swift на Android и отслеживает прогресс через проект board.

• Обсуждение в основном вращается вокруг трёх тем: «кроссплатформенный» Swift теперь позволяет писать Android-приложения на Swift, но не решает проблему UI-фреймворков, а также не затрагивает вопросы лицензирования и тулинга.
• Участники обсуждения отмечают, что даже если Swift теперь работает на Android, это не делает его «флаттером» — он не предоставляет нативный UI, и разработчики всё ещё должны решать, как реализовать UI, что делает его менее привлекательным, чем Flutter или React Native.
• Некоторые участники высказывают мнение, что вместо того, чтобы пытаться сделать Swift кроссплатформенным, было бы лучше, если бы Apple открыла Xcode и позволила бы использовать его на других платформах.
• Обсуждение также затрагивает вопрос о том, что влияние на разработчиков окажет то, что Apple не предоставляет никаких инструментов для разработки под Android, в то время как Google предоставляет такие инструменты для iOS.
• Участники также обсуждают, что влияние на разработчиков окажет то, что Apple не предоставляет никаких инструментов для разработки под Android, в то время как Google предоставляет такие инструменты для iOS.

Пол Хадсон создал приложение Hacktivate, чтобы научить детей 13+ основам кибербезопасности через формат игры "захвати флаг". В отличие от современных компьютеров, которые слишком защищены для экспериментов, приложение предлагает 240 уникальных заданий по SQL-инъекциям, взлому хэшей, стеганографии и другим практическим навыкам. "Я хочу вернуть тот же опыт, который был у меня, новому поколению", — объясняет автор, стремясь сделать обучение одновременно увлекательным и структурированным.

Приложение использует безопасную песочницу, где все действия происходят внутри игры, не затрагивая реальные системы. Задания варьируются от базовых вопросов о представлении данных (hex, binary, ASCII) до сложных криптографических задач с современными алгоритмами. "Моя цель — не превратить всех в опытных пентестеров за один день, а вдохновить новое поколение хактеров на эксперименты и обучение в безопасной среде", — подчеркивает Хадсон. Приложение уже доступно на iPhone, iPad и Mac.

• Пользователи обсуждают, как раннее влияние нехватки ресурсов в странах третьего мира сформировало их навыки и мотивацию к самообучению и творческому подходу к решению проблем.
• Поднят вопрос о том, что микротранзакции в приложениях могут быть неэтичными, особенно для детей, и что существует альтернативная версия приложения без них.
• Упомянуто, что разработчик приложения, Paul Hudson, ранее преподавал автору Swift и UIKit, что подчеркивает его вклад в обучении сообщества разработчиков.
• Участники обсуждают, что важно сохранять баланс между монетизацией и доступностью образования, и что существует версия приложения без микротранзакций.

Memory Integrity Enforcement (MIE) — пятилетняя разработка Apple, объединяющая возможности собственных чипов и ОС для постоянной защиты памяти без потери производительности. Это крупнейшее обновление безопасности памяти в истории потребительских ОС.

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

• создала безопасный язык Swift и переписывает на нём код;
• в iOS 15–17 ввели «типизированные» аллокаторы kalloc_type и xzone malloc, усложняющие эксплуатацию;
• в 2018 году первыми внедрили PAC в A12 для защиты целостности управления;

Оценив стандарт MTE (2019), Apple нашла в нём слабые места и совместно с Arm доработала спецификацию до Enhanced MTE (EMTE, 2022). Ключевые требования Apple: синхронная проверка тегов, постоянная работа и скрытность тегов от злоумышленника. Для этого потребовались глубокие доработки железа, ядра, драйверов и приложений.

• Apple представила Memory Integrity Enforcement (MIE) — систему аппаратно-программной защиты от повреждения памяти, работающую синхронно и по умолчанию на iPhone 17.
• MIE использует расширенное тегирование памяти (EMTE), что резко сокращает число рабочих эксплойт-цепочек: даже при наличии багов восстановить цепь не удалось.
• 4-битные теги (1/16 шанс угадать) защищены частым перевыбором seed и мгновенным крашем при промахе, что делает вероятностные атаки непрактичными.
• Критики отмечают: механизм не спасает от цепочек поставки и усложняет джейлбрейки, превращая устройства в «коммерческие терминалы» без возможности «покопаться внутри».
• Спор об «отсутствии массовых вредоносов» для iPhone: приводятся примеры XcodeGhost, Pegasus и других, но Apple считает их узкими кампаниями, а не эпидемиями.

Кратко:
С декабря 2026 г. CocoaPods Trunk станет только для чтения — новые версии и pod-ы добавлять нельзя. Существующие сборки продолжат работать, пока живы GitHub и jsDelivr.

Что меняется:

• Подачи новых Podspec будут отклоняться на уровне сервера.
• Репозиторий CocoaPods/Specs пометят как archived.
• Использование prepare_command в новых Podspec запрещено (май 2025).

График:

• май 2025 — блок prepare_command.
• конец 2025 — массовое письмо всем авторам Podspec.
• сен–окт 2026 — повторное уведомление.
• 1–7 ноя 2026 — тестовое отключение.
• 2 дек 2026 — финальный переход на read-only.

Обратная связь:

• Команда: [email protected]
• Orta: [email protected] или Bluesky @orta.io

• CocoaPods официально уходит в историю: мейнтейнеры решили прекратить развитие, признав превосходство Swift Package Manager.
• Пользователи благодарны за годы поддержки, но многие рады избавиться от «захвата» проекта xcworkspace и постоянных проблем с CDN.
• Критика SPM: не хватает команды outdated, баги в Xcode, плохие сообщения об ошибках; до 30 % пакетов ещё не перенесены.
• React Native, Flutter, Unity, Capacitor пока тесно зависят от CocoaPods; переход на SPM только в зачаточном состоянии.
• ~100 k старых pod-ов рискуют остаться без обновлений: придётся форкать и мигрировать вручную или ждать сообщества.

Xcode 26 Beta 7

• macOS 15.4+ требуется
• Swift 6.1 и Swift 6.0.3 включены
• iOS 18.4, macOS 15.4, watchOS 11.4, tvOS 18.4, visionOS 2.4 SDK обновлены

Новое

• Swift Testing теперь по умолчанию
• Preview canvas работает без симулятора
• Metal debugger поддерживает mesh shaders
• Instruments добавлен шаблон Swift Concurrency

Исправлено

• SourceKit-LSP не крашится при больших проектах
• Simulator корректно отображает Dynamic Island
• TestFlight теперь принимает билды с App Intents

Известные проблемы

• CarPlay симулятор не запускается
• XCTest может зависать при parallel testing
• SwiftUI .animation(.default) ломает navigation transitions

Устарело

• Interface Builder для watchOS storyboards
• bitcode полностью удалён

Скачать

• Apple Developer Portal

• Apple добавил в Xcode бета-версию интеграции с Claude (Sonnet 4) и GPT-5, но модели не поставляются в комплекте: нужен оплаченный аккаунт у Anthropic/OpenAI и передача кода на внешние серверы.
• Пользователей беспокоят приватность, утечки исходников и отсутствие офлайн-режима; многие считают, что Apple «Sherlock’нула» сторонние плагины.
• Критика Xcode усилилась: баги, медлительность и плохой UX остаются нерешёнными, а встроенный ИИ не компенсирует недостатки.
• Наблюдается ирония: Microsoft, первой внедрившей Copilot, теперь теряет эксклюзивность, поскольку Apple, Google и JetBrains внедряют собственные или альтернативные модели.

В JavaScript "🤦🏼‍♂️".length == 7 — не ошибка, а результат подсчёта UTF-16 кодовых единиц.
Эмодзи состоит из 5 скалярных значений Unicode, но в UTF-16 они занимают 7 code units:

• 🤦 U+1F926 → 2
• 🏼 U+1F3FC → 2
• ZWJ U+200D → 1
• ♂ U+2642 → 1
• VAR-16 U+FE0F → 1

Итого 7 — именно это и возвращает .length.

Другие языки считают по-своему:

• Python 3 → len("🤦🏼‍♂️") == 5 (кодовые точки, но допускает суррогаты).
• Rust → "🤦🏼‍♂️".len() == 17 (байты UTF-8).
• Swift → "🤦🏼‍♂️".count == 1 (расширенный графем-кластер).

Каждый подход отвечает на свой вопрос: «сколько code units / bytes / графем». Ни один не универсален; выбор зависит от задачи.

• Обсуждение вокруг статьи показало, что «длина строки» не имеет единого определения: бывают байты, UTF-16/UTF-32 код-юниты, скалярные значения Unicode и расширенные графем-кластеры.
• Пользователи жалуются, что разные языки и API возвращают разные числа для одного и того же эмодзи, что ломает UI-ограничения, индексы БД и обработку текста.
• Часть участников считает, что нужно явно различать «длину для хранения», «длину для отображения» и «длину для человека»; другие мечтают вернуться к чистому ASCII.
• Примеры кода на Java, Python, Raku и JS показывают, как получить каждый из вариантов длины, но подчеркивают отсутствие общего стандарта.
• Итог: «length» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.

Как я случайно стал неофициальным разработчиком Apple Wallet для PureGym

47 секунд: зарождение злодея
Каждый вход в PureGym занимал 47 секунд: открыть приложение, дождаться загрузки, нажать «Gym access», дождаться QR. 6 дней в неделю — 282 секунды жизни на вход. Решил оптимизировать.

Восьмилетний PIN
8 лет подряд использую один и тот же 8-значный PIN на турникете. Он никогда не протухал. А QR-код обновляется каждую минуту — спектакль безопасности.

mitmproxy и GitHub
Попытка «заснять» QR и положить в Wallet провалилась — код умирает за минуту. На GitHub нашёл кучу недовольных разработчиков и старые репозитории PureGym.

PassKit: забытый ребёнок Apple
QR-коды PureGym — это обычные signed passes Apple Wallet. Формат .pkpass — ZIP с JSON и подписью. Сгенерировал собственный pass: pass.json, manifest.json, подписал через openssl.

Swift-backend на Vapor
Написал сервис на Vapor:

• авторизация по логину/паролю PureGym
• парсинг JSON с QR-кодом
• генерация нового .pkpass каждые 6 часов
• отдача по deeplink https://pass.puregym.local/{id}

The Great Gym Heist
Запустил сервер на домашнем Raspberry Pi. Первый вход — 3 секунды, без приложения. Через неделю 50+ человек используют мой сервис. Никто не заметил.

Apple Watch
Добавил Watch-расширение: показ pass на двойное нажатие боковой кнопки. Работает даже без телефона.

Цифры

• 47 → 3 секунды входа
• 282 → 18 секунд в неделю
• 50+ пользователей
• 0 жалоб

Бонус
Сделал push-уведомления, если pass не обновился. Добавил темную иконку для Vision Pro.

Неловкая правда
PureGym мог бы сам выдать Wallet-pass за день работы. Но 8 лет никто не заметил.

Этика
Никаких персональных данных не храню, только токен. Если закроют — открою исходники.

Что дальше
Планирую добавить NFC-таг у входа: поднёс Watch — дверь открылась.

• Пользователи делятся опытом работы с ужасным официальным приложением PureGym: медленный старт, отключение фоновой музыки, веб-обёртка вместо нативного клиента.
• Автор статьи сделал собственный Swift-бэкенд и Apple Wallet-пасс, чтобы мгновенно получать обновляющийся QR-код и не ждать 7 секунд загрузки.
• Обсуждают безопасность: 8-значный PIN выдаётся самим сервисом, может быть скомпрометирован, а API, похоже, не имеет нормального rate-limit.
• Сообщают аналогичные истории с другими сетями (TrainMore, Fitness SF, Better) и спорят, почему компании не добавляют Wallet: «не приоритет», «слишком дорого поддерживать», «никому не платят за UX».
• Поднимают юридические вопросы: использование неофициального клиента может нарушать ToS или законы (CFAA в США), но многие считают это разумным «гражданским хакингом».