I own an Objective-C iOS framework. The build system through which my clients consume my framework rebuilds our framework's code against the version of the iOS SDK that our client is using. Therefore, some of our clients consume binaries that we have not tested on. Can I presume the binary of my code built from iOS SDK 10.0 would behave in a way that is 100% congruent with the binary of my code built from iOS SDK 12.0? My follow up question to this is, past just ensuring that my code can build against the various iOS SDKs my clients use, should I run functional tests on the different binaries these builds output?
How stable is the behavior of my code's binary when compiled against different iOS SDKS
>Can I presume
I would not make that leap. All it takes is one deprecation and you're in the red.
I would use the latest Xcode, then the Product/Analyze menu.
Then give them a pass using Instruments.
The Simulator can help test your UI.
Depending on what those uncover, you can choose to ft. See https://rubygarage.org/blog/testing-ios-app bit dated, but right up an Obj-C alley 😉
There's no simple answer to this.
One thing to keep in mind is that some API behaviors are dependent on the SDK version you linked against (link against an old SDK to get the old behavior, link again a new one to get the new behavior), and these differences might not be easily ignorable. However, apart from that, there might be subtle differences that might matter in ways you can't predict.
FWIW, there's not much value in supporting multiple minor versions of past iOS releases. You should support 10.3.3 and 11.4.1 — the last releases of iOS 10 and 11 — but not any other 10.x.x or 11.x.x releases, because users should always be upgrading to the latest minor version.
For the current major version (iOS 12 right now), it would make sense to support both 12.0.x, 12.1.x, etc — the latest point release of each minor version — because users do take time to upgrade.
But that's about it — a total of about 4-5 versions that you should support. You might not be able to prevent your framework clients from building for other versions, but you don't need to support them if they do the wrong thing.