views:

158

answers:

5

If you were going to attempt this, what would be the main factors to consider, easy/hard parts, pitfalls?

+1  A: 

It is just a new language, a new API, and another platform vendor. What could possibly go wrong?

If you give some more details about what kind of application (and its key characteristics) you would like to port we could give you a little more specific answer.

Albin Sunnanbo
Thanks Albin. Assume a variety of applications. How difficult would it be for an organization to be in the business of migrating applications that exist as iPhone apps? Maybe it's too broad of a question. Just looking for key things to consider, major pitfalls, or blogs/articles that might address this. Thanks.
Jeff Rubingh
+1  A: 

First, see MonoTouch. It might well save a bit of heartache because you might be able to keep your app's core code in a single language if you are extraordinarily disciplined about making sure no platform api calls leak into your app's core.

But yeah, what Albin said.

Wyatt Barnett
The situation with MonoTouch still seems a bit uncertain. The clause Apple added to the developer agreement that blocked Adobe's attempt to let you write iphone applications using Flash also technically prevents the use of MonoTouch. Planning a new application around it could be a very expensive mistake if Apple do decide to ban apps built using MonoTouch - though of course it could also be the best route. But there does seem to be a risk there.
JosephH
The UI libraries are going to be totally different. The on;y thing you MIGHT be able to reuse is stuff like data objects, and possibly some control logic (though even that tends to be riddled with things like collection use that also is not portable).MonoTouch is more about using the language to develop for the phone, not so much about portability...
Kendall Helmstetter Gelner
Oh, I wholeheartedly agree with you both about how foolhardy this venture is . . .
Wyatt Barnett
MonoTouch also would be of a questionable level of help if you already had an iPhone app (that wasn't already using it) as you'd have to rewrite the app first and then port it.
Matt Lacey
+2  A: 

The real problem you face is this - the design paradigms are totally different. One Windows Phone 7 you are supposed to have these long strips of data, which a user can only see partially into - on the iPhone it's more like navigating a hierarchy of data. If you really try to build the app once you are going to have an app that looks out of place on one or more platforms.

Kendall Helmstetter Gelner
A: 

Hi Jeff,

I think this is a great question, with a very straight forward answer.

For me, I consider UI's to be so light weight they are virtually throw away, in particular on a mobile device where extensive feature sets are generally less than practical and simple solutions gain consumer traction.

Granted there may be considerations of mismatch in features on both sides which will likely become less of an issue over time. Often there are different ways to approach things if you encounter a mismatch and it's important to you that your app gets the wider consumer coverage that multiple platforms affords.

So in my summation, the considerations boils down to this. Just do it, if the platform seems worth your effort to invest in. This will depend on you and your goals, your app and it's purpose, and the momentum the respective platforms generate. An individual choice for the most part.

Keep in mind all your investment can be kept in your choice of server technologies which for the most part is client platform independent. Assuming your app even needs a server.


This question is also going to be addressed in detail by Jesse Liberty in his blog series iPhone to Windows Phone 7.

Mick N
+3  A: 

Jeff.

The issues you face include a shift in the underlying pattern from MVC to MVVM, but this is not as radical as it might seem. You will be working with a new language and with new language features, in a new development environment.

There are some traps along the way, especially the differing meanings of essential terms such as Interface, Delegate and so forth.

To address this, I've started a series of tutorials called "An iPhone Developer's Guide to Windows Phone 7 Programming" which you can find on my blog

The good news is that the developer tools are free and there is a lot of documentation, both official and from the community, with a lot more coming every day. The release version of the developer code comes out on September 16 (though you can start right now with the beta code). My first tutorial tells you all about how to get everything you need.

Best of luck and let me know if I can be of help.

-jesse

Thanks.

Jesse Liberty