#react_native — Public Fediverse posts

AGENTS.md создавали, чтобы помогать агентам. Я использую его, чтобы их вычислять

Вместе с растущей AI-индустрией приходят и её побочки. Я мейнтейнер библиотеки react-native-tdlib и довольно быстро заметил: все больше PR выглядят как чистый вывод агента. Сначала я честно реагировал — писал в каждый такой PR вопросы: тестировали ли вы это, что именно меняет ваш код, зачем вот эта строчка. В какой-то момент понял, что трачу время на переписку с людьми, которые сами не знают, что написали. Первая мысль была — написать большой README или CONTRIBUTING и прямым текстом сказать: «сгенерированный код не принимаю». Но тут же упёрся в вопрос: а как доказать, что код сгенерирован? Аргумент «чую, тут пахнет Claude Code» — так себе позиция для публичного спора в комментариях к PR. Решение оказалось довольно простым — AGENTS.md . Он конечно не доказывает, что PR сгенерирован, но отлично ловит самые очевидные автоматические PR, где автор, кажется, вообще не участвовал в процессе.

https://habr.com/ru/articles/1038786/

#AGENTSmd #AIагенты #open_source #pull_request #спам #React_Native #GitHub_Actions #code_review #мейнтейнер #Claude_Code

AGENTS.md создавали, чтобы помогать агентам. Я использую его, чтобы их вычислять

Вместе с растущей AI-индустрией приходят и её побочки. Я мейнтейнер библиотеки react-native-tdlib и довольно быстро заметил: все больше PR выглядят как чистый вывод агента. Сначала я честно реагировал — писал в каждый такой PR вопросы: тестировали ли вы это, что именно меняет ваш код, зачем вот эта строчка. В какой-то момент понял, что трачу время на переписку с людьми, которые сами не знают, что написали. Первая мысль была — написать большой README или CONTRIBUTING и прямым текстом сказать: «сгенерированный код не принимаю». Но тут же упёрся в вопрос: а как доказать, что код сгенерирован? Аргумент «чую, тут пахнет Claude Code» — так себе позиция для публичного спора в комментариях к PR. Решение оказалось довольно простым — AGENTS.md . Он конечно не доказывает, что PR сгенерирован, но отлично ловит самые очевидные автоматические PR, где автор, кажется, вообще не участвовал в процессе.

https://habr.com/ru/articles/1038786/

#AGENTSmd #AIагенты #open_source #pull_request #спам #React_Native #GitHub_Actions #code_review #мейнтейнер #Claude_Code

AGENTS.md создавали, чтобы помогать агентам. Я использую его, чтобы их вычислять

Вместе с растущей AI-индустрией приходят и её побочки. Я мейнтейнер библиотеки react-native-tdlib и довольно быстро заметил: все больше PR выглядят как чистый вывод агента. Сначала я честно реагировал — писал в каждый такой PR вопросы: тестировали ли вы это, что именно меняет ваш код, зачем вот эта строчка. В какой-то момент понял, что трачу время на переписку с людьми, которые сами не знают, что написали. Первая мысль была — написать большой README или CONTRIBUTING и прямым текстом сказать: «сгенерированный код не принимаю». Но тут же упёрся в вопрос: а как доказать, что код сгенерирован? Аргумент «чую, тут пахнет Claude Code» — так себе позиция для публичного спора в комментариях к PR. Решение оказалось довольно простым — AGENTS.md . Он конечно не доказывает, что PR сгенерирован, но отлично ловит самые очевидные автоматические PR, где автор, кажется, вообще не участвовал в процессе.

https://habr.com/ru/articles/1038786/

#AGENTSmd #AIагенты #open_source #pull_request #спам #React_Native #GitHub_Actions #code_review #мейнтейнер #Claude_Code

AGENTS.md создавали, чтобы помогать агентам. Я использую его, чтобы их вычислять

Вместе с растущей AI-индустрией приходят и её побочки. Я мейнтейнер библиотеки react-native-tdlib и довольно быстро заметил: все больше PR выглядят как чистый вывод агента. Сначала я честно реагировал — писал в каждый такой PR вопросы: тестировали ли вы это, что именно меняет ваш код, зачем вот эта строчка. В какой-то момент понял, что трачу время на переписку с людьми, которые сами не знают, что написали. Первая мысль была — написать большой README или CONTRIBUTING и прямым текстом сказать: «сгенерированный код не принимаю». Но тут же упёрся в вопрос: а как доказать, что код сгенерирован? Аргумент «чую, тут пахнет Claude Code» — так себе позиция для публичного спора в комментариях к PR. Решение оказалось довольно простым — AGENTS.md . Он конечно не доказывает, что PR сгенерирован, но отлично ловит самые очевидные автоматические PR, где автор, кажется, вообще не участвовал в процессе.

https://habr.com/ru/articles/1038786/

#AGENTSmd #AIагенты #open_source #pull_request #спам #React_Native #GitHub_Actions #code_review #мейнтейнер #Claude_Code

От боли к npm install: TDLib для React-Native, или как я делал проект, а получилась библиотека

