iPhone SDK vs Windows Phone 7 Series SDK Challenge, Part 1: Hello World!

In this series, I will be taking sample applications from the iPhone SDK and implementing them on Windows Phone 7 Series.  My goal is to do as much of an “apples-to-apples” comparison as I can.  This series will be written to not only compare and contrast how easy or difficult it is to complete tasks on either platform, how many lines of code, etc., but I’d also like it to be a way for iPhone developers to either get started on Windows Phone 7 Series development, or for developers in general to learn the platform.

Here’s my methodology:

  1. Run the iPhone SDK app in the iPhone Simulator to get a feel for what it does and how it works, without looking at the implementation

  2. Implement the equivalent functionality on Windows Phone 7 Series using Silverlight.

  3. Compare the two implementations based on complexity, functionality, lines of code, number of files, etc.

  4. Add some functionality to the Windows Phone 7 Series app that shows off a way to make the scenario more interesting or leverages an aspect of the platform, or uses a better design pattern to implement the functionality.

You can download Microsoft Visual Studio 2010 Express for Windows Phone CTP here, and the Expression Blend 4 Beta here.

Hello World!

simulator[1] Of course no first post would be allowed if it didn’t focus on the “hello world” scenario.  The iPhone SDK follows that tradition with the Your First iPhone Application walkthrough.  I will say that the developer documentation for iPhone is pretty good.  There are plenty of walkthoughs and they break things down into nicely sized steps and do a good job of bringing the user along. 

As expected, this application is quite simple.  It comprises of a text box, a label, and a button.  When you push the button, the label changes to “Hello” plus the  word you typed into the text box.  Makes perfect sense for a starter application. 

There’s not much to this but it covers a few basic elements:

  • Laying out basic UI

  • Handling user input

  • Hooking up events

  • Formatting text

So, let’s get started building a similar app for Windows Phone 7 Series!

Implementing the UI:

UI in Silverlight (and therefore Windows Phone 7) is defined in XAML, which is a declarative XML language also used by WPF on the desktop.  For anyone that’s familiar with similar types of markup, it’s relatively straightforward to learn, but has a lot of power in it once you get it figured out.  We’ll talk more about that.

This UI is very simple.  When I look at this, I note a couple of things:

  • Elements are arranged vertically

  • They are all centered

So, let’s create our Application and then start with the UI.  Once you have the the VS 2010 Express for Windows Phone tool running, create a new Windows Phone Project, and call it Hello World:


Once created, you’ll see the designer on one side and your XAML on the other:


Now, we can create our UI in one of three ways:

  1. Use the designer in Visual Studio to drag and drop the components

  2. Use the designer in Expression Blend 4 to drag and drop the components

  3. Enter the XAML by hand in either of the above

We’ll start with (1), then kind of move to (3) just for instructional value.

To develop this UI in the designer:

First, delete all of the markup between inside of the Grid element (LayoutRoot).  You should be left with just this XAML for your MainPage.xaml (i shortened all the xmlns declarations below for brevity):

   1:  <phoneNavigation:PhoneApplicationPage 
   2:      x:Class="HelloWorld.MainPage"
   3:     xmlns="...[snip]"
   4:      FontFamily="{StaticResource PhoneFontFamilyNormal}"
   5:      FontSize="{StaticResource PhoneFontSizeNormal}"
   6:      Foreground="{StaticResource PhoneForegroundBrush}">
   8:      <Grid x:Name="LayoutRoot" Background="{StaticResource PhoneBackgroundBrush}">
  10:      </Grid>
  12:  </phoneNavigation:PhoneApplicationPage>

We’ll be adding XAML at line 9, so that’s the important part.


  1. Click on the center area of the phone surface

  2. Open the Toolbox and double click “StackPanel”

  3. Double click “TextBox”

  4. Double click “TextBlock”

  5. Double click “Button”

That will create the necessary UI elements but they won’t be arranged quite right.  We’ll fix it in a second. 

Here’s the XAML that we end up with:

   1:  <StackPanel Height="100" HorizontalAlignment="Left" Margin="10,10,0,0" Name="stackPanel1" VerticalAlignment="Top" Width="200">
   2:           <TextBox Height="32" Name="textBox1" Text="TextBox" Width="100" />
   3:           <TextBlock Height="23" Name="textBlock1" Text="TextBlock" />
   4:           <Button Content="Button" Height="70" Name="button1" Width="160" />
   5:  </StackPanel>

