Разработка мобильных приложений *

Четыре месяца, 1823 коммита и около 200 000 строк кода: мобильное приложение для изучения английского, почти целиком написанное через LLM-агента. Я формулировал задачи, ревьюил и принимал архитектурные решения, но код руками набирал редко.

Статья не про то, как здорово, что нейросети пишут код. Она про два места, где эта схема ломается насмерть. Первое — энтропия: локально агент пишет аккуратный код, но через двести коммитов в проекте три способа поднять модалку и четыре файла с константами анимаций. Второе — физическая реальность и невысказанные инварианты: 109 коммитов ушло на одно движение шторки над клавиатурой, а на то, чтобы «забудь» в памяти питомца работало честно, понадобилась отдельная спецификация.

Внутри: конституция проекта в CLAUDE.md, четыре слоя храповиков (включая обёртку над git, которая не даёт обойти хуки), разбор пяти причин, почему анимация рвалась на реальном Android, и слоистая память на pgvector с локальными эмбеддингами.

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

Вторая жизнь у приложения появилась после идеи сделать по 50 задач на каждый прием и решать их тем самым запоминая шаблон на опыте. Дальше неачались несколько дней мучения клоуда чат джпт на бесплатных тарифах. Они генерили мне для каждого приема по 50 задач. Кстати дисписк не очень справлялся с этой задачей, поэтому и не был использован.

И вот через несколько дней появилось мое приложение. Ну а теперь подробней о нем.

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

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

Как вы помните мы делаем мессенджер. Google-сервисы в нашем основном регионе недоступны, значит FCM отпадает, что мы с этим сделали?

Стандартный ответ на эту задачу известен и выглядит красиво: UnifiedPush. Открытый контракт, никакого Google, пользователь сам выбирает, через кого получать сигналы. Мы так и сделали в июне, всё заработало на тестовых устройствах, и мы поехали дальше.

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

Я делаю сервис по подписке и плачу налог как самозанятый. Пока платежей было три в день, чеки в «Мой налог» можно было выбивать руками. Когда они пошли круглосуточно, понадобилась автоматика — и выяснилось, что сложное в этой задаче не API налоговой, а один вопрос: что делать, когда запрос ушёл, а ответ не вернулся. Повторить — риск выдать человеку второй чек на ту же сумму. Не повторить — риск не выдать вовсе.

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

Что будет, если отрезать от стратегии все, включая монстров и графику, а из Diablo убрать возможность прицельно атаковать и пройти игру до конца?

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

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

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

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

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

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

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

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

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

В навигации есть ситуации, которые невозможно честно проверить, не выходя в «поле». Можно написать код, прогнать тесты, собрать метрики — и всё равно получить кейс, когда в жизни геопозиция «зависла», позиция «улетела», а ведение по маршруту начинает жить своей жизнью.

Мы уже рассказывали, почему геопозиция бывает нестабильной и как 2ГИС помогает пользователям в такие моменты. Сегодня выпустили ещё несколько обновлений для улучшения навигации в зонах c нестабильной геопозицией — в том числе внедрили сенсорную (инерциальную) навигацию. В этой статье расскажем, как нам в этом помогли полевые проезды. 

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

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

Модель адаптивной сложности выглядела безупречно: формулы верны, тесты зелёные. Симуляция показала, что новички получают 58% верных ответов вместо 82%. Рассказываю, как устроена модель и где был провал.

Привет, Хабр! Я Оля Шишенина, отвечаю за обучение и развитие сотрудников VK. Хочу рассказать про внутреннее мероприятие для инженеров, которое мы провели этой весной: Фиксатон VK — трёхдневный марафон по багфиксам, на котором разработчики чинили баги не только в своих командах, но и в смежных продуктах VK. Решения прошли многоэтапный фильтр от общего пула задач, через проверку кода, QA-ревью при подготовке к релизу.

Победители фиксатона получили Nintendo, Playstation, а главному победителю по баллам в индивидуальном зачёте мы подарили Niva Legend — это отличная машина для того, кто любит фиксить и тюнинговать.

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

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

В какой-то момент разработки приложение становится достаточно зрелым, а команда достаточно большой. Или наоборот. Тогда кто-то решает, что пора собирать метрики: Crash Rate, Hitch Rate, время холодного запуска, потребление памяти, сетевые ошибки. Организуются красивые дашборды, пишутся аккуратные отчеты, ставятся четкие квартальные цели.

Все довольны. Пока не придет технический директор и не спросит:

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

Если вы делаете приложение на React Native / Expo и вам нужны Яндекс.Карты, вы наверняка столкнулись с проблемой: у Яндекса есть официальный SDK для Android, iOS и Flutter — но не для React Native. Годами пробел закрывало сообщество, но в 2026-м ситуация невесёлая:

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

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

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

Привет, Хабр! Я Степан Аксенов, SRE-инженер в Т-Банке. Эта статья — часть проекта «20 в 20», приуроченного к 20-летию компании: в рамках проекта специалисты из разных городов рассказывают о своей работе, инженерной культуре и о том, как устроены распределенные команды внутри большого бигтеха.

Однажды мы отключили проблемные функции на Android с помощью конфигурационной заглушки. Через 15 минут система зафиксировала резкий рост крашей — но уже на iOS. Оказалось, что решение, безопасное для одной платформы, сломало приложение на другой. 

Этот случай еще раз подтвердил, что mobile SRE не классический SRE и в нем нельзя полагаться на привычные практики. Нет ни отката, ни новых логов задним числом, ни полного контроля над средой. В статье — как мы адаптируем SRE-подходы под мобильный банкинг, где фронт работает на миллионах устройств, которые мы не контролируем.