Un argument contre la production d'un framework multiplateforme est qu'il sera toujours ciblé sur le plus petit dénominateur commun - les clients du framework veulent écrire du code une seule fois et il s'exécute «partout» pris en charge. Donc, une plate-forme matérielle impressionnante ressemblerait à n'importe quelle autre plate-forme qui exécute ce cadre, car vous ne pouvez pas tirer parti des fonctionnalités spécifiques à la plate-forme.
Au fil du temps, cela se traduit malheureusement par des cadres se penchant vers leur plate-forme la plus populaire et piratant ensemble le support des autres plates-formes, ou tout simplement les interrompant lorsque le budget / la popularité s'épuise.
Une façon de capitaliser sur les capacités spécifiques à la plate-forme est d'avoir quelque chose comme une #if PLATFORM_FEATURE_X
construction autour de tout le code spécifique ou des vérifications d'exécution équivalentes, ce qui entraîne une surcharge de code. Cela devient assez fastidieux, car les variantes de la même plate-forme nécessiteront une manipulation spécifique. Par exemple, certains XBox v1 n'avaient pas de disque dur, donc les jeux utilisant des outils multiplates-formes ne pouvaient pas l'utiliser pour la mise en cache, par rapport à une version PC où vous pouvez garantir un disque dur.
Pour les applications de bureau / productivité, l'aspect et la convivialité de la plate-forme semblent être importants, mais de nombreuses applications ont leur propre style, il n'est donc pas difficile de se ressembler sur toutes les plates-formes, par exemple les applications conçues avec AIR.
Les fournisseurs de matériel comme Apple, Sony, Nintendo et Toshiba voudront s'assurer que leurs produits se démarquent de la concurrence, par exemple tactile, accéléromètres / gryoscopes, Blu-Ray, écran 3D. Il est peu probable qu'il y ait jamais une plate-forme avec toutes les fonctionnalités de tous les concurrents réunies en une seule (en raison du coût et de la complexité), donc une gagnera.