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

Чтобы человек навёл камеру на пачку гречки и получил название, вес и калории, нужна база штрихкодов российских продуктов. Я был уверен, что она где-то есть. Её нет. Что проверял живыми запросами, почему каталоги сетей не взять, как чек ОФД заменяет каталог и как в итоге устроен справочник на 258 тысяч позиций, который растёт ровно на то, что люди сканируют.

Всем привет, на связи Дима Котиков! Я все еще люблю разрабатывать под Android/KMP, разбираться с инструментами для упрощения работы и латте на фундучном молоке. За пять лет мобильной разработки я неоднократно сталкивался с ситуацией, когда бэкенд запаздывает, а дедлайн горит. 

Зимой 2026 мы получили задачу: новый финансовый инструмент, дедлайн через три месяца, готовность бэкенда — через полтора. Команда начала работу на моках и успела. В статье я расскажу, какие инструменты перехвата и мокирования трафика помогли нам выпустить фичу в срок без готового бэкенда, как настроить их за один вечер и почему понимание принципов работы TLS и MITM-атаки экономит часы отладки.

Год мы обкладывали мобильный проект правилами для ИИ-агентов: CLAUDE.md, AGENTS.md, правила Cursor, доменные документы хрупких зон, hooks. Каждый файл решал реальную проблему. Все они грузились всегда.

Потом я померил. Чтобы поправить отступ у кнопки, агент стартовал с 39 000 токенов фиксированного слоя — до того, как я задавал вопрос. Один CLAUDE.md весил 70 килобайт и давал 69% always-on пакета. Контекст заканчивался посреди обычных задач, крупные уходили в суммаризацию.

Четыре фазы: CLAUDE.md превратился в индекс на 114 строк вместо учебника на 409; главный кодекс на 417 строк разрезан по globs, чтобы правила про оффлайн не грузились при правке профиля; ревизия alwaysApply и прополка вендорных skills; привычки чата и защита от отката.

Стало: −64% на лёгкой задаче, −60% always-on, CLAUDE.md −77%. Задача в самой сложной зоне проекта теперь легче по контексту, чем раньше была любая правка одной строки.

Внутри: все замеры с методом, который можно повторить в своём репозитории за минуту, что мы сознательно не резали и почему, и три вопроса к каждому файлу в always-on.

^{В данной статье будем рассматривать технические детали графических API Metal, API Vulkan и многопоточное программирование, от читателя требуется знание перечисленных технологий.}

Всем привет! Я Андрей, разработчик 3D-графики в 2ГИС.

Если вы пишете рендер на C++ и у вас есть отдельный RenderThread, то, скорее всего, вы уже сталкивались с подобным: данные грузятся в фоне, а вот создание GPU‑ресурсов всё равно происходит в потоке отрисовки через прямое обращение к графическим API Vulkan, Metal, Direct3D 12. И пока RenderThread в длинном цикле создает буферы и текстуры, он не рисует — он стоит, пока не обработает список загруженных ресурсов.

У нас это выглядело так на типичной средней сцене: до появления первого кадра на поток отрисовки приходило 532 текстуры и 2713 буферов, которые удерживали 45 МБ и 20 МБ временной памяти в RAM соответственно. Всё это нужно было доставить до GPU, создать наборы буферов и текстур, далее всё освободить и только потом начинать собирать батчи и рисовать.

В статье разберём, как мы вынесли создание буферов и текстур на потоки загрузки, что для этого дает Metal, почему в Vulkan всё сложнее, и какие ограничения по особенностям работы графических API пришлось учитывать.

Привет! Я Валерия Кудрявцева, iOS-разработчик в KTS. Пора поговорить о новинке.

9 сентября 2026 года Apple представила iPhone Duo, свой первый складной смартфон. Пока пользователи обсуждали новый форм-фактор, у нас, iOS-разработчиков, вопрос был другой: как поддерживать приложение на устройстве с двумя экранами и сгибом. Для нас Apple подготовила раздел HIG о проектировании под Duo, шесть Tech Talks и хаб Get Ready for iPhone Duo.

Статья основана на опубликованных Tech Talks Apple. Xcode 27.1 beta на момент подготовки ещё не вышел, поэтому возможности 27.1 описаны по презентациям. Проверить их на практике нужно после выхода SDK.

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

Отдельный интерфейс под каждую pose Duo делать не нужно. А вот допущения в текущей вёрстке проверить придётся. Если код берёт доступное пространство из модели устройства или ориентации и считает отступы симметричными, на Duo такие расчёты дадут неверный результат. Основа остаётся одна: адаптивный UI, который смотрит на размер текущего окна и на size class.

