It’s easy to borrow the same idea from Apple to build something like UIKit for you own app. And I’ve done similar stuff several times for my past jobs and also for my side project. As I mentioned in the previous post, I’m in a newly-formed team to build a brand-new app from the ground up. So now we’re facing the same problem as before: we need to build our own UI components library. But my first question is for what?
Know what UIKit means for your apps
Even thought I’ve done this several times, I’m still cautious about the definition we give to the UI library. Because the idea behind it will define everything and have large impact on our future development.
From engineers’ perspective, we don’t want to reinvent the wheel each time, rather, we want the stuff to be reusable. But designers usually defeat that purpose by changing little things from time to time and showing off their work with custom design. They need something different.
Think about resources and the future
We know we can’t do something like iOS UIKit which is easy to use and flexible in terms of customization at the same time. As a small team which is usually resources constrained, one common request for UIKit is to improve the velocity of feature development. I built my own UI library upon this idea years ago with bunch of out-of-the-box UI elements that can be used with zero thinking and minimum configuration. It provides all the tools we need to let us focus on app development rather than the tools we need.
To make that possible, engineering team and design team took collaborative effort to build consistent UI components shared between apps for the company, helping establish a refreshed product language and brands.
Think about the company and how business works
My previous working experiences are all based on in-house development. The app itself is the product for the company. Design is much emphasized with product management by design.
FR is a completely different story. All the work we’re doing just facilitates the business and helps it moving forward. That’s said, we also need a architecture that works well with both in-house team and outsourcing vendors.
Obviously for UIKit, we don’t want vendors to know the details underneath. So one of our members has this idea that UIKit only contains layouts and theme protocol that each app should implement that part on their own. Therefore UIKit provides a lightweight foundation for future UI development. It’s very flexible as well.
We’ve discussed about this topic quite a bit and thought we can take advantage of both. But we both have concern that there are still lots of uncertain stuff about design and business requirement, not even talking about future plan. So at this point flexibility is our top priority, and as things move on we’ll find out how much can be reused and start to build a concrete UI framework from there.