A problem or limitation with the platform unification.

[sosumilee]

So Apple announced that Apple Silicon Mac will have an unified platform that they can use both iOS and iPadOS apps on AS Mac without any modification. This is a great news but there are few things that we have to concern because Apple is not clearly clariying.

1. iOS/iPadOS apps to Mac, but what about the opposite?
This has not been proved at all and I really don't think most x86 based software ported to AS Mac wont gonna work on iOS and iPadOS devices. Which means dont expect both Final Cut Pro and Logic Pro on iPad. Even both Photoshop and Illustrator have totally different UI and design compared to x86 and I dont think that's the main purpose of platform unification.

2. RAM size for iOS and iPadOS
This is one of the reason why Mac software wont gonna work properly on iPad or iPhone. 6GB is seriously isn't enough and the graphic itself also consumes RAM storage since Apple Silicons are using the unifiied memory so you will have less than 6GB if you start using Photoshop or Illustrator. Btw, Illustrator's minimum RAM size is 8GB. If you were thinking to work with pro apps from Mac with iPad, then Apple need to increase the amount of RAM or otherwise, the unifieid platform wont gonna work.

3. You still need to make an app or software separately just for Mac.
Because of different spec requirements and UI, I really dont think most software like Adobe wont gonna work with the platform unification. For gaming, it's still possible to play PC or console games on iPhone or iPad because you can use a console controller despite the graphic quality. Nintendo Switch is an ARM based console and it has 4GB of RAM so it's still possible but not for pro softwares. But if one app, all platforms dont work, then what's the benefit for Mac users?

Well, just a personal research but so far, these are my concerns. Any thoughts?

 

[jdb8167]

1. None of the macOS libraries exist on the iPad Pro. Apple would need to port them to iPadOS. If they were going to support macOS apps on iPadOS they would probably do something similar to what Google & Microsoft are doing with Chromebooks. MacOS would be added as a virtual machine and not completely native. That way Apple could virtualize the macOS kernel and map onto existing iPadOS. Probably still a lot of work but less than if they just wanted to port AppKit to iPadOS. There is a big problem though, the A12(X/Z) doesn't support virtualization. So Apple would need to add new hardware virtualization instructions and a hypervisor to iPadOS. At the same time, they could add more RAM to make it more feasible.

Having said all this, Apple probably wouldn't do any of this except under extreme pressure from competition. That competition doesn't currently exist. So I wouldn't get my hopes up.

2. RAM size on iPad Pro is 6 GB. That would probably be minimally enough to run individual apps but without virtualization, I don't see Apple even starting down the road (see above). So current RAM wouldn't matter, Apple would design the hardware to work.

3. Apple is doing a lot of work to make iPadOS & macOS applications easier to port between platforms. They have Mac-Catalyst which does a lot of the work for moving your iPadOS application to macOS while adding macOS specific features that don't exist on the iPad. And then there is SwiftUI which is an alternate way of making Mac, iPad and iOS apps that retain a lot of cross platform compatibility automatically.

All of these are shipping but they are works in progress. In a few years, the technologies will be more refined and it is likely we'll see a lot more cross platform applications.

 

[leman]

"Platform unification" is not about running same apps on all platforms but about underlaying logic unification. Platforms are still different, have different capabilities and will require different code paths to be utilized properly. But with them running on the compatible hardware means that sharing your code between Apple platforms becomes much easier AND transferring runtime data between platforms becomes much easier as well — this will enable more advanced application of technologies such as Handoff.

Taking Photoshop for example, Abode will need to maintain only one software base for iPad and macOS. They will still have to write two different front-ends, but the unrelating logic will be the same. It definitely saves time and effort necessary for testing etc.

 

[Andropov]

Taking Photoshop for example, Abode will need to maintain only one software base for iPad and macOS. They will still have to write two different front-ends, but the unrelating logic will be the same. It definitely saves time and effort necessary for testing etc.

Adobe's case will be interesting. They ported (badly) some of their apps to iPadOS with a very limited UI, so they now have an incomplete iOS version (which must be somewhat modern or it wouldn't run on iOS) along with a dinosaur app on macOS full of legacy design choices but still much more capable than the iOS version.

I think the smart move would be building a fully-functional iPadOS for both iPadOS and macOS but I don't think they will.

 

[Krevnik]

Adobe's case will be interesting. They ported (badly) some of their apps to iPadOS with a very limited UI, so they now have an incomplete iOS version (which must be somewhat modern or it wouldn't run on iOS) along with a dinosaur app on macOS full of legacy design choices but still much more capable than the iOS version.

