Now, I could be totally wrong here, however, but there is a very good chance this thing will kick arse.
Why, you ask?
Very simple. The application development model, having had a brief play with the CTP version, make XCode and Cocoa look like it just walked in from 1995. The iPhone has 120K apps or so (depending on what they have removed this week), with a development model that most of the developers using it had to learn, from scratch, and for those used to a modern language, is backward, antiquated and alien. Thats one hell of a learning curve for most developers. And by modern I mean Ruby, Python, Java, C# et al – basiclaly something invented in and for a date starting with 20.
Obj-C only makes sense if you know Obj-C, C or C++. If you only know one of the above languages, it’s has the potential to confuse the shit out of you – and leak memory all over your nice new carpet.
Contrast that with WP7. It uses .NET and Silverlight/WPF. There are a lot of people who have to adapt to a small change in the API – those who know Silverlight already – and a massive, orc-ish horde who just need to learn a bit of Silverlight over the top of their up-to-8-years of .NET. VS.NET still owns XCode for ease of use and productivity, especially VS.NET 2010. C# and the .NET managed environment kicks Obj-C and Cocoa all over the park* for getting things done. I came to this realisation when I used CocoaTouch and found that I could, using the .NET (mono) libraries, in about 4 lines of code, what took around 50 in Cocoa. (connect to URL, parse a model out of the resulting XML).
Aside from initial market share (WP7: zero. iPhone: lots) and rabid fanboi’s (‘cos, ya know, it’s not cool to like Microsoft anymore), I don’t see where the iPhone has a development advantage over WP7. And these days, it is all about the apps. WP7 will ship with the same basic features as the iphone, in a very similar package. It’s the apps that make a difference.
Throw in what happens when you can use a single technology (Silverlight, .NET, c#) to write you mobile app (WP7), back end (Azure or self-hosted), desktop and web (Silverlight or WPF). Right now, with the iPhone, I have to use Obj-C/Cocoa for Mac and iPhone, something else for Windows, and something else for backend/web (Rails? Flash? whatever else). With WP7, I can stay within the same universe, or I can move out of it as I like. If I’m a single person or small team, I know which way I’d be going.
We’ll see, I guess. I think Microsoft has one bit covered – the development story – now lets see if they can solve the other story: make consumers want it. Thats the hard bit.
Note to Microsoft: subsidise phones via MSDN. Get the devices into developers hands cheaply, and not tied to the useless US carriers. Not just at PDC or TechEd, but for anyone with an MSDN subscription, ActionPack, MS Partner status etc.
Side note: I wonder if there is a “market” for a Silverlight-style markup for CocoaTouch. Same idea – build the object tree as XML, parse it down to code/objects at compile or runtime. But using UILabel et all. Could be the best of both worlds. Same business logic, replace the views and some of the controllers, and have an app which works over both platforms. Actually, maybe thats what a XIB is….
*unless you have been using Obj-C for a long, long time. This is obviously not going to apply to the likes of Mr Gemmell and co, or anyone else with a few years of experience invested in iPhone apps.
I think there’s a fifty-fifty chance of it succeeding or failing… Microsoft’s biggest benefit is it’s advantages in the enterprise. Windows Mobile has always had many features which appeal to the corporate environments such as centralised policies, good Exchange integration, multi-tasking, and heaps of mobile applications created for business applications. But Microsoft’s change in tactics may alienate itself from the Enterprise.
For starters, none of applications for previous Windows Mobile devices will work with the new Phone 7 devices, so enterprises that rely on current mobile applications will be forced to either remain on Windows Mobile Classic devices (6.5) or re-develop all their apps for the new platform. So perhaps the new development tools will be great for developers in general, but there’s a huge cost to enterprises that have to re-develop their in-house apps.
Also, the new Phone 7 devices lack features which have always been available in previous Windows Mobile devices – the two big ones are multi-tasking and copy/cut/paste. Now I’m sure that Microsoft will eventually incorporate those two features into Phone 7 devices, but it seems unbelievable that they haven’t done all they could to enable these features from day one.
As for the consumer market – you mentioned it above, Windows Mobile is just not ‘cool’ and I’m not sure if Windows Phone 7 Series (what a mouthful!) devices will be any better. To compete against the iPhone you need to have a differentiator – Palm Pre doesn’t seem to offer anything better than the iPhone and sales have slumped recently. Android’s differentiator is the open platform, which appeals to geeks and others that value their ‘freedom’. But from what I’ve seen so far, Windows Phone 7 seems to be just trying to catch up to where the iPhone was two years ago. Just offering a different UI is not going to win people over to Phone 7. This Dilbert cartoon seems relevant to this: http://dilbert.com/strips/comic/2009-12-09/
So if Phone 7 is moving away from it’s enterprise advantages, and the devices don’t appeal to consumers, then I’m not sure that just having a good development environment will help them.
I’m not so sure about multitasking on a phone – I’ve gone without it for so long on the iPhone that I dont know if I care – and I like a working battery life. MT works nice for large devices, but not so much for small ones
that said, being able to write something which runs in the background – a worker process – thats a totally different matter, and which is what I suspect apple will do. MS already have a precedent with the Azure worker processes…..
cut and paste is useful and trivial to add. Expect it in SP1 :)
As for WinMo apps – sorry, I dont see this being a big problem. I’ve not come across a company which uses many, if any, of these, esp inhouse ones. If they are inhouse, chances are they are in NetCF, and they then have .NET people who would be, I imagine, VERY happy to upskill and port them over.
Man you are a great writer, “…and leak memory all over your nice new carpet” It took me 10 minutes to rad the entire post because I had to pick myself up off the floor I was laughing so hard.
Oh yeah and I agree with everything you said.
Honestly, the problem is that it is TOO EASY to make a Windows Phone app. ScottGu just posted his Twitter Windows Phone app and it took me less than 1 minute to read and Fully understand all the code.
On day one there will be 50k apps. Most will suck but about 500 will be really good. by next year there will be 500k with 10k really great stuff.
Thanks Michael :) I rather enjoyed writing that paragraph.
Yeah, I saw The Gu’s post – it is easy, but using MonoTouch (which I’m playing with at the moment) it’s nearly as easy to do iphone apps, so we’ll see. I’m not sure who all the 150K apps in the iphone store are for – not me, thats for sure. I use maybe 5 on a regular basis, and a few more maybe once a month….. But without those 5, I’d leave the platform.
Those apps would be:
Byline (Google reader client)
Tweetie 2
Remember the Milk (todo app)
Tube Delux
Currency (currency converter)
Almost everything else I use on a regular basis are the built in ones, which make it quite easy to move platforms.
err…
ruby-1995
python-1991
java-1995
But the rest of your points are valid, I’ve tried playing with xcode, and my motivation ran dry before I achieved anything.
yeah, I know. Objective-C was 1986, so I guess I should say “a modern language”