In my opinion, the best thing to do is to finish the development completetly, test your final product for bugs and when the teating period is over you can go ahead and publish it.
Best regards,
For more details I'm always available.

For starters, I don't think there is such a thing as perfect code. You're always going to discover (and hopefully squash) bugs along the way. Apple might roll out an update for iOS and complicate things. Perfection will always be just out of your reach. That being said, I keep a dedicated QA tester on call to ferret out all known bugs and quirks. We test and iterate until the app is as perfect as it can be. Only after my tester has performed regression testing and verified that all known bugs have been fixed do we submit the app for review. Then, once it's in the hands of real people using real devices, I can learn how good a job we've done. They tell me what they want or what doesn't make sense. You'll always want to release regular updates—if only because it's good for your marketing—and you'll want to save development dollars for future development phases during which you add significantly to the codebase. So for your first project, I wouldn't let your developers' eagerness influence the timeline. Only submit for review after you're confident that the current version of the app works flawlessly, but keep in mind that you'll have plenty of time to make more changes. And hopefully, your new revenues will pay for those changes!

Cheers,
Austin

I am assuming you are referring to a bug free app and when you say 99.9% you're referring to the % of functionality implemented as opposed to the quality level. Then I would say go live. I think Reid Hoffman's quote (founder of linked in) sums it up best. "If you're not embarrassed by the first version of your product, you launched too late."

Get something out in the market that gives you some idea if there is even a demand for the product you are producing. Not all good ideas are successful and the feedback you receive could even send you down another road, possibly saving you time and money building a product that no one wants.

Get that minimal viable product (MVP) out there, collect lots of data (analytics and feedback), learn and hustle.

If you want to read up on Lean start up philosophy and techniques buy Eric Reis book "Lean start up".

If you need any further assistance feel free to give me a call

Steve

It really depends on the type/functionality of the application.

If the app is quite small and you miss out on providing the core feature set to the user, then that will not be a good user experience. In this case you should get 99% (you can never be 100%, there's always more you can do) before you launch the app. On the other hand, if the functionality you plan to leave out does not hinder the core user experience, but possibly provides a value-add on top, that is something you can add later with an update.

Also, if it is a game which has several levels/stages, you can add more levels and stages later and provide the user enough to play with version 1 to keep them busy till the next version launches.

Remember, generally the last 10% of fixes in an app take over 50% of the time, so you want to make sure you are not bogged down with minor tweaks and fixes if they do not hinder the user's experience in using your app.

From a review standpoint, Apple will accept your app provided that the functionality you have implemented already is functional and free of obvious bugs. Assuming you've achieved that, then this becomes a business question. You've made some assumptions in creating your app about what users want. Is it better to get the app out to real users and find out if those assumptions are correct? Or would you rather make sure your assumptions are really polished even if they might be wrong? To me, the question is rhetorical.

If the core of your app is the way you want it and you'r enot planning on a huge (aka expensive) PR/media campaign on launch, just submit it.
First release is nowhere near a finished product. You will discover plenty of user requests, feedback and bugs. You should never develop a product in a "closed room".

However, there is also a discrepancy in your numbers… Is it missing 0.01% or 10%?? :)
Glad to talk details (meaning specific features) to better help you.

PS beware of a team that might be trying to close the project due to "hidden" issues.

Figure out what your minimum working platform should look like and develop that at 100%. All the extras and bells and whistles can come in updates. But if the platform does not work (aka WW2 Online, where you couldn't fire the guns...oops) do NOT put it out. You won't have anyone left waiting for the updates.