I’d bet money that the iOS version of their apps run quite a bit of that “dinosaur app” code, with things like plugin support/etc ifdef’d out. When compatibility matters, budgets can push you to reuse existing legacy code, rather than attempting to start fresh. Validating that your new stuff behaves the same as the old stuff is expensive.

I quote some info below that Office is sharing their Mac/iOS code base from 6 years ago. More recent information from the same engineer says that Win, Android, iOS and Mac are now all being built from the same code base. I’d just have to track down that other link again from one of my other posts.

So I’d be surprised if Adobe, who is in a very similar situation, would have gone the rewrite route.

1. None of the macOS libraries exist on the iPad Pro.

Not true. Most of the Apple-provided libraries are shared between iOS/iPadOS and macOS. However, AppKit and UIKit behave pretty differently, and can suck down a lot of your time working on rewriting your user interface layer, and adapting it for each. Legacy code can also be costly if it doesn’t have good separation between the UI and the rest of the logic.

But beyond AppKit vs UIKit... the underlying frameworks are the same on both platforms when it makes sense, which is the vast majority of the time. The exception there are things like ARKit, Core NFC, Car Play, and so on. And these days, there are more iOS frameworks that don’t exist on macOS because of the Mac not having these technologies/features, than vice versa.

This is from 6 years ago, BTW:

In an April 8 Reddit AMA (ask me anything) session, Erik Schwiebert, an Office for Mac software engineer, revealed how Microsoft's work on the iPad apps is now helping bring the Mac version closer to release. "The code for Office for iPad and Office for Mac is shared, as the development platforms for both are very similar," he wrote.

 

[guzhogi]

However, AppKit and UIKit behave pretty differently, and can suck down a lot of your time working on rewriting your user interface layer, and adapting it for each. Legacy code can also be costly if it doesn’t have good separation between the UI and the rest of the logic.

But beyond AppKit vs UIKit... the underlying frameworks are the same on both platforms when it makes sense, which is the vast majority of the time.

Isn't that why Apple introduced SwiftUI? Basically to replace both Appkit & UIKit? One framework to use with both Macs & iPads?

 

[sosumilee]

"Platform unification" is not about running same apps on all platforms but about underlaying logic unification. Platforms are still different, have different capabilities and will require different code paths to be utilized properly. But with them running on the compatible hardware means that sharing your code between Apple platforms becomes much easier AND transferring runtime data between platforms becomes much easier as well — this will enable more advanced application of technologies such as Handoff.

Taking Photoshop for example, Abode will need to maintain only one software base for iPad and macOS. They will still have to write two different front-ends, but the unrelating logic will be the same. It definitely saves time and effort necessary for testing etc.

Then what about iPhone app on iPad? They still dont support a landscape mode with iPhone apps.

 

[leman]

Isn't that why Apple introduced SwiftUI? Basically to replace both Appkit & UIKit? One framework to use with both Macs & iPads?

Even with SwiftUI you will still need to write separate interfaces for different platforms in order to have best apps. But it definitely makes the job easier (of course, it also makes the job harder in some other regards, SwiftUI is still VERY magical).

 

[Krevnik]

Isn't that why Apple introduced SwiftUI? Basically to replace both Appkit & UIKit? One framework to use with both Macs & iPads?

That’s certainly part of it, but devs can’t just jump over to it. It will be a process. Especially since devs like Adobe and Microsoft are very likely using Objective-C, not Swift.

C++ in particular is easier to bridge with Obj-C. So these sort of legacy apps need to bridge via C instead of C++, and convert their existing Obj-C code to Swift before they could take advantage of SwiftUI.

Even with SwiftUI you will still need to write separate interfaces for different platforms in order to have best apps. But it definitely makes the job easier (of course, it also makes the job harder in some other regards, SwiftUI is still VERY magical).

Agreed. Being able to write against a single UI interface will help. And it is something I’ve been ramping up on with my personal projects, even if I can’t use it for paid work yet.

SwiftUI is still building itself out. There’s a surprising amount of stuff you can’t do from SwiftUI that you have to drop down to UIKit or AppKit to handle.

NSCollectionView/UICollectionView couldn’t be recreated in SwiftUI until iOS 14 & Big Sur for example. Yet it’s super common in Apple’s interfaces. IIRC, they still don’t have any way to enable more advanced swipe menus like you see in Mail. Just delete. So you have to drop down to UIKit with a custom UITableView to do that.

But WidgetKit is SwiftUI-only, so it is clear that SwiftUI is intended to be the future. It isn’t quite here yet, IMO. It’ll be years before I’d recommend more complex projects adopt it. We have to wait for these gaps to be filled, and then wait for users to be on the OS versions that have the fixes.