Пишите под ios)

В общем случае нет. Вы можете запутывать (obfuscate) код в том числе код проверки подписи приложния. Есть dexguard, например. Еще можете реализовать проверку лицензии developer.android.com/google/play/licensing/overview.html. Последняя выполняется с помощью google play services, в другом процессе. Конечно можно декомпильнуть и вырезать эти проверки, но тогда часть функционала приложения(платные фичи) могут перестать работать. И каждый новый релиз придется взламывать заново. В итоге забивают на часть юзеров, что юзает 4пда.

Справедливости ради. в ios тоже не все гладко. Я не писал код под ios, про api ничего сказать не могу. сталкиваюсь со сборкой ios проектов. Так вот это боль.
немного в защиту андроид…

1. вы синтасис objective-c видели, это груви то инопланитянский?
2. Градл достаточно гибкий. Можно во время сборки запрашивать пароль от ключа подписи из консоли или даже окошка с полем ввода. Вообще вы почти не ограничены. У вас полноценный скрипатовый язык и любыми либами на jvm

об xcode

1. В ios все делается через xcode. Формат описания проекта почти машинный. Огромный xml файлы, которые xcode генерит. На билдсервере все нужно делать через ui или юзать сторонние скрипты тулзы на ruby. В андроид можно просто из консоли поправить читаемый gradle конфиг.
   
2. ios sdk монолитный. Нельзя скачать отдельные части
3. xcode нельзя поставить из консоли
4. нужно поплясать с бубном, чтобы иметь 2 версии xcode
5. Проблемы с подписями. Можно юзать фастлайн, но не спасает от обновлений икскода. В андроид просто нет таких проблем, указываешь путь к ключу, пароль и всё!.
6. Фактически нет системы зависимостей. Можно руками подключать либы из ui xcode. или юзать cocoapods, который автоматизирует редактирование проектных файлов. но и это боль. В андроид достаточно кинуть jar-ник(в 2017 никто так не делает) или указать зависимость и она удовлетворится. Опять же можно динамически создавать список зависимостей.

Гайд безопасности gpg.

1. Сгенерить master-key на чистой ос без интернета, записать sub-keys на смарт-карту или security key (yubikey или nitrokey)
2. Зашифровать master-key. На скрытом разделе.
3. Спрятать master-key. (зашить в диван)

Есть неплохой гайд по первым пунктам github.com/drduh/YubiKey-Guide для yubikey, Должно работать для любых реализаций gpg-card. Недавно понял, что прошивка yubikey закрыта, так что yubikey не тру.

Так-же можете попробовать использовать databinding.
В том-же xml вы передаете объект со всеми стилями, необходимыми для текущего экрана. На уровне java для каждого экрана вы пишите маппинг из конфига в локальные стили. И в итоге при изменениях конфига будет пересоздаваться объект локальных стилей и сетиться с помощью databinding во вью. Почти react-redux.

В xml можете дефолтные значения задавать, которые будут ссылаться уже на статичные ресурсы. Кода чуть больше, но это еще более гибко и более android-way (учитывая движение в сторону mvvm в android architecture components)

Решал похожую задачу просто перекрашиваем вью активити на уровне java кода. Shape drawable можно перекрашивать после создания. Был интерфейс IAppConfiguration, поставляющий все цвета, иконки и размеры. А все экраны перекрашивали свои вью используя его. Получалось достаточно гибки. Мне кажется, что это меньший велосипед, чем пытаться переопределить цвета в resources, ведь ресурсы — для загрузки ресурсов с учетом текущей конфигурации.

Еще это удобно если конфиг нужно получать в текущей сессии: к примеру при из firebase или longpolling с сервера. Все экраны, подписанные на изменения конфига, просто вызывают функцию, ответственную за перекраску, без пересоздания всего вью из ресурсов.

Если писать на dls вроде anko, так вообще будет выгладить однородно.

