4

EDIT:

The answer below from H2CO3 makes me almost happy. But it does not explain one thing: why do I get a runtime exception when building the app against SDK6 (UIPageViewController requires one child controller before adding it to a parent controller) but not when building against SDK5? The answer from Rolf explains what is going on: the device knows the SDK an app was built with and behaves differently to ensure maximum compatibility.

While fighting with iOS SDK versions, MonoTouch versions and different iOS Versions, I started wondering: What IS an iOS SDK after all?

I mean, I install Xcode 4.4 and I get iOS SDK 5. If I install Xcode 4.5, I get iOS SDK 6. So far no problem.

  • Now assume I build an app that targets iOS 5 and does not use any iOS 6 specific things. I but build this app using iOS SDK 6.
  • Then I build the same app but use iOS SDK 5.

Then I run both versions of the app on an iOS 6 device.

Why do they behave differently? There are small differences, for instance UIPageViewController throws an exception if no child controller is set before adding the page view controller as a child to a parent controller.

To my understanding, the callbacks, the features and everything is coming from the iOS Operating System and not from the SDK. But the OS is the same in both cases.

I totally understand that if I want to user an iOS 6 specific feature, I need to use iOS SDK 6 because a UICollectionView just doesn't exist in SDK 5. But the UI code for this view is obviously not getting included in my app, otherwise it would work on iOS5 too. So the collection view is coming from a shared library provided by the OS.

On top of that there is then MonoTouch. If we assume that each MonoTouch version is nothing but an extension of the bindings without fixing any bugs, it should not matter what MT version I use.

A short recap of my question would be: how do iOS version, iOS SDK version, MonoTouch version and application's target version play together?

Krumelur
  • 32,180
  • 27
  • 124
  • 263

2 Answers2

5

The iOS SDK consists of two components: the toolchain (Clang and/or GCC as a compiler, ld(64) as the linker and other parts of the cctools package (GNU people call it binutils) and the libraries and header files.

The toolchain (compiler) version is not strictly related to the version number of iOS. In theory, any sufficient cross-compiler can build code for any iOS (although in practice, there are exceptions and restrictions, arising out of the mistakes Apple had made when designing their compiler, including hardcoded library function names, classes and method selectors, etc.).

The header files and libraries (including the Apple-specific "framework" types of libraries) are essentially a copy of the /usr/include, /usr/lib and /System/Library/Frameworks directories on iOS. (Even this is not entirely true - on iOS, the header files are not present from iOS 3 and the libraries from iOS 3.1, because the dyld shared cache was introduced). They basically tell the compiler and the linker what functions, classes and methods are available for a specific version of iOS. Header files are for compilation-time verification and libraries are for linkage-time verification. Basically, on a normal, non-embedded system (i. e. on the desktop), where one doesn't have to cross-compile code, the "SDK" would basically mean the same files in the operating system itself, and it wouldn't be called an "SDK"; it would rather be referred to as "the sysroot".

  • To go with an example: who/what is throwing this exception when setting the child controller of UIPageViewController later? Is that the compiler of SDK 6 that behaves different from the one of SDK 5? Or is it something that says, "Hey, OS, I was built using SDK 6, throw an exception if this is done later."? – Krumelur Oct 29 '12 at 10:02
  • Runtime. Using a UIPageViewController in view controller containment. If I set the children of the UIPageViewController AFTER adding UIPageViewController itself to the controller hierarchy, this is fine with SDK 5 but fails during runtime when built against SDK 6. – Krumelur Oct 29 '12 at 10:05
  • @Krumelur That's something strange. It basically doesn't matter using what SDK you're using for building an app, there's no "I was built using X.Y SDK" stuff (why would be? iOS works just like every other OS.) - I would only find it logical if you tried to run an app that uses iOS6-only features on iOS 5. –  Oct 29 '12 at 10:07
  • And do I understand correctly: it all comes down to the fact that the compiler is part of the SDK and the compiler differs between SDK versions? – Krumelur Oct 29 '12 at 10:07
  • @Krumelur No, not at all. Re-read the first sentence of the second paragraph. –  Oct 29 '12 at 10:08
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/18709/discussion-between-krumelur-and-h2co3) – Krumelur Oct 29 '12 at 10:09
  • Let's continue that in a discussion. See link above. – Krumelur Oct 29 '12 at 10:18
2

In theory, you should be able to switch from the iOS 5 to iOS 6 SDK and not see any differences. In practice it's a little bit different.

  1. The device knows the SDK you used. This means that the device itself can decide to behave differently (for whatever reason Apple determines that's a good idea).
  2. You're using a different toolchain (gcc and related binaries), and they may compile things differently (this is rare though and I haven't seen it actually happen).
  3. MonoTouch itself may behave differently (nothing comes to mind right now, but for instance we may use different default values for things such as the Deployment Target (if you haven't set that yourself of course)).

I believe you're running into the first case - Apple has added a few restrictions to their UI hierarchy in iOS6 which they only enforce if you built against the iOS 6 SDK (to not break existing apps I presume).

Rolf Bjarne Kvinge
  • 19,253
  • 2
  • 42
  • 86
  • That makes sense. The problem I have now: the correct answer is part of H2CO3's and yours. :-) You have a lower score, so you get the tick. – Krumelur Oct 29 '12 at 13:15