Making an iPhone app. can be quite a challenge. Initially learning the iOS SDK will take time; it can be quite mysterious at first. It does get quicker and quicker as time goes on. I have used many parts of the SDK now and there are few areas that I have I not worked with.
What I have experienced with many recent projects is that technical details are implied by the design. A client does not necessarily perceive what is difficult. It is important to be realistic about how long certain features will take to implement. As well, there are things to consider like memory use and the way content feeds are handled. On a very recent project, there was an XML feed and also images in the data. A simple caching system was implemented to handle the image downloads. More time should have been available to tune this feature. The visual design which the client signs off on does not account for such "under the hood" activities. And these are very difficult item for a client to acknowledge. They cannot see the code. One needs to communicate the essence of the task. There is the potential blinding of the client with science. I personally try to avoid that. I have seen many developers go into technical detail at a meeting and no one really knew what the developer was saying aside from other developers.
It can come down to good planning and communication. Making an iPhone app is not the same as building a web-site. I think it perceived by many non-developers to be an equivalent activity. When you make an iPhone and there will be defects, issues, bugs and the odd howler. Software development is still a craft and not an engineering practice. Having said that, there should always be time allocated for developer and internal testing of an app. before the client gets the latest build.
One of the things I have done recently is make a master project plan document. I plan to use this a starting point for every iPhone, iPad and mobile app. project from now on. I have added specific tasks for risk analysis and technical proof of concept in the plan. For example, I was working on a project and one of the features was to do live effects using the camera. It turns out what was desired was technically possible but you had to rely on some esoteric knowledge of the iPhone OS to achieve the effect. The project did get there in the end and incidentally with iOS 4 there is no need to do some creative hacking to achieve the result.
And there is one postulate that has been proven true time and time again. "There will always be changes to the app just when you think it is finished". What to do - allow time for it at the end of the schedule.
I could go on and on about this; I shall stop there for the moment.