You could have just said that, and people would have nodded and said "good on you". The rest of this post actually sapped your credibility.
Thinking that alone is a mistake -- there is nothing magical about iPhone developers, and ios programming can be learned quickly. If you're doing a startup, you can't believe anything other people are doing is impossible to master.
(that may very well be the case, but it always warrants investigation)
If you make bad performance choices on an iOS application, you'll create a stuttery, ugly mess (smooth scrolling in an iOS application is surprisingly nontrivial) that will--unforgivably--sap a user's battery and ruin their experience.
People are a lot more forgiving of 2ms greater response time on a web page than a web app that drains 4% of battery in five minutes.
Well, you either found the problem and fixed it or you fixed something and now hoping it was what was crashing your app. Or you have multiple crash points in the app. If it still crashes - fine, you have more work ahead of you. Just don't try and twist words to make things look better than they are.
My honest feedback would be that your main point is lost in the story. Even though I read the whole article, the thing I was left thinking when I finished was that the root cause of your problem was 1) the failure of your contract developer to deliver and 2) you rushed an early version of the app out in 6 weeks without sufficient testing.
For what it's worth, leading with a clear apology to those affected by the problem would do no harm.
It would also help if you explained more clearly what _exactly_ you wanted to learn from the release that justified the impact of this bug on users. Eg, some key hypothesis or assumption in your business model or product roadmap etc.
Good luck with the next iteration :)
It's all fine and good getting a very basic v.1 out to get feedback - but it shouldn't crash due to an easy to detect bug.
