Мы в Контур.Эльбе обожаем мобильные приложения. У нас уже был опыт написания приложения под iOS, а также разработки и дальнейшей поддержки приложения под Android. В этом году мы вновь выпустили версию под iOS, но на этот раз на базе Xamarin и Xamarin.Forms, и нам не терпится поделиться опытом. Пока что мы успели рассмотреть разработку только под iOS, но впечатлений уже море, да и про Android пару слов однозначно скажем.Что такое Xamarin
Фреймворк для кроссплатформенной разработки мобильных приложений на базе .NET (точнее, на реализации Mono), поддерживает все основные ОС — Android, iOS и Windows Phone. Подробнее на Хабре писалось неоднократно, повторяться нет нужды.
Что такое Xamarin.Forms
Фреймворк, позволяющий разрабатывать единую вёрстку интерфейса сразу под несколько указанных выше платформ. Идея такова: вёрстку вы делаете один раз на базе Xamarin-компонентов, а на целевой платформе для каждого из компонентов вызывается код-рендерер, рисующий уже родные компоненты. Саму вёрстку можно готовить как в коде, так и в XAML-формате. UI-утилиты для вёрстки и превью получающегося интерфейса, как и год назад, всё ещё нет, так что мы выбрали вариант создания UI из кода.
Почему мы выбрали именно Xamarin+Xamarin.Forms?
Причин было несколько.
- На сервере мы используем .NET и C#, поэтому довольно удобно использовать один язык и платформу для трёх приложений (сервер, iOS, Android) – нет необходимости переключаться с одного языка на другой, возможность использовать привычные паттерны, легко выделять общие фрагменты в библиотеки и т.п.
- Из доступных фреймворков Xamarin выглядел самым развитым.
- Вариант создания HTML5-приложения мы не рассматривали: в приложении планировалось множество форм, а нативные компоненты в этом плане работаю заметно предсказуемее и быстрее. Особенно актуально для недорогих Android-смартфонов.
- Xamarin.Forms порадовал потенциальной возможностью сделать с минимальными допилками общий интерфейс для Android и iOS, а также нёс ряд плюсов, например – привычную для нас блочную модель вёрстки на iOS.
Первая кровь
Начало общения с платной версии началось с косяка системы активации: в личном кабинет на сайте Xamarin уже было видно, что оплата (999$ или 799$ для подписчиков MSDN) произведена, а вот Xamarin.Studio упорно отказывалась билдить приложение, т.к. “платная версия не активирована”. Помогла только ручная активация оплаты технической поддержкой Xamarin. Ответили они быстро, но в любом случае это отличное начало, задавшее тон всему последующему проекту.
К слову, бесплатная ознакомительная версия не позволяет собрать приложение размером более 64 килобайт для скомпилированного кода. То есть подключаем, скажем, тот же json-сериализатор (Newtonsoft) – и собрать приложение уже нельзя. Мило.
Проблемы с IDE
Xamarin предоставляет собственную IDE Xamarin.Studio, основанную на базе MonoDevelop. К сожалению, эта IDE имеет ряд проблем:
- Нестабильность. Например, очень высок шанс зависания намертво при попытке прервать сборку приложения.
- Периодически ломается подсветка или автокомплит.
- Автодополнение не умеет искать классы, не входящие в текущее пространство имён, хотя по полностью написанному обращению к классу нужный using среда прописать может.
- Возможностей для рефакторинга явно не хватает, до Resharper’а ей в этом плане далеко.
- Периодически ломается интеграция с редактором XIB’ов (файлы вёрстки для iOS). Если вы используете вёрстку через XIB или Storyboard, то для редактирования открывается XCode, а по закрытию его – обновляются автосгенерированные классы, связанные с UI. Но не всегда. Иногда среда в принципе перестаёт вызывать XCode для некоторых или вообще всех файлов. Лечится очисткой кэша студии (удалением содержимого директории ~/Library/Caches/XamarinStudio-5.0).
Но есть и хорошие новости! На тарифе business есть интеграция с Visual Studio, позволяющая писать код там. Работает очень хорошо, с частью проблем, например такими, мы не сталкивались, видимо потому, что пока не работали с Android и XAML. Но зато столкнулись с другими.
Дело в том, для сборки iOS приложения нужен компьютер или виртуалка с Mac OS X. И тут у вас два варианта:
- собирать и отлаживать приложение из Xamarin Studio, запущенной на маке;
- использовать плагин для интеграции между Visual Studio и маком (билд-хостом), тогда процесс сборки и запуска на симуляторе можно запустить из VS, и там же отлаживать. Но картинка симулятора, если вы запускаете приложение на нём, всё равно рисуется только на Маке, так что вам придётся сидеть рядом с двумя ПК разом, тестируя приложение на одном и работая в отладчике на другом.
Более того, плагин для интеграции долгое время работал нестабильно. У нас периодически возникала такая ситуация: три разработчика, у всех одна и та же версия ОС, студии, Xamarin'а и так далее. Подключаются по очереди к одному и тому же маку. В результате у одного всё работает нормально, у второго игнорируются break-point'ы, а у третьего не работает совсем.
Техническая поддержка посоветовала попробовать последние 4 версии под Mac и Windows, “может быть какое-нибудь сочетание заработает”. Установка занимает минут 20-30, т.к. инсталлятор скачивает даже те компоненты (например, библиотеки Android SDK), которые уже скачивал прошлый раз. Вот и думайте…
Но даже если плагин заработает нормально, при следующем открытии проекта в Visual Studio у вас будет отключена сеть или, например, выключен Mac – плагин с некоторой вероятностью сможет подвиснуть на поисках билдхоста. И «отмена» далеко не всегда срабатывает, один раз пришлось лезть в системный реестр и там удалять сохранённые параметры билд-хоста.
Поэтому мы долгое время работали так:
- Код лежит в сетевой папке, доступной на Mac’е и в запущенной на нём же виртуальной машине Parallels с Windows;
- Основная часть кода пишется в Visual Studio под Windows внутри этой виртуалки;
- Отладка или сборка финальной версии происходит в Xamarin.Studio на Mac OS X, но не через плагин, а через ручное открытие того же кода в общей папке.
Ну и из мелких неприятностей: при каждом открытии проекта с iOS плагин будет предлагать подключиться к билд.хосту, блокируя дальнейшую загрузку проекта до ответа на вопрос.
К счастью, после многих месяцев мучений, команда Xamarin сжалилась над нами. Последнее обновление Xamarin.Studio эту проблему решила – теперь в окошке подключения к удаленному маку появилась галочка “не показывать окно подключения”.
А, ну и ещё удаленный билд теперь делает не через собственную Xamarin’овскую утилиту, а через обычных удаленных пользователей на Mac OS X:
Как результат — соединение стало довольно стабильным и отладка нормально запускается в 8 случаях из 10. Но в любом случае симулятор запускается на другом ПК, т.е. дебаг идёт на вашей машине, а приложение запущено где-то там, картинка не выводится на вашем ПК. Можно открыть удалённый сеанс или держать второй компьютер на том же столе.
Решение всё равно остаётся несколько костыльным, но оно позволяет полностью отказаться от использования Xamarin Studio! Поверьте, после нескольких месяцев жизни в ней можем сказать однозначно: оно того стоит.
Есть проблемы и с профайлингом. Xamarin.Profiler (GUI обёртка над Mono log profiler) для iOS приложения долгое время не показывал названия написанных вами классов, была только информация, что процессорное время и память занимают такие-то нативные объекты, но как их сопоставить с написанными вами классами — ни капли не очевидно. Сейчас с этим дела обстоят лучше – написанные классы наконец то появились в списке.
Также под профайлером приложение работает намного медленней, и, как следствие, оно порой может просто не успеть за отведённое на запуск время показать первый экран, и iOS его прибьёт. А если приложение таки запустится, то может вылететь в процессе работы на симуляторе под профайлером. В качестве слабого оправдания можно заметить, что профайлер уже давно находится на стадии альфа-версии, и за последний год так и не смог добраться даже до стадии “стабильной беты” – по крайней мере, для iOS.
Проблемы с кроссплатформенным кодом
Писать кроссплатформенный код нам предлагают одним из двух способов:
- Shared Project. Код в этом проекте не компилируется в отдельную сборку, а просто включает себя как часть в несколько проектов сразу. Этакий проект-симлинк.
- PCL Library. (Portable Class Library) Кроссплатформенная библиотека.
В теории вам предлагается выбрать что-то одно. На практике мы задействовали оба эти метода.
В PCL-проекте мы писали всю бизнес-логику, работу с БД, сетью и т.п. Основной плюс в том, что PCL не позволит использовать какой-нибудь системный класс, не реализованный на одной из платформ. Так что написанный и собранный в рамках PCL код гарантированно запустится на всех выбранных платформах.
Минус в том, что PCL-библиотека пишется исходя из пересечения возможностей всех выбранных ОС, не позволяя использовать то, что отсутствует в одной из них. Т.е., если мы планируем использовать только iOS и Android, а какой-то нужной фичи нет в Windows Phone – мы ей не сможем воспользоваться. При этом для PCL есть набор “профилей”, определяющих поддерживаемые платформы, но на момент написания статьи выбрать вариант “только iOS и Android, без Windows Phone и Windows” невозможно.
В результате мы помещали в shared-сборку код, гарантированно работающий на iOS и Android, но не способный собраться под PCL. Например, туда попала поддержка gzip-ответов и другая специфика работы с сетью или базой
В PCL может не быть банальных вещей, вроде работы с файлами и т.п. — в этом случае предполагается, что в PCL-сборке будут интерфейсы, а реализации — уже в проекте под конкретную ОС. В нашем случае часть таких реализаций как раз-таки попадало в shared-сборку.
К слову, если выбираете профиль для PCL – советуем выбрать профиль 259. Подходит лучше всех по имеющимся возможностям. Мы начали на другом, не имеющем в своём составе, например, мьютексов или потокобезопасных словарей — написать руками можно, но зачем? Так же отмечу, что выбор профиля гораздо удобнее и нагляднее делается в Xamarin.Studio, а не в Visual Studio:
Ну и на закуску — ещё одна особенность PCL: вы не можете добавить в зависимости одной PCL-библиотеки другую PCL-библиотеку с иным профилем. Точнее, добавить то можете, но не любой профиль уживётся с любым. В общем, идея PCL в целом юзабельна, но в частностях может довести до белого каления.
Проблемы с биндингами к нативным возможностям платформ
Базовая идея Xamarin в том, что вы можете писать код, используя те же классы, методы и структуры, что использовали бы при написании нативного кода, просто теперь он пишется на C#. Но есть нюансы…
В случае с iOS существует довольно занятная багофича с делегатами. Вот, скажем, компонент UIScrollView. Ему можно назначить либо делегат, обрабатывающий определённые события, либо подписаться на эти события напрямую.
var scrollView = new UIScrollView();
//вариант 1
class UIScrollViewDelegate1: UIScrollViewDelegate
{
public override void ScrollAnimationEnded(UIScrollView scrollView)
{
base.ScrollAnimationEnded(scrollView);
Debug.WriteLine("Yes, animation ended");
}
}
scrollView.Delegate = new UIScrollViewDelegate1();
//вариант 2
scrollView.ScrolledToTop += (_, __) => { Debug.WriteLine("Yes, scrolled to top"); };
scrollView.ScrollAnimationEnded += (_, __) => { Debug.WriteLine("Yes, animation ended"); };
Причем при подписке на событие ScrollAnimationEnded происходит автоматическая замена делегата на внутренний Xamarin’овский. И подписка на событие ScrolledToTop будет потеряна. Казалось бы – в чем проблема? Просто не смешивай в одном коде подписку на события и делегаты! Но порой встречаются проблемные ситуации:
- В компоненте нет нужного события, хотя оно присутствует в делегате.
- В компоненте может быть уже назначен самим Xamarin’ом собственный делегат с какими-то обработчиками.
Или вот, например, в Xamarin.iOS используется класс единый класс UITableViewSource, заменяющий два iOS-протокола UITableViewDataSource и UITableViewDelegate. Это может сбить с толку.
Так же иногда меняются сигнатуры методов и классов, тот же iOS конструктор fileURLWithPath превратился в Xamarin в CreateFileUrl.
Аналогичная ситуация встречается и в Android'е — скажем, в оригинале константа GONE находится в классе View, а в Xamarin’овском варианте для той же цели нас есть enum ViewStates со значением Gone. Подобная проблема имеется и с некоторыми другими методами и константами, что вносит некоторую путаницу при переходе с нативной платформы.
Отсутствие абстракций над платформенными особенностями
Для полного счастья, фреймворк не скрывает от вас часть особенностей конкретной ОС. Например – фоновая работа с сетью:
- В Android'е вы можете просто породить новый поток для работы с сетью или фоновной сетевой сервис, если ваше приложение будет свёрнуто или телефон будет залочен — работа не прервётся.
- В iOS при сворачивании приложение останавливается, и если вы хотите что-то делать с сетью — нужно использовать иной вариант, например Background-Safe Task, останавливающуюся через несколько минут после сворачивания.
Вы скажете — это ведь просто особенности конкретной платформы? Именно. Но никто от разработчика эти особенности под абстракциями не прячет, так что повторяем, изучать каждую из платформ придётся.
Нехватка сторонних компонентов
В данный момент под Xamarin уже написано немало компонентов, но под iOS и Android их всё-таки написано больше. Если понадобится, то теоретически можно подключить бинарную библиотеку, написанную на Object-C или Java, но придётся писать проект-биндинг для связи между нативной библиотекой и Xamarin-приложением. Для iOS здорово поможет утилита Objective Sharpie, способная самостоятельно сгенерировать такой проект, но она тоже не всегда работает на 100% точно, приходится порой редактировать результат такой генерации руками, а местами даже задуматься, нужна ли вам данная библиотека вообще.
К тому же, подобные компоненты авторы часто обновляют с запозданием, по сравнению с нативной версии библиотеки. Мы стакивались с ситуацией, когда плагин TestFairy отставал на пару месяцев от нативной версии. На вопрос в тех.поддержку TestFairy нам ответили, что всё нормально, вы не теряете ничего, кроме пары мелких фич. Но при выходе новой версии Xamarin возникла проблема: приложения с данной библиотекой собранные в этой версии Xamarin начали падать в реалтайме.
Выводы
После изучения тонкостей фреймворка выводы напрашиваются сами собой.
- Xamarin позволяет удобно (с некоторыми оговорками) использовать для разработки под мобильные платформы C# и .NET.
- Xamarin, несмотря на свой возраст, довольно сырой продукт.
- Xamarin не спасёт вас от необходимости тщательно изучать особенности каждой из мобильных платформ.
В статье также планировался рассказ про Xamarin.Forms, но тот раздел настолько растянулся, что мы решили выделить его в отдельную статью. В ней мы расскажем про различные проблемы UI-фреймвока Xamarin.Forms и о том, как мы их решили.
Update. Ссылка на вторую часть.
Комментарии (29)
sidristij
14.12.2015 15:27+4С Xamarin самое печальное, что идея-то отличная, но со своими багами, которые не фиксятся, они просто теряют клиентов )
Nagg
15.12.2015 07:19Тут людей не так уж много, а вот работы поддерживать кучу разных версий и все апдейты — много :) А хороших девелоперов надо кормить, это же нишевый продукт — не Angry Birds с сотнями миллионов пользователей.
Newbilius
15.12.2015 08:10+2Довольно обидно, когда глюкавит продукт за ~1000$ в год на 1 разработчика. Будь этот инструмент бесплатным или недорогим, можно было бы простить ему некоторые шероховатости. А с повышением цены повышается и уровень ожиданий. Сейчас он местами похож на платную бету, которую представляют как законченный продукт.
kekekeks
14.12.2015 15:28+5Если совсем устанете от Xamarin.Forms, рекомендую посмотреть на наш UI-фреймворк, который недавно таки завели на мобилках. В наличии нормальный XAML, lookless-контролы, своя система отрисовки и прочие свойственные WPF плюшки. Оно, конечно, всё ещё в альфе, но разработка идёт достаточно быстро, думаю, летом уже будет RC.
Don_Eric
14.12.2015 17:59Мы недавно выпустили приложение на Xamarin.Forms, с упором на красивый дизайн.
Много кактусов, но выглядит очень хорошо. На слабых аппаратax андроида подтормаживает правда
itunes.apple.com/il/app/ydy-wt-hrwnwt/id912886096?mt=8
play.google.com/store/apps/details?id=com.yedioth.android
Nagg
15.12.2015 07:16+1>>К слову, бесплатная ознакомительная версия не позволяет собрать приложение размером более 64 килобайт
это так, но вы не упомянули про триал 30 дней + 30 дней манибэка. а так же иди лицензию за 25$ в мес.
Все проблемы с Xamarin Studio перестанут быть актуальными с приходом Xamarin Studio Roslyn (уже доступны preview)
>>так что вам придётся сидеть рядом с двумя ПК разом, тестируя приложение на одном и работая в отладчике на другом
TeamViewer — хорошая штука.
>>Но никто от разработчика эти особенности под абстракциями не прячет, так что повторяем, изучать каждую из платформ придётся.
в этом и суть — разработка как на нативных инструментах без всяких абстракций (не говорю про XForms) но на языке C# — я бы скорее назвал это фичей.
>>В данный момент под Xamarin уже написано немало компонентов, но под iOS и Android их всё-таки написано больше.
Objective Sharpe умеет генерит обертки из pods налету, а это умеет генерит обертки налету из jcenter/mavencentral и прочий гредл. Без сучков не будет — сами понимаете. Но Объектив Шарпи становится все лучше, ну а с явой проблемы связаны с разницей языков — они вроде похожи, но мелочи приносят боль.Newbilius
15.12.2015 07:56Про манибэк действительно не упомянул, дело говорите.
Но т.к. Xamarin Studio Roslyn ещё только в превью, а разработка под ней довольно больно, то поддержка Visual Studio — необходимость, поэтому инди-версию и не упомянул.
Честно, я на Roslyn-версию не смотрел, т.к. глядя местами на их релизные продукты, мне страшно представить, как там работает превью-версия. За счет чего стало намного лучше, можете поделиться? Однако любопытно.
TeamViewer — хорошая штука, да и альтернатив ему хватает. Более того, в статье упомянут вариант «Можно открыть удалённый сеанс » :-) Но всё-равно это несколько менее удобно, чем запуск нативного эмулятора того же Android'а.
«разработка как на нативных инструментах без всяких абстракций… фича»
Проблема в том, что мне довольно много знакомых разработчиков жаловалось, что с удивлением обнаружили необходимость подробно изучать особенности каждой ОС, мол это было не очевидно из рекламных компаний. Так что я решил лишний раз обратить внимание на этот момент.
Objective Sharpe я тоже в тексте упомянул, но для некоторых библиотек он выдаёт результат., требующий ооочень больших доработок. Я прекрасно понимаю, что без проблем не будет, но во многих презентациях упоминается, что «вы легко и без проблем сможете использовать нативные библиотеки». А на практике — да, использовать сможете, но далеко не всегда «легко и без проблем».
DmitrySpb79
15.12.2015 11:03+1Спасибо за материал, интересно.
Для всех коммерческих проектов которые я видел, Xamarin это скорее экзотика, обычно (как упоминали выше), часть разработчиков пишет нативно под iOS, часть под Android, а на Windows Mobile просто забивают т.к. рынок крайне мал :)
После прочтения статьи возникло ощущение, что баги и сырость Xamarin пока что перевешивают его плюсы. Как в анекдоте, «народ настолько любит халяву, что готов платить за нее любые деньги» :) Мало того, что надо все равно с особенностями каждой ОС разбираться, так еще и с глюками системы бороться.
Что осталось неясным:
— Верстка UI в xib/storyboard, работает ли, и сильно ли сложно? Или весь UI в коде?
— Сложности с отладкой: не проще ли Mac mini купить, и на нем все и писать и отлаживать? Они сейчас вполне быстрые, и не такие уж дорогие (имхо потраченное на «удаленную отладку» время в итоге дороже стоит). Или xamarin такое не позволяет в принципе? Или вопрос жадности работодателя? (доводилось работать в компании, где даже 8Гб памяти надо было выбивать пару месяцев, не то что новый комп)
— Можно ли написать какую-то часть (например работу с БД) на Xamarin, затем оформить эту часть в виде lib/framework, подлинковать ее к XCode/Android Studio, и дальше писать уже нативно в нативной IDE?
— Цена IDE. Без покупки лицензии за килобакс я не могу даже дома что-то попробовать/потестить?Newbilius
15.12.2015 12:14— Верстка UI в xib/storyboard, работает ли, и сильно ли сложно? Или весь UI в коде?
Если вы не используете Xamarin.Forms — можно использовать xib/storyboard для iOS и xml для Android. Получается нормальная нативная вёрстка.
Сложности с отладкой: не проще ли Mac mini купить, и на нем все и писать и отлаживать? Они сейчас вполне быстрые, и не такие уж дорогие (имхо потраченное на «удаленную отладку» время в итоге дороже стоит). Или xamarin такое не позволяет в принципе? Или вопрос жадности работодателя? (доводилось работать в компании, где даже 8Гб памяти надо было выбивать пару месяцев, не то что новый комп)
Сложность отладки в том, что Xamarin.Studio периодически глюкавит и отлаживать в ней код проблематично. Так что приходится юзать два компа или виртуалку с Windows и Visual Studio. Отлаживать в Xcode или другой нативной среде не удастся, сейчас альтернативы две: или Xamarin.Studio, или Visual studio.
Можно ли написать какую-то часть (например работу с БД) на Xamarin, затем оформить эту часть в виде lib/framework, подлинковать ее к XCode/Android Studio, и дальше писать уже нативно в нативной IDE?
Интересная идея :-) Но если я верно понимаю схему работы Xamarin — не сработает.
Цена IDE. Без покупки лицензии за килобакс я не могу даже дома что-то попробовать/потестить?
Без покупки у вас есть либо бесплатная версия с кошмарными ограничениями, либо полнофункциональный триал на 30 дней. Так что попробовать бесплатно можно)
Seekeer
15.12.2015 12:40>Сложности с отладкой: не проще ли Mac mini купить, и на нем все и писать и отлаживать?
На маке работать можно только через Xamarin Studio, а она сильно тормозная и глючная.
Nagg
15.12.2015 19:16Не нужно делать выводы по одной статье. Очень много написано приложений на замарине. особенно интерпрайз. Там где много клиентской логики он вне конкуренции. Тем более позволяет легко портануть код на десктопный Windows.
Mecid
Лучше все таки заниматься нативной разработкой, а не придумывать вело-костыли.
kekekeks
Там основной костыль — это Xamarin.Forms, который из себя представляет просто рассадник багов. Если использовать только обёрки над нативными классами, то всё вполне стабильно и прилично.
Mecid
Ну так вся фишка в Xamarin.Forms, нужна нативность UI на разных платформах.
Newbilius
Ну возможность хотя бы бизнес-логику не дублировать, а интерфейс сделать с нуля на каждой платформе — тоже неплохой путь. Мне вот теперь кажется, что это даже заметно лучший путь. Но об этом во второй части…
sys_int64
Луше и правда делать интерфейсы для каждой платформы своими, в большинстве случаев, т.к. пользователи iOS к примеру больше привыкли к меню с вкладками, а на Android к боковому меню. Ну и стилистика немного другая.
Newbilius
С другой стороны, многие экраны будут похожи. Вот скажем экран ввода логина-пароля и одной кнопкой — «войти». Или форма наполнения чего-нибудь. Или список с единственной строкой поиском над ним. Подобные экраны (как минимум в теории) очень хорошо должны ложиться на кроссплатформенные UI-фреймворки.
Mecid
Только если вы дотнетчик, в остальных случаях лучше использовать нативные средства разработки.
Newbilius
Тут кстати наступает интересный момент. Вот например вам требуется приложения под iOS, Android и Windows Phone. Что выгоднее, дешевле и проще, если вы не хотите отдавать проект на аутсорс?
1) держать в команде 1-2-3 разработчиков-универсалов, хорошо знающих кишки каждой ОС и свободно пишущих на Java, Object-C и C#
2) столько же разработчиков, но каждый из них пишет на C# с помощью Xamarin
3) (крайний случай, но мало ли) по одному разработчику под каждую из платформ
Тут во втором вариенте плюс и во взаимозаменяемости, и в возможности проще найти нового разработчика, и в шаринге бизнес-кода между платформами… И шаринг кода тут не последний по значимости плюс: не будет ситуаций вида «поправили баг на Android, но упустили идентичный на iOS». Да и единый набор тестов, который не придётся писать трижды, тоже повод для радости.
Mecid
Разработка приложений по гайдлайнам Google/Apple с использованием Xamarin превращается в ад.
Он подходит только в случае если вы копируете приложение под все платформы, не реализуя нативный вид.
Newbilius
Такс, давайте уточним: мы всё ещё про Xamarin или уже про Xamarin.Forms? Если первое, то никакого ада, банальный биндинг к другому языку, и никто не мешает верстать нативно, в том числе в XIB'ах под iOS и XML'ях под Android.
А вот если речь про Xamarin.Forms… то скорее соглашусь, чем нет.
Mecid
Я про Xamarin.Forms
yul
Что-то мне кажется, React Native тут уже выигрышнее выглядит.
Newbilius
JS vs C#… я пожалуй воздержусь от этого холивара :-)
Ещё аналогично можно для пары Android+iOS использовать парочку Kotlin+RoboVM. Но я слышал, что RoboVM выкупил Xamarin, а значит будущее его туманно…
yul
Ну вот с Xamarin тоже не все так безоблачно, MS может в любой момент их выкупить и как там дальше пойдет — неизвестно. React Native, по крайней мере, open source.
Don_Eric
и зачем им выкупать их?
LionAlex
Как раз, если MS решит их выкупить, то с будущим все будет хорошо. По крайней мере, оно(будущее) будет гораздо более стабильным, чем сейчас.
yul
Это уже зависит от MS. В том-то и проблема, пока для разработчиков их продукт — флагман продаж, они делают все, чтобы держать его на плаву, даже если не очень получается. Но при поглощении большой фирмой для нее это просто еще один продукт. Начнутся сложные времена — могут и закрыть, что-то урезать или ограничить финансирование, перебросить деньги на другие проекты, но уж наврядли откроют исходники и отпустят в свободное плавание. Как Dropbox недавно решил закрыть Mailbox.
yul
И в чем тут холивар? Я вообще фанат ruby, но RubyMotion пока не особо рассматриваю, например. Сейчас у меня как раз стоит выбор кросс-платформенного фреймворка для мобильного приложения и, по-моему, насколько хорошо он решает задачи гораздо важнее языка, который выучить недолго (по сравнению с изучением самого фреймворка).