Пришла мне как-то идея сделать мобильное приложение на базе Telegram. Полез в npm и сразу нашёл react-native-telegram , но это оказалась обёртка над Bot API и тут я понял, что будет весело. У Telegram с инструментами для разработчиков в целом нормально — Bot API, MTProto, TDLib. Только под RN ничего нет и вряд ли когда-то будет, насколько я знаю уже есть популярные Telegram-клиенты на React-Native, но видимо они не стали упаковывать это в библиотеку и делиться опытом с народом. Кто пробовал запилить свой клиент Telegram на RN, тот знает, что без хороших навыков нативной разработки особо ничего не получится. В какой-то момент я устал мучиться с patch-package и кучей натива внутри RN проекта, поэтому решил, что пора это упаковать в либу. Через два года и одиннадцать релизов она оказалась в официальной документации TDLib .

https://habr.com/ru/articles/1038380/

#react_native #telegram #tdlib #разработка_мобильных_приложений #ios #android #open_source #typescript #npm #библиотека

От боли к npm install: TDLib для React-Native, или как я делал проект, а получилась библиотека

Пришла мне как-то идея сделать мобильное приложение на базе Telegram. Полез в npm и сразу нашёл react-native-telegram , но это оказалась обёртка над Bot API и тут я понял, что будет весело. У Telegram с инструментами для разработчиков в целом нормально — Bot API, MTProto, TDLib. Только под RN ничего нет и вряд ли когда-то будет, насколько я знаю уже есть популярные Telegram-клиенты на React-Native, но видимо они не стали упаковывать это в библиотеку и делиться опытом с народом. Кто пробовал запилить свой клиент Telegram на RN, тот знает, что без хороших навыков нативной разработки особо ничего не получится. В какой-то момент я устал мучиться с patch-package и кучей натива внутри RN проекта, поэтому решил, что пора это упаковать в либу. Через два года и одиннадцать релизов она оказалась в официальной документации TDLib .

https://habr.com/ru/articles/1038380/

#react_native #telegram #tdlib #разработка_мобильных_приложений #ios #android #open_source #typescript #npm #библиотека

От боли к npm install: TDLib для React-Native, или как я делал проект, а получилась библиотека

Пришла мне как-то идея сделать мобильное приложение на базе Telegram. Полез в npm и сразу нашёл react-native-telegram , но это оказалась обёртка над Bot API и тут я понял, что будет весело. У Telegram с инструментами для разработчиков в целом нормально — Bot API, MTProto, TDLib. Только под RN ничего нет и вряд ли когда-то будет, насколько я знаю уже есть популярные Telegram-клиенты на React-Native, но видимо они не стали упаковывать это в библиотеку и делиться опытом с народом. Кто пробовал запилить свой клиент Telegram на RN, тот знает, что без хороших навыков нативной разработки особо ничего не получится. В какой-то момент я устал мучиться с patch-package и кучей натива внутри RN проекта, поэтому решил, что пора это упаковать в либу. Через два года и одиннадцать релизов она оказалась в официальной документации TDLib .

https://habr.com/ru/articles/1038380/

#react_native #telegram #tdlib #разработка_мобильных_приложений #ios #android #open_source #typescript #npm #библиотека

От боли к npm install: TDLib для React-Native, или как я делал проект, а получилась библиотека

Пришла мне как-то идея сделать мобильное приложение на базе Telegram. Полез в npm и сразу нашёл react-native-telegram , но это оказалась обёртка над Bot API и тут я понял, что будет весело. У Telegram с инструментами для разработчиков в целом нормально — Bot API, MTProto, TDLib. Только под RN ничего нет и вряд ли когда-то будет, насколько я знаю уже есть популярные Telegram-клиенты на React-Native, но видимо они не стали упаковывать это в библиотеку и делиться опытом с народом. Кто пробовал запилить свой клиент Telegram на RN, тот знает, что без хороших навыков нативной разработки особо ничего не получится. В какой-то момент я устал мучиться с patch-package и кучей натива внутри RN проекта, поэтому решил, что пора это упаковать в либу. Через два года и одиннадцать релизов она оказалась в официальной документации TDLib .

https://habr.com/ru/articles/1038380/

#react_native #telegram #tdlib #разработка_мобильных_приложений #ios #android #open_source #typescript #npm #библиотека

Push-уведомления в мессенджере: production-грабли которых нет в туториалах

Это девятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет. Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync() . Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё. В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.

https://habr.com/ru/articles/1035992/

#react_native #push_notifications #expo #fcm #apns #callkit #voip #мессенджер #мобильная_разработка #deep_linking

Push-уведомления в мессенджере: production-грабли которых нет в туториалах

Это девятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет. Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync() . Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё. В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.

https://habr.com/ru/articles/1035992/

#react_native #push_notifications #expo #fcm #apns #callkit #voip #мессенджер #мобильная_разработка #deep_linking

Push-уведомления в мессенджере: production-грабли которых нет в туториалах

Это девятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет. Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync() . Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё. В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.

https://habr.com/ru/articles/1035992/

