Мобильная разработка

Я не планировал переписывать приложение 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 должен оставаться «тонким».

Привет, Хабр! Это SafeMobile. Прошлым летом Google объявил, что на Android телефоны можно будет устанавливать приложения только от проверенных разработчиков. С тех пор нас регулярно спрашивают, что будет с устройствами, которыми управляет MDM – могут ли они остаться без управления, будут ли проблемы с распространением инхаусного софта и т.д.

В этой статье мы расскажем, что узнали – если на устройствах нет сервисов Google, можно не беспокоиться, но и на сертифицированных Google устройствах в РФ, похоже, всё хорошо. Детали под катом.

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

Наталья Новикова пришла в разработку из ветеринарии и начинала как самоучка — с курсов по Java. В рамках дипломного проекта онлайн‑магистратуры МФТИ «Разработка ИТ‑продукта» она создала продукт в новой для себя сфере — мобильное приложение для детского чтения на базе искусственного интеллекта. Наталья опубликовала его в RuStore и получила первые 44 платные подписки еще до защиты диплома.

В статье разбираем путь от первой идеи до работающего продукта: как проходила проверка гипотез, почему пришлось пересобирать ИИ‑ядро, как решались проблемы с галлюцинациями LLM, из чего состоит архитектура приложения и каких результатов удалось добиться после запуска.

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

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

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

В новом выпуске как 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-подходы под мобильный банкинг, где фронт работает на миллионах устройств, которые мы не контролируем.

Если вы делаете мобильный банкинг, финтех или госсервисы для узбекского рынка, рано или поздно вы столкнётесь с MyID — национальной системой биометрической идентификации от UZINFOCOM. Лицо в камеру, liveness-проверка, сверка с госбазой — и удалённое открытие счёта готово. MyID поставляет нативные SDK для iOS и Android, а вот React Native-разработчикам исторически предлагалось выкручиваться самостоятельно.

В 2024 году я написал React Native-мост для MyID, который сегодня лежит в их официальном репозитории. Тот мост был для SDK второго поколения — и вместе с ним устарел: в 3.x старый флоу интеграции удалён целиком. Плюс Apple завёз privacy manifest, а Expo окончательно стал стандартом — и почти всё, что написано в интернете про «MyID + React Native», перестало работать. Поэтому появилась новая, независимая опенсорсная обёртка для 3.x, которую я теперь поддерживаю.

В этой статье разберу, как правильно заворачивать такой SDK в React Native в 2026 году: session flow вместо паспортных данных на клиенте, три айосные грабли, на которые наступает каждая первая интеграция, устройство Expo config plugin и таксономию ошибок. Всё — с проверкой на реальном железе.

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

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

Недавно я опубликовал в Google Play приложение 99.9% исходного кода которого написано AI. Это не просто "поделка на коленке за выходные": нативное (Kotlin), больше 50 экранов, сложная анимация, мультиязычность, расширяемое.

Этого удалось добиться через очень подробную спецификацию. Каждый экран был отрисован дизайнером, для каждой кнопки есть описание какие API дернуть. Стоило ли оно того? Давайте посмотрим на цифры.

Всем привет! Меня зовут Алексей, я техлид Android-направления в компании Домклик.

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

HEIF, HEIC и AVIF на Android через ImageMagick: хроника внедрения в два этапа. Без лишней воды — только проблемы и их решения.

Мобильное приложение может стабильно проходить тесты и всё равно падать у пользователей в сценариях, которые команда не успела предусмотреть.

В статье разберём, как связать Firebase Crashlytics, Sentry и Datadog во Flutter‑приложении, чтобы собирать ошибки с контекстом, быстрее находить причины сбоев и видеть проблемы с производительностью до того, как они станут массовыми.

Мысли о масштабируемой архитектуре приложений через кодовую структуру и философии «developer as a user»; подходит для indie-разработчиков и стартапов на ранних стадиях.

В Сбер2B Онлайн-Продажи мы развиваем интеграцию интернет-магазинов с МоимСкладом. Обычно она работает незаметно для пользователя. Но если обмен данными нарушается, начинаются проблемы: заказы не попадают в МойСклад, товары перестают синхронизироваться, а данные расходятся между системами.

Со временем мы заметили закономерность. Большинство обращений были связаны не с ошибками в коде. Чаще всего причиной становились изменения в данных. Например, кто-то менял артикул или внешний код товара, тип цен, не сопоставлял статусы заказов или удалял товар в одной из систем. Для пользователя все эти ситуации выглядели одинаково — интеграция просто переставала работать, хотя причины каждый раз были разными.

Вот типичный пример из практики.

Клиент оформил заказ. На сайте он появился сразу, а в МоемСкладе нет. Поддержка начинает разбираться в ситуации. Через полчаса выясняется, что неделю назад кто-то переименовал один из статусов заказа. Из-за этого синхронизация перестала передавать новые заказы.

Самое неприятное в этой истории то, что никто не понимал, где именно искать ошибку. Для пользователя это выглядело как очередной необъяснимый сбой интеграции, хотя настоящая причина скрывалась в одном небольшом изменении настроек.

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

Стало понятно, что главная проблема — отсутствие нормальной диагностики. Пользователь не понимал, почему интеграция перестала работать, а поддержка тратила время на поиск причины. Поэтому мы добавили в сервис диагностику, которая показывает, где именно возникла ошибка, почему она появилась и что нужно сделать, чтобы её исправить.

Привет, Хабр! Меня зовут Дмитрий Попов, я Android‑разработчик в ПСБ. В какой‑то момент мне захотелось разобраться — что такое корутина и откуда они вообще взялись. Погрузившись в различные статьи и видео, я узнал много нового, рассказал коллегам внутри команды, а теперь решил рассказать и вам. Все, что важно знать о корутинах, по моему скромному мнению, — в этой статье!

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