iOS *

Всю свою сознательную жизнь я «учил» немецкий: в школе, универе, на внутренних курсах IT-компании и самостоятельно. Слово «учил» я поставил в кавычки, потому что на самом деле я ничего никогда нигде не учил, ну разве что зазубрил немецкий алфавит в школе. Всё как-то училось само, слова запоминались после нескольких повторений, грамматика – после нескольких упражнений. Слава Богу, память всегда была хорошая. Но во-первых, если в будущем эти слова и грамматика не использовались, всё это вскорости выветривалось из головы, а во-вторых, так это не работает со сложными темами. Такими, как, например, склонение немецких прилагательных.

Тем, кто учит английский, повезло: прилагательные там не склоняются вовсе, но в немецком (как и в русском) всё совсем не так:

По мере роста UI-регрессии сложнее всего становится управлять не тестами, а их окружением: состоянием приложения, ответами backend и воспроизводимостью сценариев. В статье разбираю архитектуру, которая связывает тест-кейсы QA, mock-профили, XCUITest и XcodeBuildMCP в единый процесс — от подготовки сценария до запуска в CI.

Привет, Хабр! В прошлых статьях я рассказывал про локальный переводчик с синтезом голоса на кабардинском и про то, как собрать полный NLP-стек для «финального босса лингвистики» из старых словарей. За прошедшие месяцы весь этот стек - лемматизация, POS, NER, тональность, эмбеддинги, синтез - переехал с Python/Flask на десктопе в Swift-приложение на iOS и заодно перерос сам себя: начиналось всё как синтезатор речи для одного языка, а выросло в персональную библиотеку для любого контента - книги, статьи, подкасты, видео, музыка, файлами или ссылками. Полгода на голом Swift 6, вечерами и выходными.

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

С системной функцией Picture-in-Picture (PiP) сталкивались, пожалуй, все владельцы iPhone: кто-то смотрит видео на фоне переписки, кто-то общается по видеосвязи в любимых мессенджерах. Для пользователя это просто удобство, а для разработчика видеосервиса — отдельный механизм со своей инфраструктурой, жизненным циклом и набором ограничений. В этой статье я разберу интеграцию PiP как встроенного плеера: от первого запуска до переключения контента. Поделюсь нюансами, с которыми вы точно столкнётесь на практике, и покажу, как обойти типовые грабли.

Как хобби-проект для Apple TV вырос в HomeDeck for HomeKit для двух платформ. Разбираю, как собрать единый дашборд из неоднородного графа HomeKit, разделить общий слой данных и интерфейсы iPadOS и tvOS, синхронизировать конфигурацию через iCloud и учесть ограничения большого домашнего экрана.

Дисклеймер: я держу сервис аренды маков, поэтому у меня под рукой флот одинаковых машин и повод их гонять. Цифры ниже с этих машин, методика описана полностью, данные открыты под CC BY. Ссылок на сервис в статье нет.

В этом дайджесте дистрибуция iOS‑приложения без App Store и 5 лет Compose, верификация Android разработчиков и нагрев iOS-устройств как продуктовая метрика, локальные LLM на iPhone, “бумажный” асинхронный Kotlin, ускорение корутин, пошаговая инструкция по внедрению скелетон-загрузок, проговаривания мыслей для ИИ и многое другое. Заходите!

Всем привет! Меня зовут Никита Нагорнов, я iOS-разработчик в компании «Исходный Код». В этой статье разберем, как запускать локальные LLM на iPhone.

Поговорим про:

1. Архитектуру Apple Silicon и Unified Memory — почему не можем использовать всю доступную память;

2. Память, квантование и KV Cache — где приложения начинают падать и как это отловить;

3. Core ML и MLX — чем отличаются, где какой быстрее и почему нельзя всё запускать на нейронном процессоре;

4. Температуру и троттлинг — что происходит с телефоном на длинной сессии;

5. Гибридный пайплайн — как взять сильные стороны обоих фреймворков и получить стабильную генерацию.

Я не планировал переписывать приложение React Native на C++.

Большая часть приложения прекрасно работала на TypeScript: экраны, формы, валидация, навигация, логика продукта — все это находилось именно там, где нужно. 

Проблема была более узкой и специфичной: нам нужно было, чтобы один фрагмент логики работал с производительностью, близкой к нативной, оставался общим для Android и iOS и при этом был доступен из JavaScript через обычный типизированный API.

Поначалу все звучало слишком просто. Написать интерфейс на TypeScript, позволить Codegen генерировать контракты, перенести основную логику на C++, зарегистрировать модуль на обеих платформах и использовать его из React Native как любой другой модуль.

Спойлер: да, это работает.

Чистый модуль Turbo Native на C++ действительно может дать вам одну реализацию для Android и iOS, типизированную границу через Codegen, меньшие накладные расходы, чем у старого Bridge, и удобный способ повторного использования существующего кода на C или C++ внутри приложения React Native.

Спойлер номер два: код на C++ — это не самая сложная часть.

Самое сложное начинается вокруг: CMake, NDK, Xcode, Objective-C++, время жизни среды выполнения JSI, регистрация модулей, границы потоков, владение памятью, обработка ошибок, сборки Expo, сторонние библиотеки и вопрос, который никто не хочет задавать слишком поздно — действительно ли этот модуль должен быть нативным?