#react_native #push_notifications #expo #fcm #apns #callkit #voip #мессенджер #мобильная_разработка #deep_linking

Push-уведомления в мессенджере: production-грабли которых нет в туториалах

Это девятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет. Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync() . Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё. В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.

https://habr.com/ru/articles/1035992/

#react_native #push_notifications #expo #fcm #apns #callkit #voip #мессенджер #мобильная_разработка #deep_linking

Outbox-паттерн для мобильного мессенджера: как Telegram не теряет сообщения и почему ваш код их теряет

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов. Сценарий с которого всё началось у меня. Пользователь в чате выбирает большое видео, нажимает отправить. Видео начинает грузиться. Пользователь нетерпеливый, прокручивает вверх посмотреть переписку, потом переходит в другой чат, потом возвращается. Что должен он увидеть? В Telegram он увидит свой видео-бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения , потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает. Это боль которая лечится не "правильным useState", а отдельным архитектурным слоем . Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

https://habr.com/ru/articles/1034690/

#react_native #мессенджер #optimistic_update #outbox #мобильная_разработка #архитектура #telegram #асинхронность #обработка_ошибок #retry

Outbox-паттерн для мобильного мессенджера: как Telegram не теряет сообщения и почему ваш код их теряет

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов. Сценарий с которого всё началось у меня. Пользователь в чате выбирает большое видео, нажимает отправить. Видео начинает грузиться. Пользователь нетерпеливый, прокручивает вверх посмотреть переписку, потом переходит в другой чат, потом возвращается. Что должен он увидеть? В Telegram он увидит свой видео-бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения , потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает. Это боль которая лечится не "правильным useState", а отдельным архитектурным слоем . Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

https://habr.com/ru/articles/1034690/

#react_native #мессенджер #optimistic_update #outbox #мобильная_разработка #архитектура #telegram #асинхронность #обработка_ошибок #retry

Outbox-паттерн для мобильного мессенджера: как Telegram не теряет сообщения и почему ваш код их теряет

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов. Сценарий с которого всё началось у меня. Пользователь в чате выбирает большое видео, нажимает отправить. Видео начинает грузиться. Пользователь нетерпеливый, прокручивает вверх посмотреть переписку, потом переходит в другой чат, потом возвращается. Что должен он увидеть? В Telegram он увидит свой видео-бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения , потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает. Это боль которая лечится не "правильным useState", а отдельным архитектурным слоем . Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

https://habr.com/ru/articles/1034690/

#react_native #мессенджер #optimistic_update #outbox #мобильная_разработка #архитектура #telegram #асинхронность #обработка_ошибок #retry

Outbox-паттерн для мобильного мессенджера: как Telegram не теряет сообщения и почему ваш код их теряет

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов. Сценарий с которого всё началось у меня. Пользователь в чате выбирает большое видео, нажимает отправить. Видео начинает грузиться. Пользователь нетерпеливый, прокручивает вверх посмотреть переписку, потом переходит в другой чат, потом возвращается. Что должен он увидеть? В Telegram он увидит свой видео-бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения , потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает. Это боль которая лечится не "правильным useState", а отдельным архитектурным слоем . Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

https://habr.com/ru/articles/1034690/

#react_native #мессенджер #optimistic_update #outbox #мобильная_разработка #архитектура #telegram #асинхронность #обработка_ошибок #retry

Как я сделал групповые звонки в React Native мессенджере: WebRTC, CallKit и грабли production'а

Это третья статья из серии про инженерные решения в 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 стоят денег, которые на раннем этапе продукта лучше направить в другие места.

https://habr.com/ru/articles/1033930/

#webrtc #react_native #livekit #callkit #voip_push_notifications #trickle_ice #мобильная_разработка #звонки #мессенджер

Как я сделал групповые звонки в React Native мессенджере: WebRTC, CallKit и грабли production'а

Это третья статья из серии про инженерные решения в 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 стоят денег, которые на раннем этапе продукта лучше направить в другие места.

https://habr.com/ru/articles/1033930/

#webrtc #react_native #livekit #callkit #voip_push_notifications #trickle_ice #мобильная_разработка #звонки #мессенджер

Как я сделал групповые звонки в React Native мессенджере: WebRTC, CallKit и грабли production'а

Это третья статья из серии про инженерные решения в 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 стоят денег, которые на раннем этапе продукта лучше направить в другие места.

https://habr.com/ru/articles/1033930/

#webrtc #react_native #livekit #callkit #voip_push_notifications #trickle_ice #мобильная_разработка #звонки #мессенджер

Как я сделал групповые звонки в React Native мессенджере: WebRTC, CallKit и грабли production'а

Это третья статья из серии про инженерные решения в 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 стоят денег, которые на раннем этапе продукта лучше направить в другие места.

https://habr.com/ru/articles/1033930/

#webrtc #react_native #livekit #callkit #voip_push_notifications #trickle_ice #мобильная_разработка #звонки #мессенджер

Я реализовал Double Ratchet в React Native мессенджере. Разбор протокола и кода

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку . Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст. Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему. Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

https://habr.com/ru/articles/1033830/

