Comments 4
Хорошая формула про одну продуктовую модель и осознанно выбранные нативные участки. На границе native -> TypeScript я бы только не оставлял payload как Record<string, unknown>, особенно для push и background-событий. Такое событие может пережить процесс приложения, прийти повторно после холодного старта или быть обработано уже новой версией JS-кода после обновления. У нас в таких контрактах полезны eventId, schemaVersion и типизированный payload для каждого вида события, а перед внешним эффектом - дедупликация по eventId. Тогда можно отдельно тестировать не только симметрию iOS и Android, но и совместимость сохранённых событий между версиями приложения. Версионируете ли вы native -> TS контракт и проверяете ли сценарий, когда старое событие доставляется уже после обновления клиента?
Отличный обзор! Мне как react native разработчику откликаются описанные проблемы. Про AI я бы от себя ещё добавил, что агентская разработка сделала дешёвым качественный UI/UX. Теперь агент сам за короткое время может добавлять и отлаживать разные механизмы взаимодействий внутри экрана, на что разработчику раньше приходилось тратить часы и дни. А то и вовсе разные "удобства" было проще убрать в бэклог, чем тратить на них ресурсы.
Очень смешной раздел про архитектуру. Вы правда проиграли когда выбрали реакт. Причем выше даже перечислили кучу проблем которые сразу из коробки поставляются...
Мб вам рано об архитектуре думать ?) Лучше взять хороший инструмент/фреймворк где об архитектуре уже подумали заранее и нет целых КЛАССОВ типичных проблем, как считаете ?
React Native в 2026 году: New Architecture, нативный код и AI в реальном проекте