 <p><strong>1</strong> </p> <p>First of all, you create a protocol <code>ErrorPopoverRenderer</code> with a <em>blueprint</em> for method <code>presentError(...)</code>. You thereafter extend the class <code>UIViewController</code> to conform to this protocol, by implementing the (compulsory) blueprint for method <code>presentError(...)</code>.</p> <p>This means that you can subclass <code>UIViewController)</code> with additional protocol constraint <code>ErrorPopoverRenderer</code> for the subclass. If <code>UIViewController</code> had not been extended to conform to protocol <code>ErrorPopoverRenderer</code>, the subsequent code in the example you linked would case compile time error (<code>... does not comply to protocol ErrorPopoverRenderer</code>)</p> <pre><code>class KrakenViewController: UIViewController, ErrorPopoverRenderer { func failedToEatHuman() { //… //Throw error because the Kraken sucks at eating Humans today. presentError(ErrorOptions(message: "Oh noes! I didn't get to eat the Human!", size: CGSize(width: 1000.0, height: 200.0))) //Woohoo! We can provide whatever parameters we want, or no parameters at all! } } </code></pre> <p>However, there is a possible issue with this method, as presented in your link:</p> <blockquote> <p>Now we have to implement every parameter every time we want to present an ErrorView. This kind of sucks because we can’t provide default values to protocol function declarations.</p> </blockquote> <p>So of the protocol <code>ErrorPopoverRenderer</code> is not intended solely for use by <code>UIViewController</code>:s (or subclasses thereof), then the solution above isn't very generic.</p> <p><strong>2</strong></p> <p>If we want to have a more broad use of <code>ErrorPopoverRenderer</code>, we place the <em>specific</em> blueprints for each class type that might make use of the protocol in <em>protocol extensions</em>. This is really neat as the more specifics parts of <code>ErrorPopoverRenderer</code> blueprints for method <code>presentError()</code> can be specified differently for different classes that are to possibly conform to the protocol, and the method <code>presentError()</code> can be made more minimalistic.</p> <p>I quote, from the example:</p> <blockquote> <p>Using <strong>Self</strong> here indicates that that extension will only ever take place if and only if the conformer inherits from UIViewController. This gives us the ability <strong>to assume that the ErrorPopoverRenderer is indeed a UIViewController</strong> without even extending UIViewController.</p> </blockquote> <p>In this method, since <strong>the code now knows</strong> (we did, already in 1.) that it is a view controller that will call <code>presentError()</code>, we can place the specific <code>UIViewController</code> stuff directly in the blueprint implementation, and needn't send it as a long list of arguments.</p> <p>Hence, 2. is, for this specific use, a kind of more "generic" approach, in the sense that we slightly minimise code duplication (calling <code>presentError()</code> vs <code>presentError(... lots of args ...)</code> from several different <code>UIViewController</code>:s).</p>