#double_ratchet #signal_protocol #e2e #endtoend_encryption #react_native #криптография #мессенджер #ecdh #hkdf #web_crypto_api

Я реализовал Double Ratchet в React Native мессенджере. Разбор протокола и кода

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку . Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст. Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему. Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

https://habr.com/ru/articles/1033830/

#double_ratchet #signal_protocol #e2e #endtoend_encryption #react_native #криптография #мессенджер #ecdh #hkdf #web_crypto_api

Я реализовал Double Ratchet в React Native мессенджере. Разбор протокола и кода

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку . Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст. Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему. Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

https://habr.com/ru/articles/1033830/

#double_ratchet #signal_protocol #e2e #endtoend_encryption #react_native #криптография #мессенджер #ecdh #hkdf #web_crypto_api

Я реализовал Double Ratchet в React Native мессенджере. Разбор протокола и кода

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку . Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст. Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему. Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

https://habr.com/ru/articles/1033830/

#double_ratchet #signal_protocol #e2e #endtoend_encryption #react_native #криптография #мессенджер #ecdh #hkdf #web_crypto_api

Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге

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

https://habr.com/ru/articles/1033502/

#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram

Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге

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

https://habr.com/ru/articles/1033502/

#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram

Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге

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

https://habr.com/ru/articles/1033502/

#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram

Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге

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

https://habr.com/ru/articles/1033502/

#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram

Хроники Облачного княжества: как я приручал монолит‑дракона

Часть 1. Когда я шёл в DevOps, я думал, что буду приручать серверы. Оказалось — людей, процессы и древнего дракона по имени Легаси. Я пришёл в Башню релизов ровно в девять ноль‑ноль — как человек, который ещё верит в расписание. Башня стояла на холме, укрытая облаками и корпоративными ценностями. Над входом висел герб: три кольца, перечёркнутые молнией, и девиз, вырезанный на граните так, чтобы его невозможно было отрефакторить: «Не деплой в пятницу». Внутри меня встретила девушка в мантии, похожей на худи с капюшоном, и сказала:

https://habr.com/ru/articles/1022326/

#React_Native #стартап #мобильное_приложение #поиск_команды #хакатоны #нетворкинг #frontend

Хроники Облачного княжества: как я приручал монолит‑дракона

Часть 1. Когда я шёл в DevOps, я думал, что буду приручать серверы. Оказалось — людей, процессы и древнего дракона по имени Легаси. Я пришёл в Башню релизов ровно в девять ноль‑ноль — как человек, который ещё верит в расписание. Башня стояла на холме, укрытая облаками и корпоративными ценностями. Над входом висел герб: три кольца, перечёркнутые молнией, и девиз, вырезанный на граните так, чтобы его невозможно было отрефакторить: «Не деплой в пятницу». Внутри меня встретила девушка в мантии, похожей на худи с капюшоном, и сказала:

https://habr.com/ru/articles/1022326/

#React_Native #стартап #мобильное_приложение #поиск_команды #хакатоны #нетворкинг #frontend

Хроники Облачного княжества: как я приручал монолит‑дракона

Часть 1. Когда я шёл в DevOps, я думал, что буду приручать серверы. Оказалось — людей, процессы и древнего дракона по имени Легаси. Я пришёл в Башню релизов ровно в девять ноль‑ноль — как человек, который ещё верит в расписание. Башня стояла на холме, укрытая облаками и корпоративными ценностями. Над входом висел герб: три кольца, перечёркнутые молнией, и девиз, вырезанный на граните так, чтобы его невозможно было отрефакторить: «Не деплой в пятницу». Внутри меня встретила девушка в мантии, похожей на худи с капюшоном, и сказала:

https://habr.com/ru/articles/1022326/

#React_Native #стартап #мобильное_приложение #поиск_команды #хакатоны #нетворкинг #frontend

Хроники Облачного княжества: как я приручал монолит‑дракона

Часть 1. Когда я шёл в DevOps, я думал, что буду приручать серверы. Оказалось — людей, процессы и древнего дракона по имени Легаси. Я пришёл в Башню релизов ровно в девять ноль‑ноль — как человек, который ещё верит в расписание. Башня стояла на холме, укрытая облаками и корпоративными ценностями. Над входом висел герб: три кольца, перечёркнутые молнией, и девиз, вырезанный на граните так, чтобы его невозможно было отрефакторить: «Не деплой в пятницу». Внутри меня встретила девушка в мантии, похожей на худи с капюшоном, и сказала:

https://habr.com/ru/articles/1022326/

#React_Native #стартап #мобильное_приложение #поиск_команды #хакатоны #нетворкинг #frontend

[Перевод] Ключ от всех дверей: как я взломал все электросамокаты одного производителя

