Un argumento en contra de producir un marco multiplataforma es que siempre estará dirigido al mínimo común denominador: los clientes del marco quieren escribir código solo una vez y se ejecuta 'en todas partes'. Entonces, una increíble plataforma de hardware se parecería a cualquier otra plataforma que ejecute ese marco ya que no puede aprovechar las características específicas de la plataforma.
Con el tiempo, esto desafortunadamente resulta en marcos inclinados hacia su plataforma más popular y pirateando el soporte para las otras plataformas, o simplemente eliminándolos cuando se agota el presupuesto / popularidad.
Una forma de capitalizar las capacidades específicas de la plataforma es tener algo así como una #if PLATFORM_FEATURE_X
construcción en torno a todo el código específico o verificaciones equivalentes de tiempo de ejecución que resultan en una hinchazón del código. Esto se vuelve tedioso con bastante rapidez, ya que las variantes de la misma plataforma necesitarán un manejo específico. Por ejemplo, algunos XBox v1 no tenían disco duro, por lo que los juegos que usan herramientas multiplataforma no podían usarlo para el almacenamiento en caché, en comparación con una versión para PC que puede garantizar un disco duro.
Para las aplicaciones de escritorio / productividad, la apariencia de la plataforma parece ser importante, pero muchas aplicaciones tienen su propio estilo, por lo que no es un problema tener el mismo aspecto en todas las plataformas, por ejemplo, aplicaciones creadas con AIR.
Los proveedores de hardware como Apple, Sony, Nintendo y Toshiba querrán asegurarse de que sus productos hagan algo para diferenciarse de la competencia, por ejemplo, Touch, Acelerómetros / Gryoscopes, Blu-Ray, pantalla 3D. Es poco probable que haya una plataforma con todas las características de todos los competidores en una sola (debido al costo y la complejidad), por lo que uno ganará.