Дальше разберу изменения iOS 27, что система сделает сама и что нужно править в коде, новые API 27.1 и типичные ошибки при аудите. В конце сравню подходы с Android foldable и расскажу, что из этого уже есть в Compose Multiplatform.

Когда я начинал делать VibeLing, то был уверен — чем больше свободы дает продукт, тем он лучше. Поэтому вместо готового курса сделал приложение, в котором каждый сам решает, что ему учить. Но когда пошел поток пользователей, выяснилось, что проблема была совсем не в количестве возможностей. Большинству не хватало самого простого: понятного следующего шага.

Покупал GoIP, чтобы разобраться с телефонией на своём железе, а в итоге написал три проекта: сервер для GSM-шлюзов, клиент к нему из одной кодовой базы на Android, iOS, десктоп и браузер, и шлюз, через который внутренние номера FreePBX звонят обычными звонками Telegram

Привет, Хабр!

Продолжаю серию аудитов. В прошлый раз я разобрал семь яндексовских приложений — и там было на что посмотреть: буфер обмена, WebRTC-утечки, распознавание ключевых слов в аудиопотоке. На этот раз расширяю выборку и меняю фокус.

Одиннадцать приложений. Банки, госсервисы, маркетплейсы, навигация, магазин приложений. Все — из топа российского Android-рынк. Методология — статический анализ (SAST) плюс пассивный перехват logcat. Трафик не вскрывался, SSL Pinning не обходился, в Secure Folder не залезал.

237 уязвимостей суммарно (включая расширенную проверку). Шесть приложений с ключами подписи образца прошлого века. ВК с 11 трекерами и рейтингом риска 98/100. И Госключ, который неожиданно оказался единственным, кто делает всё правильно.

Изучать язык читая книги в оригинале полезно и увлекательно. Можно загрузить очень интересную книгу, запретить себе читать ее на русском и получится отличная мотивация для чтения и запоминания слов. Это может дать хорошее понимание языка в текстовом виде, но не поможет, когда в отпуске вам захочется что‑либо выяснить или просто поговорить в баре с англоговорящими. Для того требуется тренировать навык построения предложений и разговорной речи. И тут к нашим услугам либо живой репетитор, либо duolingo‑содержащий продукт с бесконечными синтетическими заданиями вроде составления the cat is on the mat перетаскиванием слов. Кому это вообще может быть интересно? Впрочем, выход есть.

Что такое SPAC на бирже. Это фирма которая уже внутри и уже может собирать деньги. А новые фирмы которые хотят добраться до биржевых денег побыстрее могут использовать такие вот фирмы контейнеры. Это не кооператив. Есть владелец SPAC который оказывает такие услуги. Некий сервис за процент.

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

Ну казалось поначалу что это ну не велика проблема. Оказалось что велика да еще и для российского разработчика. Она не велика. Она практически непреодолима.
Теперь то каждый может стать разработчиком. И тому уже есть примеры когда люди с идеями пишут софт без знания ничего из программирования. Грешным делом я и сам уже балуюсь вовсю.

Но в магазины не попасть никак. А хотелось бы.

Потому что есть жесткий список того что должно быть.

В 2013 году я купил книгу про то, как делать приложения, и загорелся. И вот спустя 13 лет, я все же выпустил свое первое приложение — дневник тренировок, от первого запроса в Claude Code до публикации в RuStore и Google Play. Рассказываю, как без навыков программирования я сделал свое первое рабочее приложение.

Мобильное приложение, команда из шести человек. Агенты писали наш код давно — проблема была в том, что они писали «типовой React Native», а не наш: лезли в android/, тянули hex в стили, забывали lint.

Рассказываю, как мы дошли до состояния, когда большинство мелких и средних задач уходят в production через pull request, который никто из людей не писал — только ревьюил: слоистые доки под разные аудитории, Cursor hooks, которые блокируют запись в нативное дерево и не дают агенту остановиться на красном lint, safe‑list автономных задач, Telegram‑бот на Cursor Agent SDK, замыкающий цикл «QA‑агент нашёл баг → /pr_qa → PR». И раздел о том, что не сработало.

Главная мысль: агент становится членом команды не тогда, когда ему хорошо объяснили правила, а тогда, когда среда не даёт их нарушить.

Скорость команды часто пытаются измерить количеством сильных разработчиков. Но самый быстрый человек в хаотичной системе обычно не ускоряет команду. Он просто первым начинает компенсировать её проблемы.

В большом проекте скорость чаще теряется не в коде, а между мыслью «надо поменять вот это» и моментом, когда изменение можно будет увидеть, обсудить, проверить и выпустить.

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

В такой среде архитектура нужна не для красивой схемы. Она нужна, чтобы изменения были дешёвыми.

