Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Novell Programming Technology

iPhone Gets .Net App Development 327

Posted by ScuttleMonkey
from the next-comes-drag-and-drop-development dept.
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."
This discussion has been archived. No new comments can be posted.

iPhone Gets .Net App Development

Comments Filter:
  • Launch Times? (Score:5, Interesting)

    by glennrrr (592457) on Monday September 14, 2009 @04:24PM (#29419359)
    Well how long does it take to load the whole Mono framework runtime because every second counts on the iPhone?
    • Re:Launch Times? (Score:5, Informative)

      by Gwala (309968) <adam@NOsPaM.gwala.net> on Monday September 14, 2009 @04:27PM (#29419401) Homepage

      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)

      by Anonymous Coward on Monday September 14, 2009 @04:27PM (#29419415)

      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)

      by digitalunity (19107) <digitalunityNO@SPAMyahoo.com> on Monday September 14, 2009 @04:29PM (#29419439) Homepage

      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)

        by thetoadwarrior (1268702) on Monday September 14, 2009 @04:34PM (#29419493) Homepage
        Like MS will ever allow that to happen. If .Net and Mono were completely compatible then it would be much easier to port apps to Linux and therefore remove the need for Windows.
        • by markdavis (642305)

          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)

          by poetmatt (793785) on Monday September 14, 2009 @04:39PM (#29419573) Journal

          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)

          by SanityInAnarchy (655584) <ninja@slaphack.com> on Monday September 14, 2009 @04:55PM (#29419761) Journal

          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? (Score:5, Informative)

            by Cyberax (705495) on Monday September 14, 2009 @05:03PM (#29419859)

            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)

              by shutdown -p now (807394) on Monday September 14, 2009 @05:53PM (#29420273) Journal

              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:Launch Times? (Score:4, Insightful)

      by palegray.net (1195047) <philip.paradis@pa3.14legray.net minus pi> on Monday September 14, 2009 @04:31PM (#29419463) Homepage Journal
      My guess is approximately zero seconds, as Apple is sure to kill this.
      • 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)

          by Snap E Tom (128447) on Monday September 14, 2009 @04:46PM (#29419637)

          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)

            by Anonymous Coward

            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.

            • by peragrin (659227)

              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)

            by tyrione (134248) on Monday September 14, 2009 @05:30PM (#29420103) Homepage

            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.

        • 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.
          • Re: (Score:3, Insightful)

            by Em Ellel (523581)

            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)

          by SanityInAnarchy (655584) <ninja@slaphack.com> on Monday September 14, 2009 @04:58PM (#29419803) Journal

          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.

          • by AHuxley (892839)
            'I don't know, how does Google Voice hurt Apple? How does Java hurt Apple?"
            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".
            • by Em Ellel (523581)

              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)

              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?

          • by peragrin (659227)

            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)

            by EastCoastSurfer (310758) on Tuesday September 15, 2009 @12:14AM (#29422685)

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

            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.

        • Lolzers. You god modded Troll for absolutely no apparent reason.
      • Re: (Score:2, Insightful)

        by Jon Pryor (118031)

        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.

        • 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. But at least it is possible to get as high as 4 stars with Mono; I'm actually surprised by that.
          • Downhill bowling 4
          • Billiards 2
          • Space Pig 1
          • Age of Curling 3.5
          • DuskTreaders 2.5
          • X-Razer 2.5
          • Invinciball 3
          • SlidePop 2
          • FuguMaze 2
          • Monkey Diving 2.5
          • Ball-X 3
          • Fugu-Tilt 2
          • Pizza Dash 2
          • Debris 2
          • Trash It! 2.5
          • Asteroid Strike 2.5
          • Crazy Snowboard 3.5
          • Bubble Bang 2.5
          • Bounce
          • 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.

      • by samkass (174571)

        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.

  • Anyone know why Apple would allow one and not the other? Does Mono not multitask or something?
    • by pavon (30274) on Monday September 14, 2009 @04:31PM (#29419465)
      MonoTouch compiles the code into a native executable, rather than shipping with a VM. Apple has no reason to disallow that.
      • by kalirion (728907) on Monday September 14, 2009 @04:35PM (#29419503)

        Since when has it needed a reason?

      • by SanityInAnarchy (655584) <ninja@slaphack.com> on Monday September 14, 2009 @04:45PM (#29419627) Journal

        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)

          by Xtravar (725372)

          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)

            by icepick72 (834363)

            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)

              by naasking (94116)

              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).

          • 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)

              by yabos (719499)
              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.
          • 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.

        • by PixelSlut (620954)
          Can you give a link to support this? I have never heard before that they ban frameworks.
          • by ceoyoyo (59147)

            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.

          • 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

        • by tyrione (134248)

          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.

          • 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.

        • by pavon (30274)

          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

          • 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.

    • by asdf7890 (1518587) on Monday September 14, 2009 @04:37PM (#29419551)

      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.

    • by loufoque (1400831)

      Mono and CLR are different implementations of the CLI.
      Mono is *not* CLR.

  • by TejWC (758299) on Monday September 14, 2009 @04:35PM (#29419515)

    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)

      by Plug (14127) on Monday September 14, 2009 @05:01PM (#29419823) Homepage

      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.

      • by Shados (741919)

        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?

        • 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.

        • by naasking (94116)

          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:3, Insightful)

      by CodeBuster (516420)

      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)

        by daBass (56811)

        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

        • 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)

            by daBass (56811)

            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

      • by ceoyoyo (59147)

        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)

        by Santana (103744)

        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 frameworks like C# and Java is truly vast)

        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)

        by SuperKendall (25149)

        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)

    by tylersoze (789256) on Monday September 14, 2009 @04:36PM (#29419537)

    Unity, www.unity3d.com, which uses Mono, has been available on the iPhone for some now.

  • So...is this an alternative to Apple's iPhone SDK, or does it work with it? (in other words, could developers not have to pay the Apple tax to write iPhone apps?)
    • Re: (Score:3, Informative)

      by ZackSchil (560462)

      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.

    • by PixelSlut (620954)
      It's basically a language binding. That's it. But if you're fluent in C# and don't feel like spending the time to learn Objective-C, it looks like it's totally worth it.
  • :P

    Okay, so now we have a .net runtime (mono) on the iPhone. Can we safely assume that the plethora of mono apps can be ported? (http://www.mono-project.com/Software)

    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.
    • by Plug (14127)

      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.

  • by codepunk (167897) on Monday September 14, 2009 @06:44PM (#29420677)

    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.

  • by rabtech (223758) on Monday September 14, 2009 @08:48PM (#29421567) Homepage

    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).

  • by gig (78408) on Monday September 14, 2009 @10:19PM (#29422135)

    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.

Chemist who falls in acid is absorbed in work.

Working...