I’m happy to see that Miguel de Icaza and crew have found a home in their new company and will be continuing to bring their high quality products to the .NET world.  Given that there was so much whirlwind when the Novell/Attachmate stuff happened recently, it’s worth taking a look back at where things have been and hopefully look forward to where they are going in the future.

It has been a bumpy road for those who want to use .NET to target iOS and Android.  The products we’ve had available to us were definitely not the problem — they are fantastic.  The big hurdles have always been related to legal and availability issues.  MonoTouch was released in September 2009 and immediately questions were raised as to whether Apple would allow it.  There was a bit of a war of words between those who would use MonoTouch and Cocoa developers who thought it was a bad idea to not use and learn the native tools/platform.

After about 7 months of Apple allowing apps to be developed with third party tools and languages, they dropped a bombshell on all of us on April 8, 2010 with the infamous change to Section 3.3.1 of the iOS Developer Program license.  The changed section read:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This looked to be a deathblow primarily aimed at Adobe.  Adobe has a set of tools that allows for developers to create iOS apps in Flash and Apple wasn’t too keen on that idea.  Unfortunately, this meant that MonoTouch fell under this new restriction and there was a lot of worry that we would lose the ability to create iOS apps with C# forever.  However, Miguel and his team at Novell pledged to move forward despite the change to Section 3.3.1.  Miguel proposed a few theories on his blog and explained why he thought MonoTouch was misrepresented in the conversations regarding 3rd party tools and languages.  Many in the community stuck around in spite of the change while others were unable to due to their companies not wanting to wade through the uncertainty.  Those that stuck around quickly found that Apple was still allowing apps developed with MonoTouch into the App Store.  Section 3.3.1 was clearly a policy that Apple was going to enforce on a very subjective basis.  Either they did not want to enforce it in all cases, could not enforce it in all cases, or were using it to pick and choose their battles.

Thankfully, it didn’t last long.  On September 9th, 2010 (almost a year after MonoTouch was officially released), Apple published a statement announcing a change to Section 3.3.1.  The new version of the section relaxed “all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code”.  This was a definite victory for the 3rd party platforms and indicated that the path was clear for MonoTouch to thrive.

Now we come to the aforementioned whirlwind that was kicked up on May 3rd of this year by InternetNews.com when they reported that Attachmate “laid off an unknown number of U.S. based Novell developers that were working on the open source Mono project” (link).  What followed was an almost two week period of uncertainty.  Was the rumor true?  Was the entire Mono team released or did some of them stay?  What about MonoTouch and MonoDroid?

None of these questions were answered until May 16th, 2011 when Miguel announced the formation of Xamarin which would carry the torch for iOS and Android development using C#:

This set off another round of speculation since Xamarin was going to be developing new tools instead of leveraging the existing MonoTouch code.  This was primarily due to licensing issues regarding Mono and MonoTouch/MonoDroid.  The plan was for the team to rapidly get up to a public beta on the new tools within a few months.  Clearly, they had their work cut out for them.

Again, however, the uncertainty surrounding the future of Mono was short lived.  On July 18th, Miguel announced on his blog that a partnership had been formed between Novell/Attachmate and Xamarin.  The partnership included Xamarin obtaining a perpetual license for “all the intellectual property of Mono, MonoTouch, Mono for Android, and Mono for Visual Studio” which would allow them to begin immediately selling and supporting MonoTouch and MonoDroid.

This brings us to today where we now have the opportunity to benefit from all that has transpired in the past.  We are able to buy MonoTouch in its current state and get support from the team that created it.  We will also benefit immensely from the work that the team did in the time between May and July of this year.  A lot of new ideas were formed in this time period.  This is very common when you take a fresh look at an existing problem.  Miguel has stated that these new features will be rolled into the existing MonoTouch codebase in future versions.  So, where is MonoTouch heading?

I think now that the team has the opportunity to fully focus on the future of C# for mobile, we are likely to see some wonderful things coming soon.  Xcode 4 integration was previewed at one point for MonoTouch and I can’t wait to see that full integration happen.  iOS 5 is on the horizon and if the past is any indication, MonoTouch will be ready to support it when the time comes.  Miguel has also mentioned improvements to MonoDevelop which would be welcomed with open arms.  I guess what I’m waiting for more than anything are the surprises that the team most likely has in store for us.

All I can say is I’m hoping for a bright (and stable) future for MonoTouch!

Update: Seems like the future is now!  Miguel announced Mono 2.10.3 and there also is a new version of MonoTouch (4.0.4.1).

I am pleased to announce that top secret Project Empty Tome is officially under way.  I will provide more details as the project progresses but I am certain that this is something the entire MonoTouch community will benefit from.

I may call on a few of you in the community for help on this project and I look forward to your input when that time comes.  Stay tuned to this this blog (subscribe to the RSS feed!) for more updates as they become available. 

