DeepMenu VS swift-async-algorithms

I've been working on the menuing side [1] based on crossing Fitt's Law with Huffman trees. But, don't know the constraints for ALS.

Hopefully, whomever takes this on doesn't take the standard Accessibility approach, which is adding an extra layer of complexity on an existing UI.

A good friend, Gordon Fuller, found out he was going blind. So, he co-founded one of the first VR startups in the 90's. Why? For wayfinding.

What we came up with a concept of Universal design. Start over from first principles. Seeing Gordon use an Accessible UI is painful to watch, it takes three times as many steps to navigate and confirm. So, what is the factor? 0.3 X?

Imagine if we could refactor all apps with a LLM, and then couple it with an auto compete menu. Within that menu is personal history of all your past transversals.

What would be the result? A 10X? Would my sister in a wheelchair be able to use it? Would love to find out!

[1] https://github.com/musesum/DeepMenu

Am experimenting with a new menuing idiom with SwiftUI [1]. It is both delightful and infuriating. Am delighted by autolayout. But, way too much semantics for observers. To simplify, I intentionally avoided structs, for view models, and resorted to classes.

I hope to create a package and use it for metal based visual music synthesizer. But, those complaints about playing nice with UIKit? Am rather worried.

[1] https://github.com/musesum/DeepMenu

Last weekend, I started reading up on Swift Concurrency through the use of async-await, actors, etc... I really liked what I read and thought of converting my current code to use these new Swift Concurrency tools and ditch the GCD. I used continuation to convert all methods with completion handlers from the Device class to async throw methods and turned Device into an actor in order to protect some members from race conditions. Once more, I am faced with the issue of calling the async methods of the Device actor one by one (waiting for each ones completion before starting the next one). I spent a lot of time thinking on how to do this and came across a number of useful references such as this one and this one. I tried to think of ways of implementing such a channel in my controller class, to guarantee sequential execution of different tasks that require the underlying library, but I'm facing a few issues with this approach:

AsyncStreams also now has the associated AsyncAlgorithms library https://github.com/apple/swift-async-algorithms which covers a lot of the Combine features (debounce, merge zip etc.)

You might find the treasure trove known as Swift Async Algorithms and look at their test suite.

https://github.com/apple/swift-async-algorithms

Requires Xcode 14, which is still in beta and cannot push to the App Store.

Also, Apple fucked their back port badly. It’s supposedly fixed now, but if you built an app that used async/await anywhere in Xcode 13.X and a user installed running iOS 12/13/up to 14.5 they’d crash on launch.

So I personally wouldn’t trust it, and instead just push to raise your iOS minimum. I’ve had no problems requiring iOS15 in my projects over 1M installs

Asynchronicity is only one aspect of Functional Reactive Programming. You’re comparing single values vs. multiple values. AsyncStream is a better analog, but I’m pretty sure you still need to bring in swift-async-algorithms to have an apples-to-apples comparison.