Если вы не контролируете всю производственную цепочку для оборудования, как, например, Apple, у вас нет шансов в долгосрочной перспективе. Если ваш продукт не является действительно инновационным и рынок так сильно этого хочет, или если вы играете на рыночной нише (например, в сфере здравоохранения). Мое предложение было бы сделать исследование рынка и проверить, что ваш клиент в первую очередь использует в качестве мобильных устройств. Сначала вы должны выбрать одну или две топовые платформы и постепенно добавлять новые платформы, если спросит рынок. Если вы находитесь в США, возможно, iPhone, Android, RIM будут лучшим выбором, в Европе мне придется выбирать между iPhone, Android, Symbian, Windows. Это похоже на разработку веб-сайта, который вы начинаете с двух лучших браузеров и постепенно добавляете поддержку для второстепенных.
О переносимых библиотеках. Я бы не стал делать ставку на это. Вместо этого я разработал бы архитектуру, используя слои абстракции. Например, у меня будет слой абстракции Bluetooth, который предоставит функциональные возможности моему бизнес-логическому уровню; внизу у меня будет BlueZ, если я разверну на Android / Linux, может быть, GameKit для iPhone, стек MS или Widcomm для Windows и т. д.
КПК мертвы, на самом деле они слились в смартфоны и планшеты, они были эволюционным шагом. Так что забудь их.
HTML5 - хорошая идея, но это только передний уровень, вы должны иметь дело также с бизнес-логикой и нижними уровнями.
Bluetooth SPP хорош, потому что он распространен и совместим, как веб-сервисы для предприятий. Вместо предоставления API, который зависит от платформы, вы можете предоставить набор пользовательских AT-команд, которые могут использоваться любым, кто может подключиться по Bluetooth к SPP.