Jednym z argumentów przeciwko tworzeniu frameworkowego frameworka jest to, że zawsze będzie on skierowany na najniższy wspólny mianownik - klienci frameworka chcą napisać kod tylko raz i działa on obsługiwany „wszędzie”. Tak więc jedna niesamowita platforma sprzętowa wyglądałaby jak każda inna platforma działająca w tym frameworku, ponieważ nie można wykorzystać funkcji specyficznych dla platformy.
Z czasem powoduje to, że frameworki skłaniają się ku swojej najpopularniejszej platformie i hakują razem wsparcie dla innych platform lub po prostu odcinają je, gdy skończy się budżet / popularność.
Jednym ze sposobów na wykorzystanie zdolności specyficznych dla platformy jest stworzenie czegoś takiego jak #if PLATFORM_FEATURE_X
konstrukcja wokół całego określonego kodu lub równoważne kontrole środowiska wykonawczego, co powoduje rozdęcie kodu. Jest to dość nudne, ponieważ warianty tej samej platformy będą wymagały specyficznej obsługi. Na przykład niektóre XBox v1 nie miały dysku twardego, więc gry korzystające z narzędzi wieloplatformowych nie mogły go używać do buforowania, w porównaniu do wersji na PC, w której można zagwarantować dysk twardy.
W przypadku aplikacji Desktop / Productivity wygląd platformy wydaje się ważny, ale wiele aplikacji ma swój własny styl, więc „nie ma problemu, aby wyglądać tak samo na wszystkich platformach, np. Aplikacjach zbudowanych w środowisku AIR.
Dostawcy sprzętu, tacy jak Apple, Sony, Nintendo i Toshiba, będą chcieli upewnić się, że ich produkty robią coś, co wyróżnia się na tle konkurencji, np. Dotyk, akcelerometry / gryoskopy, Blu-Ray, wyświetlacz 3D. Jest mało prawdopodobne, aby kiedykolwiek istniała platforma z wszystkimi funkcjami wszystkich konkurentów połączonymi w jedną (ze względu na koszty i złożoność), więc jedna wygra.