The designer does it’s best at guessing what we want, but in this case we want things to be a bit simpler.

So we’ll just clean it up a bit.  We want the items to be centered and we want them to have a little bit of a margin on either side, so here’s what we end up with.  I’ve also made it match the values and style from the iPhone app:

   1:  <StackPanel Margin="10">
   2:      <TextBox Name="textBox1" HorizontalAlignment="Stretch" Text="You" TextAlignment="Center"/>
   3:      <TextBlock Name="textBlock1" HorizontalAlignment="Center" Margin="0,100,0,0" Text="Hello You!" />
   4:      <Button Name="button1" HorizontalAlignment="Center" Margin="0,150,0,0" Content="Hello"/>
   5:  </StackPanel>  

Now let’s take a look at what we’ve done there.

  • Line 1: We removed all of the formatting from the StackPanel, except for Margin, as that’s all we need.  Since our parent element is a Grid, by default the StackPanel will be sized to fit in that space.  The Margin says that we want to reserve 10 pixels on each side of the StackPanel.

  • Line 2: We’ve set the HorizontalAlignment of the TextBox to “Stretch”, which says that it should fill it’s parent’s size horizontally.  We want to do this so the TextBox is always full-width.  We also set TextAlignment to Center, to center the text.

  • Line 3: In contrast to the TextBox above, we don’t care how wide the TextBlock is, just so long as it is big enough for it’s text.  That’ll happen automatically, so we just set it’s Horizontal alignment to Center.  We also set a Margin above the TextBlock of 100 pixels to bump it down a bit, per the iPhone UI.

  • Line 4: We do the same things here as in Line 3.

Here’s how the UI looks in the designer:


Believe it or not, we’re almost done!

Implementing the App Logic

Now, we want the TextBlock to change it’s text when the Button is clicked. 

In the designer, double click the Button to be taken to the Event Handler for the Button’s Click event.  In that event handler, we take the Text property from the TextBox, and format it into a string, then set it into the TextBlock.  That’s it!

   1:  private void button1_Click(object sender, RoutedEventArgs e)
   2:  {
   3:      string name = textBox1.Text;
   5:      // if there isn't a name set, just use "World"
   6:      if (String.IsNullOrEmpty(name))
   7:      {
   8:          name = "World";
   9:      }
  11:      // set the value into the TextBlock
  12:      textBlock1.Text = String.Format("Hello {0}!", name);
  14:  }

We use the String.Format() method to handle the formatting for us. 

Now all that’s left is to test the app in the Windows Phone Emulator and verify it does what we think it does!


And it does!

Comparing against the iPhone

Looking at the iPhone example, there are basically three things that you have to touch as the developer:

1) The UI in the Nib file

2) The app delegate

3) The view controller

Counting lines is a bit tricky here, but to try to keep this even, I’m going to only count lines of code that I could not have (or would not have) generated with the tooling.  Meaning, I’m not counting XAML and I’m not counting operations that happen in the Nib file with the XCode designer tool.  So in the case of the above, even though I modified the XAML, I could have done all of those operations using the visual designer tool.  And normally I would have, but the XAML is more instructive (and less steps!).  I’m interested in things that I, as the developer have to figure out in code.  I’m also not counting lines that just have a curly brace on them, or lines that are generated for me (e.g. method names that are generated for me when I make a connection, etc.)

So, by that count, here’s what I get from the code listing for the iPhone app found here:

HelloWorldAppDelegate.h: 6

HelloWorldAppDelegate.m: 12

MyViewController.h: 8

MyViewController.m: 18

Which gives me a grand total of about 44 lines of code on iPhone.  I really do recommend looking at the iPhone code for a comparison to the above.

Now, for the Windows Phone 7 Series application, the only code I typed was in the event handler above

Main.Xaml.cs: 4

So a total of 4 lines of code on Windows Phone 7.  And more importantly, the process is just A LOT simpler.  For example, I was surprised that the User Interface Designer in XCode doesn’t automatically create instance variables for me and wire them up to the corresponding elements.  I assumed I wouldn’t have to write this code myself (and risk getting it wrong!).  I don’t need to worry about view controllers or anything.  I just write my code.  This blog post up to this point has covered almost every aspect of this app’s development in a few pages.  The iPhone tutorial has 5 top level steps with 2-3 sub sections of each.

