🚀 История о том, как Профи.ру переезжали на React Native
Давайте сразу сделаю дисклеймер, я хорошу отношусь в целом к RN и понимаю что есть области где их применение оправдано и эффективно. Так же я не видел в своем опыте ни одного удачного кейса миграции B2C приложений с натива на RN. Каждый раз эффективные менеджеры или CTO продают эту идею CPO именно так как в статье, получают квоты, финансирование, бонусы, а в итоге теряют в UX пользователей и стоимость поддержки оказывается не такой уж дешевой как на бумаге. После этой вводной готов поделиться историей автора:

Начало. Большая мечта
🔵Компания хотела стать масштабным маркетплейсом и вырасти в 10 раз.
🔵Для этого решили радикально повысить скорость разработки.
🔵У компании были два основных продукта: бэк-офис и клиентское приложение.

Выбор React Native
🔵Бэкенд переезжал на Node.js, фронт был на React.
🔵Решили использовать TypeScript для единого стека.
🔵Переход к нескольким департаментам вместо разделения по технологиям.

Часть 1. Бэк-офис. История успеха
🔵Переезд бэк-офиса на React Native прошёл быстро и безболезненно.
🔵Команда из 2–3 энтузиастов переписала приложение за несколько месяцев.
🔵Горизонтальная структура ускорила работу команд.

Часть 2. Ожидание vs реальность
🔵Решили переписать клиентское приложение на React Native.
🔵Надеялись на гладкую миграцию, но столкнулись с проблемами.

Проблемы с производительностью
🔴Лаги и подвисания из-за мостика между нативом и RN.
🔴Сложные анимации требовали постоянного обмена сообщениями, что приводило к задержкам.

Проблемы с экосистемой
🔴Небольшое и молодое комьюнити React Native.
🔴Отсутствие библиотек для некоторых функций, например, для яндекс-карты и сплеш-скрина.
🔴Приходилось писать собственные модули.

Проблемы с обновлениями
🔴React Native в версии 0.х.х, каждое обновление может сломать код.
🔴Обновления требуют много времени и ресурсов.
🔴Apple и Google ужесточают требования к версиям SDK.

Альтернативы и выводы
🟣Рассматривали Flutter, но отказались из-за потери универсальности разработчиков.
🟣Плюсы: прокачали разработчиков, ускорили разработку, сэкономили ресурсы.
🟣Минусы: много времени на обновления, риск выгорания, упрощение фич.
🟣Несмотря на минусы, команда справляется благодаря гибкости и настойчивости.

🐥 Быстрое создание миниатюр с помощью CGImageSource
При работе с изображениями нам редко нужно показывать их в полном размере — чаще всего это миниатюры или превью. Использование для этого полностью загруженных изображений не эффективно, поэтому мы часто прибегают к кешированию миниатюр. Тестирование производительности:
🔴Создание миниатюры 12-мегапиксельного JPEG на Mac M4 Pro занимает 710 мс
🟢На симуляторе iOS с UIGraphicsImageRenderer это занимает 210 мс
🟢Функция UIImage.prepareThumbnail() для iOS уменьшает время до 130 мс
🟢На macOS такой функции нет. Но есть CGImageSourceCreateThumbnailAtIndex() - время создания миниатюры на macOS сократилось до 26 мс
🟢UIImage имеет две реализации миниатюр: одна для CGImage, другая для CGImageSource
🟢CGImageSource работает быстрее, чем CGImageCreateThumb()

Если в вашем проекте есть создание миниатюр, проверьте что используете эффективные методы