State of Apple's Catalyst (daringfireball.net) 16
At its developer conference in June this year, Apple introduced Project Catalyst that aims to help developers swiftly bring their iOS apps to Macs. Developers have had more than half a year to play with Catalyst. Here's where things stand currently: The crux of the issue in my mind is that iOS and Mac OS are so fundamentally different that the whole notion of getting a cohesive experience through porting apps with minimal effort becomes absurd. The problem goes beyond touch vs pointer UX into how apps exist and interact within their wider OSes. While both Mac OS and iOS are easy to use, their ease stem from very different conventions. The more complicated Mac builds ease almost entirely through cohesion. Wherever possible, Mac applications are expected to share the same shortcuts, controls, windowing behavior, etc... so users can immediately find their bearings regardless of the application. This also means that several applications existing in the same space largely share the same visual and UX language. Having Finder, Safari, BBEdit and Transmit open on the same desktop looks and feels natural.
By comparison, the bulk of iOS's simplicity stems from a single app paradigm. Tap an icon on the home screen to enter an app that takes over the entire user experience until exited. Cohesion exists and is still important, but its surface area is much smaller because most iOS users only ever see and use a single app at a time. For better and worse, the single app paradigm allows for more diverse conventions within apps. Having different conventions for doing the same thing across multiple full screen apps is not an issue because users only have to ever deal with one of those conventions at a given time. That innocuous diversity becomes incongruous once those same apps have to live side-by-side. Columnist John Gruber of DaringFireball adds: I think part of the problem is Catalyst itself -- it just doesn't feel like nearly a full-fledged framework for creating proper Mac apps yet. But I think another problem is the culture of doing a lot of nonstandard custom UI on iOS. As Wellborn points out, that flies on iOS -- we UI curmudgeons may not like it, but it flies -- because you're only ever using one app at a time on iOS. It cracks a bit with split-screen multitasking on iPadOS, but I've found that a lot of the iPad apps with the least-standard UIs don't even support split-screen multitasking on iPadOS, so the incongruities -- or incoherences, to borrow Wellborn's well-chosen word -- don't matter as much. But try moving these apps to the Mac and the nonstandard UIs stick out like a sore thumb, and whatever work the Catalyst frameworks do to support Mac conventions automatically doesn't kick in if the apps aren't even using the standard UIKit controls to start with. E.g. scrolling a view with Page Up, Page Down, Home, and End. Further reading: Apple's Merged iPad, Mac Apps Leave Developers Uneasy, Users Paying Twice (October 2019).
By comparison, the bulk of iOS's simplicity stems from a single app paradigm. Tap an icon on the home screen to enter an app that takes over the entire user experience until exited. Cohesion exists and is still important, but its surface area is much smaller because most iOS users only ever see and use a single app at a time. For better and worse, the single app paradigm allows for more diverse conventions within apps. Having different conventions for doing the same thing across multiple full screen apps is not an issue because users only have to ever deal with one of those conventions at a given time. That innocuous diversity becomes incongruous once those same apps have to live side-by-side. Columnist John Gruber of DaringFireball adds: I think part of the problem is Catalyst itself -- it just doesn't feel like nearly a full-fledged framework for creating proper Mac apps yet. But I think another problem is the culture of doing a lot of nonstandard custom UI on iOS. As Wellborn points out, that flies on iOS -- we UI curmudgeons may not like it, but it flies -- because you're only ever using one app at a time on iOS. It cracks a bit with split-screen multitasking on iPadOS, but I've found that a lot of the iPad apps with the least-standard UIs don't even support split-screen multitasking on iPadOS, so the incongruities -- or incoherences, to borrow Wellborn's well-chosen word -- don't matter as much. But try moving these apps to the Mac and the nonstandard UIs stick out like a sore thumb, and whatever work the Catalyst frameworks do to support Mac conventions automatically doesn't kick in if the apps aren't even using the standard UIKit controls to start with. E.g. scrolling a view with Page Up, Page Down, Home, and End. Further reading: Apple's Merged iPad, Mac Apps Leave Developers Uneasy, Users Paying Twice (October 2019).
Corporate Thinking (Score:5, Insightful)
Needless to say both approaches are stupid and bring to mind the expression "If my grandmother had wheels, she'd be a bicycle."
Re: (Score:1)
Re: Corporate Thinking (Score:2)
Re: (Score:2)
"Apple wants to shove their tablet applications onto their desktops"
I actually don't understand why this is supposed to be a problem. Anyone who has been a Mac user for a long time remembers when most Mac applications were as simple as a phone app. There were tons of such simple apps, and many of them were quite popular. At the time Macs only supported one button mice, and the OS didn't even provide for long presses. Lots of useful apps exist on phones, and are no simpler than the MacOS apps of old, so why
Re: (Score:2)
I actually don't understand why this is supposed to be a problem
"The lack of cohesion in UI paradigms is driving me crazy!" - is something you've never heard from an iOS user. Seems like a bunch of UI / UX purists getting their panties bunched up.
Problems? - inefficiency/climate-change for 1 (Score:4, Informative)
I actually don't understand why this is supposed to be a problem.
I'll take the bait! :)
...a major culprit?...bootstrap and a dozen JavaScript frameworks so that the devs can be assured 1 page renders (poorly) on your laptop and your phone. At work, we have an old application that no one has touched since 2008 or so because it was done right the first time and isn't used enough to continuously invest in. Despite having a terrible backend, this app is the nicest I've used in a long time. No Bootstrap...no responsive design...no JavaScript frameworks...just basic HTML tables like we wrote in the 90s and simple JavaScript for validation/DHTML.
Beyond the usability issues, this means we get crappy apps that can be deployed in 2 environments. An example of this is Electron-based text editors. Text editors used to be the fastest app you owned, but VSCode is one of the slowest I've seen. Atom isn't any better. There are layers upon layers of inefficient technologies designed to make the developer happy and the user miserable. JavaScript should be your last choice, never your first choice...for pretty much anything. Nowadays, it CAN do anything, but does it do anything as well as other technologies?...in my experience, I have yet to see a desktop JS app outperform a well-written native one and node.js is definitely not faster than Java or C++ (I have written apps in all 3)
Ever notice how recent web applications are surprisingly slow and clunky despite your CPU/GPU/internet-connection being faster?
It is such a delight to use because it is so fast when the browser is done loading, it is done...I can scroll VERY quickly through it and it amazes me how fast the browser handles it. It never rerenders anything...just renders it correctly at startup and that's it. I can do what I need to do in a fraction of the time it takes a modern UI and my CPU meter never spikes. I wish everyone could see it to be reminded of how nice the web could be!
A good desktop application is different than a good tablet or a good phone app. Each uses different technologies. Each has different needs. I have yet to see something that works well across multiple platforms...only things that work adequately in one and poorly in the rest.
This desire to write one page/app for all scenarios has a real cost besides my annoyance....it requires a lot more electricity to do basic things. More CPU heat is generated...your battery's life is shortened as it drains faster and has to be recharged more often.
It's fun to rant about coal or cars when complaining about Climate Change. How about JavaScript? How about bad code? How about unnecessary layers of abstraction? Pointless microservices? We waste a ton of electricity and resources running inefficient UIs and web pages for no good reason...just because that's what's trendy among UI designers and front-end programmers (backend developers have their sins as well, but that's a longer story). If software engineers just put a minimal amount of thought into application efficiency or intelligently restricting their framework abuse, it would have a huge impact on how much electricity we consume...and make their users MUCH happier. Everyone wants faster apps and longer battery life.
The same can be said about another framework designed poorly to render iOS apps on MacOS. I have tried them on my macbook and am not impressed. They are surprisingly slow for widgets that I remember having in the 90s and being faster. They're not TERRIBLE...but I never asked for iOS apps on my macbook. I'd rather have really fast macbook widgets calling the same REST services with as little overhead as possible...also, how many of these apps do something that a web page couldn't do better?
Re: (Score:2)
but I never asked for iOS apps on my macbook. ...
Then don't install them
Does JS outperform an emulator? (Score:2)
I have yet to see a desktop JS app outperform a well-written native one
Does a desktop JS app outperform a native one whose publisher compiled it for an instruction set different from that of your machine? One example is running an x86 or x86-64 executable in emulation on an ARM CPU.
Re: (Score:2)
I don't see why this is a problem on desktops that have a *windowed display*. Just put the tablet/phone app into a window and be done with it. The only thing that's going to be a big issue is touch input on non-touch systems.
Yes, it will look retarded. We'll see how non-awesome phone apps are on a computer in a window, even ones we like, but it will mostly work if it does what people want.
Apple screwed the pooch originally with iOS by not requiring everything to be built around a variable display size an
Re: (Score:2)
Cross compiling doesn't tell us they are moving anywhere except attempting to be more flexible and explore what works. Since the processors are different between iOS devices and Macs, necessarily they must have cross compiling to see what is it precisely that makes the UIs work differently for the user. The new cheesegrater Mac is outfitted with Intel processors that ARM won't be able to come close to in processing power for years to come.
Re: (Score:1)
Since when did Apple start caring about speed over style and usability?
User perception (Score:3)
As someone who publishes iOS Apps I initially thought this might be a good thing but I've since decided to leave well alone.
My reason being that my Apps are designed for iPhone and iPad UI and screen size/shape.
The majority of users, on Macs, won't appreciate that my software is primarily for iOS and not MacOS therefore their expectations will be set according to MacOS UI standards and UX.
So I'd expect to take a hit in the ratings/reviews from MacOS users not impressed by the "weird UI/UX"
In a couple of years, once the early adopters have been burned, the MacOS public has become more aware of these ported apps and catalyst has matured (or not) then it might be worth re-evaluating.
Also MacOS doesn't have as big a market size as iPhone's (the iPad only accounts for about 5% of my app users base) so the benefits aren't really there either in terms of expanding user base.
It would have been much easier for both the developers and users if Apple had just put their iOS emulators on the Mac App store with full App Store and iCloud support allowing MacOS users to use their iOS Apps on a larger screen.
The Mac would then instantly gain the entire iOS App Store repertoire with nothing required by developers (other than us having to sign off on a new iTC T's &C's).
I enjoy using my Apps on the emulator but I'm the only one who can.
For 95% of things it is easy and painless if you prefer a track pad like I do (e.g. two finger pinch etc is tricky. Apple's to blame for no touch screen on MacOS. In some ways iOS is better.).
No additional work for the developer and clearly differentiated for the end user.
The end user perception changes from "weird Mac App" to "my iPhone Apps".
Phone games (Score:3)
To the other user's comment, I think most people who want to play phone games on a desktop aren't going to care much about the UI, either, so that's another reason I think this would be a good use case for this kind of thing.