The day they provide this, is the day they are clearly signalling the end of macos.
So the "end of macos" is unlikely in my book.
It's unfortunately not even as useful as it sounds but it is a start. I'm still at the early stages of setting it up for real work.
If you're able to do all your work on Android or the web, it would work. But for me there's still a ton of Windows and Mac software I need to get the job done. The other problem is DeX doesn't really work in a laptop form yet, and I like to do work from cafes a lot.
Maybe this year's WWDC will show us something closer to that.
I'm holding out hope for this, since they "added" mouse support to iPadOS in 2019. There has to be a reason for that plus Universal apps, plus SwiftUI, right?
2. You don't need AirPlay, you could drive a monitor and keyboard/mouse directly, using an HDMI/USB dongle. But yes, as you said, software is the hold up. The rest is ready.
Most people who need a desktop OS, want a desktop or notebook that performs faster than a smartphone. Otherwise they can just get an iPad or low end laptop and it won't set you back much more than keyboard + mouse + display. Cloud sync takes care of the rest.
https://www.macrumors.com/2018/11/01/2018-ipad-pro-benchmark...
Then, plug tablet to monitor and “type/write” on the tablet.
Unless someone were to come out with some kind of massive productivity gain by switching input types, people aren't going to switch and these supplemental technologies will never get built.
When I write code, I don’t need to type fast. However, I like to layout things quickly: proper indentation, docstrings, spacing, order/position of functions.
I think those can be solved.
I could live without a keyboard.
Your phone and to some extent tablet are limited screen estate with the finger as the primary method of interaction.
Your desktop is nearly unlimited screen estate with high precision input methods (mouse and keyboard).
The "just different UIs" mean "entirely different UIs tailored to specific interactions and completely changing behaviour of an app in all but the simplest cases"
I’m sure you could do this with Linux now, it’s just such a niche use case nobody has mass produced it.
Let's say, you started editing a document on your phone. You then put it in a dock. Now what? The separate desktop OS starts, and?...
And you edit the document in a desktop UI now.
Apple already has this feature (moving data and open files and apps and such from mobile to desktop transparently), called Continuity.
So a phone in dock would have to run two OSes in parallel, and the apps in both OSes would have to run and support continuity-like hand-off.
When I can edit a freaking PowerPoint presentation on an iPhone (in a pinch - I wouldn't want to do it all day), then I have to think it's not only possible, but already done.
Email is probably the best example. Every major email app is on multiple platforms, and I'd be very surprised if most of the code is not already the same among platforms except for the UI.
So I'd submit that it is a solved problem.
I'm not sure that's necessarily true. Are you aware of Mac Catalyst?
https://developer.apple.com/mac-catalyst/
(Of course, the user experience will always be somewhat different on a small phone screen compared to a big Mac screen. But that doesn't mean you can't build an app that works well on both from one code base. And certainly an iPad app is not all that different from a Mac app.).
And I am familiar with Catalyst. I think Catalyst is a good example of how software suffers in a K/M-oriented environment when it came from a touch environment without many modifications. Even the Apple-developed apps have too many controls and views designed for tactile screens. The Catalyst development team is introducing UI elements that make more sense in macOS, like a compact calendar picker to replace the touch-style picker wheel, but it’s going to take a long time before a Catalyst app lets a developer quickly make a macOS version that feels designed for macOS, and again, there is a need for that native macOS feel because quality touch UI interfaces are slow and difficult to use on a laptop or desktop.
... and hope that Apple reinvents user input on mobile.
A little Soli for advanced gestures:
A selfie keyboard?
https://www.cnet.com/news/samsungs-selfietype-creates-a-magi...
Better voice commands. For example, why can’t I say “build app”
“Rename function foo to bar“
However, we should also expect to see PC use pushed into more advanced and specialized territory on our most powerful and versatile devices as phones and tablets assume more traditional PC work. That specialized use will advance as fast as the most attuned interface for that platform (keyboard+mouse) and the others will necessarily lag behind.
I rename things dozens of times a day. Saying "rename function A to B" dozens of times a day is unviable on desktop and is nearly unusable on the phone. And this is a fundamentally different UI.
Sure they can, just not on the same screen sizes/input methods.
You could have Excel that looks like iOS Excel when opened in the iPhone that automatically turns into Excel that looks like macOS Excel when the iPhone is connected to a larger screen with a mouse and everything.
In the process you'll also get to reuse large parts of both UI code, and almost all of the non-UI code.
And if you've started from scratch, it would be even easier to find ways to reuse more UI code -- e.g. components could come in "auto-dual" versions that adapt.
Could you explain to me how can you trivially combine two apps?
> In the process you'll also get to reuse large parts of both UI code, and almost all of the non-UI code.
Yes to the non-UI code. Hard no to the UI code.
You will need to design a completely different set of interactions, components, layouts etc. for the mobile version compared to the desktop version.
You already have the UI code for mobile and desktop. All you need to do is switch to one or the other when the user connects/disconnects an external monitor.
At the most basic, you could just save the spreadsheet state (staying with the Excel used as an example), and load in the background and switch to show the desktop version of the app with it pre-loaded. Same way as if the user manually saved their spreadsheet, closed the mobile version of the app, and opened the same spreadsheet with the desktop version - but more transparently.
Between this and "sharing UI" there is a big spectrum. If you already have the mobile and desktop version, and the backend is more or less the same (as can be the case with apps like Excel for macOS and iOS), then compared to the work you've already done its trivial to add an intelligent way to switch from one UI to the other keeping all the other state (working spreadsheet, clipboard, current executing action, etc).
>You will need to design a completely different set of interactions, components, layouts etc. for the mobile version compared to the desktop version.
Not necessarily. A sphreadsheet cell is a sphreadsheet cell. Whether you click on it with touch or the mouse pointer doesn't matter. You could easily share the same underlying widget (and e.g. just show more of them). The formula editor that appears can similarly be shared. Other forms might need some extra padding, or some widgets to become larger or smaller etc.
We already have apps that run the same in iOS and macOS, through Apple's translation layer + layout constraints and switches on widgets. The "Voice Memos" apps is basically the exact same thing between iOS and Mac.
There's no "just switch". I wish people stopped hand-waving at complex technical problems with "just"s and "all you need"s.
What you're saying is: "you have two completely different UIs with completely different modes of interactions, completely different layouts, affordances, a myriad other things. 'All you have to do' is ship them together and switch them on the fly".
> then compared to the work you've already done its trivial to add an intelligent way to switch from one UI to the other
It is not "trivial"
> A sphreadsheet cell is a sphreadsheet cell. Whether you click on it with touch or the mouse pointer doesn't matter.
It does matter. Because interactions are completely different. Just for the most trivial example: once you've selected a cell, you can immediately start typing you can immediately start typing when you're on a desktop. On a mobile device you have to do an additional tap (double tap in Excel) or tap a different area (entry box in Google Sheets) on the screen to start typing. And that's just one interaction. There are hundreds of other interactions which will be different.
> We already have apps that run the same in iOS and macOS, through Apple's translation layer + layout constraints and switches on widgets.
Yes, and almost all of them fail in the most basic ways on the desktop: they provide incorrect widgets (dates for example), they break user input, they handle focus incorrectly, they don't have keyboard shortcuts, they use interaction patterns that are alien to the desktop and so on and so forth.
Let's take a look at "voice memos":
- No shortcut to delete a Voice Memo, but a slide-to-reveal Delete button. Alien to desktop
- Esc doesn't work to exit editing screen or recording screens
- Cmd+W quits the app which is against the HIG
- Once search input has focus, you can't Tab out of it (but you can Shift-Tab)
- In the editing screen the Crop Button is inside window chrome which is against HIG if I'm not mistaken.
Yes, this app runs "the same on iOS and MacOS", and that's precisely the problem: it shouldn't run "the same". It must be different because the desktop is different.
And note: this is a first-party app with next to zero functionality: a few buttons, a screen that shows one thing at a time. That's it. And it already is filled with inconsistencies and bad behaviour on the desktop. It will only be much, much worse for any app with more complex functionality (unless developers take conscious and specific steps to address this).
Also see, "Catalyst and Cohesion" [1]
[1] https://wormsandviruses.com/2019/12/catalyst-and-cohesion/
Well, and I wish you've read my whole comment before the BS about hand-waving. I explicitly describe what I mean.
>What you're saying is: "you have two completely different UIs with completely different modes of interactions, completely different layouts, affordances, a myriad other things. 'All you have to do' is ship them together and switch them on the fly".
Yes. Nothing particularly special about it. You could do just that: it's technically feasible (trivial even), and it would still be an adequate experience.
>It is not "trivial"
Well, agree to disagree. I've done it for apps and it's nothing much. What would be trivial for you, just flipping a compiler flag or changing 10 lines of code? Well, you ain't gonna get that.
>It does matter. Because interactions are completely different. Just for the most trivial example: once you've selected a cell, you can immediately start typing you can immediately start typing when you're on a desktop. On a mobile device you have to do an additional tap (double tap in Excel) or tap a different area (entry box in Google Sheets) on the screen to start typing.
That's a bogus difference. If the mobile device is connected to an external BT keyboard, you can already "just start typing".
Even if that wasn't the case, 99% of the widget is the same. The fact that to get the virtual keyboard to show up cell focus on mobile is not enough, is a negligible difference (not to mention it will probably not even touch the cell widget code, but be in another part of the UI dispatch, even handle directly by the framework).
>Yes, and almost all of them fail in the most basic ways on the desktop
And they are still perfectly operable, and people (including me) use them every day. So there's that.
Sorry, but I’m missing something in you comment.
Interactive workflows also differ between UIs.
Since so much of an OS is the native UI and the first-party applications, even if the mobile, tablet and PC versions of an OS share some libraries, they can’t really share enough to meaningfully call them one OS without compromising the experience on all three.
So while there may be three pane email on the iPad as well as Mac, and email on iOS, they don’t really share enough to be called the same app, and if they did, at least one of them would suffer. And some of the interactions on the macOS version effectively can’t be brought over.
I included EndNote only because there’s deep integration in Pages.
iOS is still much lighter weight than MacOS, uses less memory, doesn’t have swap, optimized for battery use, and optimized more for security than flexibility.
It’s powerful enough. The UI isn’t that big of an issue.
All of the advantages of an iPad go away - you get Windows 2-1.
iOS is optimized to consume as little power and memory as possible.
Yes. But no reason we need "unlimited processes" to use iOS for development and other stuff.
A few processes with a hard limit would be doable...
I also need to be able to launch a web browser or Postman to debug interactively. I personally hate developing on a laptop with no external monitors (preferably two). I would definitely hate trying to do that with iOS’s simplistic multi app/multi window support.
Also, while the Files app is okay for one off documents and sharing between apps. How would that work in a development scenario?
You would also need to allow apps to communicate with each other over TCP/IP locally.
Now you’re back to a multi window GUI (making iOS more complex) and apps having random access to the file system (less secure).
If you want an iPad to behave like a laptop - why not just buy a laptop? Alternatively, if you want a laptop with the power of MacOS and the power/performance capabilities of ARM, wouldn’t it make more sense for Apple to port MacOS and create ARM laptops?
The iPad is so light, I have no trouble throwing one in my laptop bag along with my laptop and syncing files between apps on both using cloud storage.
It has to be opt-in because otherwise legacy processes would break, but it is definitely present.
Or are you believing the same 10+ year old conspiracy theory that Apple plans to make it mandatory for apps to be installed from the Mac App Store?
Also Windows 10X is just another failed gimped version of Windows that is suppose to make Windows run better on tablets and low power devices.
MSIX is what is driving Windows 10X security, which coincidently is the future of Windows package management.
Signed drivers have been a requirement for Windows forever. Apple is actually late to the game.
It’s also well understood that from a security and stability standpoint that moving drivers into user space was preferable.
Sandboxing restricts what your app can do and you have to use entitlements to use certain features.
But no, notarization is not “required” and as an end user you can ctrl-click the first time you run an app to bypass it.