Несколько лет назад я решил купить электросамокат, чтобы ездить на работу. Я уже какое-то время пользовался прокатом самокатов, но устал от необходимости «охоты» на них или отсутствия их рядом с домом, когда мне нужно было ехать в офис. Мой выбор остановился на Äike T. Не потому, что он оказался лучше других самокатов: на самом деле, его цена была даже выше других, и в этом ценовом сегменте рынка явно имелись скутеры с более высокими параметрами. Однако я выбрал Äike, потому что его производили в моей стране, а мне нравится по возможности поддерживать местные компании. Äike («молния» на эстонском) был спроектирован и изготавливался в Эстонии, прямо в Таллине. Насколько я могу судить, разработчики использовали не так много стандартных компонентов. Конструкция была разработана с нуля, модуль IoT и аккумуляторные блоки тоже производили локально, и так далее. Нельзя сказать, что это однозначно лучше, ведь при этом усложняется обслуживание самоката, но сам продукт мне показался амбициозным. Ещё одной причиной покупки стало то, что у производителя была сестринская компания Tuul («ветер» на эстонском), занимавшаяся прокатом электросамокатов. Это тоже были скутеры Äike, и из всех конкурентов мне больше всего нравились Tuul/Äike, поэтому я по возможности пользовался их прокатом. В прошлом году компания Äike обанкротилась . В будущем это не предвещало ничего хорошего: станет всё сложнее находить запчасти, ведь они были нестандартными. Но возникли у меня и более актуальные опасения, связанные с возможностью пользоваться самокатом. У него нет ручной функции включения/отключения. Для включения и выключения, открывания аккумуляторного отсека, переключения в режим транспорта и так далее необходимо было приложение.

https://habr.com/ru/companies/ruvds/articles/1012440/

#internet_of_things #iot #электросамокаты #react_native #ruvds_перевод

[Перевод] Ключ от всех дверей: как я взломал все электросамокаты одного производителя

Несколько лет назад я решил купить электросамокат, чтобы ездить на работу. Я уже какое-то время пользовался прокатом самокатов, но устал от необходимости «охоты» на них или отсутствия их рядом с домом, когда мне нужно было ехать в офис. Мой выбор остановился на Äike T. Не потому, что он оказался лучше других самокатов: на самом деле, его цена была даже выше других, и в этом ценовом сегменте рынка явно имелись скутеры с более высокими параметрами. Однако я выбрал Äike, потому что его производили в моей стране, а мне нравится по возможности поддерживать местные компании. Äike («молния» на эстонском) был спроектирован и изготавливался в Эстонии, прямо в Таллине. Насколько я могу судить, разработчики использовали не так много стандартных компонентов. Конструкция была разработана с нуля, модуль IoT и аккумуляторные блоки тоже производили локально, и так далее. Нельзя сказать, что это однозначно лучше, ведь при этом усложняется обслуживание самоката, но сам продукт мне показался амбициозным. Ещё одной причиной покупки стало то, что у производителя была сестринская компания Tuul («ветер» на эстонском), занимавшаяся прокатом электросамокатов. Это тоже были скутеры Äike, и из всех конкурентов мне больше всего нравились Tuul/Äike, поэтому я по возможности пользовался их прокатом. В прошлом году компания Äike обанкротилась . В будущем это не предвещало ничего хорошего: станет всё сложнее находить запчасти, ведь они были нестандартными. Но возникли у меня и более актуальные опасения, связанные с возможностью пользоваться самокатом. У него нет ручной функции включения/отключения. Для включения и выключения, открывания аккумуляторного отсека, переключения в режим транспорта и так далее необходимо было приложение.

https://habr.com/ru/companies/ruvds/articles/1012440/

#internet_of_things #iot #электросамокаты #react_native #ruvds_перевод

[Перевод] Ключ от всех дверей: как я взломал все электросамокаты одного производителя

Несколько лет назад я решил купить электросамокат, чтобы ездить на работу. Я уже какое-то время пользовался прокатом самокатов, но устал от необходимости «охоты» на них или отсутствия их рядом с домом, когда мне нужно было ехать в офис. Мой выбор остановился на Äike T. Не потому, что он оказался лучше других самокатов: на самом деле, его цена была даже выше других, и в этом ценовом сегменте рынка явно имелись скутеры с более высокими параметрами. Однако я выбрал Äike, потому что его производили в моей стране, а мне нравится по возможности поддерживать местные компании. Äike («молния» на эстонском) был спроектирован и изготавливался в Эстонии, прямо в Таллине. Насколько я могу судить, разработчики использовали не так много стандартных компонентов. Конструкция была разработана с нуля, модуль IoT и аккумуляторные блоки тоже производили локально, и так далее. Нельзя сказать, что это однозначно лучше, ведь при этом усложняется обслуживание самоката, но сам продукт мне показался амбициозным. Ещё одной причиной покупки стало то, что у производителя была сестринская компания Tuul («ветер» на эстонском), занимавшаяся прокатом электросамокатов. Это тоже были скутеры Äike, и из всех конкурентов мне больше всего нравились Tuul/Äike, поэтому я по возможности пользовался их прокатом. В прошлом году компания Äike обанкротилась . В будущем это не предвещало ничего хорошего: станет всё сложнее находить запчасти, ведь они были нестандартными. Но возникли у меня и более актуальные опасения, связанные с возможностью пользоваться самокатом. У него нет ручной функции включения/отключения. Для включения и выключения, открывания аккумуляторного отсека, переключения в режим транспорта и так далее необходимо было приложение.

