Live data from Hacker News

Designing a Timeline for Mobile Video Editing

img.ly

1–10 of 16 posts

Re: Designing a Timeline for Mobile Video Editing

#5
I’m curious why they chose SwiftUI. In my experience, this kind of highly responsive editor UIs are best implemented using immediate mode GUI techniques. A declarative layer like SwiftUI or React is often a hindrance.

The article alludes to these issues:

”All these gestures must behave as expected and not interfere with each other. We found it unexpectedly difficult to fine-tune and harmonize these interactions with pure SwiftUI, so we used some proven legacy iOS techniques to get it right.”

The use of the word “legacy” kind of sounds like they went with SwiftUI simply because it’s the newest thing rather than through an evaluation of implementation strategies…

Re: Designing a Timeline for Mobile Video Editing

#6
post #5

I’m curious why they chose SwiftUI. In my experience, this kind of highly responsive editor UIs are best implemented using immediate mode GUI techniques. A declarative layer like SwiftUI or React is often a hindrance. The article alludes to these issues: ”All these gestures must behave as expected and not interfere with each other. We found it unexpectedly difficult to fine-tune and harmonize these interactions with…

[deleted]

Re: Designing a Timeline for Mobile Video Editing

#8
Overall, I love it! I tried to import an MP3 from OneDrive into the video editor; it showed that it imported, but on playback, there was no sound. However, I could clearly hear the sound in the import preview window. Then, I tried replacing it with a sound already included, and then replacing it back with my MP3 to see if that would work, but the app crashed.

Re: Designing a Timeline for Mobile Video Editing

#9
post #5

I’m curious why they chose SwiftUI. In my experience, this kind of highly responsive editor UIs are best implemented using immediate mode GUI techniques. A declarative layer like SwiftUI or React is often a hindrance. The article alludes to these issues: ”All these gestures must behave as expected and not interfere with each other. We found it unexpectedly difficult to fine-tune and harmonize these interactions with…

> 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.

Post reply on HN