Magic Lasso Redesigned
Under the covers, Magic Lasso has been re-architected using SwiftUI which enables a shared but tailored UI implementation across the iPhone, iPad and Mac apps.
The move to SwiftUI delivers improved user accessibility including complete support for variable type sizing and Dark mode. In the future, multilingual support will also be considerably easier to rollout.
Over 95% of the app’s UI is now written in SwiftUI, an increase from less than 30% this time last year.
What I did notice going through the process though is that if you base the implementation on the SwiftUI defaults you will definitely get some strange, and especially on macOS, less than ideal behaviour. This led me to not use some of the inbuilt SwiftUI approaches for certain UI elements. Instead, I created custom implementations that better fit within user expectations and best practice iOS and macOS conventions.
[…]
A huge part of the work was actually prototyping approaches in SwiftUI to see what works well and what doesn’t. Once a clean path was discovered, the final implementation was relatively straightforward but it was based upon those learnings. The hard part was ensuring simplicity and not falling into the many traps of weird behaviour that are present in the System Settings UI for instance.
Personally I prefer working in SwiftUI now – probably because I no longer need to implement two similar UIs in both UIKit and AppKit.
Previously:
- Sonos Apologizes for App Redesign
- Overcast’s New Foundation
- Rewriting SoundCloud in SwiftUI
- Converting the Streaks Apple Watch App to SwiftUI
- Magic Lasso Adblock 3.0
4 Comments RSS · Twitter · Mastodon
For more detail, some of the in-built SwiftUI views that Magic Lasso tailors or does not use at all on macOS as the UI or functionality was less than ideal (on that platform and OS version that needed to be supported):
- List
- Label
- Navigation Stack / View / Link
- Group Box
There's also a lot of #if's to provide alternate approaches between platforms. The code also frequently references a global 'isMacOS' variable to customise spacing, font and styling between macOS and iOS. Without these custom metrics, I felt that the default scale and spacing of SwiftUI macOS UI elements did not fit well into the platform.
How come the window isn't resizable on Mac? You also can't navigate lists etc. with arrow keys.
I also don't get why when I click to add a "custom rule" a sheet presents, then a popover presents and it really isn't clear how you are supposed to dismiss the popover. It feels a little odd. Hitting the escape key doesn't work (only clicking the cancel button in the sheet *underneath* the popover does).
I mean I guess SwiftUI is *good enough* for this for most people.... when your main app functionality is performed by an extension. And I'm sure the ad blocker functionality works well (as evidenced by positive reviews) but I wouldn't consider this to be some sort of vindication of *SwiftUI* as a framework.
@ObjC4Life thanks for your feedback and thoughts.
> How come the window isn't resizable on Mac?
For good or bad, this is a design decision and actually the AppKit version of the app had the same limitation. In this case, SwiftUI would make resizable window content a lot easier to work than the prior AppKit implementation would have.
> You also can't navigate lists etc. with arrow keys.
Yes this is a limitation with the SwiftUI Table View in the version of macOS that Magic Lasso needs to support. If the minimum macOS version was upped, then there would be more flexibility here, but the SwiftUI Table is very limited and has gotchas in the version the app's supporting. This is a big problem in the way that SwiftUI functionality is tied to a particular OS version.
> I also don't get why when I click to add a "custom rule" a sheet presents, then a popover presents and it really isn't clear how you are supposed to dismiss the popover. It feels a little odd. Hitting the escape key doesn't work (only clicking the cancel button in the sheet *underneath* the popover does).
This is also a design decision. The rest of the UI in that sheet depends upon a URL being entered so the popover presents itself for a URL entry. Until a URL is entered, then the rest of the UI cannot be easily inferred. Did a lot of UI work back and forth on this behaviour as it's quite a complex problem, but it may not have been tackled it the best. The lack of escape key support and some behaviour is definitely due to SwiftUI, though potentially ESC could be custom supported in the current implementation.
I'm not proposing or advocating that SwiftUI is a great or appropriate framework for all apps or most apps. There is definitely a LOT of issues in it currently, missing functionality and poor behaviours. A lot of time was spent to workaround these issues and get a polished UI out the door for Magic Lasso that supports multiple platforms.
However, for this particular type of app - which previously had separate AppKit and UIKit implementations – the benefits of sharing most of the UI code between the two platforms has definitely been a win.
Disclaimer: I was continuing the conversation from this post https://mjtsai.com/blog/2024/07/26/sonos-apologizes-for-app-redesign/#comments in my original comment (I wasn't just coming in to troll).
>This is also a design decision. The rest of the UI in that sheet depends upon a URL being entered so the popover presents itself for a URL entry. Until a URL is entered, then the rest of the UI cannot be easily inferred.
I think I would have decided on something else but it is your app not mine.
>However, for this particular type of app - which previously had separate AppKit and UIKit implementations – the benefits of sharing most of the UI code between the two platforms has definitely been a win.
Thanks for answering so honestly and congrats on having such a popular app.
My main beef with SwiftUI is I don't think it can go anywhere near as far as AppKit and UIKit; plus it is degrading the entire platform in what I view as a ridiculous quest to reinvent the wheel.
If we're just interested in saving ourselves time if you have a UIKit app and let it run in iOSOnMac mode or Mac Catalyst (Designed for iPad) I think most of the time those apps are on par with a hand written SwiftUI one.
