Development dilemmas and Windows Phone 7

bridgwatera | 12 Comments
| More

In a fortnight that has seen Microsoft mobile lead Andy Lees encourage staff to write their own Windows Phone 7 (WP7) apps to help support the launch, the company is (allegedly) cooking up an employee developer program to fast-track apps made privately within Microsoft.

But is there an issue here? Will developing for WP7 be a struggle and will the weight of momentum carrying iPhone app development experience any turbulence? What would be really nice here is if all the children would agree to get along and play nicely together so that sharing (let's call it porting shall we?) would be a breeze.

Phone.png

Then we'd all get more apps, more quality, more choice, more value and more interoperability. Sadly, this does not look likely.

Mobile development specialist Terence Eden works with developers on both platforms and has this to say on the subject.

"Porting apps to WP7 from iPhone is close to impossible in the traditional sense of porting. This is simply because iPhone development requires a Mac running OS X and WP7 development requires a PC running Windows Vista or Windows 7. So, essentially, I have to buy another machine and/or another operating system if I want to do both."

"While there are some coding similarities - the platforms are different enough to render porting ineffective. It really does require ground up rewrites. Of course, the same assets can be used - graphics, network APIs, sounds, etc - but the user interface guidelines are strict enough to warrant redoing many screens from scratch."

"That said, the development tools for WP7 are fantastic. The demos, tutorials and support from Microsoft are second to none. But you won't see many 'ports' of complex iPhone apps unless they're created by companies with significant resources."

So what lies on the road ahead (to coin a Bill Gates book title) for WP7 development? Well Microsoft's internal app development programme certainly has limits, the staff members are not allowed to profit from any of the development they do, as they would be in violation of their original employment contracts. So don't expect the next Twitter any time soon.

In terms of where the Windows Phone 7 sits as a device, I will defer again to Terence Eden's erudite opinion which he has expressed in his blog which you can read for yourself here on an ongoing basis.

"WP7 is the first device that I've seen which has been designed from the ground up for both work and play. It has an (unfair?) advantage working with Microsoft's range of enterprise software - OneNote, SharePoint, Outlook - as well as having the necessary range of security policies for a corporate environment. On the play side, it has total integration with Xbox and a wicked set of 3D graphics," said Eden.

As to whether the WP7 and iPhone marriage will ever flourish, I will this time defer to Rudyard Kipling, in his Barrack-room ballads, 1892:

"Oh, East is East, and West is West, and never the twain shall meet."

12 Comments

The biggest reason not to develop apps for Windows Phone 7 is that the platform has a high chance of failing in the market.

Microsoft runs around saying it has a 10-year commitment, but that means nothing, as it will be out of Microsoft's control if the OEMs abandon the platform.

It's a very immature version 1 product, which shows. A large proportion of the APIs are not finished, which prevents apps from accessing certain hardware features (video camera / compass) and network features (sockets).

Terence Eden (above) says Windows Phone 7 has "the necessary range of security policies for a corporate environment." No it doesn't.

It doesn't even have the basics. For example, Microsoft's Windows Rights Management Services (Information Rights Management) won't be working when Windows Phone 7 is released. That means you can't control who can or cannot read Office documents.

My impression is that Windows Phone 7 is going to become yet another of Microsoft's mobile failures. It doesn't have any must-have features, yet it is loaded with shortcomings, meaning it'll be just as half-baked as Kin was.

Their is a sinple test you can do, would i make sence for Microsoft to utilise their massive in house development teams to build up a collection of app, even if sucess was assured; the answer is yes. Seen from this perspetive you should read too much into this other than MS is taking WindowsPhone seriouly and it's only going to increase it's possibliably to sucess. As for comments about lack of commitment, how long have their been in the phone business. Answer longer that Apple and Google combined.

Thanks very much for your excellent comment - the fact that you have granular knowledge of the rudimentary APIs (if they are as you suggest) is enlightening news.

It's true that we don't associate Microsoft with mobile success per se - so I appreciate your balancing words in response to Terence's comments. I assume that he has found solutions that fit his means and is happy - but your experiences to the contrary are equally valuable to read.

Thanks again - AdrianB

Thanks for your comment - Microsoft's longevity in the phone business doesn't quite seem to marry up with the company's success in this area.

We DO hope that Microsoft is taking the Windows Phone 7 seriously - and we hope that there is widespread uptake by developers and corporate players. partners etc.

It's better for product innovation and competition that way right?

AdrianB

Please stop with the misinformation.

Microsoft IS letting its employees profit from development of apps, and profit they will. Spreading false rumors sucks.

Can you back that comment up with hard facts and a link? If so, we'll edit appropriately.

On the face of it, it does appear that Microsoft will not be paying employees extra wages as a result of apps posted internally that are construction during work time.

Adrian

There are two issues here:
1. Is Windows Phone 7 going to be popular enough to be worth considering developing apps for?
and
2. If you decide it is worth it, is the complexity of porting/sharing code going to be so complex it may make you reconsider?
Obviously no one knows the answer to question 1 for sure yet, but as you've probably guessed by the fact I put the second question in I think they will be popular enough to invest my time learning about and developing applications for.

But why?
- They are amazing devices. Please don't write them off till you've used one.
- Microsoft knows this industry. Windows Mobile was really good back in the day and while they've drifted off course in the last few years all the evidence seems to be that they've been carefully watching the market change around them and learning from it. And they've also been learning from their own experiences. (Arguably, while Android re-make a lot of the mistakes which were made with Windows Mobile.)
- Windows Phone is designed specifically for mobile use in a way that we've not seen on other devices before. Plus it's not trying to be something it isn't or shouldn't be - a PC on phone hardware.
- Microsoft has spent the last 5 months trying to convince developers to build apps for the phones. And developers have been responding. There will be a lot of high quality apps available in the marketplace when the devices launch.
- There are also a lot of desktop and web developers who are currently using Microsoft technologies who are keen to build for mobile as it
- The (fully transparent) marketplace policies Microsoft are putting in place will ensure the quality of applications and avoid data security issues which are notorious on some other platforms.
- Despite all the criticisms of a lack of hardware variations there are a lot of manufacturers signed up to produce devices. The fact they think they can make money selling devices which many think will be hard to differentiate from those of a different manufacturer should be seen as a string endorsement.
- The email and calendar integration puts almost all other devices to shame. I've heard lots of people who have used actual devices say that they'd get one for that reason alone.
- Xbox Live integration is a strong selling point for a lot of mobile gamers.
- Microsoft is not afraid to try new things. And learn from them and move on if not successful. (Cough-Kin-cough)
- Microsoft can't afford not to be successful. Mobile is the future and Microsoft needs to be there if they are to survive long term.
- Plus I've heard from trusted sources what the ballpark marketing budget is. (My lips are sealed though.)
- I've also noticed that a lot of the people who are panning the phone are the same people who said the iPad was pointless and no-one would ever buy one. ;)


Ok, so what about the experience of developing or porting an app?

Yes, the bad news is that your Objective-C code used to make your iPhone app can't be compiled to make a Windows Phone 7 app.

Here's the good news though: If you've already built an iPhone app you've done the hard part. By almost every account I've heard and read, Windows Phone 7 development is much easier than iPhone development. (Yes, I've done both and agree too.)

Not convinced, here's a simple comparison of the differing development experiences http://www.slideshare.net/DonBurnett/i-phone-versus-windows-phone-7-coding-4766023

Plus if you're building a copy of something that already exists you've probably done a lot of the complex logic for the app already. Plus the non-development functions such as to determine if there's a market, setting up support channels, etc. should already be in place.
In development terms you'll also be able to reuse existing backend services and design assets, images, etc. This essentially allows for reuse of the code which isn’t on the device.


But don't you still end up with two code bases?
Well, yes. But that's the price you pay for targeting 2 different platforms with very restrictive development options.

This is the same situation for every scenario where you want to write code to run on different operating systems.

This is not an issue that's unique to Windows Phone 7.

You have the same issue if you want to build apps that run on more than one of iOS, Android, Blackberry, Symbian, webOS, Windows Mobile, Maemo, Bada, etc.

Plus it's not just a mobile issue. If you want to create an app which runs on Windows (desktop) and on a Mac (or *NIX) you'll likely have the same issues.

For some platforms, writing in C or C++ may be an option but you'll pay the penalty(?) of writing in a lower level language. Plus you'll probably end up with code containing lots of #IFDEF statements. My experience with some such codebases has left me happier using different files for each platform. And if you're doing that the code may as well be in different languages.

There are some alternatives, such as PhoneGap ( http://www.phonegap.com/ ), which build in JavaScript and can then be compiled to create native apps for multiple platforms (with Windows Phone 7 support coming soon) but use of such a platform typically tends towards a lowest common denominator approach to application design and only supports functionality common to all devices. This of course means that you miss out on the features and possibilities which are unique to each phone. You do also still need a build environment to compile each app though so there really is no escape for have both Mac and Windows operating systems. They could of course be on the same hardware though.


I mentioned reusing assets from the apps developed from other platforms. Many see this as an impossibility because the design guidelines for different phones vary so greatly (especially the “Metro” design language of Windows Phone 7). If that’s you, you’ve misunderstood the meaning of guideline. It’s not the same as a rule or a law. Oh, I’m all for guidelines and making an app look like it belongs on the platform where it’s running but you should never follow guidelines blindly. Follow them until there’s a good reason not to. Wanting to create a design that will work on very different environments is a very good reason to not stick rigidly to guidelines.
Oh, you made the decision to make your application look like the operating system of the other platform you built your app for. I guess you won’t be making that mistake again.


There is still a good reason to not port your application to Windows Phone 7 though: Because you can’t!

Two main reasons for this would be if your app does something which is not permitted by the marketplace policies or the app requires functionality which is not available on the phone.

Windows Phone 7 is a “reboot” and for a very large part it is essentially being built from scratch. This means that at launch it won’t have as many features or APIs available to developers as some other platforms. If you need something which isn’t available the decision on whether to port, at least for now, is made for you.

Many see the lack of features as an obvious disadvantage. While this is true in part, I think there’s a hidden benefit here too though. With many developers coming to mobile development for the first time but using the same tools they used for developing for the desktop, the temptation will be to use the techniques and patterns they’ve traditionally used. Developers who try this will quickly reach problems and be forced to learn new ways of working which are appropriate to a mobile platform. They will, of course, also be able to take these new techniques and methodologies back to the desktop with them too.
Long term I think that being forced to work in the restricted environment will lead to better developers creating better apps. Ultimately everyone wins.


For full disclosure, I run the Windows Phone User Group ( http://wpug.net/ ) in the UK but am not employed by Microsoft and have received no special perks for this, save for a free T-shirt. (No, I haven't got a developer device yet.)

I'd have to say I'm on the same page as Matt here, comming from just a pure gaming background, I've been doing XNA for many years now doing games for PC and XBOX.
For MS to then also include this framework straight off the bat just goes to show how much commitment they have to the whole mobile platform.

I've tried writing games for most mobile platforms and have always shied away eventually, usualy due to either the steep learning curve or complicated platforms (including Windows mobile 6 and such in that). XNA is a dream to pick up and for me to require no additional special skill to direct port to a mobile device with Windows Phone 7, save the obvious restriction with mobile capabilities and considerations.

On top of that, I have dabbled with some Business Line aps as attepts to convert some of our outsourced iPhone dev. It was easy to pick up and blend makes the transistion easy just based on our original designs, literally just drag and drop with limited coding required. The POC app for example only took 8 hours to put together (mostly in blend) and that included the time needed to learn the basics of the toolset. Sample data came for free with Blend which made the initial demo to the project sponsors a breeze.

The future does hold some challenges mind, so it's not all a walk in the park, consumibg business line web services orriginally written for consumption by the iPhone app is chalenging at present, but that has to be expected since we are still in a Beta stage with the tols and api.

That being said, the Beta tools are rock solid and there is a wealth of community resources (not just MS, although their offerings are very comprehensive) arround and hekp is always on hand in the developer forums (something definately lacking in iPhone land)

Now I'm not completely dissing the iphone, it does have a leading market share and a smooth interface. However there were the same mumblings arround when Android first release and they have certainly found their niche (I'm actually commenting here straight from an Andriod for example). Microsofts offering os going to certainly be a serious contender in the marketplace and is certainly not trying to be an iPhone killer.

If you love to be connected and have a centrally agregated information store at your fingertips with full exchange and office integration, Then the WP7 wins hands down.

As for the apps, with the tools being so easy to use I can see a lot of firms considering penetrating this market as well as their existing base simply due to the lower development costs involved with getting apps to market. Games will be another matter since XNA is a managed framework, so some studios or devs will shy away initially just because of that, but I feel they will come arround in the end. Also Silverlight can be used for simplier "pick up and play" games as well.

All in all I see this as exviting time as a mobile/game dev and relish the day when I have a device in my hand to play with all this stuff on. For now I'm content with the free emulator and borrowing dev devices at the many WP7 conferences going on everywhere at the mo.

Simon & Matt, great comments! People just like to bash everything MS, seems to be the fashion these days. Anyway, I'm looking forward to WP7 and have been dabbling with XNA. I find it such a joy to use and the documentations are excellent. I can create a game and immediately target 3 systems - Windows PC, Windows Phone and Xbox. Where else can I do that?

Hi Adrian,

I found a few other article listed on this page here about Windows Phone 7 Development: http://www.devcommunity.info/category/windows+phone/

Thanks

I just got an android phone because the phone did the job I bought it for.... There are way better phones than an iphone that don't have basic problems such as antenna issues, call quality etc. In addition, I think people have had enough of that Apple.

That's the biggest problem to port between WP7 and iPhone??????

I thought the biggest problem was called C#, microsoft forces you to use a language of his own!

Leave a comment

About this Entry

This page contains a single entry by Adrian Bridgwater published on July 30, 2010 10:39 AM.

Nastrovia! IBM opens Polish cloud computing centre was the previous entry in this blog.

Developing the 'drive-by' desktop application is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.