Windows Phone vs iOS Development (with C#): Round One

DISCLAIMER: This is not about iPhone vs WP7 devices; its about development tools. If you think you can enter into a device fight here, or you like to listen to Justin Bieber, you should leave the page now.

I like programming, and that's it. Well...no. I LOVE programming. No matter the platform, OS, framework or  language; I find that programming is a rewarding experience. Of course as with anything in life, you want that experience to be as smooth as possible. And that's why I am so picky with development tools... They are supposed to make my work easier. And this entry is about that, comparing the development tools used to create apps for iOS (iPhone) and Windows Phone.

Recently I had the opportunity to develop the same mobile app for two platforms: Windows Phone and iOS. While I have developed for these platforms before, I rarely have coded the same app (and a complex one) for the two of them. And this is a good chance to perform a comparison, because it gives me a fair point of view, rather than comparing experience by running some code fragments, or reading some biased blogs (I will try not to be...).

The environments


I am a .NET Developer, and I prefer C# over objective-c anytime (we can have a fight about that later). So I decided to use MonoTouch for the iPhone, this also helped me reuse a lot of source code between the two apps. Essentially anything except GUI related code could be reused.



Used configurations


Round One....


1. Integration of tools


Here it gets a bit cumbersome on the iPhone side for a C# developer, not only I need MonoTouch - so I can build with C# to iOS - but I also have to play with a combination of two IDEs: MonoDevelop and Xcode. Fortunately, they work pretty good. Xcode is used for designing and connecting outlets, etc. Some minor drawbacks with resources in the solution, like adding an image from the designer, but nothing that would make your work impossible.

However, the full environment for development in Visual Studio is much more seamless.

Verdict: WP++

2. Performance/Responsiveness 


Both environments perform in a similar way, no long waits or bottlenecks or freezes, even the small MacBook Air, performed great if you consider it was almost half of anything the PC was. I did experience some minor issues (crashes) with Xcode, but after an update, everything was OK.

Verdict: iPhone++

3. Development Costs


Developing for both platforms require a license that cost 99/year. Using MonoTouch is free if you will only use the emulator, but in order to connect to a real device (which is a *must*) you require a paid license. Both MonoDevelop and Xcode are free. But again, you require a Mac computer. And in the case of Visual Studio the WP SDK is free, but of course, you need Visual Studio (and Windows).

Both costs should be considered similar, even considering Apple's hardware is usually more expensive than the regular PC equivalent. 

Verdict: tied

4. Connecting to the device


This is an aspect where iPhone wins, I never had a problem just plugging in the an iPhone to the laptop, and run the Solution in MonoDevelop to deploy it to the device. It is simple. (Although it did required some initial work with certificates, etc. But that's a one-time only thing)

In the WP side every time I plug the device  I have to run Zune or use wpconnect.exe (I wrote about it already here). It became upsetting after you have to run several tests walking around with the device. Also you can't debug when connected through Zune if you are using the camera...

Verdict: iPhone++

5. The IDEs


Here is another tricky comparison, since I am using Xcode as an aid to edit XIB files, and MonoDevelop to edit the C# files, however, we must admit, neither Xcode nor MonoDevelop are mature enough in comparison to Visual Studio. Designing with Xcode is clumsy at best when compared to Visual Studio (and I am not even including Expression Blend here to make it fairer).

Verdict: WP++

6. The emulator


And here is worst part on the iPhone development. The emulator for the iOS is terrible, still better than the ones for Android - have to admit that - but is an awful emulator. Just to mention some problems:
  1. File system case sensitiveness differs from the real device
  2. No Camera 
  3. GPS emulation tricky to use
  4. No Accelerometer 
The Windows Phone emulator is a clear winner here, as it provides all of the above and also performs way better.

Accelerometer with WP Emulator


GPS on WP Emulator

The ability to emulate the accelerometer and GPS sensors on the WP greatly helps development by reducing the amount of time dedicated to test on the device. We can actually do a lot of more work with the emulator itself  before going into the field to test with real live data.

Verdict: WP++

Summing up.


So far, after this first round, the development tools' fight is like this:

iPhone: 2    Windows Phone: 3

Will come again soon, with more on Round Two... debugging, designing, execution performance, benchmarks, networking, error recovery and more.





Comments

MSc. Leonardo Paneque said…
Hi Erick,
I will post a new comparison soon, however, some aspects still are the same, Xcode has improved (a lot), but design mode is still not the best thing.

Silverlight/xaml and bindings are way more powerful than what we have on Xcode right now.

3/25/14, 3:26 PM
Post a Comment

Popular posts from this blog

Get-ChildItem vs Dir in PowerShell

Image
Batch as usual Recently I was in the need of modifying a huge amount of files across a network share. After installing Serviio media streaming service I noticed that it will crash "randomly". After checking the logs it was clear that ffmpeg was crashing when trying to open subtitle files that were not in the encoding indicated by the Serviio console. I needed a quick way to update all subtitle files to a common encoding, so I decided to convert all files to UTF8. Since I use a windows environment I went directly to PowerShell and wrote this.  Get-ChildItem -path .\ -filter *.srt -file  | ForEach-Object { (get-content $_.FullName) | Out-File $_.FullName -encoding utf8 } This worked almost right except for files with "[" or "]" (among other symbols) on the name or path. To solve it, just added the "-LiteralPath" switch to tell powershell not to consider any wildcards on the path name and just use it exactly as it is.  Get-ChildIt
Read more

The case for a 4 week sprint

Image
Every time we talk about SCRUM, the length of the sprint is stated as a period of "two to four weeks", rarely, however, have I seen people going outside of the 2 weeks. This is not written on stone of course, and while 3 weeks might seems odd, there is a benefit to using a longer period for your sprints.  Image is taken from scrum.org Without any hard data to back that decision, the answer I get from asking about this decision seems to be related to "delivery speed", we assume that because we deliver value to the business every 2 weeks, we are in a more "agile" environment. Well, that might not be so true in every sense or for every project. Let's break some arguments: 1. Sprint length is not equal to the speed of delivery There is more to the speed of development and delivery than the timeframe of the delivery cycle, in a world with DevOps and full CI/CD implemented for your project, you could (should?) actually deliver features every single day all t
Read more

NODE.js fs.readFile and the BOM marker

Working on a ReactJS project, got a small glitch while trying to read a JSON file and parse it as a javascript object. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString); } output:   SyntaxError: Unexpected token   After checking, double and triple checking again that the file was correct I went deeper and realized that "fs.readFileSync" was returning me the BOM for the UTF file at the beginning of the string. So we just need to strip it out. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString.replace(/^\uFEFF/, "")); } I then checked and there are "packages" for this, however I don't think is proper to just import a new dependency just to fix something this small. The big issue here is why is this considered correct. The BOM is not
Read more