iPhone Gets .Net App Development

snydeq writes "Novell has announced MonoTouch 1.0, a commercial SDK that allows developers to build iPhone apps using Microsoft's .Net Framework instead of the Apple-designated C or Objective-C languages. The SDK leverages Novell's Mono runtime for running Windows apps on non-Windows systems, allowing developers to utilize code and libraries written for .Net and programming languages like C#. With MonoTouch, the Mono runtime provides such developer services as garbage collection, thread management, type safety, and Web services, said Mono leader Miguel de Icaza."

Comments

Launch Times?

[glennrrr]

Well how long does it take to load the whole Mono framework runtime because every second counts on the iPhone?

Re:Launch Times?

[Anonymous Coward]

If I am not mistaken and given that Apple bans other execution environments, the last step in building is compiling to native code. So there are no JIT times, I donÂt know about other loading times.

Re:Launch Times?

[digitalunity]

I would be more worried about WinForms compatibility. I developed a couple of .NET applications(never again!) and running them with the Mono runtime is markedly different than MS's runtime. Stability wasn't great with Mono and controls didn't always behave the same.

Although I won't developing any more .NET applications if I can avoid it, it would still be nice if Mono matured to the point where it could replace the MS runtime without noticeable difference.

Re:Launch Times?

[SanityInAnarchy]

Actually, there are two large things standing in the way of that:

1. The best .NET development tool, from what I can tell, is still going to be some form of Visual Studio.
2. Unlike Java, .NET makes native bindings dirt simple. If you were using a DLL in C++, you can use the same DLL in C# relatively easily.

#1 means that even if people want to target Mono, they might develop in VS.NET anyway, which is a bunch of VS.NET and Windows sales for Microsoft. #2 means that anyone who doesn't deliberately target Mono is probably going to call a bunch of native win32 code, just because it's so trivially easy to do so.

Note that both of these exist even with a "100% compatible" Mono, unless it was also combined with a 100% compatible Wine, and we all know exactly how likely the latter is.

Re:Launch Times?

[SanityInAnarchy]

How does this hurt Apple?

I don't know, how does Google Voice hurt Apple? How does Java hurt Apple?

I mean, you can sort of come up with a rationale, but it's really, really strained. Basically, it's not about whether it directly hurts apple, as whether it might hurt Apple, and/or whether it lets Apple give up even a tiny iota of control over their platform, and/or whether it hurts Apple's partners.

In this case, it's probably about control. Apple is going to be very wary of any language which supports eval(), since that means my app could just download new code from the Internet and eval it, thus eliminating the middleman (bottleneck!) that is the Apple approval process for all future updates.

Re:Mono?

[RightSaidFred99]

Are you being double-backwards redundantly hilarious? .Net and Microsoft are stable now. Let's see on what platforms the largest growth for remote exploits over the last year have been, shall we?

As a beta user of this, let me clarify

[rabtech]

Let me clarify how this works:

1. Yes, it is compiled ahead-of-time so there is no violation of the iPhone Developer SDK ToS rules; this also means a lot of the powerful Reflection stuff doesn't work because you can't do runtime inquiry on a type and create an instance dynamically. It also means the DLR is unlikely to ever run on the iPhone.

2. Much of the types map to Objective-C types, UI Kit, etc, and so does the only GUI library. (Note that types like System.String map to NSString, etc as well.)
You actually still do your GUI in Interface Builder, but MonoDevelop picks up changes to the XIB and auto-generates partial classes to represent the XIB actions and outlets. This step alone eliminates a lot of the boilerplate crap you have to do with Xcode that we Visual Studio developers are used to having the computer take care of automatically. Events can be handled via the C# obj.Event += handler syntax, MonoTouch takes care of hooking it up behind the scenes.

3. You can import Apple frameworks with DllImport and call any of the Foundation functions. There are also helpers that take handles (pointers) from those functions to Objective-C objects.

4. Most of the glue is automatic by decorating your classes/methods with the proper attributes (eg: make a class implement a protocol, then mark the methods as to what message in the protocol it handles). It really is a very slick package and a joy to use.

5. Garbage Collection! This rocks, it was very disappointing to see Apple fail to bring their GC over to the iPhone.

6. Most of your libraries aren't going to work because they require reflection, framework classes, etc that don't exist or aren't statically linkable into your executable. Besides, that isn't the point. For me, the point is to use a language I am used to (avoiding the @synthesize, -/+, and [[[[[[[ crap that makes Objective-C annoying to use). It is impossible to overstate how much the automatic hookup with XIB files makes developing a GUI so much easier to do. I only wish IB would automatically make all controls Outlets, then I'd be set. I find that you spend way too much time spitting out boilerplate code and doing repetitive boilerplate actions in IB when the computer could just as easily figure all that out for me (like Visual Studio does with a WinForms app).