Now, it’s worth pointing out that the iPhone development model uses the Model View Controller (MVC) pattern, which is a very flexible and powerful pattern that enforces proper separation of concerns.  But it’s fairly complex and difficult to understand when you first walk up to it.  Here at Microsoft we’ve dabbled in MVC a bit, with frameworks like MFC on Visual C++ and with the ASP.NET MVC framework now.  Both are very powerful frameworks.  But one of the reasons we’ve stayed away from MVC with client UI frameworks is that it’s difficult to tool.  We haven’t seen the type of value that beats “double click, write code!” for the broad set of scenarios.

Another thing to think about is “how many of those lines of code were focused on my app’s functionality?”.  Or, the converse of “How many lines of code were boilerplate plumbing?”  In both examples, the actual number of “functional” code lines is similar.  I count most of them in MyViewController.m, in the changeGreeting method.  It’s about 7 lines of code that do the work of taking the value from the TextBox and putting it into the label.  Versus 4 on the Windows Phone 7 side.  But, unfortunately, on iPhone I still have to write that other 37 lines of code, just to get there.

10% of the code, 1 file instead of 4, it’s just much simpler.



Making Some Tweaks

It turns out, I can actually do this application with ZERO  lines of code, if I’m willing to change the spec a bit. The data binding functionality in Silverlight is incredibly powerful.  And what I can do is databind the TextBox’s value directly to the TextBlock.  Take some time looking at this XAML below.  You’ll see that I have added another nested StackPanel and two more TextBlocks.  Why?  Because that’s how I build that string, and the nested StackPanel will lay things out Horizontally for me, as specified by the Orientation property.

   1:  <StackPanel Margin="10">
   2:      <TextBox Name="textBox1" HorizontalAlignment="Stretch" Text="You" TextAlignment="Center"/>
   3:      <StackPanel Orientation="Horizontal" HorizontalAlignment="Center" Margin="0,100,0,0" >
   4:          <TextBlock Text="Hello " />
   5:          <TextBlock Name="textBlock1"  Text="{Binding ElementName=textBox1, Path=Text}"  />
   6:          <TextBlock Text="!" />
   7:      </StackPanel>            
   8:      <Button Name="button1" HorizontalAlignment="Center" Margin="0,150,0,0" Content="Hello" Click="button1_Click" />
   9:  </StackPanel>

Now, the real action is there in the bolded TextBlock.Text property:

Text="{Binding ElementName=textBox1, Path=Text}" 

That does all the heavy lifting.  It sets up a databinding between the TextBox.Text property on textBox1 and the TextBlock.Text property on textBlock1. As I change the text of the TextBox, the label updates automatically.

In fact, I don’t even need the button any more, so I could get rid of that altogether.  And no button means no event handler.  No event handler means no C# code at all. 

Want to see more? Check out Part Two.