MonoTouch 1.2 adds a new class called UITableViewSource that is intended to reduce some of the code clutter that is encountered when using TableViews in MonoTouch.  The UITableViewSource class combines UITableViewDelegate and UITableViewDataSource into one convenient class that contains the methods of both.  This results in a much closer approximation of the way the UIKit classes work.  In UIKit you would typically have your TableViewController implement the protocols for delegate and datasource and thus all of your methods from these two protocols would be in the same class.  The UITableViewSource class gives you a similar code structure.

I have modified the uitvc template for generating a UITableViewController that uses this new UITableViewSource class.  Create an Empty class file from the File->New File…->General menu.  Delete everything in this class file.  Type uitvc and hit the tab key. This will create a UITableViewController subclass that sets up a UITableViewSource as its Source.  All you need to do is specify the namespace for the controller, the name for your class, the shorthand that will be used to reference the instance of the controller in the UITableViewSource, and the Title for the controller.  I have provided a few overrides that will get you started after that.  You can download the template here: uitvc.template.xml

You will need to add this to ~/.config/MonoDevelop/templates/code (choose “Go to folder…” from the Finder menu and paste the directory to find it) and restart MonoDevelop. (Note: If you don’t see templates/code in ~/.config/MonoDevelop, go to Preferences in MonoDevelop and click on Code Templates under Coding.  This should populate this directory.  You don’t need to do anything else here, just close Preferences and follow the instructions above to add the file to the ~/.config/MonoDevelop/templates/code directory.)

Yes, you read that title correctly, MonoTouch 1.2 supports debugging in MonoDevelop!  I have known about this for a while and I’ve just been waiting for the opportunity to let all of you know this wonderful news.  It hasn’t been an easy secret to keep as it is definitely a game-changing feature for many of you that have been on the fence about whether or not to jump on the MonoTouch bandwagon.  Well, you can’t use lack of debugging as a reason to not justify the purchase any more.

The really cool thing about this debugging support is that it works on both the simulator and the device.  Since Apple does not directly allow third parties to participate in their debugging infrastructure, Geoff Norton and Michael Hutchinson, et al., had to do a lot of work to get this to work and they should be commended for their efforts.  Debugging MonoTouch requires the iPhone to communicate back to the computer.  From the upcoming documentation at http://monotouch.net/Documentation/Upcoming/Debugger:

The MonoTouch debugger is a soft-debugger, that means that the generated code and the Mono runtime cooperate with the MonoDevelop IDE to provide a debugging experience.  This is different than hard debuggers like GDB or MDB which control a program without the knowlege or cooperation from the debugged program.

For on device debugging, your iPhone needs to be on the same Wi-Fi network as your computer (yes, debugging over Wi-Fi…even Apple doesn’t completely allow this).  You should note that the debug build of your code will include the cooperative Mono runtime so the resulting program will be larger than a regular program. This is because the generated code has been instrumented to be debugged.   A debug build will also be slower than a regular release build so it should not be used for performance testing.

The team has put a lot of really hard work into this.  The result of this work is a truly native feeling debugging atmosphere that should be familiar to anyone who has used IDE debugging in the past.  You set a breakpoint on a line and when your code hits that breakpoint you can inspect local variables in the Locals window, see the Call Stack in the Call Stack window, and get on-hover information for variables in your code.  At the end of this post there are screenshots for you enjoyment (and salivation!).

I can really only summarize this release in one word: awesome.  Go check it out for yourself later today at http://monotouch.net and stop into the IRC channel at irc.gnome.org #monotouch and say thanks to the development team for this awesome feature.

Update: According to Miguel de Icaza, there will be a beta of MonoTouch 1.2 available later today.

Here are the screenshots I mentioned previously:

The MonoTouch team has released version 1.1 of their framework for building iPhone applications using Mono.  This is an exciting release with lots of fixes and additions.  I’m personally looking forward to seeing the smaller application sizes and faster startup speed.  Web Services support will also be great for those of you with SOAP-based backend systems.  If you are developing MonoTouch applications, you have to get this!  Details after the jump.

If you have purchased MonoTouch, you can download the updated version from the download link provided when you purchased the product. 

If you are using the evaluation version you can download the updated version of MonoTouch from http://monotouch.net/DownloadTrial to receive the update.
You can download the updated MonoDevelop at: http://monodevelop.com/Download/Mac_MonoTouch 

Highlights:

            • All new iPhone 3.1 APIs are now available.
            • Native code generation is now 30% smaller for core assemblies.
            • Reduced startup time by up-to 50%.
            • Web Services support.
            • MonoDevelop now has an updater feature, so developers can more easily get the latest Mono, MonoDevelop and MonoTouch.

