Slightly confused. This article says ipad app -> macos. Does that include ios -> macos cause ipad has a different os now.
iPadOS, iOS, tvOS are all still "iOS". The difference is what "Idiom" the platform uses: Phone, Pad, or TV. That changes some of the UI behavior. Pad supports split screen, and uses a UISplitView differently than Phone. TV does some things differently as well.
But I can write one app against UIKit and reuse even UI elements between all three platforms, because it is all UIKit.
Catalyst is UIKit for macOS. Nothing more, nothing less. But it looks like macOS is using the Pad idiom.
Will these "Catalyst" built apps require Catalina? Anyone know.
Yes. Catalyst (UIKit) was private in Mojave, and since Catalina is the first major version with UIKit as a public framework, it will require it.
So, is this anything like Universal Apps in Windows? I vaguely remember there being some derision over this.
I'm not a developer, so from the user perspective I think this could be good, especially if they don't force a dumb down of apps for Mac (which based on the Keynote they aren't).
I guess iOS being based on OSX is finally beginning to fulfill its potential after 12 years.
It is like Universal Apps, but there's a key difference between Apple's approach and Microsoft's. Microsoft built UWP on top of WinRT (edit: the framework, not Windows RT, the SKU) that was part of Win8. These are "Modern" or "Metro" apps. The fact that you had to completely port an app to it to get the benefit made it expensive for established apps like Photoshop. And because of how WinRT worked, you may not even get all the benefit of it since there were some weird issues around WinRT in C++ that I don't know if they resolved in the Win 10 timeframe.
Apple played a longer game. iOS/tvOS/iPadOS and macOS already share a
lot of frameworks: Foundation, AVFoundation, Core Data, Core Graphics, Core Animation, Map Kit, etc, etc etc. Before Catalyst, I could still write up an app with a single codebase that compiled for all 4 platforms, mostly. The problem is that AppKit and UIKit are different enough that you have to "fork" a piece of your code for AppKit and one for UIKit. This makes managing things a bit trickier and just more effort. By bringing UIKit to the Mac, what Apple is doing is saying to the (more numerous) iOS devs: "You can now bring your app to the Mac without having to deal with AppKit to do it".
The advantage here is that UIKit is something people already use. iOS has the larger developer base. It's now less of a "semi-port" and now a "tweak it for Mac like you do for tvOS or iPad" situation. That's important.
But, in many ways, because the two have shared most of their core frameworks for years, it was also a lot less work to get here. I think Apple was hoping that only having AppKit/UIKit diverged was enough to entice more devs, but I guess not quite.