Ох, Ольга, как же вы правы! Начать сэкономить на разработке, это прям мечта, а тут кроссплатформенность так и манит, ага. Но мне вот что накипело: ведь кроме тех очевидных рисков, что мы уже обсудили, есть еще всякие мелочи, которые потом в копеечку влетают! Ну вот, например, производительность. Она ж может страдать, особенно если приложение сложное, с кучей анимаций или обработкой данных в реальном времени. Пользователи же не будут ждать, пока оно там загрузится, уйдут к конкурентам, ну и все… А еще бывает что для какой-то специфической фичи платформы (ну, знаете, там, какие-то фишки iOS или Android) приходится писать нативный код в дополнение, и тогда вся эта "экономия" куда-то улетучивается, как будто ее и не было никогда… Вот такие дела, переживаю жутко, когда думаю о таких вот неожиданных проблемах

Марго, чертовски точно подметила насчет производительности. Это ж пррям классика жанра с кроссплатформой.

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

Разбирались, копались в нативном коде, профилировали. Оказалось, что мост между JS (или Dart, в случае Flutter) и нативным кодом, который отвечает за доступ к железу, просто не справлялся с такой нагрузкой. Потери пакетов, задержки, все дела. В итоге пришлось оптимизировать прямо на уровне нативных модулей, что, по сути, сводит на нет всю экономию от кроссплатформенности.)

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

BugHunter сказал(а):

Марго, чертовски точно подметила насчет производительности. Это ж пррям классика жанра с кроссплатформой. Вот прям помню, как на одном проекте пилили мобильный…

BugHunter, вот прям в точку про производительность! Я сама это проходила, когда мы с командой пытались запилить приложение для учета детских садов на Xamarin. Ну, типа, задумка была такая, чтобы и на iOS, и на Android одна кодовая база работала. И ведь сначала все шло как по маслу, выглядело красиво. Но когда дело дошло до обработки большого количества данных, вся эта "экономия" как-то начала превращаться в головную боль... приложения тормозили, а на старых устройствах вообще еле дышали. Так что да, универсальность, это, конечно, здорово, но иногда лучше не гнаться за ней слепо, а выбрать нативный подход, чтобы потом не переделывать все с нуля.))

BugHunter, да, производительность, это отдельная песня! Особенно когда дело доходит до работы с железом напрямую. С нативными платформами таких проблем, конечно, меньше, потому что там все заточено под конкретную ОС.

Но вот что я заметил на практике: кроссплатформенность реально спасает, когда нужно быстро вывести MVP на рынок и протестировать гипотезу. На одном из прошлых проектов мы так запустили приложение для управления складом. затраты на разработку для iOS и Android сократились чуть ли не вдвое, а время выхода на рынок, на месяц. Это был прям выигрыш!

Мудрый_Сергей сказал(а):

BugHunter, да, производительность, это отдельная песня! Особенно когда дело доходит до работы с железом напрямую. С нативными платформами таких проблем,…

BugHunter, интересно, а какой именно функционал сканера штрихкодов вызывал наибольшие трудности с производительностью? Вот прям интересно, как это проявлялось: тормоза при сканировании, большая задержка между считыванием и отображением данных, или что-то другое? Ведь сама по себе обработка штрихкода, если не ошибаюсь, это довольно ресурсоемкая задача, особенно если речь идет о большом потоке данных в реальном времени. Хотелось бы узнать, какие именно "узкие места" вы тогда обнаружили.