ключ как мост данных между триальной частью функционала и платными функциями: "Нет ключа - данные из основного блока просто не попали в коммерческую часть приложения. Удобно тем что нет никаких условий и сравнений.

Хороший подход и с идеей.
Только не забывайте о том что память ключа немного ограничена (я уткнулся в лимит).
Впрочем, когда ключи дойдут и начнете эксперементировать - готов про Code много чего рассказать (как его правильно готовить) :)

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

А что произойдет в данном случае кроме потери данных?

К примеру мы пишем в ключ количество оставшихся запусков, таким макаром можно увеличить это значение :)

В четвертых, есть еще конечно вариант с Guardant Code - ключ, конечно, немного дороговат, но там есть много приятностей, одной из которых является отсутствие лимита на 1 миллион перезаписей (ресурс гораздо выше, правда не во все области памяти). А другой приятностью, является то, что мы можем принимать данные из софтверного блэкбокса, реализуемого в приложении (к примеру закрытого виртальной машиной) и спокойно их расшифровывать непосредственно в ключе, где и принимать решение - как именно и где будем их хранить - во внешней FLASH или внутри защищенного блока (там тоже есть нюансы, но грубо как-то так).

Благодарю, Александр!
Уже заказал ключи Guardant Code они где-то в пути мне тоже они показались более удобными. Только вот нет примеров по ним...

А что произойдет в данном случае кроме потери данных?

В самом простом приближении воспользуйтесь предлагаемой SDK криптографией с привязкой к ID ключа, а для рандомизации, GP счетчиком 0х6 оффсет UAM, который будет декрементировать при каждом обращении к "критическому участку кода".
Сами данные храните там где вам удобно.

В четвертых, есть еще конечно вариант с Guardant Code - ключ, конечно, немного дороговат, но там есть много приятностей, одной из которых является отсутствие лимита на 1 миллион перезаписей (ресурс гораздо выше, правда не во все области памяти). А другой приятностью, является то, что мы можем принимать данные из софтверного блэкбокса, реализуемого в приложении (к примеру закрытого виртальной машиной) и спокойно их расшифровывать непосредственно в ключе, где и принимать решение - как именно и где будем их хранить - во внешней FLASH или внутри защищенного блока (там тоже есть нюансы, но грубо как-то так).

В итоге - я бы посоветовал остановиться на промежуточном варианте решения (через доступные криптоапи из SDK), правда сам использую последний вариант, ибо он мне более удобен, с учетом почти 9 летнего варианта работы с промежуточным :)