What are the implications of re-writing or porting a game to the iPhone?

The changes to control your game using the iPhone's touch and tilt controls are certainly going to be a fair amount of work, and there are certain features which simply aren't supported on iPhone, such as the terrain engine, pixel shaders, render-to-texture. Dynamic typing of variables is also not supported, so you will have to convert your code to use statically-typed variables. Depending on how you wrote your code initially, this may be significant work.

But in addition - and I would say most significantly - you should never underestimate the amount of optimisation that you'll need to get your game running at a decent speed on an iPhone.

Even if you think your game has a fairly low poly count and draw call count, or is fairly well optimized, until you have actually tried developing for iPhone you could still be in for a shock.

Many iPhone developers find that they have to go to great lengths to optimize their game if it was previously written for webplayer or Mac/PC standalone. If you haven't done this before, you may end up having to learn a lot more about code and scene optimisation before you start getting a decent frame rate. Here's a random handful of common techniques off the top of my head, which iPhone developers tend to use to squeeze out the last drop of performance. These are in no particular order, and each one could be expanded on in much more detail.

• Reduce poly count and draw calls right down. I've heard reports of 70 draw calls running at a good speed, but really you probably want to aim for less than half that if you'll also have any significant physics and scripting in your game.
• Use pools of reusable objects, rather than instantiating objects during play
• Avoid physics that involve many objects clumping together
• Increase the physics timestep as high as is tolerable
• Remove most (or all) lights from your scene. Use baked lighting instead.
• Pack as much as you can together into texture atlases, to maximise material sharing.
• Use built-in arrays rather than dynamic arrays
• Cache references to everything that you possibly can (eg, components), to avoid lookups during play
• Manipulate many small objects from a central controller, rather than many small Update()'s
• Use sprites combined into a single mesh (a la SpriteManager)
• Use a single combined mesh with bones to animate the positions of separated submeshes as if they are separate objects.

For more information, do some broad searches around the subject of iphone optimsation. For example:

Custom Google Search for iPhone optimisation

Unity Answers search for questions tagged iPhone optimisation

edit (addendum):

Having re-read this, I feel I should stress that I'm not saying it's always a huge effort to rewrite a game for unity iPhone. Many of the above-mentioned optimizations are things that seasoned developers would make use of in a non-iphone game too and should already be familiar with. So if you understand and have experience of these things already, then in all likelihood it will be just as much fun porting to iPhone as it is in regular Unity!

My answer is mainly aimed at those developers who are new to Unity and new to coding in general, who might not be aware of this kind of stuff - because when coding for desktop builds you have far more leeway in which less-than-optimal code and graphics will still run at a very fast speed, and it's these areas which will trip you up if you try to do the same on iPhone.

And I'd like to add that the simple fact that you can publish from the same Unity project to both Mac, PC and iPhone at all is undeniably awesome.

Good Luck!

If the app doesn't require much performance optimizations then major focus would be the new input. The rest shouldn't really give you much trouble.