I know some interactions and content are far too complicated to apply to a default iOS UI element - but when it comes to ones that could go either way, what are the best practices in making a decision? I'm curious what the pros/cons(if any) are from a design and technical stand point.
Add a comment
|
2 Answers
From my personal experience it is good practice to go with standard components as much as you can - The number one reason for this is deprecation and support in future OS-versions.
The biggest impact we had to deal with was the update from iOS 6 to iOS 7 - We implemented a ton of custom components - Custom navigation, custom pickers, custom alertViews - When iOS 7 was announced we did not only had to redesign most of the app for obvious reasons, but also had to refactor a lot of the code. Especially when your team starts coding in swift instead of objective-c there might be a lot to refactor.
Also, if you´re working within a closed system that provides you with tons of components out of the box you should go with these - The user will experience the app on a platform that he uses for many other apps which (most of the time) use standard components. So the consistency between your web-app or brand-identity for your app should not come from custom components but from your brand/- app-identity within standard components (tint your navigationBar or tabBar, iconography, implement your brand´s font, etc)
If your App is task-heavy you should stay with standards, because efficiency is important for users. This can be supported by use of standards.
If your is full of informations, buttons and controls arent important, but the content. Here one can stylize and customize controls without hinder users main objective - having the right content or effectiveness.
