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?
I am pretty sure that adding your own runtime violates the developer agreement. The article didn't say if this "app" ever got approved but I highly doubt it would (this would also raise concern about the lack of Java on the iPhone).
Also, using C# is not THAT much better than the native objective-c. According to the article, it seems that "mono-touch" is really just C# bindings for cocoa-touch and I have had very bad experience using C# bindings for just about any kind of C code (allocated memory not getting garbage collected, bindings/function names being outdated, unmanged heap space limits, etc.). It sounds fun to play around with but I definitely wouldn't invest a large amount of time/money on it yet.
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!
So, Apple would also allow applications that were compiled with a gcj like compiler as well. I think that's the point the GP was making.
code running on a virtual machine => not allowed
Code not running in a virtual machine => allowed
Well.. maybe. Or Maybe not. But Definitely not sort of.
No, you'll still need to compile with XCode and sign the apps through Apple's $100 development program to try them out on a real phone. This just offers different UI libraries to link to when making your app rather than using cocoa.
If they crash or misbehave, Apple will reject your app though. So hopefully they're pretty solid. I imagine this is mostly to help enterprise customers port their Windows Mobile apps to the iPhone.
Because they don't just want crappy ports of crappy applications. They want stylish applications designed specifically with the iPhone in mind. And guess what? It's working!
Buckle your ROFL belt, we're in for some LOLs.
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.
I seem to recall that Mono is/was justified by Miguel de Icaza by virtue of .Nets inevitable popularity (Linux distros would _need_ it). When I read this article I can't help but think that the motivation here is to help make .Net more popular, and by extension, Mono more popular. I already abandoned Gnome, but I won't be surprised when I'm eventually trapped into installing Mono. .Net, C#, Java, I can't point to technical deficiencies and say "That's why I don't like them," but I have _never_ liked an app written in one of those languages. Buggy dependency ridden crapware has been my experience. I realize that an applications overall suckiness isn't necessarily a reflection of the language, but experience has set that expectation for me.
I really hope this project goes nowhere, because the last thing I want is more .Net apps in the world, on any platform.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
I'm unsure the mechanism used by Mono but when programming .NET on Windows there is a utility -- named ILMerge -- which allows multiple assemblies including Framework assemblies (dlls) to be compiled into one executable file; allowing a .NET app to without the need for a Framework's file to be spread about, kind of erasing the fact a Framework exists.
(I.E. http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx )
Also on the Windows side the Common Language Runtime (CLR) of the .NET Framework is always needed to interpret the Microsoft Intermediate Language Code (MSIL) "byte code" which is the result of explicit compilation of any .NET application's source code files (C#, VB.NET, COBOL.NET, IronPython, etc). This is a sort of on-the-fly compilation or translation to machine code that occurs as needed.
Even when a native executable for the Windows machine is generated by the ngen.exe utility, in order to bypass MSIL translation at runtime, ...the CLR is still required to manage the native executable (memory management, garbage collection, security, type enforcement, etc).
(I.E. http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.71).aspx )
Much C# code is compiled in managed mode (requires management by the CLR) and I'm sure the C# implementation for the iPhone would express this simplified programming model too. However I'd be interested to know what Novell/Mono team does with the CLR in the iPhone given the fact Apple does not like frameworks, interpreters or compilers. Does Mono compile the CLR feature into iPhone app, or get rid of it in favour of C# on top of a different concept, or something else?
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?
The advantage of mono-touch would be that it allows C# programmers to write iphone apps without having to learn objective C
That is not an advantage. Go native, or don't bother.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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 ...)
I have been programming games in unity which uses mono for the iphone for over 6 mos now. Since it compiles to
native code it runs blistering fast and is very stable. No there is not a problem with violating the apple sdk requirements
as it is compiling to native code.
Got Code?
Re:ILMerge, the Mono linker does it too, and better. It can remove unused code for instance.
Re: CLR on the iPhone, IIRC, it generates a native executable with all the needed code linked in, including GC, and any necessary runtime support (excluding JIT which is outlawed on the iPhone).
Higher Logics: where programming meets science.
"Guys, if you need to make iPhone apps, you got to build it using ObjectiveC"
Those games I have been programming and distributing using mono C# in Unity for the last 6 mos must be a figment of my imagination.
Got Code?
According to this http://monotouch.net/Documentation/Debugging There is virtually no debugging support for developing C# application on MAC OS X. No breakpoints and only Console.Writelines !!!!
Hey, if you want to use half-assed ports, knock yourself out.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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)
And why does another implementation language automatically imply half-assed ports?
It shows that the implementor is unwilling to learn.
Your ignorance is showing.
No, that's my experience. I've seen quite a few half-assed ports to the Mac in my time, and I sure as hell don't want to see them on the iPhone.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Excuse me? C# and .NET take the same approach as Java which is to provide the most powerful general purpose programming language + massive class library of common functionality possible
NeXT was taking that same approach probably before you were even programming.
The Objective-C language itself is not quite as modern as newer languages (though I personally think with blocks and GC it's pretty much there, though those will take a bit to translate over to the iPhone). But Objective-C has a huge set of libraries as well.
I've done extensive Java development prior to switching to iPhone development full time. Really there's not anything missing when you look across the NS and CF class libraries - rich collection classes, string handling with deep unicode support, internationalization, complex date/time formatting, good tools for introspection, RegEx support, etc. etc. etc.
A few of the Mac frameworks are curiously missing for the iPhone (the most curious to me being the one supporting SOAP) but there are good quality third party wrappers that fill those gaps.
And then of course, Objective-C has really useful frameworks like CoreData, and CoreAnimation which are richer than what you can get with other platforms (party because CoreData does not make the pretense at being an OR mapper, just a tool for managing object graphs that happens to support a database as one kind of store). I would say the existence of some of these frameworks especially makes it more useful and productive for application development than either C# or Java currently - especially since after using decades of different UI coding models, Interface Builder is the first IDE GUI development tool it makes sense to use over hand coding elements.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If this was an HTML5 target the app would not require Apple's approval to run on the iPhone, and it would also run on other platforms. This could be a target that makes an app to run on all smartphones, since they all have WebKit.
If these apps look generic they won't get approved for App Store. You have to design your way into app Store as well as engineer. With HTML5 you can do what you please.
Never, a Libertarian is just a greedball Republican who smokes pot.
Tired of all the isms, don't exploit people as an employer, or a government, mmmmK?
Programming Objective-C is not difficult. If you can program in any other language you can program in Objective-C. The hardest part about it is learning which frameworks and APIs are required to write your app.
Then we'll have to agree to disagree.
Back when I had a Mac, I much preferred having NeoOffice to having nothing but TextEdit. That's kind of a no-brainer.
Don't thank God, thank a doctor!
Taste isn't for everybody.
Nor is common courtesy, obviously.
There has never been a time when those were your only two options.
What would you suggest?
Don't thank God, thank a doctor!