This is largely true, but it draws the playing field Apple wants you to see. There is a large part of the playing field that is omitted, cloud, the web and the Internet in general. And this playing field alone is as important as all the playing fields Apple is competent in combined.

Apple is second to last in that respect. Google and Amazon both understand the web a whole heck of a lot better than Apple. Only Samsung understands the web less than Apple.

Yes, they have cloud services, but for the most part, Apple's developer community has been generally unhappy about Apple's iCloud offering. This stems from two causes:

(1) first, the competency of Apple's team in this area are not comparable to the competency of Apple's other teams (mainly operating systems devs, app devs, industrial designers, supply chain specialists, etc.). No engineer who is truly competent in these domains (cloud, internet, web) has Apple as top of mind when they think about what company to go work for.

(2) second, Apple doe not only not understand the value of decentralization, but they actively fight it. This works fine for "single-player" experiences, but for "multi-player" experiences this is a disaster. I, as an Apple user, cannot dictate the devices and software my friends, family, colleagues, etc. will use, so any experience that is only truly complete when all these other people are also part of Apple's walled garden, will either never truly succeed or will outright fail.

So yes, only Apple can compete with Apple on it's home turf, but there are other playing fields than the ones Apple likes to talk about.

Lastly, Apple has only succeeded as much as it has with the unified experience, not because it did things better, but because the web (and specifically the browsers and the DOM) have failed to truly acknowledge that the web can't [yet] compete with Apple (and native in general), is that we don't have a feature complete and performant browser-based alternative for the building blocks you actually need to build apps, namely retain-mode scene graphs.

Browsers need to give some really deep thought to creating the equivalent APIs to things like qt, kde, gnome, Core Animation, etc. The DOM just does not cut it. FWIW, it's exactly what we're working on at Famo.us, and we're hoping others take note and some of the ideas we're exploring become co-opted by the browsers for inclusion as an alternative to the DOM, but that still plays nicely with the DOM.

Further proof that Apple has succeeded only because others have stumbled can be seen by comparing iOS to Android as well. Apple was a much better experience for a while before Android caught up. Some of this was because of Apple's big head start, but some of it was due to one technical/product decision made by Android early on, that when reversed made all the difference in Android's ability to compete with Apple: Early on Android settled on immediate mode graphics. This was the main reason Android user experience and performance just felt wrong for a while when Apple's felt right. Once Android embraced retain mode graphics fully, the Android experienced improved dramatically, so much so that I would say that Android, with its developer community, can also do anything Apple can do.

[0] http://famo.us/

[1] http://acko.net/blog/shadow-dom/