https://habr.com/ru/companies/ruvds/articles/1012440/

#internet_of_things #iot #электросамокаты #react_native #ruvds_перевод

[Перевод] Ключ от всех дверей: как я взломал все электросамокаты одного производителя

Несколько лет назад я решил купить электросамокат, чтобы ездить на работу. Я уже какое-то время пользовался прокатом самокатов, но устал от необходимости «охоты» на них или отсутствия их рядом с домом, когда мне нужно было ехать в офис. Мой выбор остановился на Äike T. Не потому, что он оказался лучше других самокатов: на самом деле, его цена была даже выше других, и в этом ценовом сегменте рынка явно имелись скутеры с более высокими параметрами. Однако я выбрал Äike, потому что его производили в моей стране, а мне нравится по возможности поддерживать местные компании. Äike («молния» на эстонском) был спроектирован и изготавливался в Эстонии, прямо в Таллине. Насколько я могу судить, разработчики использовали не так много стандартных компонентов. Конструкция была разработана с нуля, модуль IoT и аккумуляторные блоки тоже производили локально, и так далее. Нельзя сказать, что это однозначно лучше, ведь при этом усложняется обслуживание самоката, но сам продукт мне показался амбициозным. Ещё одной причиной покупки стало то, что у производителя была сестринская компания Tuul («ветер» на эстонском), занимавшаяся прокатом электросамокатов. Это тоже были скутеры Äike, и из всех конкурентов мне больше всего нравились Tuul/Äike, поэтому я по возможности пользовался их прокатом. В прошлом году компания Äike обанкротилась . В будущем это не предвещало ничего хорошего: станет всё сложнее находить запчасти, ведь они были нестандартными. Но возникли у меня и более актуальные опасения, связанные с возможностью пользоваться самокатом. У него нет ручной функции включения/отключения. Для включения и выключения, открывания аккумуляторного отсека, переключения в режим транспорта и так далее необходимо было приложение.

https://habr.com/ru/companies/ruvds/articles/1012440/

#internet_of_things #iot #электросамокаты #react_native #ruvds_перевод

Как мы написали React Native библиотеку для Яндекс Карт за два дня с Claude

Сначала коротко о том, зачем нам это было нужно. Мы в основном пилим решения для фудтеха, а для мобилок используем React Native (почему, рассказывали тут ). В одном из таких проектов (российская сеть ресторанов по франшизе) нам нужно было прикрутить Яндекс Карты. Изначально хотели взять либу react-native-yamap (респект тем, кто ее делал) — но как выяснилось, она работает только на старой архитектуре RN. После обновления до 0.76 версии, где Fabric стала использоваться по умолчанию, приложения на iOS начали падать: карта не рендерится, события не доходят до JS, приложение крашится при взаимодействии с картой и вот это вот всё. И судя по открытым тикетам, мы не одни, кто столкнулся с этой проблемой. Полезли искать, написал ли кто-то уже библиотеку под новую архитектуру — но либо таких людей нет, либо ни с кем не делятся. Спойлер: мы пока тоже не будем, ещё обкатываем либу на своих проектах — но уже сейчас хотим рассказать, как собрали новый пакет с помощью Claude Code за два дня.

https://habr.com/ru/articles/1004576/

#React_Native #Яндекс_Карты #Fabric #TurboModules #Codegen #Claude #iOS #Android #нативные_модули #новая_архитектура

Как мы написали React Native библиотеку для Яндекс Карт за два дня с Claude

Сначала коротко о том, зачем нам это было нужно. Мы в основном пилим решения для фудтеха, а для мобилок используем React Native (почему, рассказывали тут ). В одном из таких проектов (российская сеть ресторанов по франшизе) нам нужно было прикрутить Яндекс Карты. Изначально хотели взять либу react-native-yamap (респект тем, кто ее делал) — но как выяснилось, она работает только на старой архитектуре RN. После обновления до 0.76 версии, где Fabric стала использоваться по умолчанию, приложения на iOS начали падать: карта не рендерится, события не доходят до JS, приложение крашится при взаимодействии с картой и вот это вот всё. И судя по открытым тикетам, мы не одни, кто столкнулся с этой проблемой. Полезли искать, написал ли кто-то уже библиотеку под новую архитектуру — но либо таких людей нет, либо ни с кем не делятся. Спойлер: мы пока тоже не будем, ещё обкатываем либу на своих проектах — но уже сейчас хотим рассказать, как собрали новый пакет с помощью Claude Code за два дня.

https://habr.com/ru/articles/1004576/

#React_Native #Яндекс_Карты #Fabric #TurboModules #Codegen #Claude #iOS #Android #нативные_модули #новая_архитектура

Как мы написали React Native библиотеку для Яндекс Карт за два дня с Claude

