and you get to test betas of future iOS releases anyway, so if something breaks, you&#39;ll catch it and release a fix.<br><br>That assumes that all apps get updated when new OS releases come out, and that&#39;s not true. Many apps stop being maintained, but they may have many users, and Apple does whatever they can to make sure apps don&#39;t break when users update iOS. The reality is that Apple spends a lot of time working around hacks implemented in apps like swizzling, etc. <br><br>I&#39;m really worried about the world where monkey-patching iOS internals is no longer possible<br><br>I&#39;m excited about that world, because Apple won&#39;t have to waste time worrying about ugly hacks, and they can focus on fixing bugs instead. <br><br>In any case, this proposal is about final by default. Final is already part of the language, and I&#39;m sure Apple wouldn&#39;t hesitate to use it extensively when/if they write frameworks in Swift, so I don&#39;t think this proposal would change that. <br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 20, 2015 at 1:17 PM Andrey Tarantsov &lt;<a href="mailto:andrey@tarantsov.com">andrey@tarantsov.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">This is another proposal that&#39;s right on principle, but breaks down in real-world scenarios.<div><br></div><div><div></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">To play devils advocate, take for example UINavigationController in UIKit on iOS.</div></div></blockquote><div><br></div></div></div></div><div style="word-wrap:break-word"><div><div>This.</div><div><br></div><div>Real iOS apps subclass and override things that were never supposed to be overridden, swizzle iOS internals and do a lot of other nasty stuff, because sometimes that&#39;s the only way to get the effect you want, and you get to test betas of future iOS releases anyway, so if something breaks, you&#39;ll catch it and release a fix.</div><div><br></div><div>I&#39;m really worried about the world where monkey-patching iOS internals is no longer possible. Thankfully, a Swift-based UIKit isn&#39;t anywhere on the horizon.</div><div><br></div><div>ON THE OTHER HAND, I do agree with this proposal for our own code. I&#39;ve always used</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>// override point</div></div></blockquote><div><div><br></div><div>to mark methods designed to be overridden, and a keyword to document this formally would be appreciated.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><div>A.</div><div><br></div></div></div></blockquote></div><div dir="ltr">-- <br></div>Javier Soto