Samsung Dex is this. I can dock my phone and get a desktop experience. I have Visual Studio Code running now (though code-server[1]) and Ubuntu userland (via Termux/Andronix). Plus all other Android apps running in detached windows.
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.
It's definitely responsive enough; performance is not the problem. It is software availability that the biggest problem -- Android doesn't even really have a decent desktop-class text editor. But email, web browsing, games, etc is all fine; I can multitask all these things in a Dex desktop.
I used DeX (the non-Linux version) while my main laptop was in for repairs, and it got me through. There were even positive surprises, like discovering it supported external hard drives and some of my pro audio gear. I could connect my Focusrite Scarlett USB audio interface which is connected to my JBL 305P studio speakers.
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.
Current iPhone has the power to do so, and can connect via ApplePlay and bluetooth. So the only holdup is software.
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.
Maybe they plan to support it for iPadOS devices and either no support or stripped down for iPhone. It’d be cool if we at one point had desktop power in our pockets though. (Yes I know we do to some extent, but it’s still a bit of a stretch for a daily driver.)
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.
Smartphones are probably pretty close to being powerful enough for 80% of desktop use cases. Having one device that can dock to a "laptop" shell and give me a full screen desktop OS would be amazing.
Why? Writing is much slower than typing and less accurate to boot. There are also a lot of problems to solve for a variant input which have long been settled with keyboard. For example code completion, jumping to the definition, showing errors where they keyboard focus is, etc.
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.
I often typo and get corrections from the text editor I used, when I write not-code text.
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.
The problem is that the "just" is an unsolvable problem.
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"
All of this is true, but with processing power and disk space increasing, you could envision a world where a phone simply has a copy of a desktop OS that it could boot into for docking, like a Mac with a Windows partition.
I’m sure you could do this with Linux now, it’s just such a niche use case nobody has mass produced it.
If MSFT can make Excel run on my iPhone, then I have a lot of hope.
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.
I believe you misunderstood. The issue is not whether software can be ported to a touch platform. It is that keyboard/mouse-oriented UI and ergonomics and a touch-oriented UI and ergonomics cannot successfully co-exist. It’s not a programming challenge.
(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.).
Again, you are thinking of porting a touch app to a non-touch device when the issue is that good touch and non-touch UI and ergonomics cannot co-exist on the same device.
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.
Voice certainly seems like a viable solution to some of that. In some ways it’s imminent if the accessibility improvements pushed to iOS, iPadOS and macOS are advanced just a bit further.
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.
All of this won't solve the mobile/desktop dichotomy.
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.
>Again, you are thinking of porting a touch app to a non-touch device when the issue is that good touch and non-touch UI and ergonomics cannot co-exist on the same device.
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.
Since you have both of those apps already, you can trivially combine them.
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?
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.
> You already have the UI code for mobile and desktop. All you need to do is switch to one or the other
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).
>There's no "just switch". I wish people stopped hand-waving at complex technical problems with "just"s and "all you need"s.
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.
Basically, it’s really hard to actually develop totally separate UIs in the same app, e.g. another user brought up the Catalyst project, which is bringing poor-fit touch paradigms into macOS despite the developers’ intentions in many cases. One paradigm will be dominant. Care must also be taken to not load too many unused resources.
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.
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.
Modern desktop operating systems don’t limit the number of processes actually running. iOS limits the type of apps that can run in the background and will kill a process that uses to much cpu or RAM.
iOS is optimized to consume as little power and memory as possible.
For me personally to do any type of development, I either need a constant network connection or the ability to run my stack locally including databases and Redis.
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.
I happen to have good guesses reading between the lines, and it quite obvious where required notarization, user space drivers, application entitlements and iOSification of macOS are heading to.
MSIX is what is driving Windows 10X security, which coincidently is the future of Windows package management.
Application entitlements were required shortly after the Mac store launched - over 10 years ago and only for App Store apps. If Apple wants everything to be App Store only, they really are taking their sweet time.
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.
Well, first there is a difference between “notarization” and “sandboxing”. Notarization just requires you to have your app signed, is a completely automated process, and in no way restricts what your app does.
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.
Doubtful, there's still a wide difference between MacOS and iPadOS, if anything they've diverged more in recent years. The multitasking workflow on iPadOS is flux, and has complexity issues.