Знакомый попросил ChatGPT написать интервальную тренировку одним HTML-файлом. В браузере всё пикает, но стоит погаснуть экрану — тишина. Разбираюсь, почему веб-страница не умеет будильник, и что с этим делать, если код вам написал чат.

В первой части мы разобрали, как Dart отличает число от объекта, а во второй – как убирается молодое поколение. Там все держалось на одном приеме: живых переносим в соседнее полупространство, а всю старую половину выбрасываем целиком.

Почему в старом поколении переезд не подходит

В молодом поколении все было просто – отбрасываем мертвые объекты и забываем про них, в старом поколении все по-другому. Для старого поколения такая операция слишком дорогая. Количество живых объектов больше, чем неживых, а это значит, что нам бы пришлось копировать почти всю память с места на место. Также необходимо было бы держать вторую половину пространства запасам такого же размера как и занятую часть полупространства. Для решения этой проблемы существует mark-sweep (Пометка-очистка).

тобы приложение работало одинаково хорошо у пользователей с разными моделями смартфонов, его желательно протестировать на таких же устройствах. Но что делать, если аудитория насчитывает десятки тысяч человек и у каждого разные смартфоны: у кого-то Samsung последней модели, флагманский Huawei, REALME, INFINIX или старенький Xiaomi, а кто-то из ностальгии купил iPhone 4? Разные модели, разные операционные системы… Как вариант, в таком случае можно использовать мобильную ферму — собрать свою или использовать готовое облачное решение. 

Привет, Хабр! Я Саша, руководитель направления поддержки в Selectel. Мне стало интересно посчитать, сколько стоит собрать мобильную ферму своими руками и насколько это выгодно для среднего и крупного бизнеса в сравнении с облачным решением. Что получилось — рассказываю под катом.

Дети порой попадают в плохие ситуации, и не всегда есть возможность позвонить родителю. Мы, команда Мой МТС, придумали решение — бесплатный виджет для детских смартфонов, который устанавливается на главный экран через приложение «Мой МТС». Ребенок может в любой момент отправить сигнал бедствия. Одно нажатие на SOS-кнопку — и родитель получает уведомление, что что-то произошло, и точную геолокацию ребенка.

Расскажем, что за это за виджет и как мы его разрабатывали.

Нативное приложение на C в продакшен часов Xiaomi, вы когда нибудь мечтали о таком? Я покажу как - на примере последней модели Xiaomi SmartBand 10 Pro, оно того стоит, работает быстро, возможности практически не ограничены, интеграция не сильно сложная, и то что сломали разработчики поправимо, а главное это довольно интересно.

Всем привет! Сегодня я хочу поделиться историей, которая длится уже порядка 10 лет.

Это история не про успешный успех или очередное нытье о том, как сложно и несправедливо, это просто про меня и мой путь. Она началась много лет назад, в далеком 2016, когда Tilda только приобрела свою первую популярность и из всех кипятильников кричали: «Web-разработчикам конец», «Убийца веб-разработки».

В 2016 году мне было 22 года, и я толком не понимал, чем заниматься. У меня был закончен специалитет и бакалавриат по финансам и банковскому делу. Я застал кризис 2014 года, уйдя с хорошей должности в банке в армию на срочку. Вернувшись, я полгода обивал пороги во Владивостоке в то время, когда все банки массово сокращали персонал. В целом, если у тебя не было «волосатой руки», твой максимум составлял 50 тысяч рублей, и то с премией!

Работал я в тот момент в одном дочернем банке одного очень известного Зеленого Банка, на должности кредитного эксперта. Единственное, что занимало мою голову, был вопрос: «Что я вообще здесь делаю и какого будущего я хочу?»

Этот вопрос я задавал себе сотни раз, и единственный ответ, который находил: «Хочу создать что-то свое, хочу помогать людям, хочу, чтобы это было красиво и супер удобно». Но что конкретно делать я не имел ни малейшего понятия.

Эта статья не про геймдизайн, не про монетизацию, не про продвижение и не про то, почему ваша игра никому не нужна.

Речь исключительно о технических ошибках при разработке игры на LibGDX, которые могут привести к низкому FPS, микрофризам, большому потреблению памяти, повышенному расходу батареи или проблемам при сборке под WebGL.

Причём в первую очередь я говорю о мобильных играх и WebGL-версиях, которые запускаются непосредственно в браузере. На мощном десктопном компьютере многие из этих проблем могут быть практически незаметны.

Я сам разрабатываю игры на LibGDX и периодически наступаю на разные грабли. Поэтому ниже не академический список оптимизаций, а вещи, на которые я бы обратил внимание уже в начале разработки.