In June of this year, at WWDC, Craig Federigi artistically and with examples spoke about something very important. Thanks to what Twitter returned to macOS, and Jira and Asphalt appeared. But the most important thing about the cause of these miracles was not said.
So that no one doubts the importance and value of this reason, macOS 10.15 arranged a brutal and ruthless sweep. 32-bit applications went under the knife, with which they did not dare to finally part for many years, applications without the author’s signature (by which, in which case, the author will be easily and quickly calculated). The victims of this monstrous act of vandalism, until their very last day, were in demand, many of them were unique, there was nothing to replace them with. An area of increased demand has formed. And now you need to satisfy this demand as quickly and efficiently as possible. Weren’t they in a hurry? Suddenly, this “catalyst”, regularly accelerating the creation of Mac’ov applications in test tubes in Apple laboratories, or under the supervision of its experts, in the real world will turn into a “zilch”?
How did the creation of Catalyst begin?
Have they exaggerated their achievement? People who create software and those who organize and manage think differently. In the late 80s, a lack of understanding of this difference in thinking literally destroyed the planned success of NeXT. What this company could offer, with proper application, promised real competitive advantages. Brilliantly, by personal example (and Steve is still a manager, not a programmer), he inspired the audience: the libraries and development tools from NeXT are simple, effective, and the time for developing programs is reduced significantly. They believed him. Those who make decisions have a misconception about what they saw. When specialists tried to convince them, they did not believe anyone. Programmers are lazy people, managers are reinsurers, all bad. Result: deadlines for the implementation of projects were set unrealistic (because in NeXTSTEP everything is developed faster at times), without preliminary staff training (because everything is simple and clear, there is no need to learn), and even with overstated requirements. Naturally, this did not work, project after project ended in nothing. Disappointment, accusing Jobs and NeXT of cheating and cheating.
Craig Federigi courageously stepped on the same rake. To turn an iPad application into a real Mac application, you need to check the “Mac” checkbox in Xcode, in the project’s configurator. And that’s almost all. The transformation does not end there, something else needs to be done in the project, but all this will take a maximum of several days. And even a few hours. Everything is easy and simple. Here are some examples (Twitter, Jira, Asphalt). Give it a try! This is easy!
In the summer of 2018, something similar was already said. Several iPhone apps (News and something else), somehow magically, were ported to macOS Mojave. To be honest, they were not impressive. Mentioned Marzipan technology. Something similar was already done at Apple in the early 10’s, but for some reason the project was closed. And now – Catalyst. Catalyst. A substance that itself does not participate in a chemical reaction, but accelerates it many times. The presentation by Craig Federigi was, as always, brilliant and exciting. Immediately, all Apple representatives available for communication began to ask the same question: “is it a merger of iOS and macOS?” – to which everyone answered “no”. Yeah, the journalists decided, that means a merger. I don’t think so. And in any case, even if it were a merger,
How to port an application from iPad to Mac
If you omit the details and greatly simplify everything, all current Apple systems are very similar. What does not deal with the user interface is almost the same in them. We will call this part by the name of the main library included in this part: Foundation. On macOS, AppKit is the user interface; on iOS and iPadOS, UIKit. The physical principles of the interfaces are significantly different. In Mojave, as part of a project codenamed Marzipan, an unusual library with the familiar name UIKit appeared next to AppKit. For consumers (program source files), it almost matched one-on-one with UIKit from iOS. But its filling, as close to the original as possible, imitated UIKit using macOS, that is, AppKit.
The application resulting from catalysis works like this: since most of its source code is written for iPadOS, the interface part of the program interacts with UIKit / macOS, which acts as a smart simultaneous translator. AppKit interacts with macOS itself. At the level of the flowchart, it is simple and elegant, in reality, everything is more complicated. Translating instructions from a real iPad application into instructions for macOS might not be ideal. The Foundation block (which was not even shown on the flowchart) is almost identical on macOS and iPadOS. Nearly. In addition to Foundation and UIKit, other libraries are used in the real application, not all of which are supported on macOS. In the source code, everything that tries to use these libraries needs to be isolated. And, perhaps, this part of the application functionality needs to be implemented by some workarounds. I.e,
Even a superficial acquaintance with Catalyst is enough to correctly answer the question about the merger. This is not a merger. This is another way to create macOS apps, nothing more. Currently, such applications have to pass checks in two App Store. First, in the iOS App Store (iPadOS App Store, as far as I know, has not yet appeared), the basis for catalysis should be an iPad application that meets Apple requirements. And then – in the Mac App Store. Troublesome? It seems that Apple plans to organize a separate App Store for the “catalytic” applications (to be honest, I can’t imagine how a special App Store can be inserted into this scheme – I look forward to it). Turning macOS apps into iPadOS apps isn’t even considered.
