There were a ton of different design variations! The differences were mostly in the details. The main requirement was to build a video editor that does everything that a video editor does, but as well as possible. And because this editor is designed to work within third-party apps that license the SDK, we wanted it to be well-designed but neutral, as easy to use as possible. One example of a rejected idea: We had played around with the idea of collapsing and expanding the clips when you scroll vertically in the timeline, like an accordion, but it turned out that traditional vertical iOS-native scrolling felt better.

Thanks for sharing! We will have a look and try to reproduce the issue you’re seeing.

Great question! The most important difference is probably that this is an SDK, which means that it can be built into all kinds of apps by other companies that want to offer video functionality.

There is a demo app on the iOS app store, check out the link in the article if you want to give it a spin!

Valid point! I agree in general. For timelines though, I believe that most people expect timeline user interfaces to be horizontal. Vertical scrolling may be more comfortable, but it clashes with existing mental models for video editing.

You’re right, it may be worth exploring a vertical timeline though, especially for more experimental video editing concepts! It would definitely be possible to implement with the IMG.LY SDK.

> they went with SwiftUI simply because it’s the newest thing rather than through an evaluation of implementation strategies

Not that it applies to this project, but in my experience, this is one of the plagues of the lower-paid engineering team.

On the books it looks like the company is saving money by hiring on the low end of the salary scale. In practice the budget is spent inching away at minor upgrades, while enthusiastically adopting new techs for experimentation and resume-padding purposes.

Hi! I wrote the article.

Excellent question! You are right, we definitely did not choose to implement it in SwiftUI because it’s easier than it would have been with UIKit.

Our main concern was to build a future-proof solution for our SDK customers. Apple has repeatedly made clear that they consider SwiftUI the future of UI development for their platforms.

Even though we were not able to implement the whole timeline experience without falling back to UIKit techniques, we think the result was worth the extra effort. For example, it is very flexible in terms of appearance and theming, including sizes, colors, animations, and behavior.