DeepMenu VS EffectivePower

Compare DeepMenu vs EffectivePower and see what are their differences.

Our great sponsors
  • Scout APM - Truly a developer’s best friend
  • Zigi - Workflow assistant built for devs & their teams
  • SonarQube - Static code analysis for 29 languages.
  • InfluxDB - Build time-series-based applications quickly and at scale.
DeepMenu EffectivePower
2 2
0 129
- -
9.1 10.0
2 months ago 18 days ago
Swift Swift
- -
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of DeepMenu. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-06-16.


Posts with mentions or reviews of EffectivePower. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-05-25.
  • SwiftUI in 2022
    7 projects | | 25 May 2022
    I just finished writing a little Mac app in SwiftUI for my personal use yesterday: ( for a slightly out-of-date screenshot). Here are my thoughts.

    The good:

    * Making all the graphs (they're drawn by hand!) was very nice and easy. The speed at which I could iterate with them was incredible, and I could just move code around and lay things out and move them between moves in a way that AppKit (or UIKit) would not allow, at all.

    * I could keep the code very clean, with each component being very specific and isolated. Plumbing bindings through made things very natural and I can imagine taking the code I made there and just plopping it into another project as-is.

    * The result is actually kind of nice, IMO? There's a lot of focus on whether SwiftUI works and stuff but not much focuses on what the end result is. I had an app in my mind that I wanted to make, and it was mostly possible to make it in SwiftUI. In some places I was pleasantly surprised that things I would have been hesitant to try before (slider in a toolbar!) "just worked".

    The middling:

    * I initially supported macOS 12.0 only. Someone asked me to backdeploy to 11.0, which was a little painful mostly because Material didn't exist back then and neither did support for initializing a color from a NSColor. I did kind of a lazy stab at it and the end result being fairly simple, but took about an hour to write: If I had to support 10.15 I think I would honestly rewrite large parts of the app in AppKit, maybe keeping just the graphs as view representables.

    * My data model has tens of thousands of elements. Ensuring the "reactivity" didn't cause a bunch of things to be recalculated when they shouldn't was a bit of a challenge. The place I have it now is very nice (I have them defined in such a way that they will never update unless they need a redraw) but this definitely does not come "for free", you'll find out about it after profiling and need to figure out how to fix it.

    * I wrote simple versions of things that don't seem to exist in SwiftUI but AppKit provides for free, such as magnification bouncing. It was like three lines of code to get something that seems reasonable, but with SwiftUI I'm never sure if this is a "we just didn't add it yet" thing or a "oh this is so simple in the framework that you should just write it yourself".

    The bad:

    * Things are broken and I don't know why. If you use magnification gestures the callbacks stop getting called. No indication why. I have some commented out code that would've used a table in the sidebar, but I had to use a List instead because it seems like SwiftUI does not properly update the table and it crashes with an assertion.

    * Documentation sucks but that's nothing new. There's a lot of things that work but you need to be clever at arriving to getting to that point. It's a fun challenge for a toy project but for a production thing I can see this being super frustrating.

    * If you mismatch a type somewhere the compiler is just going to time out rather than telling you what is wrong. Thankfully you can just go through and comment out large parts of the app to reduce the scope of where the error is coming from, but the fact that this is necessary is kind of annoying.

What are some alternatives?

When comparing DeepMenu and EffectivePower you can also consider the following projects:

BreadBuddy - Recipe scheduler for iOS

swift-async-algorithms - Async Algorithms for Swift