There isn't anything in this article that explains why you can't support both. The only sentence about this is "We can’t leverage what iOS 7 has to offer and a lot of the UI is compromise.", which doesn't cite any difficulties they've run into. The only iOS 7 features they mention are UIDynamics and the receding keyboard—the rest are iOS 5/6 features.
I agree that the article could've gone into more depth about the difficulties they faced, but most developers will agree "a lot of the UI is compromise" is the key point. Supporting iOS 6 and 7 visuals at the same time just means your app looks out of place in both versions.
> Supporting iOS 6 and 7 visuals at the same time just means your app looks out of place in both versions.
Assuming you want it to look exactly the same on both. I have an app that offers a flat, stylised look on iOS 6 and a completely native iOS 7 look on iOS 7.
The problem is a lot of iOS 6 apps don't use mostly native UI. The article touches on this when talking about all their custom code because previous iOS components were not as easily customizable. My next update will be iOS 7 only, at which point I plan to drop a lot of custom code and switch back to mostly native UI.
Yes, UIKit only became easily customisable in iOS 5 and the OP's app was written for iOS 3.
But even then you can port it to native UIKit (which is a good idea either way), and then make iOS 7 frameworks optional, and add a few UIAppearance calls for iOS 6. The last two pieces are extra effort that might not worth it for < 30% of your users, but it's still completely possible.
There are some excellent 3rd-party frameworks and libraries for doing spring-based animations that work on previous versions of iOS. My favorite (that I still use and favor above UIDynamics even on iOS 7-only apps) is JNWSpringAnimation which uses CAKeyframeAnimations to do amazing springy, bouncy animations. The same code is wholly portable to Mac apps as well which is an awesome bonus.
