SwiftUI and Catalyst: Apple Executes Its Invisible Transition Strategy (macworld.com) 44
Catalyst is Apple's framework that enables developers to easily bring existing iOS apps to the Mac, while SwiftUI is a new, Swift-based technology that makes it easy for developers to create one app that runs on all of Apple's platforms. Jason Snell from Macworld highlights the slow, invisible transition of these new technologies. From the report: Catalyst, which arrives this fall, will allow developers who are well-versed in the vagaries of writing iOS apps to use those skills to write Mac apps. This will most commonly take the form of bringing iPad apps to the Mac, with additions to make them feel more like native Mac apps, but it's more than that -- it provides iOS developers with a familiar set of tools and access to an entirely new platform, and it makes the target for professional apps across Apple's platforms broader by including both the iPad and the Mac. iOS apps are currently built to run on devices running Apple-designed ARM processors, and if the rumors are true, that's another transition waiting to happen. But given that all Mac and iOS developers are already using Apple's Xcode tools to develop their apps, I suspect that the pieces have been put in place for a fairly simple transition to a new processor architecture.
And then there's SwiftUI, which may be a harder concept for regular users to grasp, but it's a huge step on Apple's part. This is Apple's ultimate long game -- an entirely new way to design and build apps across all of Apple's platforms, based on the Swift language (introduced five years ago as yet another part of Apple's long game). In the shorter term, iOS app developers will be able to reach to the Mac via Catalyst. But in the longer term, Apple is creating a new, unified development approach to all of Apple's devices, based in Swift and SwiftUI. Viewed from this perspective, Catalyst feels more like a transitional technology than the future of Apple's platforms. But we're talking about the long game here. Transitional technologies are all a part of the long game. Catalyst will bring those apps to the Mac. iOS and Mac developers will pick up Swift and SwiftUI. Mac apps can integrate iOS stuff via Catalyst. iOS apps can integrate Mac stuff for use on the Mac. And all developers can begin experimenting with SwiftUI, building new interfaces and replacing old ones in a gradual process. "And then we'll turn around sometime in the 2020s and realize that all of this talk of UIKit and AppKit and Catalyst is behind us, and that our apps are written in Swift with interfaces created using SwiftUI," Snell writes in closing. "It will have all changed due to Apple's slow and steady pace of iterative, continuous improvement. The long game never stops, and it can be hard to see that you're even in it."
And then there's SwiftUI, which may be a harder concept for regular users to grasp, but it's a huge step on Apple's part. This is Apple's ultimate long game -- an entirely new way to design and build apps across all of Apple's platforms, based on the Swift language (introduced five years ago as yet another part of Apple's long game). In the shorter term, iOS app developers will be able to reach to the Mac via Catalyst. But in the longer term, Apple is creating a new, unified development approach to all of Apple's devices, based in Swift and SwiftUI. Viewed from this perspective, Catalyst feels more like a transitional technology than the future of Apple's platforms. But we're talking about the long game here. Transitional technologies are all a part of the long game. Catalyst will bring those apps to the Mac. iOS and Mac developers will pick up Swift and SwiftUI. Mac apps can integrate iOS stuff via Catalyst. iOS apps can integrate Mac stuff for use on the Mac. And all developers can begin experimenting with SwiftUI, building new interfaces and replacing old ones in a gradual process. "And then we'll turn around sometime in the 2020s and realize that all of this talk of UIKit and AppKit and Catalyst is behind us, and that our apps are written in Swift with interfaces created using SwiftUI," Snell writes in closing. "It will have all changed due to Apple's slow and steady pace of iterative, continuous improvement. The long game never stops, and it can be hard to see that you're even in it."
As Apple completes its move from SGI (Score:1)
For a decade or more, Mac's provided "Linux/Unix with a pretty face" which made them good development or even execution platforms for tools that came from the SGI environment. These tools dominated technical fields such as modelling, finite-element analysis, fluid dynamics, image processing, ... Big markets, for the time, that kept companies afloat. Times change, and as the Mac's transition from technical to commercial/consumer platform means they cease to be relevant to the older fields. Should encoura
Boy do you have that backwards!! (Score:4, Insightful)
Times change, and as the Mac's transition from technical to commercial/consumer platform
Except it is the opposite - witness the new Mac Pro, the best PC you can buy (when it comes out). The scientific library support has never been more robust, and SwiftUI will make it way easier for scientists to construct complex visualizations rather than having to wade through a ton of API's oriented to producing consumer apps.
What is truly upon us now, is an age not of consumer apps, though that is one segment - it is the UNIX promise of small specialized executables to do specific tasks well, only now in GUI form and as easy to build as it was to build small command line utilities in C or shell scripts back in the day.
Re: Boy do you have that backwards!! (Score:2, Offtopic)
Re: (Score:1)
witness the new Mac Pro, the best PC you can buy (when it comes out).
What? Who told you that? You can already build a more pissed-off PC than that.
poor baby iFanboy got hurt by facts (Score:1)
Why do Mac lovers still get mod points? All they ever do with them is demonstrate how butt-hurt they are. It's a fact that you can already build a faster PC than the mac pro for less money, as always.
Re: (Score:3)
Re: (Score:1)
Not everyone can or wants to build their own
So they pay someone else to do it. Back when it was a hot build, I built a dual Xeon with a RAID in it so that an office full of creative people could use it for video editing. They had macs, but they wanted something cheaper to run Adobe apps on, and even paying me to assemble it for them, they got much more machine for much less money even after paying me, and I charged them pretty good money.
Swift UI is a bigger deal than it may seem. (Score:5, Insightful)
Some of you probably look at Swift UI and compare it to so many things that look a little like it that have come before...
But if you look into how it works at depth, it already has a ton of very powerful features that mean it's not just one of a thousand silly UI toys where you can slap a simple UI together but falls apart in complex cases. Indeed, complex cases are where it starts to get pretty good (although at that point the code you are looking at is no longer so super clean). You can build complex UI with complex alignment of many elements that works as perfectly as you want it to, which is pretty amazing all by itself.
I also think this approach where you have back and forth with a graphical UI builder and code is a really great approach, one that lets people come at making UI's in a way that is most natural for them - I read someone say that at long last there would be peace between those who liked to build UI in code, and those who liked a GUI builder.
Combine that with the ease of quickly testing your UI on a deal device, and I think this platform could be the thing that really gets a lot of kids into programming in a way that Swift Playgrounds was not.
It's not like everyone can start to build apps with it right away but it is a great first step and an excellent direction to drive people toward. I've not really seen anyone against it wholesale, just some who are cautious (and well they should be when things like this have come and gone before). The very large spread of people who really like this shows great potential for how quickly this will be adopted.
Re: (Score:2, Interesting)
SwiftUI is a bigger deal than it seems solely because Interface Builder is a terrible, godawful, horrible, piece of shit. And the current "storyboard" system that takes a whole bunch of XIBs and jams them into a single XML file is even worse.
SwiftUI is a big deal because at least code might be fixable when you have conflicting changes, but the weirdly opaque storyboard XML pretty much isn't. (This is because of the use of generated IDs everywhere. If you have conflicting changes that change an ID somehow, y
Re: (Score:3)
SwiftUI is a big deal because programmatically creating Apple interfaces used to be nearly impossible, because you "weren't supposed" to do that.
That was always fine, the auto-layout stuff was fully programmable and if you were "not supposed to do that" Apple wouldn't have gone to all that work of making the visual layout language stuff.
Maintaining that code sucked though.
For most people IB helped them do it right in a way they would not be doing in code... and made it lots easier to make and see the effect
Re: (Score:2)
This looks really good. I remember sitting in the IB session at WWDC98 and several of us were asking for these things. They were expected to be final by 10.3. :)
Plan B (Score:5, Interesting)
I see this as Plan B. Apple has been working for years on a way to seamlessly integrate iOS and OSX. This is one of the primary reasons they have not released any Macs (laptop or otherwise) with touchscreen hardware. Apple is years behind in the touchscreen laptop game - I have a Lenovo touchscreen laptop because it very conveniently allows me to do web development on a full computer yet test touchscreen interface very easily. The hardware is now cheap and ubiquitous, but Apple doesn't have it (even though they themselves brought the multi-touch capacitive display to mainstream with the iPhone - up to that point the only consumer touch screen devices were single-touch resistive). Why? Because Apple has been waiting to unveil the touchscreen Mac at the same time that OSX could natively run iOS apps in a seamless way. Think of that - it would be a game changer.
This is not a hardware problem. Heck, they could easily throw a A12X Bionic SOC onto the motherboard and have it handle running the iOS apps at full speed. This is purely a software problem. And, to get much more specific, it is a UI problem. Simply wrapping an iPhone app in a tall rectangular window and adding a touch screen just doesn't cut it, as any of us developers know who use the iPhone simulator while debugging on a mac.
News of this leaked back in 2017, and the project was / is called Marzipan. Here it is 2019 and the closest we're getting is a set of UI tools that *should* make it easier to transition UIs across the platforms - assuming developers choose to switch to those tools to develop their UI. That's a far cry from Apple simply bringing the existing iOS app store straight into OSX (vastly increasing the value of Macs since they would be able to run the largest, highest quality app collection in the world).
So, I see this as recognition of Apple of the failure to do this entirely at the OS level behind the scenes. They are instead creating tools (and certainly down the road, forcing migration to those tools) that place constraints upon, and control the definition of, the UI in such a way that the app can run on anything from a phone to a tablet to a laptop whether the developer wants to target such disparate platforms or not.
It is here already (Score:3)
Because Apple has been waiting to unveil the touchscreen Mac
You have apparently totally overlooked the iPadOS changes.
Re:Plan B (Score:4, Informative)
Catalyst is Marzipan.
Re: (Score:3)
Best of luck... (Score:3)
While Apple has much fewer native applications than Windows, I think they will learn what Microsoft learned in trying to unify phone, tablet and desktop UI in a single application. It just doesn't work very well. It's not a matter of a better language or framework (fin my mind, Swift and SwiftUI are not massively better or different than C# and XAML anyway). It's that different form factors have different use cases, those demand different logic, and that's where the idea of a single application just falls down.
An application to record audio on a tablet is not the same as a DAW on a workstation. Quick editing of pictures on a phone is not the same as Photoshop.
Now, I do think there is room to improve the 2 in 1 experience (Surface Pro, etc.). For example, take something like Outlook. If you are tablet mode, you probably want to find emails, not really compose them. If the UI reorganized to really optimize those use case and then flipped back, that might work. I just think the gap between a phone and a laptop is just too wide. Separate applications for a phone just makes more sense to me.
Clueless Idiot Hype (Score:1)
I've been developing applications for iOS and macOS for over a decade now. About five years ago I built an application that could run on both macOS and iOS. It was primarily designed for iOS, but later I was able to get it running on macOS without many changes at all.
It was surprisingly easy to do with a few preprocessor macros and class categories to handle the naming differences for Cocoa classes on each platform. (E.g. UIColor vs NSColor). The other thing was that the co-ordinate spaces are different for
Summary too long (Score:2)
There is very little substance in there.
SwiftUI new tech to build UI that works for both iOS and Mac, Catalyst to port iOS apps to Mac.
Why does it need to be a full page?
Apple will hold it back (Score:2)
It has to be portable between Mac/iOS/Windows/Linux. It can be, there's no technical problem. But it won't be. So as someone who resolutely refuses to be tied to a platform, I suggest Apple takes this thing and shoves it into their collective ass. I'm gonna stick with Gtk as I have for the past decade.
Re: (Score:3)
---until the worst (Score:2)
...that no one is buying Apple anymore.
Apple have been here before with Obj-C write once-run everywhere except no one wanted what SteveJobs had to sell, couldn't afford programmers skilled in Obj-C in the first place and NO ONE wanted to buy-in to the SteveJobs SANDBOX.
In the end AAPL face the SANDBOX problem. It's a real moat and iCloud is no sign they've learned how build bridges, on-ramps and hubs to synch with the rest of us in the RealWorld.
Stranding Business doesn't win new customers so a sandbox bui
Why do I care what 10% of the market does? (Score:2)
If it's not truly cross-platform (that is, to Android and/or Windows) I can't be bothered.
iOS is like 10% of the market? macOS is like 10% of the market?
I already target them just fine with react-native and various ways to bring that to desktops (electron, etc).
So, I wasn't really starving for cross-platform development tools to begin with and I'm certainly not picking up a proprietary one from a minority vendor - what a terrible business decision that would be.
Re: (Score:2)
Why would I care what an anonymous coward thinks?
But seriously, I don't make my money on app revenue. My apps are real tools for real businesses. The businesses pay, not the users.
Everyone tries to rebut with the app revenue argument but it's still a yawn for me. I'm a developer not a user. Talk to me about what percent of salaries are paid developing Android apps vs iOS apps and you have my ear.
Nothing about this is actually easier for cross-platform. They fragmented iPadOS from iOS, smooth guys, thanks. S