React Native *

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

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

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

🇧🇷 🇨🇳 🇮🇳 Локализуем React не трогая код компонентов

React-компоненты из node_modules уже скомпилированы, поэтому внедрить react-i18next в них обычно невозможно без форка библиотеки. В статье показываю, как перехватить все вызовы jsx/jsxs через кастомный react/jsx-runtime и автоматически локализовать текст даже внутри уже собранных компонентов, не меняя их исходный код.

Обычно процесс разработки API выглядит так: мы пишем контроллер. Затем каким-то образом его документируем. После чего фронтер, опираясь на такую документацию, пишет клиент.

Мы делаем одну и ту же работу трижды.

В прошлой статье я рассказывал, как избавиться от первого дублирования. С помощью бандла sunrise-studio/symfony-openapi можно генерировать OpenAPI-документ из кода, минуя процесс документирования.

Но это решает проблему только наполовину. Если OpenAPI-документ вытекает из кода, то клиент должен вытекать из OpenAPI-документа. Иначе написание клиента – и есть то самое дублирование.

В этой статье я расскажу как замкнуть цепочку:
Controller → OpenAPI → Client → Feature
Где каждый последующий шаг вытекает из предыдущего, а не дублирует его. 

Я сделал анти-шагомер на Expo и React Native: приложение, которое награждает за неподвижность и ругает за шаги. Снаружи это шутка про anti-wellness, внутри — Android step counter, background tasks, локальные пуши, Zustand, native-модуль для TYPE_STEP_COUNTER и state machine для чек-апа “я живой, но мне лень”. Рассказываю, что сломалось по дороге и почему фоновая логика в мобильной разработке — это не cron.

Всем привет!

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

Я в одиночку делаю детское приложение, где дети учат английский через рисование: рисуют слова, а оно распознаёт рисунок и отвечает голосом. В MVP голос был системный — бесплатный, но звучит как робот из нулевых, пока сам не зайдёшь в настройки и не докачаешь нормальный. Я сделал модалку с инструкцией. Угадайте, сколько людей ей воспользовались. Короче, примерно никто.

Значит, хороший голос должен достаться всем сразу, без единого телодвижения юзера. И при этом дёшево — причём не только по деньгам.

Рассказываю, как я завёл озвучку через ElevenLabs так, что в проде она почти ничего не стоит, работает офлайн и отвечает мгновенно. Ключ оказался в одном наблюдении: всё, что приложение когда-либо скажет, известно заранее. А ещё — почему, когда ты соло и кодишь в паре с агентом, главные проверки в пайплайне работают за ту команду, которой у тебя нет.

AnkiAI-Cards - мобильное Android приложение с помощью ИИ генерирует карточки по шаблону и отправляет их напрямую в AnkiDroid внутри смартфона. Помогает изучать иностранные слова ассоциируя с контекстом фраз и предложений.

В статье представлен разбор создания CRM-системы, разработанной с применением искусственного интеллекта для ускорения кодинга и архитектурного планирования. Проект представлен как будущий полигон для построения хорошего фреймворка для автотестирования с помощью Python.

Привет, Хабр. Это история о том, как я делал ставки 7 лет, потом бросил, а потом написал приложение, которое помогло бы мне бросить раньше. Расскажу и про продуктовые решения, и про техническую часть: React Native + Expo, полностью офлайн-архитектура без бэкенда, шесть языков, и как сейчас выглядит публикация в Google Play для нового индивидуального аккаунта разработчика.

Разбираем очень неприятный баг в React Native + iOS: почему push-уведомления сохраняются на Android, но теряются на iOS в background/killed state. В статье обсудим как на самом деле устроены APNS, Notification Service Extension, App Groups и почему проблема вообще не в React Native. Будет интересно…

Пришла мне как-то идея сделать мобильное приложение на базе Telegram. Полез в npm и сразу нашёл react-native-telegram, но это оказалась обёртка над Bot API и тут я понял, что будет весело.

У Telegram с инструментами для разработчиков в целом нормально — Bot API, MTProto, TDLib. Только под RN ничего нет и вряд ли когда-то будет, насколько я знаю уже есть популярные Telegram-клиенты на React-Native, но видимо они не стали упаковывать это в библиотеку и делиться опытом с народом.

Кто пробовал запилить свой клиент Telegram на RN, тот знает, что без хороших навыков нативной разработки особо ничего не получится. В какой-то момент я устал мучиться с patch-package и кучей натива внутри RN проекта, поэтому решил, что пора это упаковать в либу. Через два года и одиннадцать релизов она оказалась в официальной документации TDLib.

Это девятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет.

Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync(). Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё.

В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов.

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

В Telegram он увидит свой видео‑бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения, потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает.

Это боль которая лечится не «правильным useState», а отдельным архитектурным слоем. Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

Привет, Хабр. Меня зовут Карим, я Flutter разработчик уже 7 лет и последний месяц я делаю фреймворк для server-driven UI на Dart.

Зачем еще один SDUI

У всех реализаций, которые попадались мне на глаза, есть общая черта - собственный DSL. JSON-схемы, кастомные конфиги. Для каждого решения приходится учить новый язык.

При этом Flutter-разработчики уже знают хороший язык описания UI. Он называется Flutter.

Это третья статья из серии про инженерные решения в ONEMIX — моём мессенджере на React Native. В первой я разбирал трёхуровневый кэш сообщений, во второй — реализацию Double Ratchet E2E. Сегодня — про звонки.

Звонки в мессенджере — это та функция, которая работает либо отлично, либо никак. Пользователь привык что WhatsApp/Telegram звонят мгновенно, показывают входящие на заблокированном экране, переживают переключения Wi-Fi/LTE, и работают из фона. Если твоя реализация делает хоть что-то из этого хуже — пользователь это сразу заметит и переключится на "нормальный" мессенджер.

Я потратил несколько месяцев на то чтобы довести звонки в ONEMIX до production-уровня. В процессе пришлось изучить WebRTC изнутри, разобраться с iOS CallKit и VoIP push notifications, и собрать десяток граблей которые в туториалах не упоминают. В этой статье — как это устроено, какие решения оказались критичными, и что бы я сделал по-другому.

Сразу оговорка. Я не использую готовые SDK типа Agora, Twilio, 100ms. У них отличное качество и поддержка, но они не дают полного контроля над процессом — а для мессенджера контроль критичен. Когда звонок не проходит, пользователь винит приложение, а не "SDK от третьей стороны". Плюс готовые SDK стоят денег, которые на раннем этапе продукта лучше направить в другие места.

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES‑GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку. Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст.

Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему.

Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат.

Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой.

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

Как я с помощью AI автоматизировал процессы своей мини‑пекарни — 3,5 месяца разработки, 2 071 коммит, два ИИ‑ассистента и VPS с 2 ГБ RAM