Сначала коротко о том, зачем нам это было нужно. Мы в основном пилим решения для фудтеха, а для мобилок используем React Native (почему, рассказывали тут ). В одном из таких проектов (российская сеть ресторанов по франшизе) нам нужно было прикрутить Яндекс Карты. Изначально хотели взять либу react-native-yamap (респект тем, кто ее делал) — но как выяснилось, она работает только на старой архитектуре RN. После обновления до 0.76 версии, где Fabric стала использоваться по умолчанию, приложения на iOS начали падать: карта не рендерится, события не доходят до JS, приложение крашится при взаимодействии с картой и вот это вот всё. И судя по открытым тикетам, мы не одни, кто столкнулся с этой проблемой. Полезли искать, написал ли кто-то уже библиотеку под новую архитектуру — но либо таких людей нет, либо ни с кем не делятся. Спойлер: мы пока тоже не будем, ещё обкатываем либу на своих проектах — но уже сейчас хотим рассказать, как собрали новый пакет с помощью Claude Code за два дня.

https://habr.com/ru/articles/1004576/

#React_Native #Яндекс_Карты #Fabric #TurboModules #Codegen #Claude #iOS #Android #нативные_модули #новая_архитектура

Как мы написали React Native библиотеку для Яндекс Карт за два дня с Claude

Сначала коротко о том, зачем нам это было нужно. Мы в основном пилим решения для фудтеха, а для мобилок используем React Native (почему, рассказывали тут ). В одном из таких проектов (российская сеть ресторанов по франшизе) нам нужно было прикрутить Яндекс Карты. Изначально хотели взять либу react-native-yamap (респект тем, кто ее делал) — но как выяснилось, она работает только на старой архитектуре RN. После обновления до 0.76 версии, где Fabric стала использоваться по умолчанию, приложения на iOS начали падать: карта не рендерится, события не доходят до JS, приложение крашится при взаимодействии с картой и вот это вот всё. И судя по открытым тикетам, мы не одни, кто столкнулся с этой проблемой. Полезли искать, написал ли кто-то уже библиотеку под новую архитектуру — но либо таких людей нет, либо ни с кем не делятся. Спойлер: мы пока тоже не будем, ещё обкатываем либу на своих проектах — но уже сейчас хотим рассказать, как собрали новый пакет с помощью Claude Code за два дня.

https://habr.com/ru/articles/1004576/

#React_Native #Яндекс_Карты #Fabric #TurboModules #Codegen #Claude #iOS #Android #нативные_модули #новая_архитектура

Выставить приложение в плей маркет и быть заблокированным через месяц

Мы хотели запустить приложение в нише 18+ всего за неделю. Звучало как идеальный план, но на деле это вылилось в три года работы и вечный бан в Google Play. В статье я расскажу, как мы пытались обмануть систему, набивали шишки с React Native и в итоге заменили отдел маркетинга на скрипты в n8n. Это история о том, как потерять аккаунт разработчика, но все-таки построить прибыльный продукт

https://habr.com/ru/articles/993448/

#react #expo #react_native #мобильная_разработка #приложения_на_ios #приложения_на_андройд #дизайн_приложений #аналитика_приложений

Выставить приложение в плей маркет и быть заблокированным через месяц

Мы хотели запустить приложение в нише 18+ всего за неделю. Звучало как идеальный план, но на деле это вылилось в три года работы и вечный бан в Google Play. В статье я расскажу, как мы пытались обмануть систему, набивали шишки с React Native и в итоге заменили отдел маркетинга на скрипты в n8n. Это история о том, как потерять аккаунт разработчика, но все-таки построить прибыльный продукт

https://habr.com/ru/articles/993448/

#react #expo #react_native #мобильная_разработка #приложения_на_ios #приложения_на_андройд #дизайн_приложений #аналитика_приложений

Выставить приложение в плей маркет и быть заблокированным через месяц

Мы хотели запустить приложение в нише 18+ всего за неделю. Звучало как идеальный план, но на деле это вылилось в три года работы и вечный бан в Google Play. В статье я расскажу, как мы пытались обмануть систему, набивали шишки с React Native и в итоге заменили отдел маркетинга на скрипты в n8n. Это история о том, как потерять аккаунт разработчика, но все-таки построить прибыльный продукт

https://habr.com/ru/articles/993448/

#react #expo #react_native #мобильная_разработка #приложения_на_ios #приложения_на_андройд #дизайн_приложений #аналитика_приложений

Выставить приложение в плей маркет и быть заблокированным через месяц

Мы хотели запустить приложение в нише 18+ всего за неделю. Звучало как идеальный план, но на деле это вылилось в три года работы и вечный бан в Google Play. В статье я расскажу, как мы пытались обмануть систему, набивали шишки с React Native и в итоге заменили отдел маркетинга на скрипты в n8n. Это история о том, как потерять аккаунт разработчика, но все-таки построить прибыльный продукт

https://habr.com/ru/articles/993448/

#react #expo #react_native #мобильная_разработка #приложения_на_ios #приложения_на_андройд #дизайн_приложений #аналитика_приложений

React Native. Часть 2: Bare Workflow, Expo, стили и платформенные особенности

