@jrose @porglezomp @saagar @hikari having written that deprecation message, with 15 years of love in my heart, let me say: good riddance

@jrose @porglezomp @saagar @hikari but yeah, those conformances are forever

@millenomi @jrose @porglezomp @hikari I have discovered that if you mark all your initializers as convenience inits it probably breaks something or the other but you don’t have to interact with NSCoding directly

@saagar @jrose @porglezomp @hikari yup, correct. It means that you are inheriting your designated initializer situation from your superclass, that is, you support using your superclass’s initializers to produce a fully functional object of _your_ subclass, and so the init(coder:) of your superclass is good enough for your subclass too.

The moment you add a designated init, the init(coder:) of your superclass isn’t sufficient anymore and you have to do both (if only to fatalErrror out).

@millenomi @jrose @porglezomp @hikari Yeah so the lie here is that calling the superclass’s designated initializer is not actually going to provide a functional object because I do all that work in the convenience initializer

@saagar @millenomi @porglezomp @jrose btw interface builder can call init on your class if you prefer that to initWithCoder:, but I assume it can't connect outlets and stuff if you do (or can it 🤔)

@saagar @millenomi @porglezomp @jrose or, of course, set up a frame for a view, so this has questionable utility for actual views

@hikari @millenomi @porglezomp @jrose The best views are ones that are hardcoded to support exactly one size

@jrose @porglezomp @saagar what do you mean by “claims to be” 😨

@jrose @porglezomp @saagar oh is this about how every UIView descendant must implement initWithCoder: itself

@hikari @jrose @porglezomp Yes, except nobody does because Interface Builder is basically dead and buried at this point