I've seen companies falling at the other extreme ... making the interface "totally" decoupled, so that they could replace the UI anytime they wanted. That's why monstrosities like XSLT appeared.
But I haven't seen any example of a good application yet that does this successfully, because whether you like it or not, the web UI will require backend logic that your iPhone app does not, and vice-versa. And you'll either create a common denominator, or two different branches.
Also, if your iPhone app is so similar, maybe it shouldn't be an app in the first place, but an iPhone-optimized website. It's Apple's fault if they aren't making the integration between websites and the iPhone easier.
Don't get me wrong, web services have their place, but make no mistake ... a website that assembles the page from web services is a lot trickier to scale (assuming you're the one providing those services).
No XSLT was an attempt to make the UI generic, either you accept that UI are a custom tailored to be optimized for the platform or you accept the dumb terminal philosophy where you try to generalize the UI to adapt to all platforms.
The fact remains that human preference is for tailored UI and not until AJAX took hold was the desktops dominance as a platform threatened. Time and time again, tailored UI's are preferred. It is the reason for Apple's return to stardom as well as the rise of web 2.0.
Developers try to fight this mentality to work in their boxed solution and I understand it, but you have to clearly refute evidence to the contrary to believe that the user prefers application developed in this manner.
So If that is the case why not design an architecture that accounts for this reality and makes peoples jobs whose responsibility it is to assist the user instead of enforcing a developers domain on them.
As well, I do not agree that different UI's require different back end logic they require different work-flow logic and work-flow is not reusable. If they require different back end logic for say getCustomer, addCustomer, validateAddress then there is core architectural flaw in the solution. How a customer is then displayed is a problem for the UI e.g. Do I show all info in one screen do I show pivots to make room for more screen real-state.
It is not Apples fault, that is faulty logic, Apple is giving their users what they want and their last quarter clearly reflects that.
Web sites that rely on web services are not tricky to scale look at my document on amazon I referenced. It is essential to scaling. Google, Amazon et. al. are doing this precisely for that reason scalability and to not be locked into back-end or front end technologies. Not to mention you are distributing all work-flow and dynamic templating to the clients, which in practice has a large impact on resource utilization.
I know that they are using lots of web services, but the assembly is still mostly done on their servers (not in the browser), and you're talking about something else (or have I understood you wrong?).
I've seen a talk from an Amazon fellow. They are using web services for parallel processing ... their frontend servers are sending asynchronous requests to those services, which is a huge win.
But in a browser, for an Ajax frontend that happens to periodically request updates, one thing that happens is that the number of requests made from a single client is a lot larger. Surely it doesn't reload all the static files, but those are non-issues even for a reasonable high-traffic website ... just put something like Varnish to serve them and make sure they have expiration headers in the future.
My company did consultancy work in matters of scalability for http://www.erepublik.com/ and after we placed a Varnish in front (that also functions as a load-balancer for Apache servers) it could handle thousands of concurrent requests to static files. And their biggest problem was definitely not the load on their Apache servers (it was MySql).
different apps from these companies are further along in there utilization of a decoupled architecture than others but most all are working to this end, Many of Google's "applications" completely rely on this approach, I cannot comment on their mainstay (search). But most of Google app are assembled via the browser (Gmail, Docs, Maps, Wave) Its core to their strategy, hence entering into the browser market and the rapid push for HTML 5. As for Amazon most ancillary portions of their offerings use a decoupled strategy. The last understanding that I had, was they where waiting for a concrete SEO solution before moving their main asset .com over. These are large companies with legacy code base so it is natural that this architecture is emerging in their new product offering and acquired products first and is migrating it's way back into the legacy code base. In another post I provide referential links to the subject.
OK, you have a point, but I always was under the impression that Google is using Ajax in Gmail, Docs and Maps for user-experience, not for scalability.
I've seen companies falling at the other extreme ... making the interface "totally" decoupled, so that they could replace the UI anytime they wanted. That's why monstrosities like XSLT appeared.
But I haven't seen any example of a good application yet that does this successfully, because whether you like it or not, the web UI will require backend logic that your iPhone app does not, and vice-versa. And you'll either create a common denominator, or two different branches.
Also, if your iPhone app is so similar, maybe it shouldn't be an app in the first place, but an iPhone-optimized website. It's Apple's fault if they aren't making the integration between websites and the iPhone easier.
Don't get me wrong, web services have their place, but make no mistake ... a website that assembles the page from web services is a lot trickier to scale (assuming you're the one providing those services).