Published on <a href="http://ift.tt/2pfveEU">| Prototyping: From UX to Front End &mdash; Medium</a> Raul Riera 
<h4>Reusability, where it matters.</h4>
I used to kid around with my co workers by using the saying “We are not here to write code, we are here to ship” (paraphrased, I don’t quite remember where I saw that). I was of course partly kidding, the truth lies in between. Ironically, I am one of the few iOS developers that <a href="http://ift.tt/2pGiXfm">likes frameworks</a>.
If you <a href="http://www.twitter.com/raulriera">follow me on Twitter,</a> you already know how demanding I am on the quality of first party iOS apps. But one thing most of them have done right is that they are easily recognisable and always on brand.
Let’s look at a couple of different apps created by Apple.
<img alt="" src="http://ift.tt/2pfun79"><img alt="" src="http://ift.tt/2pGo3rU">Podcast and AppStore
Now, these two are so similar that it took me a few seconds to tell which app was which. This would be the most extreme example where you can clearly notice that both apps were created with the exact same components: a featured gallery and a list of apps. That is it, modify a few colours, round up some corners and you are done.
Let’s take a look at another example, while still obvious this one does manage to provide you with two completely different UI elements while still sharing some components.
<img alt="" src="http://ift.tt/2pfDpRq"><img alt="" src="http://ift.tt/2pG9G6U">Health and Calendar
These two are easier to tell apart, in fact they only share a single piece between them. But it helps us realise just how modular the Calendar app is, since it’s sharing the “day picker” without sharing the full “day view”. You would also notice that even the shared “day picker” is not exactly the same on both examples, the font size and colour has been tweaked, as well as the date formatting. Configuration is key when you want to share UI components across features or apps.
<h3>Why UI components are great?</h3>
Going back to that initial joke, components are a huge time saver. Instead of designing and developing every single screen on the app. Create several sharable components that you can use between several screens and features. Just like the ones identified in the previous screens.
If you ever played around with <a href="http://ift.tt/1H3SRVh">ResearchKit</a>, you can immediately see that components are the selling points of this framework. There are so many different options to pick that arguably you could create any type of app using them.
Components are excellent for prototyping and shipping features faster than with snowflake designs and interactions scattered across your app. But like always, everything needs to be balanced. You don’t want your users to be unable to tell your screens apart.
We could dig into more examples from iOS itself, specially the dark themes that seem to be present in some apps like Watch, Clock, Clips, etc. And also the sort of experimental layouts like Maps and Music (maybe iOS 11 related?) But I intentionally wanted this to be short and non technical, maybe for another post.
Thanks for reading 💚
Get in touch on Twitter: <a href="https://twitter.com/raulriera">@raulriera</a>
<img src="http://ift.tt/2pGoUsy" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2pfCgcF">Building apps like LEGO™ 👷‍♀️👩‍💻</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building apps like LEGO™ ‍♀️‍

Reusability, where it matters.

Top Stories