It won't be that simple.

1) Look and feel. Dui apps will have a different look and feel from Symbian ^4 apps, at least, this is one of the arguments used against my proposal. However, App Stores have look and feel as one of their main requirements, so a Dui app will not be allowed on Symbian^4 App Stores, and a Symbian ^4 app will not be allowed on Maemo 6 App Stores. This fact alone will make this proposal unusable for commercial developers.

As my proposoal results in apps having the look and feel of the host platform, it is not an issue there.

2) These libraries will be huge, and statically linking will result in huge apps. Huge apps are very hard to download, and App Stores have limitations on size too. It also results in the apps taking up more space on a device, so you cannot sell as many apps to a single customer as you could when apps were smaller.

3) Why have two libraries doing the same thing instead of one? If Dui and Symbian^4 can be put on both device classes, there is no difference. So kill either Dui or Symbian^4. The argument here was again that Maemo6 and Symbian ^4 is for different device classes. For political reasons, with two competing parties developing competing UI frameworks, it will mean the death of one party.

The problem is that both parties think that commercial third-party developers are very much interested in device look and feel, as they are, being their companies representative.

People, let me tell you, once and for all, commercial third party developers don't care at all for look and feel. True, look and feel will help sell a device to a device manufacturers customer, and for a device manufacturers perspective look and feel is vitally important.

But commercial third party developers will go for the look and feel that attracts the most paying customers. We don't care what we think ourselves about a given look and feel, we only care about the ease of making money.

Having a different API for each existing look and feel is bad for us as it makes it harder to make money. What we therefore do is support only the best money making API&look and feel combi's in the market. Currently that is iPhone OS, Symbian OS, RIM,

Again, device manufactures care about looks and feel, and commercial third party developers care about API's. What is good for both then is a unified API supporting lots of looks and feels. As far as we are concerned, different parties inside a company can slug it out all they want. It's not my company after all, and if the competition is better for my business I will switch anyway.