One angle that wasn’t addressed is that because .NET is much more developer friendly, a case could be made that it reduces the risk for developer errors resulting in bugs.

I personally don’t think it makes sense to use a Mono library to do iPhone development. Half of the learning curve is understanding the capabilities of what the iPhone specific libraries can do. Learning the syntax of Objective C is somewhat trivial, considering it is a C-based language.

That’s just my perspective, though. I’ve found iPhone development to be cumbersome and time consuming than Web and WinClient dev in .NET. It’s much easier to debug and write cleaner, faster code in .NET.. but I wouldn’t use .NET for the iPhone.

I am not talking about Flash apps, I am talking about the Flash runtime it’s self. This was a simple example.. I could go on and on listing other C++ apps that have bugs that go unpatched.

What is your point? Are you trying to point out that MS restricts Windows Dev to just Windows machines? If so that is an ignorant argument. Why would MS waste time on an 8% market share? It is simple business sense. Think about it. Apple has an incredibly small market share as a whole, now just think about how small the dev sub market must be. To answer your question, yes, Xcode is a barrier. There are far more developers on Windows then Mac. How hard would it be for Apple to release an IDE for Windows. They are idiots if they think they will somehow gain market share by restricting Xcode to Macs only. Developers will simply go with a more open platform like Android. Sure developers looking to make a quick buck on a useless iPhone app may be willing to invest resources in Xcode but enterprise developers looking to develop custom apps for there own inhouse use are not going to waste time developing in a new language on another platform.

Interpreters are slower. Yes, but MonoTouch is not an interpreter, and, for that matter, neither fundamentally are .NET and Java.

Interpreters are bigger security risks. Nope — but perhaps Microsoft should be so kind as to label all patches as “C++” patches to make it easier for some to track. Since all software can contain bugs, and interpreters add a layer, we can grant partial credit here, since more layers == more opportunities for bugs. Again, this is completely irrelevant, since MonoTouch is not an interpreter.

Usability fail (not in the posts, but in a your comments). Yes, when that occurs, which is perhaps annually to upgrade the .NET framework on Windows, and slightly more often with a Java applet. Strike three — also completely irrelevant, since MonoTouch does not utilize a separate runtime or downloaded VM.

So zero for three on the strawmen, but again, the problem is “mitigated.” I guess that is zero for four, because

Mitigate = to lessen the severity of a problem.

The problems that you manufacture here are not lessened; they never existed.

I know several devs who just picked up a Mac Mini and a switch and got to work. A Mac Mini is cheaper than the 1 year enterprise MonoTouch price in any case, and comes with Xcode for free.

I understand the idea of Flash, .Net, Java, etc. from a certain point of view, I’m just still not convinced it produces a better end product and experience for the end user.

(Though in this case, yes, it’s mitigated by the advance compile — having a “you must download Java” or “.Net” box popup is instant fail from a usability standpoint.

All together, you get a piece to rival any FUD (http://tinyurl.com/2478pa ) cooked up in the darkest bowels of Microsoft marketing labs. I salute you, sir!

There are not .NET expolits on your Windows boxes all the time. There are buffer overflows in IE and even in the .NET runtime engine from time to time, but guess what? That part is largely written in C/C++. As for service packs on Windows, those almost exclusively fix issues in non-managed C/C++ too. It can be difficult to spend 30 seconds on google before asserting one’s biases as fact, but you might want to try it, even on your own blog.

If better is easier, then great. If easier leads to crappy UI and poor user experience, then no thanks. Especially as we move into mobile computing.

Flash isn’t native, it’s also a runtime and has even more security problems, not to mention performance issues, than .Net in my experience.

@iBamse,

Agreed and what I stated in the post. It sounds like they’re using native iPhone UI elements as well, which is great to hear.

As a user I would rather have a native app. A well written app in C++ is going to out perform a .Net app but .Net isn’t the bad performer that people try to make it out to be. People try to lump .Net’s performance in with that of Java. It is far more practical for developing simple silly iPhone apps.

Doesn’t it execute code in the data layer to make it seem like it runs faster? I thought that was part of the reason IE was run outside of DEP?

(I don’t care if Apple or whomever makes something, I just currently prefer native apps over any of the dodgier alternatives. There’s a trade-off to everything and the convenience of .Net, Java, etc. come at a price)

Languages like C# and Java have been and will continue to be the languages of choice used for a lot of major development projects. Not only are they safer (sandboxed code), but they focus on productivity and ease of reading. Bravo to Novell for doing this. If only it wasn’t so darn expensive…

I am not sure it will do much for getting the iPhone into the enterprise market though. There is still no simple method to distribute apps for internal corporate use. Making them public on the AppStore may firstly not be acceptable for a number of reasons like security, confidentiality and licenses, and would secondly introduce the delay and rejection risk of going through Apple’s often critizised approvement process.

What is required for a real breakthrough in the corporate market is a possibility to set up an “internal” AppStore. Maybe combined with some kind of AppStore proxy where the company can chose to make third party apps of their choice available for free download to its employees, being autmatically paid for behind the scenes.

a) Neither Java nor .NET are code interpreters b) Even if they were, other things being equal they would pose less security risks than code running closer to the metal, because a (J|.NET)VM sandboxes the damage many types of exploits can cause.