В этой статье я подробно расскажу о создании C++ Turbo Native модуля для React Native: где этот подход полезен, где он добавляет скрытые затраты на поддержку, чем отличается регистрация для Android и iOS, почему важна обертка TypeScript и почему сам TurboModule должен оставаться «тонким».

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

App Store review отклонил наше приложение по Guideline 1.2 — основная механика (пользователи оценивают фотографии друг друга) запрещена как категория, и это не лечится правками метаданных. Так мы стали одними из первых, кто дистрибутирует iOS‑приложение исключительно через альтернативный маркетплейс. Документации по этому пути мало, местами она противоречива, поэтому — пошаговый разбор того, что реально пришлось сделать.

Перед первой публикацией разработанного мной приложения WeCount я был уверен, что главная причина возможного отказа — ошибки в коде или проблемы в пользовательских сценариях. На практике оказалось наоборот: за всё время App Review к функциональности приложения не возникло ни одного вопроса. Почти все замечания касались исключительно регистрации пользователя.

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

В новом выпуске как Apple в iOS 27 удалось сократить время запуска приложений и разработка системы автоматической синхронизации фотографий, интервью с Senior iOS инженером из TikTok’а и интеллектуальные приложения для Android с Jetpacker, 15 лет Kotlin, безмолвные ошибки, что и как измерять в мобильной разработке, частная социальная сеть без алгоритмов и рекламы и многое другое. Подключайтесь!

Приложение поддерживает 20+ языков. Каждое обновление — это не только новая сборка, но и правки в обоих магазинах: название, подзаголовок, описание, «что нового». Для каждого языка, на каждой платформе, через медленный веб-интерфейс.

При двух десятках языков и двух платформах обновление «что нового» вручную занимает 30–40 минут. При этом легко ошибиться: скопировать не ту версию текста, забыть один язык, перепутать поля между iOS и Android.

В статье покажу, как свести всё это к одному коммиту.

TL;DR: после каждого проекта на диске остаётся 2–40 ГБ мусора, который никто никогда не убирает. Я раскопал свой Mac (460 ГБ, из них свободно было 14), нашёл около 150 ГБ хлама чисто девелоперского происхождения, по дороге упёрся в неожиданно интересную задачу — как отличить папку build со сборкой от папки build с чем угодно ещё — и в итоге написал себе инструмент. Ниже — вся археология с цифрами и командами, можно повторить руками, ничего не покупая и не скачивая.

DarkGram — гайд по установке: разбираем все рабочие способы

После того как первая статья про DarkGram набрала 9К+ просмотров, самым частым вопросом стало «а как это поставить?». В этом гайде — все актуальные способы установки для iPhone и iPad: через SideStore и TrollStore с разбором плюсов, минусов и подводных камней каждого варианта.

Мы сделали клиент Telegram для iOS, у которого не будет ни страницы в App Store, ни кнопки Get. И дело не в деньгах. Рассказываем, что мы построили и почему пошли своим путём.

Как я сделал свободный и бесплатный ɹǝddoH - multi-hop SSH L3 VPN для iOS/Android

И запаковал сервер так, что его можно поднять с телефона: вбил IP и root-пароль - и нода в библиотеке. Цепочка из нескольких VPS - entry → relay → exit. Теперь даже на сервер заходить не надо.

Преамбула

Раньше я делал Naive-клиент, и он нормально работал. Но потом клоуны решили включить поведенческий анализ. И вот - все. Ничего не работает. Дальше опять начинается гуглинг и, в итоге, опять я прихожу к VLESS с кучей надстроек, эмуляций различных браузеров, игр и так далее. Ах да, еще надо это все настраивать, делать цепочки из нескольких серверов, чтобы выход и вход не совпадал, заниматься скриптингом и снова молиться, что все заработает и будет работать дальше. А тем временем ssh -D отлично работал все это время, и я такой, а почему бы не выдать root всем завернуть это все внутрь ssh, да еще и по цепочке, да еще и чтобы настраивалось одной кнопкой. И не прокси, а полноценный VPN.

Ведь протокол уже есть - SSH. Его не надо изобретать. Им пользуются все, как и https. Если клоуны заблокируют SSH, то это будет конечно весело, тут уже, боюсь, я ничем помочь не смогу. Осталось лишь написать клиент под это дело, опубликовать его в сторах, доказать опять Apple что это приложение уникальное (как они достали с этим), рассказать ревьюверам в Гугле что такое SSH и как оно работает... тяжела жизнь Open Source программиста. Но я справился.

В этом дайджесте вопросы о System Design и аннотации в Kotlin, Gradle под капотом и как мигрировать Flutter-приложение на SPM, как отправить 1 миллион уведомлений, открытый веб в виде социальной ленты, архитектура независимого умного дома и многое другое. Заходите!

Привет, Хабр! Меня зовут Эдуард. В прошлой статье я рассказывал про локальный переводчик и синтез голоса на кабардинском. С тех пор проект вырос: я делаю приложение на iOS для чтения с синтезом и распознаванием речи на кабардинском и ещё паре десятков «обделённых» языков. Чтобы приложение было умным (ранжировало важные предложения, искало по смыслу, вело чат по книге, читало с выразительной интонацией), ему нужен полный набор языковых сигналов: лемма, часть речи, именованные сущности, тональность и эмбеддинги.

Для английского, немецкого и испанского всё это Apple даёт из коробки. Для кабардинского - ноль по всем пяти пунктам.

Прежде чем лезть в дебри, я решил спросить у Gemini Pro, насколько это вообще реально. Ответ меня обескуражил.