Reputation: 3089
I implemented a major feature in our app and updated to iOS 8 in the same branch. I replaced all the deprecated methods with the new iOS 8 ones. It turns out this was a bad idea, since a large portion of our users are still on iOS 7, and we want to ship this feature, so now I need to figure out where all those iOS 8 methods are and go back to the original. I did comment my commits well enough that I should be able to find most of these changes, but I'm worried there will be some I've missed.
Is there any way to get Xcode to say "Hey, you're building for iOS 7, but that's an iOS 8 method you're calling"? Of course it doesn't do this by default, because that would make supporting multiple OS versions annoying. If Xcode can't do this, is there a tool that does?
Upvotes: 0
Views: 251
Reputation: 7944
There is a tool called Faux Pas which allows to do that (and has many more useful analysis options). Also AppCode IDE can do what you asked. Other than that, you can run your unit tests (if you have the problematic code covered) on iOS 7 simulator / device and methods unavailable on iOS7 will crash.
Upvotes: 1
Reputation: 535860
Backwards compatibility is hard. You're not the first person to notice this. I have long theorized (in public) that the reason it's so hard is that Apple doesn't want you to do it: they want you to support the latest and greatest and that's all, thus helping to force everyone to upgrade, which is ultimately how they make money (because you might also be forced to buy new hardware, don't you see).
Apart from testing your running app like crazy, and maybe writing really great unit tests at every inch of the way, the only thing I can think of is to whip out an old copy of an earlier version of Xcode, open your project, and try to compile it with the Base SDK set to an earlier version of the system. That way, your iOS 8-only calls are errors and will come to light quickly.
Upvotes: 1