Hacker News Digest

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 в США), но многие считают это разумным «гражданским хакингом».