Fixes:

            • Fixed invalid CFRelease in CFRunLoop (#541524)
            • Fixed IList<T> in full-aot (#540355)
            • Fixed Delegate.BeginInvoke in full-aot
            • Fixed XElement[].Count in full-aot (#539085)
            • Fixed MKAnnotation in Simulator
            • Fixed linker to not always pull in Mono.Security
            • Fixed System.Timer linked-away exception
            • Decreased startup time on device by up to 50%
            • The System.JSon assembly is now available for inclussion.

Additions:

            • Added bindings to new 3.1 APIs
            • Added generic trampoline for marshal-runtime-invoke wrappers, providing significant code savings (34% on mscorlib size, equivalent savings for other assemblies).
            • Added 2 new ctors to NSFoundation.NSMutableUrlRequest
            • Added additional support for alternate types to NSData
            • Added new StringSize overloads to UIView
            • Added CALayer.Sublayers property
            • Added CoreAnimation.CATransaction class
            • Added new SystemSound constructors
            • Added SystemSound.FromFile (string)
            • Added System.Web.Services client support.
            • Added WCF client support (EXPERIMENTAL)
            • Added support to emit DWARF debug symbols in full-aot mode
            • Added support to be auto-updated from MD.
            • Updated keybidings to MonoDevelop for Emacs.

Changes:

            • SystemSound.FromFile no longer throws exceptions on error, and instead will return null.
            • iPhoneOSGameView no longer calls GL.Oes.BindFrameBuffer () during the second and subsequent CreateFrameBuffer () calls.  Code overriding iPhoneOSGameView.CreateFromBuffer () does not need to call GL.Oes.BindFramebuffer (All.FramebufferOes, base.FrameBuffer) to add a depth buffer to the frame buffer.

If you have any questions or concerns please see http://monotouch.net/Support

UPDATE #2: Polls closed!  Thank you for your input!  More news soon.

Please help me in my planning for the upcoming MonoTouch screencast series.  Screencasts will be the same (or better!) high quality as the “Getting Started With MonoTouch” screencast.  The goal of the series will be to take the viewer through all aspects of iPhone development and provide comprehensive training for this development framework.

To keep the quality at this level and produce the number of screencasts that will be needed to cover all of the topics that need to be covered, these screencasts will not all be able to be free.  That is where I need your feedback.  Please submit your answers to the following polls to help me make some pricing decisions!  Your input will help make this training series successful.

Update:

An update to this screencast for MonoTouch 5 will be coming soon.  Other than downloading from http://ios.xamarin.com instead of the old MonoTouch site and some changes to MonoDevelop, most of the concepts in this screencast are still valid.

MonoTouch is a new framework from Novell for creating iPhone applications using C#.  Since some of the concepts of developing for the iPhone platform will be foreign to the .NET developer, I thought it would be a good idea to create a screencast that eased them into the process.  Since a lot of .NET devs will be new to the Mac, I have tried to make as few assumptions as possible with regards to the your comfort level and proficiency with Mac OS X.

In this screencast, I will walk you through installing Mono (the open source cross platform .NET implementation), MonoDevelop (an IDE), and MonoTouch.  Once everything is installed, we will develop a “Hello iPhone” application.  Throughout the process of developing this application I will introduce you to core concepts of MonoTouch as well as familiarize you with Interface Builder (Apple’s tool for creating iPhone interfaces).

Getting Started with MonoTouch : click to view screencast

I hope this screencast helps get you up and running creating awesome iPhone applications using C#!

Note: The link to the web client for the IRC channel is actually on the Community page, not the Support page at monotouch.net.

If this screencast helped you, consider “touching” is to promote it at MonoTouch.info by clicking the “Touch it” button below and “kicking” it to promote it at DotNetKicks.

This two part screencast will walk through an example of creating a UITabBarController and adding a custom UITableViewController to it in both Xcode and MonoTouch.  I have tried to highlight the similarities and differences between the two frameworks/IDEs.

Having the option of creating iPhone applications in C# is intriguing and with the right project needs it could be a lifesaver.  While parts of the process are still a little rough around the edges, this is still an exciting project to follow/get involved with.

Part I: Creating the app in Xcode with Cocoa – click to watch

Part II: Creating the app in MonoDevelop with MonoTouch – click to watch

Also, here is the uitvc code template that was used to create the UITableViewController subclass: uitvc.template.xml  You will need to add this to ~/.config/MonoDevelop/templates/code (choose “Go to folder…” from the Finder menu and paste the directory to find it) and restart MonoDevelop. (Note: If you don’t see templates/code in ~/.config/MonoDevelop, go to Preferences in MonoDevelop and click on Code Templates under Coding.  This should populate this directory.  You don’t need to do anything else here, just close Preferences and follow the instructions above to add the file to the ~/.config/MonoDevelop/templates/code directory.)

UPDATE: I fixed the IntPtr constructor in the uitvc template.  It did not correctly pick up the name of the TableViewController subclass.  This new version should fix that.

If you have any questions, please visit http://monotouch.net.  Join the IRC at irc.gnome.org channel #monotouch.

Click the “kick it” link below to promote this story at DotNetKicks if you found this story helpful.