Corellium won their legal case, allowing them to rent [1] iOS Cloud VMs for security research, https://hn.algolia.com/?query=corellium
If iOS can be virtualized on Apple Silicon Macbooks, it could reduce demand for commercial iOS virtualization services.
Individuals: $400/month
Business: $60,000/year
You still gotta do hardware management yourself in other words but CI is good business!
Which isn't actually all that much, compared to the amount you pay your developers.
Still, saving cloud spend by making the build faster or using self hosted runners is probably worth it.
Many corner stores can fix a smashed iPhone screen.
https://www.theverge.com/2024/7/22/24200536/windows-xp-ipad-...
Jailbroken Apple M1 iPads with iOS16 can use the iOS hypervisor to run VMs without overheating their devices or waiting hours to boot.
Still, we can thank Apple for small mercies like UTM, ashell and iSH.
As a science experiment, Apple could silently launch a "VM store" with $100 VMs, accessible only via hidden URL. How badly do Apple customers want to use the iPad hardware they already purchased? Could Apple customers be extorted into paying for VMs? Will anyone ever ship a competitive tablet running Linux?
Except their charging cables. Apple actively trades goodwill for those margins.
VMs would be a subset of existing iOS/macOS. VMs are more uniform targets than bare-metal, less likely to crash.
Think Microsoft CAL (client access license) paper entitlements.
Or papal certificates of indulgence, https://theconversation.com/the-catholic-view-on-indulgences...
Software margins with iPad-as-DRM-dongle, investors would rejoice! Broadcom and Qualcomm would be envious.
If you wanted to debug and print out your original papercraft without remoting into another machine, that will probably be good enough.
yt-dlp on iPad via iSH is surprising useful.
Well, unless you are using JavaScript?
> [Zhuowei Zhang] concluded that (GUI) macOS applications cannot run on iOS—but (graphical) iOS apps can run on macOS. Mac Catalyst seems to work, expectedly, only one way.
To be clear, as an iPad Pro owner, I don't think "just put macOS on iPad" is the answer to the iPad's problems, either. But I can appreciate why people complain about it. Apple sold them "a computer", they want "a computer". With full iPad ports of Mac apps, a filesystem that isn't entirely built around share sheets and hope, project exports that don't demand you keep the app foregrounded because Apple can't be arsed to add a "Eat The Whole Battery" multitasking mode, multiple user profiles, third-party developer tools, third-party app distribution, and generally, the ability to innovate on the platform without Apple's prior written consent[0].
The iPad was originally announced as Apple's answer to the netbook: a cheap(ish) touch computer for casual computing tasks and games. In that narrow lane, it succeeded. But in 2015 with the introduction of the iPad Pro, Apple decided that the iPad was going to replace the Macintosh. The Mac was there to be to the iPad what the Apple Lisa was to early Macs: an annoying technical relic to bootstrap software onto the newer, superior platform. Except Apple didn't have the courage to pull the trigger on several features necessary for creative and development workflows on iPadOS until it was too late. e.g. The reason why iPadOS is built so heavily around share sheets is because, for the first six years of the iPad's life, that was the only way to share data between apps[1]. So there's a lot of old apps that do things the annoying way, a lot of roadblocks that get put up arbitrarily, and so on.
[0] More broadly, the creative economy needs to stop talking about consent. Consent is for sex, not creativity.
[1] iOS 9 (?) added support for shared containers, but AFAIK each app that wants to use the container has to opt into it; and all apps have to be published by the same corporate entity or otherwise consent to data sharing in this way. There was no way to just have files owned by the user and nonconsensually modified by other apps.
Although that is an intriguing (and controversial) possibility, Apple has never explicitly stated that. What they have done, is continued to heavily invest in the Mac lineup. IMO the ‘Pro’ in iPad Pro is meant to target creative professionals, not all the types of professionals (for e.g. programmers).
The answer is obvious to Apple iPad Pro + Magic Keyboard customers:
MOBILE MICROTASKING
Apple continues to pour billions into science experiments like Vision Pro (iPad-on-Skull) and anemic cloud services, while refusing to improve the workflows of millions of customers who are willing to pay for repackaging of existing technology already sold by Apple. Fortunately, the industry has not been standing still while Apple squandered a decade of feature-frozen tablet supremacy. Google is now shipping VMs on both phones and tablets.
> At a privately held event, Google recently demonstrated a special build of Chromium OS — code-named “ferrochrome” — running in a virtual machine on a Pixel 8. However, Chromium OS wasn’t shown running on the phone’s screen itself. Rather, it was projected to an external display, which is possible because Google recently enabled display output on its Pixel 8 series... Hopefully, Google will offer the ability to run Chrome OS alongside Android in a future device
But, in Microsoft's case, it's sort of different. They had Windows 10 Mobile for tablets which is the closest thing to iPadOS, I suppose. Windows 10 Mobile couldn't run Win32 applications, similar to how iPadOS can't run macOS applications. Microsoft killed Windows 10 Mobile...
Implementation-wise though, it's a big effort for Apple. They can't just make macOS applications runnable on iOS. Something like reverse Mac Catalyst for iPadOS wouldn't work due to how complicated and different macOS is compared to iPadOS. It would probably have to be a full on emulation of macOS on iPadOS for applications to run.
So, it would seem like starting with macOS then implementing iPadOS on-top would be better than starting with iPadOS and implementing macOS, which is literally what Mac Catalyst is. So now, Apple has to make sure that all iPadOS APIs work with Mac Catalyst (they don't yet) and they have to do something to make the UX work better when switching between touch and M&K.
Bringing it back to Microsoft and Windows now. It's quite similar actually. Think of Windows 10 Mobile = iPadOS, UWP = iPadOS apps, Win32 = macOS apps. Microsoft killed Windows 10 Mobile and replaced it with full-on Windows 10. Windows 10 can run UWP apps.
Similarly, Apple will likely have to kill iPadOS and fully implement compatibility with iPad apps on Mac for macOS to ever be on iPads.
The ability to run macOS on an iPad with a keyboard and mouse (and perhaps even a second screen), and run ipad OS when you're away from those things would be pretty great.
The hardware is already capable of this.
Microsoft has a long history of trying to make both work, but I think the reality of it is actually not that far away:
Windows 10/11 is a very poor tablet OS, a ton of stuff will be clunky with touch as it's currently just a very thin layer of adjustments on top of the OS, and expecting to get access to all the potential of the machine without a keyboard and trackpad will be a recipe for disappointment.
So, if the iPad had to rival the Surface Pro, it could probably do it tomorrow by just sticking macos on it with the accessibility options (virtual keyboard, mouse etc) and call it a day.
Where Microsoft is truely different is that they still shipped the Surface Pro and let users deal with it. The UI in tablet mode is almost the same, with just the taskbar a bit bigger. Sometimes you'll absolutely need a mouse, so if you don't have one you pull the virtual mouse, solve your situation and go back to what you were doing. Sometimes the entry field is from an obscure API and doesn't pop the keyboard, so you pop it manually and deal with it. Or you absolutely need a shortcut, so again you pop the keyboard in the middle of nowhere, hit the shortcut, and make the keyboard go away.
This is the clunkiness Microsoft has fully embraced, and it makes their tablets actually "just work" as you're given all the tools to straightly do what you want to do. That's where Apple is backing out, and chose to build a DisneyLand OS instead of a gritty, dirty and clunky, but fully functional city like environment.
I get why people want a more polished and elegant experience, but if the goal is to get things done, it's probably the most realistic way forward.
This would lose the security properties of iOS, which is a big part of the value proposition for iPhones and iPads.
> They can't just make macOS applications runnable on iOS.
Other operating systems can run in _parallel_ with iOS. Hardware support for nested virtualization has shipped on Apple Silicon since M2. Google implemented Android Virtualization Framework. There's no shortage of candidate VM operating systems. Microsoft implemented WSL (Windows Subsystem for Linux) VM. Apple could ship ASF (Apple Subsystem for FreeBSD) VMs.
Right. Apple is adding more and more security features from iOS into macOS. But, people are going to complain about that too.
> Other operating systems can run in _parallel_ with iOS
Absolutely, but there is a performance hit and memory management becomes an issue. You still need a host OS as well to unify the UX. Also, there needs to be some way for IPC between the applications of different OSes.
> Microsoft implemented WSL
WSL has networking and memory management issues. WSLg sort of works. Its architecture is wild [1]. Display scaling is terrible though. IPC between Windows and WSL guests is limited.
WSL 2 was released in 2020 and it still has issues. It's not a simple problem to solve.
Microsoft has also gone from WinRT, UWP, WinUI, MAUI, and now WinUI 3 trying to unify application development [2]. Again, it's not a simple problem to solve.
I think the only OS that has actually unified application development across all form factors is Android/Chrome OS. But, people complain about how limited Chrome OS is.
[1] https://github.com/microsoft/wslg?tab=readme-ov-file#wslg-ar...
Depending on how you use it, you have up to 3 VMs running in the background with Wayland passtrough: ARCVM (Android), Crostini (Linux dev environment) and Borealis (SteamOS).
All these VMs run Linux and Google uses MGLRU in cooperation with Chromes tab discarder to balance memory.
Google et al. has put a lot of effort into improving Linux's virtualization capabilities. Goes with being the OS of choice for pretty much all servers I suppose.
As anyone can imagine by that list, every new acronym requires a rewrite, and most folks that aren't on Microsoft pay list no longer care.
You can shit on Microsoft all you want, but those listed APIs still work. People expect Microsoft APIs to exist essentially forever, so every breaking change pretty much has to be a new API.
Having a single simple API for developing across different devices and inputs that automatically provides great UX across the board just isn't possible. It's going to be complex and it's on the developer to cater to each device. An API to cater to everything is literally web APIs.
[1] https://chromeos.dev/en/posts/io-2024#android-on-chromeos
[2] https://developer.android.com/about/versions/13/behavior-cha...
No they don't work, that is why each iteraction requires a rewrite.
WinRT for Windows 10, isn't the same as WinRT for Windows 8.1, isn't the same as WinRT for Windows 8.
WinUI 3.0 has features that are Windows 11 only, although Project Reunion promised compatibility across Windows 10 and 11, it is still quite far from Win 2.0 in features and tooling, years away in fact.
Likewise the WinRT used by WinUI 3.0 in Win32 mode, isn't the same as WinRT used by WinUI 2.0 in UWP mode. Meaning the set of underlying COM plumbing differs in behaviour and exposed set of interfaces.
And I will leave it here, as Github issues and discussions already have plenty of rant material on the matter from the Windows developer community.
What I am saying is that the older APIs are forwards compatible with newer versions of Windows. On Windows 11, you can still run applications using those old APIs.
On Android and iOS, your old app may break when running on a newer OS version.
Microsoft doesn't have the luxury of changing the behavior of older APIs on newer versions of Windows, so they end up having to make completely new ones.
Seemingly the only thing stopping those apps from running on the iPad unmodified is the operating system. I want the operating system that runs on the other Mx devices to run on my iPad Pro. I have wanted this for years. I have never been even close to alone in wanting this.
One can dream… but really, this is not all that far-fetched
https://www.cnx-software.com/2022/02/14/android-13-virtualiz...
We had that with linuxonDex or maruos or motorola or..
People say they want that, but when they actually do, it completely flops.
That feature isn't yet exposed to end-users, although the plumbing is in place. So far only on Pixel devices.
There's potential for phones docking to desktops via USB-c, running both Android and Linux/ChromeOS VMs.
Or allow Linux/FreeBSD VMs.
I have a feeling that the reason that Apple hasn't made their Simulator into an Emulator, is because they don't want folks digging into the substrate of iOS.
Slightly OT but the first iPhone ran OS X at launch.
I think as time went by and the "OS X" running on phones diverged more and more, they renamed to iPhone OS and then iOS some time later? Something like that anyway.
https://web.archive.org/web/20070112064939/http://www.apple....
EDIT: You can run a iOS apps on macOS without recompilation, but it uses Mac Catalyst which is a user-space shim for iOS apps to work on macOS. Even then, not everything works.
> Your apps use the same frameworks and infrastructure that Mac Catalyst apps use to run, but without the need to recompile for the Mac platform.
> Although you can run your iOS apps unmodified on a Mac with Apple silicon, Mac Catalyst lets you build your app specifically for macOS and customize your app’s behavior on that platform.
Mac Catalyst was a multi-year effort by Apple. Doing the same to run macOS apps on iOS would probably be even harder due to how complicated macOS is compared to iOS.
[0] https://developer.apple.com/documentation/apple-silicon/runn...
iOS applications are sandboxed by the kernel, with no opt out. macOS applications are not sandboxed by default and are opt in.
Then there are the API and UI differences.
EDIT: That linked blog post in the parent blog post also shows how different the userspace is: https://worthdoingbadly.com/macappsios/
EDIT: iPadOS 16 enables virtual memory swap [1]
[0] https://developer.apple.com/library/archive/documentation/Pe...
[1] https://www.apple.com/newsroom/2022/06/ipados-16-takes-the-v...
Not sure what you meant by that, you always could `mmap` files into memory on iOS. Back in the 32 bits days there was a ~700 MB limit due to the address space, but there aren't anymore nowadays with 64 bits. If `didReceiveMemoryWarning` is called on your app, then you need to free resident memory but the kernel will take care of dumping file-backed memory pages for you.
Probably a lot of iOS AAA apps are still in ObjC.
It is unwise to pull the rug from established developers.
1. https://www.xia0.sh/2024/03/09/Boot-Newer-iOS-with-QEMU-Step...
For everything else, like running ARM software on x86 (and vice versa), you'll have to resort to emulation, which involves either interpreting the code or dynamically recompiling it. By definition, you can emulate anything on anything else (someone recently booted Linux for MIPS on an Intel 4004, the first ever microprocessor), but the performance might be a problem.
This is also less of a QEMU problem and more just that ARM does not emulate well on x86_64 due to their designs.
ARM Linux is close to usable, however.
Only emulating the portion of the instruction set available from the userspace is another story though. At least the way Apple does it with Rosetta and Microsoft with whatever their thing is called, you don't even notice that an app is running under emulation. The only giveaway is that it takes a noticeable time to start for the first time while the code is being translated. It's truly impressive.
It seems the main obstacle is in paging where x86 4KB clashes with Apple 16KB (ARM/64 supports multiple sizes), so, 2-level paging canʼt aid and an emulator has to shadow-paging which is, definitely, much slower.
> Apple does it with Rosetta and Microsoft with whatever their thing is called, you don't even notice that an app is running under emulation.
But they still use a vendor-specific TSO support in hardware.
UTM might do what you want but likely not on x86.
> Virtualize macOS as well.
> Run multiple instances of macOS on your Apple Silicon Mac with UTM. This can be useful for developers as well as security conscious users.
> Note that macOS VM support is limited to ARM based Macs running macOS Monterey or higher.
What is ARM hardware in this case? Did you mean the T2 processor on Intel Macs?
Contrast with an emulator, where you are just running the full iOS build identical to the build on a real device. You would in theory be able to run any iOS binary unmodified and probe how the real os works.
It’s sort of like the difference between running an app through Wine versus running an app in a Windows VM, except in the case of the simulator it’d be like if you had to custom recompile/link a Windows app first against the Wine environment before being able to run it. If you wanted to study how Windows works internally, there's not much you can learn about that from running Wine, but there is quite a lot you could learn from probing a VM running Windows.
Koh Nakagawa's work on reverse engineering Rosetta 2 dives into this topic extensively: https://ffri.github.io/ProjectChampollion/part1/
One interesting side effect of this ABI difference comes from modern x64 macOS using AVX2 instructions by default but Rosetta 2 not supporting AVX2. Because Rosetta 2 uses a different ABI than native arm64, code running under Rosetta 2 can't just call into the native arm64 system libraries; for calls to system libraries, Rosetta 2 transpiles from the x64 versions of those as well, which are available on Apple Silicon Macs thanks to the universal binary architecture. In macOS, all of the commonly used system dylibs are pre-linked into a single giant file called the dyld cache. Since the native x64 dyld cache contains AVX2 instructions though, it isn't usable by Rosetta 2, so for when a system library call requires going into the dyld cache, Rosetta 2 ships with a _separate second version_ of the x64 dyld cache that is compiled without AVX2. This is an interesting quirk that has proven to be exceptionally useful for getting newer macOS versions running on older unsupported Macs that have Intel CPUs that are too old to support AVX2.