l'interface des Windows 10 peut-être, mais quid des logiciels tiers?

tu peux avoir toutes API en commun du monde, et un OS qui sait s'adapter, si les développeurs n'ont pas prévu différentes ergonomie, pour différents type de machine, alors ça ne sert à rien.

iOS tourne sur iPhone et iPad, mais il faut bien que dèv. trouvent des astuces pour faire des applications "universelles", avec 2 interfaces différentes (souvent l'astuce de la colonne de gauche d'ailleurs)

@ Eurylaime : « L'interface de Windows 10 tiendra compte du matériel présent et s'adaptera donc pourquoi pas ? »

Parce que, comme ça a déjà été signalé ci-dessus, on ne parlait pas de l’interface de l’OS, mais de celle des applications.
Une interface qui, à de rares exceptions près, doit être différente entre un environnement tactile à écran petit ou moyen et un environnement de bureau classique. Et pas seulement à cause de la taille de l’écran — loin de là.

Le multifenêtrage, notamment, ne se pratique pas sur les smartphones et tablettes, mais est un gros avantage d’un environnement tel que Mac OS. Et sortir sur ce dernier une application directement portée d’un environnement du genre iOS, où les fonctions sont accessibles de façon beaucoup plus modale via une seule fenêtre, c’est la plupart du temps une aberration (une erreur que commettent même certaines équipes chez Apple, par exemple avec la dernière version d’iWork).
Évidemment, ce point précis se remarque moins pour les applications Windows, cet environnement n’ayant jamais été très orienté multifenêtrage (Windows, ça a toujours été plutôt un système permettant de passer d’une application affichant une fenêtre en plein écran à une autre application affichant aussi son unique fenêtre en plein écran).
Il reste cependant d’autres points différenciant une même application entre sa version de bureau et sa version mobile, notamment des fonctions qui ne sont pas réalisables de la même façon avec un souris et une approche tactile.

Bref, même avec des API strictement identiques d’un enrivonnement à l’autre, il resterait aux développeurs, dans de nombreux cas, à développer deux, voire trois, versions différentes de l’interface de leurs applications. C’est déjà le cas, dans une bien moindre mesure cependant, entre les versions iPhone et iPad d’une même application.
Du coup, bien qu’il soit techniquement très facile d’enrober tout ça en une seule application « universelle » (Apple a plus de 20 ans d’expérience dans ce domaine, elle n’a pas attendu Microsoft pour jouer avec ce concept), ça resterait, du point de vue du développeur, un travail de développement de deux applications différentes partageant une base commune, sans gain réel par rapport à la distribution séparée de ces deux applications.
Et pour l’utilisateur, le gain n’est pas si évident non plus : on peut mettre en avant la simplification de la gestion de sa logithèque, mais en échange il se retrouve avec le risque de payer systématiquement le prix du développement de la version « bureau » de ses applications même s’il ne veut en utiliser que la version mobile (et inversement), le tout pour des applications prenant plus de place sur son smartphone.

Il pourrait cependant être intéressant qu’Apple mette en place une possibilité d’application « universelle » du point de vue du paiement : pour les développeurs qui le souhaitent, avoir la possibilité de coupler une application Mac et une application iOS, pour, par exemple, que l’achat de l’application Mac ouvre automatiquement le droit à l’utilisation de l’application iOS (cette dernière restant achetetable séparément pour ceux qui ne s’intéressent pas à son pendant pour Mac). Ça pourrait être pratique pour certains cas.