Comments (20)
  1. barrkel says:

    I think lines of code generated by tooling should be minimized. Frameworks and languages should minimize the amount of code that your tools end up writing, because ultimately that’s code *you* need to maintain.

    As such, discounting code written by tooling is a cheap trick in my book.

    I’m no fan of Apple, and I like my Nexus One much more than my girlfriend’s iPhone or indeed my iPod Touch. But the comparison presented herein is weak. There’s a reason why typical VB programming was derided, and why ASP.NET was often derided too, when it devolved into multi-megabyte viewstate: because it promotes tooled-up double-click-and-code mentality, which is corrosive to good and maintainable design of software.

  2. Chico says:

    Nice post, I hope to see more comparisons !

  3. Thanks for the comment barrkel.  

    My goal was not to mimizize what’s generated by tooling (in this sample, there’s not much), but to try to even the playing field by narrowing the comparision to "code the developer MUST write to get the app working".  

    The UI on iPhone is defined in a Nib file, which I don’t think you can inspect via the tool.  There’s "code" in there, and it’s analogous to the XAML, but I don’t know how to count it.  So I can’t count "everything".  Likewise, I don’t want the differences to come down to semantics or formatting, for example where the curly braces are, so I don’t want to count that.  

    So I thought it fair to limit the comparison to code that the developer must actually type, and I want it to be a reasonably fair and accurate count.

    So I’m certainly open to other methodologies if you have a suggestion.  I just couldn’t think of another way to do it.

  4. Nice article!  But most developers I know, already know those truths.

    Personally, I learned Objective-C back in the 90’s when I purchased NeXTStep.  Regardless, I abhor the syntax of the language, and only tolerate it (along with Xcode) because the iPhone (and app store) is such a compelling platform.  The potential to make good money exists and is real.

    The combination of Silverlight, XAML, and C# is a far better development platform.  However, I find that my business sense often overrules my development preferences.  Time is limited, so you spend it where you feel you’ll get the best returns.

    The Windows Phone 7 story is an intriguing one.  Only time will tell if it can become as profitable for developers as the iPhone though.

    In the mean time, I for one will continue to concentrate on the iPhone and the impending iPad.  If only I could write iPhone apps using Silverlight…

  5. Eduardo Scoz says:

    This is just unfair: you’re comparing C to a high level language and platform. Number of lines of code only is not enough to say a platform is better or not than the other.

    If you want a fair comparison, take a look at MonoTouch (http://monotouch.net), which allows you to develop for the iPhone using Mono (.NET). You can write your entire application with the same one line of code to run on the iPhone, without having to bother with all the XML. I’ll do it in a few minutes and blog it at http://escoz.com.

  6. MisterJames says:

    I, too, was floored by the intensity of the iPhone intro.  We looked at it about six months ago.  The tooling isn’t anywhere near VS and we’re already using 2010 so xCode seemed quite a bit less mature.  Keep these going…I agree the comparison should be limited to what you actually have to do (measure of work). I pulled out of iPhone dev after Hello World because of the verbose code I foresaw writing (we stuck to web app dev).

  7. Eduardo Scoz says:

    Hi Shawn

    I just blogged a MonoTouch solution and comparison to your hello world sample here:


  8. Well, I guess MVC is better for more complex apps so comparing these two very simple apps by lines of code is just tricky. Perhaps comparing it with a MVVM type sample would be more honest. But the code-less version just beats it. And it’s more intuitive too, why would you even need a button? IMHO Silverlight just rocks!

  9. Neil Weber says:

    Comparing the two environments is good, but comparing lines of code (or XAML which IMHO is code too) is a poor metric.  What I think is most important is comparing how many concepts and much complexity the developer needs to deal with the write the application.  That includes packaging and deployment as well as tools and API complexity.

    One obvious strike against the iPhone development environment is it’s use of the ancient Objective C language with it’s 70’s era pre-processor and its lack of a garbage collector.

  10. You’re line count for the iPhone SDK is not at all accurate.  

    In your example, none of the lines of code in the app delegate files (.h and .m) would have been written by the developer.  Those are all normally generated by XCode when you create a project.  Yes, you could write them all by hand if you wanted too (same as you could with the XAML on the Windows side), but it would be very unusual for someone to do that.  

    Those lines of code certainly are not something "the developer must actually type".

    By my count in the example Apple files provided, I see:

    MyViewController.h: 7

    MyViewController.m: 18

    And even those counts could be shortened.  There’s unnecessary creation and assignment of temporary variables.

    Granted, you’ll never get down to 4 lines of code, but is this even a necessary or important comparison?   With either tool, Windows or Apple, there is just a handful of lines of code needed to write a simple Hello World app.  

    What’s the point?   Those difference between those numbers definitely would not scale to a real project.   You can’t reasonably compare percentage of initial lines of code for Hello World and make the conclusion that one SDK platform is going to require x% more lines of code than the other.

  11. Miguel de Icaza says:

    Loved the post, I love the work that you guys have done with the tooling.


  12. Hey lots of great comments!

    @Edward – yep, the platform has to be successful for any of this to matter.

    @Eduardo – great post, thanks for doing that.  I’ll be doing several more of these, so keep doing them in MonoTouch.  The MonoTouch example is MUCH nicer.  I’m not sure I completely agree with you on your XML/XAML comments, but I see your point.

    @Frank – yes, MVVM works very, very nicely with Silverlight.  But it was overkill for this case as you don’t really "need" it to make this very simple app work, which is all many authors really care about.  I will definitely be using it in future posts to even it out a bit more where it adds real value.

    @Neil – Concept count is a great idea.  I’ll think about how to use that.  To be clear, I’m not super-happy with code counting, it’s just hard to find an objective metric here.

    @Brian – this has not been my experience with XCode, but it’s very possible I’m using it wrong.  When I’ve used it, I’ve had to hand code most of the things in the h and m files – interface decls, didFinishLaunching init code, instane members, property decls, etc.  If there is a way to get the tool to generate all that stuff for me (which I kind of expected, but haven’t seen it), I’ll happily update the totals.  But according to the iPhone SDK walk through(s), you have to type all of them yourself.  There are some things it creates (dealloc), but that’s just the template.  Are there more ways?

  13. Foobar Boofar says:

    Nice article!

    I always feel people are slightly dishonest in saying that XAML is "no lines of code". It is, and it is harder to understand than normal procedural code for one. I think the most valuable comparison to be made is 1. How easy is it write, and 2. How easy is it for someone else to understand your code. The number of actual lines of code I find to be largely irrelevant.

  14. pocketMax says:


    I’m running a long-term project similar to this to compare commercial dev. on all major smartphone platforms.

    I plan to create the same "commercial" product on WM6, WP7, iPhone, Android and maybe Symbian and Blackberry if time allows. The goal is to finish by the end of the year and compare tool-sets, debugging, and also the issues with releasing and marketing on each platform.

    The WM6 version is already in prototype, and for WM7 I’ve just getting started.


    Bruce Jackson

  15. alxt says:

    Thanks Shawn, this is really cool! Here’s a question – does Silverlight for Windows Phone 7 series include all the features in Silverlight 3.0, including Triggers, Behaviours and the new controls such as DataGrid? Or it is only a subset of full Silverlight functionality? What about the new features in Silverlight 4.0, e.g. MEF, will they be supported for Windows Phone development?

  16. The answer to this question depends on how you define “Silverlight”.  

    On triggers and behaviors, those components actually come from Blend, and you can still use them via Blend.  So they’re there, but not part of the default platform, same as in Silverlight 3.

    The vast, vast majority of what developers think of as Silverlight is there (e.g. “in the box”)

    What’s not fall into three buckets:

    1) Stuff that doesn’t make sense on the phone.  

    Examples of this are pretty much everthing in System.Windows.Browser (e.g. DOM Bridge).  That’s intended for an app running in the browser, which isn’t the case on the phone, so it’s not there.

    2) Stuff that could run but isn’t optimized/styled/etc.

    DataGrid is a great example.  DataGrid isn’t a great UI for the phone, so we haven’t done the work to style it for the phone but there’s no technical reason why it *shouldn’t* run.  There’s few examples of this, like tooltip (no mouse!) that are techically there but not styled and you won’t see them as part of the default dev API set.

    3) Stuff that isn’t available due to platform differences and/or aren’t there “yet”.

    There are a few things that aren’t there: Reflection.Emit isn’t supported on the phone’s runtime and we’re looking at what to do there.  Sockets are important and we’ll add them in the future, and this is probably the biggest one.

    On the other hand, there’s a bunch of stuff that isn’t anywhere BUT the phone: sensors, media access, notifications, location, etc.  

    So it goes both ways!

    We’ve got a MEF build that works on the phone, I think we’re figuring out how to deliver it.

  17. I don’t think it is fair that you know the VS tooling better than the iPhone SDK and do comparisons. I could do the same and say that working in WP7 is much harder… I just don’t know the tooling. You could have had IB generate a lot of the code you wrote yourself.  If you are going to do "real" comparisons, I say you stop posting about the iPhone until you actually learn the tools and can do "honest" comparisons. Focus on what you know which is the WP7 tools, please don’t knock the others. You sound like you are working for the government.

  18. @Scott – I understand your point, thanks.  But in case it’s not clear (in which case I’ll clarify it), the iPhone version comes straight out of the iPhone SDK, including using IB for the UI.  If I had written it, then you’d be right.  I’m making the assumption that the samples in the iPhone SDK represent best practices in terms of using the tools.

  19. Adam Wright says:

    Interesting article Shawn, but a bit mistaken in places. I decided to writeup a response post myself, showing me write the iPhone version using an identical amount of code, at http://www.archgrove.co.uk/weblog/2010/03/25/104. I’ve also looked a bit at why you might have come to these conclusions.

    I look forward to reading more!

  20. Don Burnett says:

    What kind of program can you come up with on the iPhone dev system in 90 seconds?

    When you can do this on the iPhone with Interface Builder (I do iphone work as well as WP7 and Android..

    When you can do all of this as rapidly on the iphone as you can Windows Phone 7 then I'll say Apple and Google (with AppInventor) has something… As far as monotouch goes.. It can't do this this quickly either…


    Do a fair tools comparison for those commenting (don't be a fanboy),  and Shawn get out of visual studilo for these comparisons 😉

Comments are closed.

Skip to main content