Артем Зайцев
К сожалению, только по ссылке в сторе, вряд ли. Лучше обратится в компании или к конкретным разработчикам.
В отличии от многих продуктов Гугла Flutter - это опенсорс. Убить его в привычном смысле невозможно.
Так же если посмотреть на слухи о той же Фуксии - она должна поддерживать Флаттер из коробки, а это уже кажется долгоиграющей песней.
В данном случае: потому что Xamarin не настолько популярен. Все же основная война - между Flutter и RN.
Плюс, насколько я знаю даже майки используют тот же RN вместо Xamarin в своих проектах(пример Скайп).
Разработчики выпускали первую версию в достаточно короткие сроки(не факт, что натив бы успел в такие). Это часто важно для бизнеса.
Да и видимо аудиторию приложения устраивает производительность на данный момент.
И, думаю, сейчас ведутся работы по его улучшению.
Это как один из вариантов. Согласен, что вполне возможный.
Но он влечет небольшой нюанс: придется писать "проброс" бизнес-логики. Это не всегда удобно. Но в целом, уже есть подобные эксперименты.
В целом, тут вопрос что понимать под сложностью.
Соглашусь: приложения полностью построенные на AR или на использовании камеры сейчас наверно будет менее больно делать на нативных решениях.
В остальном, многие кейсы Flutter покрывает.
Они использовали React какое-то время и отказались.
Да, такое на вполне возможно реализовать. Даже, кажется, на Flutter это будет быстрее и удобнее, так как дизайн здесь отступает от официальных гайдов, следовательно может быть один на обе платформы.
Плюс, судя по тематике, общения с "платформой" здесь в принципе нет. И это так же плюс к варианту реализации на кроссплатформе.
Дополнительный, а не отдельный.
Надо уточнить, что наличие такого "платформенного" кода крайне мало и далеко не всегда есть. Скорее есть некоторые платформенные настройки и конфигурации.
А 4 разработчик нужен также для усиления команды, если необходимо адаптировать дизайн. Верстать все же придется под конкретную платформу в таком случае, но на том же Flutter.
Dart. Не JavaScript. Формально похож, но это другой язык.
Есть куча библиотек для графиков и диаграмм.
Есть либы для svg.
Так же полный аналог Retrofit для REST, реализация для GRPC, уже готовые решения для БД и тд.
Да, к сожалению пока только добираемся до Kotlin MPP. Ну и пока он еще в experimental статусе.
Но ниже в коментах я уже указал, что МПП - это тема для команд от двух, а лучше трех разработчиков и проектов заточенных под гайды платформы.
До Flutter смотрел на кроссплатформу как на цирк.
После, понял что это инструмент, который позволяет упростить и удешевить разработку без потери качества(при наличии опыта и квалификации).
Да, есть ограничения. Но для достаточно обширных сфер( ритейл, екомм, банкинг, приложения не требующие жесткой оптимизации на уровне железа) - это выгодно. Команда дешевле и команде проще.
По поводу гайдов: сейчас часто наблюдаю даже нативные приложения, которые отходят от гайдов конкретной платформы. Есть много brand first design приложений. Здесь Flutter также позволит уменьшить стоимость разработки.
По поводу оценок.
Приложение написанное на Flutter в AppStore с 4.7 (https://apps.apple.com/ru/app/%D1%80%D0%B8%D0%B3%D0%BB%D0%B0-%D0%B0%D0%BF%D1%82%D0%B5%D1%87%D0%BD%D0%B0%D1%8F-%D1%81%D0%B5%D1%82%D1%8C/id1505062873 )
Приложение, которое бывало в топах апп стора: https://apps.apple.com/ru/app/reflectly-self-care-journal/id1241229134
Качество часто зависит от рук разработчиков. И натив - это не панацея от оценки в три звезды.
1) Думаю надо поставить вопрос как "хороший мобильный разработчик" должен быть писателем плагинов. Тут человек на начальном этапе может без опыта натива, но он должен готов его приобрести.
А в остальном: Flutter - это инструмент. Кому-то он может не подойти, а кому-то наоборот. Понятное дело, что он имеет свои ограничения, как и любой другой.
Вот недавно посмотрел на Kotlin MPP(снова, с тех пор как появился флаттер), и для себя сделал вывод: это решение для комплексной команды(как минимум два нативных разраба, Android еще и общую часть может делать). При этом на Flutter проект можно сделать в одного(так как везде один язык), особенно если приложение не имеет большого количества нативных фич.
Но в целом котлин приятен.
Как и обычно, но больше делаем уклон на собеседованиях в сторону мышления соискателя. Не настолько важно глубокое знание языка, сколько понимание как решить фундаментально те или иные задачи.
Далее у нас есть вводный курс на начальном этапе работы у нас.
А когда рефлексия стала таким частым кейсом?
Из примеров: тот же Dagger в Android давненько ушел от рефлексии к кодгену. По причине, что рефлексия - отличный шанс стрельнуть себе в ногу. Плюс, насколько мне не изменяет память, это одна из причин "медленности" той же Java(тут могу, честно, ошибаться).
Да и частый кейс использования рефлексии в Java - узнать ::class. В Dart типы существуют в рантайме, и спокойно берутся без нее. Ну и к слову в самом языке рефлексия то есть. Запретили ее именно во фреймворке, чтобы не замедлять.
По поводу популярности: судя по трендам stack overflow/Google trends Flutter опережает тот же React. Это конечно лишь относительно реакта.
Но несомненен рост мобильного коммьюнити. Интерес аудитории очень сильно растет - это заметно по количеству докладов на специализированных конференциях, откликах на вакансии, количеству таковых.
Да в моменте - это явно ниже "натива". Но тому уже лет 10:)
А вот динамика и будущее фреймворка пока говорит о вполне реальном росте специалистов.
И сразу замечу: я не имею ввиду, что нативные разработчики не нужны и не будут нужны. Они нужны и очень сильно. Но там где действительно все сложно и надо работать на достаточно близком уровне к ОС. Для всего остального есть более высокоуровневые инструменты.