Slashdot Mirror
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."
Well how long does it take to load the whole Mono framework runtime because every second counts on the iPhone?
MonoTouch compiles the code into a native executable, rather than shipping with a VM. Apple has no reason to disallow that.
Since when has it needed a reason?
Unity, www.unity3d.com, which uses Mono, has been available on the iPhone for some now.
Anyone know why Apple would allow one and not the other? Does Mono not multitask or something?
No one has said that they would. The article itself states:
Mono is associated with the LGPL (GNU Lesser General Public) license used for distributing free and open source software, Novell with MonoKit is distributing Mono under commercial terms. The LGPL requires that users can replace an LGPL library with their own version of a library, a conflict with App Store requirements, according to Novell.
As the AC says, so does gcj.
But the problem is, Apple has explicitly disallowed "frameworks" -- and this definitely sounds like a framework.
Which is another way of saying, Apple is strongly discouraging if not outright banning one of the best ways to re-use code. Can anyone tell me why Apple is against code re-use on the iPhone?
Don't thank God, thank a doctor!
MonoTouch is not a runtime or an "app", it's a library with which you compile your own apps. It's ahead-of-time compiled, so you end up with a binary that runs on the iPhone.
It opens up iPhone development for millions of .NET developers, many of which may not have any interest in Objective C. And as far as I can tell, C#/Mono is garbage collected, and Objective C (on the iPhone) is not. That alone would make me interested in checking it out.
If you're not interested, that's great, move along.
It compiles to native code. It just allows you to use C# to do it.
Haha! That's a good one. Although I'm sure the developers of the 250 games that have shipped with Unity probably care somewhat. :)
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?
I think you may be prejudiced by your previous experience.
If his position is based on experience, then by definition it's not prejudice.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
"MS fooled a generation of 20 and 30 somethings into buying its code books and learning how to code in their walled garden."
Well, it was a much bigger garden than Apple's and the gardeners were well paid.
"Once touched by MS you are not used to learning any new skills"
Whatever you think of Windows, it could hardly be argued that developing for it didn't require learning "any new skills" (C, Win32,C++, MFC, COM, ATL, COM+, SQL Server, ASP, .NET framework, C#, ASP.NET, ADO.NET, DirectX, WCF, WPF, WWF, LINQ ...)
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).
Natural != (nontoxic || beneficial)