(Не очень) скрытые издержки общей кодовой базы iOS и Android

[@KanuTaH]

Ну не знаю, а в чем идея? У всего есть границы применимости. Если автор признает, что даже в 2013 году, когда еще по сути не существовало инструментов для кроссплатформенной мобильной разработки, и приходилось на все педалить свой велосипед,

Такое решение позволило выдавать большой объём кода как на Android, так и на iOS силами маленькой команды

то сейчас, когда есть Qt, Flutter, React Native, для разработки продукта на начальном этапе силами небольшой команды использовать что-нибудь из этого — самое то. Потом, когда продукт и его команда вырастут и начнут приносить деньги, тогда можно будет уже перейти на нативные технологии (если будет смысл в этом к тому времени, конечно).

[@mOlind]

Расскажу свою историю: Мы делаем фреймворки для офлайн карт, навигации, поиска на iOS и Android. Код максимально шарится между платфомами. Приведу пример: Для того чтобы показать вьюху с картой на стороне ОС мы обрабатываем касания, реализуем API для взаимодействия с компонентом и создаем surface для рендера. Весь остальной код пишется на C++. И там его очень много. Парсинг данных, парсинг стиля, применение стиля к данным, подготовка данных для OpenGL/Metal, весь сетевой стек, очереди фоновых задач, обработка данных пользователя. API, которое видит разработчик — это просто верхушка айсберга. Это с одной стороны. Много сложного кода, его лучше писать один раз. И ошибки ловить один раз.
При этом мы делаем приложения Guru Maps на своих же фреймворках. И тут ситуация обратная весь интерфейс и большинство кода этих приложений пишутся так, как это принято на конкретной архитектуре. Общий код на C++ тоже есть, но его мало. Это работа с данными и конверсия между бинарным форматом,GPX,KML в любую сторону.
Категоричный вывод о том что общий код на C++ вреден — я бы не делал. Он сильно облегчает жизнь. Но это должно быть что-то такое, в чем нужна скорость и нет зависимости от специфичных для платформы плюшек.

[@ababo]

Самое главное, требовалась кастомная система сборки для создания библиотек, которые содержат код C++, а также оболочки Java и Objective-C.

Gradle отлично переваривает CMake-проекты.

[@cdriper]

Зависит от объема приложения и сложности бизнес-логики. Начиная с какого-то момента общая плюсамя часть кода начинает окупаться и приносить доход.
Представьте себе, например, проект масштабов Microsoft Office.
Ясное дело, что на хеловорлдах такой подоход не выстрелит.

[@lim14]

Поддерживаю автора статьи. В компании, в которой я работал была похожая проблема. Хочу также дополнить, что у нас была поддержка Windows Mobile. Т.е. ядро написанное на C++ должно было поддерживать 3 платформы в идеале. На практике под Windows Mobile было практически своё ядро, что поражало ещё больше проблем.
Также была проблема, если вы распространяете приложение не через Google Play (Bundle), а через платформы, которые этого не поддерживают или обычной apk, то размер apk увеличивается из-за необходимости поддержки всех типов процессоров. У нас кода на C++ было большинство, поэтому размер apk увеличивался кратно количеству процессоров. Можно было конечно apk разбивать, но этот вариант не всегда подходил