Вполне вероятно, что у меня другое мнение по этому вопросу, чем у большинства, учитывая мои сильные чувства по поводу собственных пользовательских интерфейсов платформы и элементов управления / виджетов, но я очень склонен предпочесть ваш второй подход. Даже я не достаточно мазохист, чтобы пройти через процесс создания всего приложения отдельно.
Так что я бы определенно написал бы код библиотеки или уровня данных, полностью отделенный от уровня GUI. Делать это в C ++ - очевидный выбор, особенно если вы уже знакомы с этим языком, но об этом позже. Дело в том, что этот код должен быть ограничен только вашей «бизнес-логикой» и, таким образом, полностью независим от платформы. Если вы следуете твердым объектно-ориентированным принципам, должно получиться, что основная часть работы по программированию выполняется на этом уровне.
Помимо этого, вы бы написали тонкую библиотеку «обертки» поверх основной ОС и функций пользовательского интерфейса для Windows и OS X. Библиотека обертки была бы единственной сущностью, отвечающей за непосредственное взаимодействие с платформой и вашими данными код уровня должен вызывать функции из этой библиотеки-оболочки, а не напрямую из API платформы.
Конечно, некоторые из вас, читающие это, вероятно, кричат " Но это то, что QT уже делает для вас! " Да, я знаю. Но он не использует нативные виджеты и не соответствует стандартным соглашениям платформы в очень многих местах. Это означает, что это отстой. Я видел другие библиотеки-оболочки для Windows, которые делают правильно, но я еще не видел одну на OS X, которая выглядела бы прилично. Да, я придирчив, но и ваш типичный пользователь Mac. Они просто не будут мириться с типом мусора на своем экране, который будут видеть пользователи Windows, и даже команда Mac Office знает это. (Мы все вместе приветствуем вас за то, что вы пытаетесь сделать это правильно.)
Что касается выбора языков, вы говорите, что ищете код native на обеих платформах. Это довольно сложная капля желе, чтобы прикрепить ее к стене. Например, считаете ли вы JIT-совместимый код нативным? Если нет, то это исключает C #. Исключение любого типа интерпретируемого кода исключает множество других потенциальных языков. Вам не останется много вариантов , отличных от , чем C ++ и Objective-C. Но программирование на C ++ / Win32 не намного сложнее, чем программирование на Какао, просто другое.