Самом неожиданным в https://reactnavigation.org/ оказалось отсутствие способа понять внутри экрана, что он ушел на задний план в общем случае. Условно: не реализовано аналогов onResume, onPause.
https://github.com/react-community/react-navigation/issues/51 вот тут пол года обсуждают как это должно быть написано: hoc, подписка на ивенты или функции компонента.

Есть экспериментальная либа https://github.com/satya164/react-navigation-addons. Сейчас написал костыль над ней, чтобы все работало как привычно.

Еще разные navigator-ы по разному управляют компонентами экрана, и у вас не всегда есть контроль над этим. Если у вас на ios табы, на на android drawer, то логика монтирования экранов будет разной: табы грузятся сразу, drawer грузит только текущий экран. В сочетании с первым недостатком писать немного больно.

навигация на react-native пишется куда короче в простых случаях, но когда у вас сложная логика при смене экранов, придется писать велосипеды и костыли.

<сарказм>
использовать immutable data structures
</сарказм>

Зашел на сайт ДИП, включил версию для слабовидящих, переключил цветовую схему на «черный фон, белый шрифт». Очень удобно, зачем слабовидящим видеть заголовки статей

Есть еще функция: «отключить картинки», которая чудесно дополняет этот режим =)

Посмотрите на fastlane, он из коробки поддерживает сборку, отправку в фабрик, публикаю(включая метаданные). Оформив все ваши таски ввиде скрипта для фастлайн, вы получите более легкую переносимость. В один день вам захочется перейти на тимсити или гитлаб. Еще один плюс: можно запускать как отдельный скрипт на вашей машине. Минусы: нужно знать руби, возможно медленнее решений на баше и плагинов на несколько процентов.

На сколько мне известно, существует несколько способов применения шрифта к TextView: 1) наследование 2)проход по всей иерархии вью с поиском TextView с нужным атрибутам. 3) кастомный layoutInflaiter(как в каллиграфии) 4) датабиндинг. Неплохо было бы сравнить эти способы, говоря о шрифтах.

датабиндинг работает только для атрибутов явно прописанных во вью. Вы не можете задавать шрифты в стилях или темах.

Это не самые важные проблемы. Для меня было неожиданностью следующее: 1) поддерживаются не все шрифты. Если шрифт не поддерживается, то будет использован стандартный. Проверить поддерживается ли шрифт нельзя. 2) нет поддержки файлов шрифтов с несколькими шрифтами внутри.

красиво, модно, но не работает для свойств из стилей и тем.

Поправка: keybase уже заработал. Там можно держать свои публичные ключи

Можно юзать почтовые сервисы с криптографией вроде protonmail
Можно развернуть открытый почтовый сервис на своем сервере
О gpg: есть хранилища публичных ключей, скоро заработает https://keybase.io/

Думаю, что и на котлине вполне можно такое написать, тут никакой магии. Мне больше интересно самому проверку типов написать, в виде отдельной функции. Или же дополнить язык лямбдами и написать вывод типа, но вот реализацию последнего пока не представляю именно на kotlin.

Спасибо за ответ.
Про

Result.Some.Some.Error("...")

sealed класс транслируются в abstact class, а каждый наследник в inner class(в скале ведь так-же case классы работают). По этому описанной ситуации быть не может.

Просто захотелось иметь возможность описывать связывания до и после выражения. Вы правы, семантика одна.

2 + 1 * 3 будет вычислено еще на этапе записи выражения в рантайме, так-как это перегруженные операторы.

Уже сейчас есть возможность описывать выражения через деревья с помощью конструкторов). Могу написать эквивалент вашему. Инфиксные функции я добавил для демонстрации возможностей dsl. Согласен, что с ними я получил кучу проблем.

Написал If Else, почти как у вас и функции к нему:

val example= 
             ifE(const(1), BoolKey.Less, const(2)) {
                variable("helloHabr")
            } ifFalse {
                const(2016.0)
            } where ("helloHabr" to 2016)

Теперь точно нужна проверка типов. Легко можно разные типы в then else вернуть.