В первой части мы разобрали эволюцию архитектуры React Native. Теперь перейдем к практическим вопросам: как организован процесс разработки и какие платформенные особенности встретятся в работе. Процесс разработки Выбор между классическим подходом и Expo – одно из первых архитектурных решений в проекте. Разберем оба варианта. Bare React Native Процесс требует настройки окружения (Xcode для iOS, Android Studio для Android). В упрощенном виде процесс запуска приложения для разработки выглядит следующим образом:

https://habr.com/ru/articles/990818/

#React_Native #Expo #EAS #Стилизация #Мобильная_разработка #Bare

Подборка атак через библиотеки: CVE в React Native и не только

Итак, 5 ноября команда JFrog опубликовала предупреждение об уязвимости CVE-2025-11953 в инструментах командной строки проекта React Native Community CLI. React Native — это платформа которую используют тысячи разработчиков для создания мобильных приложений, которые мы видим в App Store или Google Play. А React Native Community CLI через командную строку предоставляет инструменты для разработки и сборки этих приложений, куда как раз и входил злополучный пакет. На первый взгляд, это еще один CVE в длинном списке. Но проблема глубже: уязвимость в популярном пакете может затронуть сотни проектов одновременно и ударить не только по продакшену, но и по устройствам разработчиков и CI-пайплайнам. В статье разберем, как библиотеки из удобных помощников превращаются в точку входа для злоумышленников, почему такие инциденты не решаются простым апдейтом и какие механики атак через зависимости встречаются чаще всего. В конце обсудим дилемму — стоит ли вообще полагаться на сторонние фреймворки или лучше писать нативно. Детали под катом.

https://habr.com/ru/companies/selectel/articles/979572/

#selectel #информационная_безопасность #уязвимости #CVE #информационные_технологии #фреймворки #атаки_на_библиотеки #атаки_на_инфраструктуру #React_Native

Написать приложение без опыта. Часть 1. Вводная

Отпуск, целых две недели, без программирования. К вечеру первого дня уже не знал чем себя занять. Работать мне запретили.. гады. Как ещё может отдыхать программист? Делать новый pet-project. Надеюсь на картинке не я...

https://habr.com/ru/articles/973068/

#flutter #react_native #мобильная_разработка #petproject

Какой фреймворк выбрать для MVP стартапа: опыт разработчика и фаундера

Автор: разработчик и фаундер с опытом запуска стартапов в сферах туризма , HR tech , а сейчас — в музыкальной индустрии . По образованию — Data Scientist , по призванию — Android-разработчик и продукт-менеджер . Работал в крупных продуктах вроде X5 и Uzum , где впервые познакомился с Kotlin Multiplatform Mobile (KMM) . Когда настал момент создавать прототип для своего музыкального стартапа, выбор был очевиден: я уже знал Kotlin , имел боевой опыт с KMM — и хотел быстро двигаться без лишних компромиссов. Но KMM — не единственный путь. На столе были и Flutter , и React Native , и даже классическая нативка . В этой статье я расскажу:

https://habr.com/ru/articles/902336/

#kotlin_multiplatform #android #ios #react_native #flutter #kotlin #software_engineering #multiplatform #startups #startup

Подстраиваемся под новые требования Google: переходим на 16 KB memory page (гайд для разработчиков React Native)

Ну как, вы уже обновили свои приложения для поддержки новых требований Google? Если нет, то эта статья будет вам особенно полезна =) Напомню, что с 1 ноября 2025 года приложения, таргетирующиеся Android 15 и выше, должны поддерживать 16-килобайтные страницы памяти . Как вы помните по предыдущим статьям, я работаю в МойОфис в команде разработки мобильной версии высоконагруженного корпоративного мессенджера Squadus (бэкенд на Node.js, NestJS и Meteor, а веб-интерфейс на React). Мы уже успешно перестроились на новые стандарты Google, и поэтому могу компетентно рассказать, что именно требуется, как адаптировать под это React Native-приложение и что делать, если используемая библиотека ещё не успела обновиться.

https://habr.com/ru/companies/ncloudtech/articles/960520/

#react_native #mobile_development #google #android #мобильная_разработка

React Native тормозит? Проверь эти 8 узких мест в производительности, прежде чем винить фреймворк [ЧЕК-ЛИСТ]

Идея этой статьи родилась во время задушевных разговоров на кухне и за утренним кофе с коллегами. Началось все с вопроса: «Чтобы ты бы сказал себе прошлому, чтобы релизы стали легче, а спринты прекраснее?» Конечно, в тот момент я ничего дельного не ответил, но, кажется, наконец-то сформулировал идеальную фразу: «Настоящий разработчик, Слав, это не тот, кто с сияющим макбуком и вкусным смузи. Разработчик — тот, кто делает то, что нужно сделать. И в легаси покопаться приходится, и memory leak дебажить, а он всё равно делает, потому что так надо». Привет, Хабр! Меня зовут Вячеслав Чащухин, я — разработчик в МойОфис. Занимаюсь мобильной версией

https://habr.com/ru/companies/ncloudtech/articles/914244/

#React_Native #crossplatform #mobile_development #crossplatform_mobile_programming #performance #react #мойофис #reactjs #reactjs