iPhone Gets .Net App Development 327
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."
Launch Times? (Score:5, Interesting)
Re:Launch Times? (Score:5, Informative)
Probably not too bad - my guess would be it's using the AOT version of Mono, which compiles the framework into the final application, resulting in much better load times in performance-critical environments (see http://www.mono-project.com/AOT [mono-project.com] )
Re:Launch Times? (Score:4, Interesting)
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? (Score:5, Interesting)
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? (Score:5, Insightful)
Re: (Score:2)
Exactly.
Why would anyone get excited about this, I don't know. Sounds like a big mess just waiting to happen.
Re:Launch Times? (Score:5, Insightful)
It's no magic that Mono is always a version behind .net or more. It's just that lots of people are not realizing this yet, or the same with silverlight. It's stupid because if it was complete compatible then people would actually have more interest in windows, too.
Re:Launch Times? (Score:5, Interesting)
Actually, there are two large things standing in the way of that:
#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? (Score:5, Informative)
Java has quite nice bindings to C++ now in form of JNA ( https://jna.dev.java.net/ [java.net] ), it's actually about as powerful as .NET interop.
Of course, managed C++ is even better still.
Re:Launch Times? (Score:4, Informative)
Java has quite nice bindings to C++ now in form of JNA ( https://jna.dev.java.net/ [java.net] [java.net] ), it's actually about as powerful as .NET interop.
Yeah, there's also J/Invoke [jinvoke.com].
The problem is Java language itself. Yes, you can map unsigned ints to signed ones, pointers to longs and structs to classes, and so on - but mappings can get very complicated when API itself is (i.e. lots of nested structs/unions of arrays of pointers, etc). In C#, the type system lets you drop this level of abstraction when needed (or when it is simply inconvenient), and work with raw pointers, C-style fixed-size arrays, structs and unions with exact same memory layout - no marshaling involved. It is faster as well, obviously, since there's no need to copy data back and forth (which can cost a lot for large object graphs).
Re: (Score:3, Insightful)
lets you drop abstractions.... i am not sure for which language this is making a point.....
We're talking about directly invoking functions from native shared libraries. Regardless of abstractions, this scenario is inherently unsafe - since anything can happen in native code - so it doesn't matter if you represent a pointer as an int, the function that you're calling will SIGSEGV on a null value anyway, and may quietly corrupt memory if you give it a wrong non-null value.
An abstraction level here doesn't really buy you any safety, and only serves to map native constructs (such as pointers) to the
Re: (Score:3, Informative)
It's extra work to use managed and unmanaged code in the same project. Microsoft's implementation of Winforms is a wrapper for legacy WIN32 controls, leading to a lot of funky behavior when you try to subclass them.
It's generally just a pain in the ass to use compared to Qt on Windows or Linux, which gives me true interoperability and a slick interface with little work. There are some controls available in .NET that aren't there in Qt, but the reverse is true also. I find Qt's model/view architecture easier
Re:Launch Times? (Score:4, Insightful)
Re: (Score:2, Informative)
How does this hurt Apple?
This will only increase the amount of apps they'll have in their store - as just about anyone and their mother can learn C#, or knows it already.
Re:Launch Times? (Score:4, Informative)
Because a secret agenda of theirs is to make you use XCode to develop apps. This was made quite clear to my former company on a project. That's why you won't see Java nor Flash any time soon, and the ToS explicitly forbids apps that execute external code. I theorize that by doing this they 1) want control and 2)hope that the iPhone development activity propagates into OS X development activity.
Re: (Score:2, Insightful)
and the ToS explicitly forbids apps that execute external code.
Actually, the ToS explicitly forbids apps that execute external code from running on the iPhone
This is an 'app' that runs on your workstation, used to compile code into an executable. The resulting executable, which would not execute any external code just like all the apps out there now, would be perfectly fine to put on the iPhone.
It's an SDK, not an interpreter.
Re: (Score:2)
except you can't put apps onto the iphone without apples approval.
while I think they are a bit to restrictive, they do make sure apps don't do stupid things like able to install malware.
Re:Launch Times? (Score:5, Insightful)
Because a secret agenda of theirs is to make you use XCode to develop apps. This was made quite clear to my former company on a project. That's why you won't see Java nor Flash any time soon, and the ToS explicitly forbids apps that execute external code. I theorize that by doing this they 1) want control and 2)hope that the iPhone development activity propagates into OS X development activity.
Yes. Use our Development Tools on our Platform. Truly it is a secretive agenda. Get real.
Re: (Score:3, Informative)
> Visual Studio Express has everything you need that comes with Visual Studio
No it doesn't. No resource editor for one.
Re: (Score:3, Interesting)
Doesn't the EULA also forbid you from distributing executables made with Visual Studio Express editions?
Re: (Score:3, Informative)
Of course, Visual Studio Express doesn't come with any mobile development tools, which might be useful to someone wanting to write for mobile devices (not that this applies to the iPhone).
Re: (Score:2)
Re: (Score:3, Insightful)
Apple cares as much about control over the application development platform as they do about the number of apps in their store. Look, I don't hate Apple or anything (hell, I'm posting this from a new MacBook Pro), but the truth is the truth.
I call BS.
Apple cares far more about control than about number of apps. These are the people who for a year after launch of the SDK forbidden posting of any sample code in public!!! Number of apps is not a priority to Apple - otherwise it would take less than a month it takes now to get an app even looked at, let alone approved and they would not reject applications just because they did not like the loading splash screen. (they objected to one of my submissions because splash screen was a logo instead of a
Re:Launch Times? (Score:5, Interesting)
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: (Score:2)
It hurts Apples partners and customers. The telcos ability to use the same device to sell various upgrades and data plans, mins ect.
Your role as a consumer is to link your bank account to a regional telco and enjoy.
Java might just eat into battery life just enough to on average change the device from "lasts a long time on a change" to "the battery life is ok".
Re: (Score:2)
Java might just eat into battery life just enough to on average change the device from "lasts a long time on a change" to "the battery life is ok".
"lasts a long time on a charge"??? I am not sure what phone you are talking about, but "the battery life is ok" would be a huge improvement for iPhone. My iPhone requires several charges a day - I cannot imagine it getting any worse. My wife uses hers much less, so she usually makes it to the evening hours, but having a charger in any place I spend more than a few hours is a must.
Re: (Score:3, Interesting)
How much do you use it? I use my iPhone G3 as a music player roughly six hours a day, make a few phone calls, send lots of text messages and perhaps an hour or so of Web browsing and I generally have a least a half-charge left at the end of the day. Sure, I've had phones with better battery life but they didn't do nearly so much. It's a trade-off, for sure.
I do use it a fair deal more than an average user and while I would agree that it is really pretty decent on battery when you listen to music, any time a screen is on you can just SEE the battery drain. I mostly use phone, email, calendar and SMS and while most of those use screen (and thus drain battery) I think also at fault is the very poor radio inside my G3. I pretty much do not get any reception inside most buildings (which is sad, cause I spend most of my time in downtown SF - if you can't get recept
Re: (Score:3, Interesting)
It hurts Apples partners and customers.
Ok, I'll bite. How does it hurt customers?
The telcos ability to use the same device to sell various upgrades and data plans, mins ect.
Um... What?
Data seems to be much more expensive than minutes.
Your role as a consumer is to link your bank account to a regional telco and enjoy.
I don't see how this is improved by letting said telco lock down my phone, or lock me into a two-year contract.
Java might just eat into battery life just enough to on average change the device from "lasts a long time on a change" to "the battery life is ok".
...and Javascript doesn't?
Re: (Score:2)
well java, and flash on other phones cut battery life by 1/3 or more. not to mention horrible load times. Apples' native apps already cut battery life down.
Re:Launch Times? (Score:5, Informative)
It hurts ATT and thus hurts Apple. The reason for the Google Voice rejection became clear when ATT announced their 'a-list' program to start on the 20th of this month. As long as you have a plan costing $59+ (most iphone plans) you can put 5 numbers on your a-list that will not count against your minutes. Add the Google Voice number to your a-list and boom, unlimited talk time.
Re: (Score:3, Informative)
they open the door to even shittier apps and hellishly non-native interfaces.
So does any turing-complete language with a decent graphics API. In other words, so does Objective C.
I don't see why another language is a problem as long as Apple requires native UIs using Cocoa, and actively polices the app store.
Java is *still* slow,
Citation needed.
lowest common-denominator shit.
Which iFart isn't?
Can you imagine if we had "normal" cell phone programs on the iPhone instead of people taking the time to do native versions?
We'd actually have portable apps! What a novel idea! Someone would be able to develop an iPhone app, and then after Apple rejects it for some bullshit reason, they can actually go deploy it on Blackberry, Symbian, Palm, or Android!
Re: (Score:2)
Re: (Score:2, Insightful)
My guess is approximately zero seconds, as Apple is sure to kill this.
Why would Apple want to kill this?
MonoTouch is not significantly different from Unity 3D [unity3d.com], which has been used to create over 40 games for iPhone [tirania.org] already.
The primary difference is, instead of needing to create user interfaces purely atop GL, you can use the CocoaTouch libraries and get native buttons, frames, html controls, etc.
Average Star Rating 2.6 (Score:2)
Re: (Score:2)
The 40 games listed on the above link have an average rating of 2.6, and range from a rating of 1 star to 4 stars, which is not bad, but not particularly good either
Actually, it is pretty good. For some reason, there are a lot of idiots rating iPhone apps, and apps that perform exactly as the developer claimed, flawlessly, get a lot of low ratings. I've seen a lot of reviews that go like this: "This app does what it is advertised to do, perfectly. It's very useful. But I wish it also did (function that makes no sense for this app)" and they rate it 1 star.
Re: (Score:2)
They can't kill the project, but they can deny any app written with it from the App Store, which they will almost certainly do as any sort of interpreted code is already a violation of the iPhone SDK licensing agreement. Unless this compiles everything all the way down to ARM machine code, it's already banned.
Why CLR (.NET mono) and not JVM (Java)? (Score:2)
Re:Why CLR (.NET mono) and not JVM (Java)? (Score:5, Insightful)
Re:Why CLR (.NET mono) and not JVM (Java)? (Score:5, Insightful)
Since when has it needed a reason?
Re:Why CLR (.NET mono) and not JVM (Java)? (Score:4, Informative)
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?
Re: (Score:2, Insightful)
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!
Re: (Score:3, Informative)
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 [microsoft.com] )
Also on the Windows side the Common Language Runtime (CLR) of the .NET Framework is al
Re: (Score:3, Informative)
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).
Re: (Score:2)
I don't think there's much of a desire on anyone's part to port legacy applications to the iPhone. The value comes from being able to use a language you already know which for most people isn't Objective-C.
Re: (Score:3, Insightful)
Re:Why CLR (.NET mono) and not JVM (Java)? (Score:5, Informative)
"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 ...)
Re: (Score:2)
Because they don't just want crappy ports of crappy applications.
Seems to me that discouraging code reuse is a great way to get lots of crappy applications reinventing the wheel.
Re: (Score:2)
Re: (Score:2)
Me either. As far as I know there's no problem using a framework provided it's embedded in the .app bundle. The iPhone NSBundle class seems to provide the same framework support that the Mac NSBundle class does, except for the obvious filesystem restrictions.
Re: (Score:2)
In other words, it discourages any kind of preprocessor. Nice.
Re: (Score:2)
I don't know that they do, but I do know that there was a specific framework -- can't remember the name, but one man's ebook was rejected when it was built in this framework, yet sometimes accepted when he hid the fact that he used the framework.
It isn't so much that they banned the framework explicitly, as that the use of this framework led to an app not being approved, yet the exact same app, once it had been scrubbed of obvious references to that framework (seriously, changing variable names), was approv
Re: (Score:2)
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?
Yes Mono Frameworks are a POS compared to Cocoa Frameworks. See how substantial your arguement is and how I counter with an equally weighted view? In this case, it's true, but it's just as weak of me to proclaim it simply to defend one or the other. Bottom line, Cocoa Frameworks are unified down to the kernel. Mono would be a second-rate solution.
Re: (Score:2)
Yes Mono Frameworks are a POS compared to Cocoa Frameworks. See how substantial your arguement is and how I counter with an equally weighted view? In this case, it's true,
Actually, no, it's not. As the AC says, Mono Touch wraps Cocoa anyway. This is about Apple not allowing people to build frameworks, even if said frameworks cooperate with their precious Cocoa.
It really looks like you're confusing an API with a language.
Bottom line, Cocoa Frameworks are unified down to the kernel. Mono would be a second-rate solution.
Actually, it looks like you don't know the difference between an API and a language. If you're the competition, maybe I should get into iPhone development, because damn.
Re: (Score:3, Insightful)
Re: (Score:2)
That is not an advantage.
Yes it is.
Or do you want to have an actual discussion? Why isn't it an advantage?
Go native, or don't bother.
Why?
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
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?
Re: (Score:2)
But the problem is, Apple has explicitly disallowed "frameworks" -- and this definitely sounds like a framework.
No, they haven't. They disallow (and don't provide any mechanism for) the installation of shared libraries that more than one application uses and they disallow the inclusion of any type of interpreter, or VM that could allow people to run applications that haven't been blessed by Apple and sold through the iPhone App Store.
I know that java can be compiled, and there is absolutely no reason that someone couldn't write a Java->Cocoa wrappers and submit a compiled version of a java app if they wanted. AFAI
Re: (Score:2)
VM that could allow people to run applications that haven't been blessed by Apple and sold through the iPhone App Store.
Except their own, of course. JavaScript has eval(), which does work on the iPhone, AFAIK. It's up to Apple to reject apps that use it to download code from the Internet.
So really, this is a complete bullshit argument.
I wouldn't want to waste my time developing anything for the iPhone given their approval policies.
Agreed.
Re: (Score:2)
They do not want third party apps using fourth party libraries using Nth party foo on their platform.
Uhm... Why not?
Code reuse and the deployment implementation are completely separate issues.
Except that they tend to avoid even apps which have had some of their code generated by a third-party tool, so it seems that "deployment implementation" or not, Apple's policy is effectively blocking some forms of code re-use, for no good reason.
Re: (Score:3, Informative)
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
Re: (Score:2)
Actually, it's not even that. The TOS state that you can't run external code. If you want to write an app that includes an interpreter, VM or whatever that runs code included in the app then that's fine.
The Commodore emulator that was approved on the app store the other day was such a program. It was pulled because it was found that it was trivial to get user access to the basic interpreter (thus running outside code). When they patch it up so that you can't do that, it'll probably get approved again.
Re:Why CLR (.NET mono) and not JVM (Java)? (Score:4, Informative)
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.
Re: (Score:2)
Mono and CLR are different implementations of the CLI.
Mono is *not* CLR.
Violates the developer agreement (Score:3, Insightful)
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.
No it doesn't. (Score:5, Informative)
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 [mono-project.com], 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.
Re: (Score:2)
I'd be curious about the garbage collection stuff though. Its ahead-of-time compiled, there's no runtime, and you usually need a runtime for the garbage collection, unless the compiler includes a pseudo-runtime to run the app or something. I'd assume it works the same as Java native compilers...how do those work, i never looked?
Re: (Score:2)
I would imagine it works in the same way Boehm GC (libgc) for C/C++ works. GC doesn't require a "runtime", it just requires a, well, GC, running on its own separate thread, started from main(). Of course, one could say that such a GC constitutes a "runtime", but that's stretching it.
Re: (Score:2)
Every language has a runtime, except assembly, it's just that some runtimes are statically linked with the final executable. This is the case here.
Re: (Score:2)
Chances are you already have installed one, nearly all the unity built games "zombiville" etc are built on it.
Re: (Score:3, Insightful)
Also, using C# is not THAT much better than the native objective-c
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 (C# and .NET which allows any language to compile to the CLI assembly are arguably even more powerful than Java right now). C# and .NET are definitely MORE powerful than objective C in a general purpose sort of way (objective C might have more depth in specific targeted areas like GUI widgets, but the breadth of massive fram
Re: (Score:3, Insightful)
Just because a platform has a greater number of frameworks doesn't mean it is more powerful. You could even turn it around and say that the number of 3rd party frameworks being developed indicates the language is missing some important stuff and everybody is trying to solve it in their own way, with lots of redundant, very similar frameworks.
You are probably comparing your desktop/server experience wth those languages to a mobile platform. I program Java and .Net for server apps every day and iPhone by nigh
Re: (Score:2)
I will grant you that the iPhone certainly has attracted a lot of attention from consumers and developers (unusual for an Apple platform), but one must be careful not to confuse popularity with ease of development. The iPhone may be easy to develop for (don't know personally), but that doesn't prove that popular == easy to develop for. The PlayStation platform, for example, has historically been both popular AND difficult to develop for. In fact, Sony went so far as to tout "difficulty of development" as a
Re: (Score:3, Interesting)
but one must be careful not to confuse popularity with ease of development. The iPhone may be easy to develop for (don't know personally), but that doesn't prove that popular == easy to develop for.
Absolutely, but in this case, from my experience it is true. I find it very easy and there are numerous stories of people new to programming making some very good and popular apps.
Apple has historically been more like Sony in this regard, limiting who can write for their platform AND what they can publish.
This is only try for the iPhone. ("historically" thus only going back 14 months!) There is not a single limation on the Mac platform; you can write anything you like and publish it any way you like. All without paying Apple anything, of course.
Also, something to remember about mobile platforms in general and iPhone in particular: they generally have a more limited and defined feature set because everyone has essentially the same hardware device (or with only minor variations).
You should try mobile development! :) To support the majority of Java ME phones that are
Re: (Score:2)
The Objective C/C libraries apple provides are pretty extensive too. I'm not really familiar with .NET though. Does it provide a good hardware accelerated/optimized FFT for example? Distributed object system? GPU accelerated image and video processing?
Re: (Score:3, Interesting)
Having more libraries doesn't make a language more powerful; in any case, it would make it more productive.
The hard link you have in your mind between Objective-C (or the libraries available to it, since you seem to interpret it as the same thing) and GUI widgets is j
Not more extensive (Score:3, Insightful)
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 librarie
Unity (Score:5, Informative)
Unity, www.unity3d.com, which uses Mono, has been available on the iPhone for some now.
Re:Big Difference Between The Two (Score:4, Informative)
Haha! That's a good one. Although I'm sure the developers of the 250 games that have shipped with Unity probably care somewhat. :)
XOR to iPhone SDK? (Score:2)
Re: (Score:3, Informative)
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.
Re: (Score:2)
Re:XOR to iPhone SDK? (Score:4, Informative)
It compiles to native code [monotouch.net]. It just allows you to use C# to do it.
Re: (Score:2)
Unless this thing compiles to native code, a runtime interpreter isn't allowed by Apple's SDK.
That's not really quite correct. Apple has approved apps that use a runtime interpreter. They key is that the app cannot allow any means of downloading "outside" code to run on the interpreter. If you want to implement your app as an interpreter for language Foo, which is only used to interpret the Foo code you include as part of the app, that should be OK.
...but does it run Linux? (Score:2)
Okay, so now we have a
Hmm - I could see playing Donkey.NET (http://www.microsoft.com/downloads/details.aspx?FamilyID=990D0EC1-23EA-4408-898D-1FD5727A8890&displaylang=en) playing on the iPhone.
Re: (Score:2)
No, you do not have a .NET runtime. You have a way of using .NET to build apps using the Apple UI objects, and compiling them to native code. The "plethora of Mono apps" you refer to are generally written using Gtk#, and would have to be re-architected to use the iPhone UI.
Re: (Score:2)
LOL
Have been doing this for months. (Score:3, Interesting)
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.
As a beta user of this, let me clarify (Score:4, Interesting)
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).
Should have used HTML5 (Score:3, Interesting)
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.
Re:Must be app-store approved... (Score:5, Informative)
Re: (Score:3, Interesting)
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 ap
Comment removed (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
I have had the JVM crap out on me multiple times when programming in JAVA- I have never encountered a failure or SINGLE runtime bug in .NET.
Re:Mono? (Score:4, Interesting)
Re: (Score:3, Interesting)
"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.
Re: (Score:3, Funny)