Fails to generate correct code when storyboard deployment target differs from default

[Multiforge]

Hi, I'm working on an that ships for iOS 9+ but which has a new feature that only works on iOS 12+. As a result, these new classes are declared in code like so...

@available(iOS 12.0, *)
final class AugmentedRealityViewController { ...

and the AugmentedRealityViewController.storyboard is configured accordingly for iOS 12 (otherwise Xcode correctly complains that the classes in the storyboard are iOS 12-only)...

but unfortunately R.swift seems to (naively?) output code that ignores this...

    struct augmentedRealityViewController: Rswift.StoryboardResourceWithInitialControllerType, Rswift.Validatable {
      typealias InitialController = AugmentedRealityViewController
      
      let bundle = R.hostingBundle
      ...

which naturally results in a compiler error in the autogenerated code, like so...

'AugmentedRealityViewController' is only available on iOS 12.0 or newer

Can R.swift be made smarter so that it correctly wraps its autogenerated code with @available(iOS 12.0, *), (i.e., available only in whatever version of iOS matches what's specified in the storyboard)? That would hopefully get rid of this compile error.

Many thanks!

[tomlokhorst]

Right, that would be a good thing to add!

Just looking at to what the nib file contains, it appears there is this extra dependency: <deployment version="4608" identifier="iOS"/>

The 4608 here refers to iOS 12.0 in some way, iOS 12.1 is 4624, there's a bunch of those number for each iOS version. I'm unsure where those numbers come from. Is there a mapping table somewhere we could use?

[Multiforge]

Thanks for looking into this!

Is there a mapping table somewhere we could use?

Not so far as I know. No idea where Apple gets those numbers from. ¯_(ツ)_/¯

However, you could easily build a mapping by changing the storyboard's deployment target to each previous version in turn, and observing the changes to the storyboard's <deployment/> version / identifier.

[mac-cain13]

Agree with @tomlokhorst that this would be a nice feature to have. Should not be too hard to implement, manually mapping versions will require some maintenance but think we can handle that.

I did Google a bit, but can't find anything on those number, so manually mapping seems like the only viable option.

[justin-espedal]

I found this issue while googling to try to find a list of the numbers myself. In case you guys were still wondering about the deployment version mapping, it seems there's a pretty basic pattern there.

The difference between each major version is 256, except for 9 and 10.

7.0 = 256*7
8.0 = 256*8
9.0 = 256*9
10.0 = 256*16 <- there's a big jump at 10 for some reason.
11.0 = 256*17
12.0 = 256*18

Each minor version is a difference of 16.

7.0 = 1792 (= 7*16*16)
7.1 = 1808 (= 7*16*16 + 1*16)
8.0 = 2048 (= 8*16*16)
8.1 = 2064 (= 8*16*16 + 1*16)
8.2 = 2080 (= 8*16*16 + 2*16)

9.0 = 2304 (= 9*16*16)
9.1 = 2320 (= 9*16*16 + 1*16)
9.2 = 2336 (= 9*16*16 + 2*16)
9.3 = 2352 (= 9*16*16 + 3*16)

10.0 = 4096 (= 16*16*16)
10.1 = 4112 (= 16*16*16 + 1*16)
10.2 = 4128 (= 16*16*16 + 2*16)
10.3 = 4144 (= 16*16*16 + 3*16)

11.0 = 4352 (= 17*16*16)
11.1 = 4368 (= 17*16*16 + 1*16)
11.2 = 4384 (= 17*16*16 + 2*16)
11.3 = 4400 (= 17*16*16 + 3*16)

12.0 = 4608 (= 18*16*16)
12.1 = 4624 (= 18*16*16 + 1*16)
12.2 = 4640 (= 18*16*16 + 2*16)

Seems somewhat predictable, with the only hiccup being the jump between 9 and 10.

[tomlokhorst]

Ha! That's it. Somebody in the Xcode team is being clever. The Xcode version is encoded in the hexadecimal representation of the version number.

Xcode | Dec  | Hex
------ ------ ------
  7.0 | 1792 | 0x700
  7.1 | 1808 | 0x710
  8.0 | 2048 | 0x800
  9.3 | 2352 | 0x930
 10.0 | 4096 | 0x1000
 10.1 | 4112 | 0x1010
 12.2 | 4640 | 0x1220

[justin-espedal]

Ooh, I wouldn't have seen that. Fantastic.

[Multiforge]

Great detective work guys!

[justin-bestbuy]

Hi, any progress on this? It's been over a year and we could really use this functionality. Thanks.

[rudymatos]

We are temporary ignoring those files for now (using the .rswiftignore file) which is a bummer since we really want to be able to use R.swift to instantiate those .storyboard and .xib files.