Hello, Changing the name is a necessity if you want to have a good looking program. Consider an API like "drawString:" and "drawString:atPoint:" and "drawStri

Hello, Changing the name is a necessity if you want to have a good looking program. Consider an API like "drawString:" and "drawString:atPoint:" and "drawString:atPoint:withFont:". These are acceptable in the world of objective-c, because they are used with parameters, but they are not really suitable in this way in C#. So we map the API names to forms that are idiomatically correct in C#. In the above case, we would like map those to a single "DrawString" method name with three different overloads. But this depends on the case. In general, we follow the .NET Framework Design Guidelines for our naming conventions. As for forms, you are correct, we built it for a class of users that had different requirements than those that are building consumer applications. Now, while I am the first one to tell developers to use our native APIs to create great consumer experiences, just last week I ran into a gorgeous looking app and only later I discovered that the gorgeous UI was actually built entirely with Forms, even the animations. More importantly, the app was built on record time by a single developer. I could not believe it (need to ask the customer for permission to disclose that their product is built with our product). So I walked away with a new insight: that good UIs require good taste and someone passionate enough to make the UIs happen and that even something that we intended for mostly business scenarios can create great UI experiences.