ViewElements

Why?

All iOS apps have at least one UITableView. It displays a list of elements (called UITableViewCell) that users can scroll vertically. These cells are reused automatically as they go in and out of screen. So, displaying a thousand of items is not a problem.

You can see this in most builtin apps from Apple, like Settings.

Most common (and default) appearance of UITableView

However we shouldn’t stop here. See these pages:

They are just rows of elements stacking together:

Debug mode

It is clear now that UITableView can be used to build any kinds of page in the app, not only table views. Another huge advantage of this is that the cells are reused automatically.

However, creating a table view is a repetitive and tiresome task. It uses the concept of data source, and thus the code for the presentational layer is separated into multiple functions (e.g., cellForRowAtIndexPath, heightForRowAtIndexPath, estimatedHeightForRowAtIndexPath). This makes the code hard to work with as it grows.

Solution

ViewElements simplifies the process of building UITableView and reusing UITableViewCell. It allows developers to declare arrays of rows such that the final appearance and the order of the rows, will directly mirror the code. Thus, all parts of the code for each row are close together, make it easier to work with.

It also provides API, called Component, to build a view by nesting UIStackView together. With a combination of UITableView and UIStackView. While table view deals with displaying and reusing cells in the vertical direction, stack view deals with UI creation in each cell.

ViewElements has data structures that wrap those complexities and provide APIs to construct a complete view. Once a view is setup, it can be reused anywhere, under the provided API. But the built-in elements provided can already do a lot!

Check this quick demo:

A demo using built-in label elements. These are the only code to build what you see.

What’s Next

This proves to be great solution for static pages in the app. However, for a dynamic page, and those that interact with data such as form inputs, we need more.

Currently, I’m combining a reactive programming library called RxSwift with ViewElements, in order to enable data-driven UI.

Lessons

The API designer has the power to guide developers in either right or wrong directions.

When it goes right, developers will feel that a framework is intuitive. They can guess how it works, what they should do, or not do, on their own without consulting a documentation.

Usually such framework is designed in a way that mirrors the real-world objects.

Throwing fatal error is good when developers are building their apps with a framework. But utilizing syntax, static types, or complier of a programming language to restrict developers from writing invalid code is much more elegant.

Future

Currently, many parts of the iOS development are still imperative. We have to do a lot of things manually like structuring views in the app, handling events and UI updates, managing the lifecycle, etc.

Thus, believe that there will be more native frameworks and libraries that provide markup language (e.g., HTML) to construct native views.

While React Native is really great at creating views and apps with Javascript, it won’t be reliable enough to be able to build high quality mobile applications.

Those tools will soon expand to facilitate other aspects in the app creation. This includes networking, navigation, and user interactions.

As a result, there will be a platform that allows anyone without technical knowledge to create native apps.

I am sure Apple must have some kind of internal markup system that can make creating apps a breeze. Such system would also allow the UI — or the whole app — to change dynamically over the internet.