Get the top HN stories in your inbox every day.
walterbell
ravetcofx
my god, $4-$8/hr who is paying for these VMs?
rtpg
You say that but companies routinely pay projects like Circle CI similar orders of magnitudes for chunkier CI builds (one place I know having builds take 30 minutes.... with 64 shards. Basically paying like 5-10 bucks per commit)
You still gotta do hardware management yourself in other words but CI is good business!
eru
> Basically paying like 5-10 bucks per commit
Which isn't actually all that much, compared to the amount you pay your developers.
stuckkeys
Is there an alternative service that offers similar service? I am not sure if I have ever seen anything else come close to what these guys do. I recall them going into battle with apple and it looks like they had won. But it sucks that we do not have any open source solution for iOS or Android to emulate the OS for these devices.
teknolog
I remember we paid Circle CI ungodly amounts to host a dozen trash can Mac Pros to run our iOS CI. Early Swift versions caused huge spikes in build times.
saagarjha
These people: https://www.corellium.com/about#:~:text=Who%20we%20serve
e____g
No, those people are almost certainly paying far below list price.
wingerlang
Certainly not paying anyones rent, but I've paid them a couple of bucks over the years to test software on their VMs, since they can come jailbroken out of the box.
walterbell
attackers and defenders of zero day vulns in iOS black boxes
ronsor
This is cheaper than 8xH100 GPU compute time for AI.
sangnoir
This is such a left-field comparison. One H100 costs $25,000, whereas one Macbook Pro/iMac/iOS device costs roughly a tenth of that. It's not at all surprising that it's cheaper to rent something that has CapEx costs 2 orders of magnitude less than that of 8xH100 ($200k for the GPUs alone).
smcleod
You think that's a lot wait until you see what AWS charges for GPU instances...
gorkish
This is great; for your next trick, can you please figure out how to install MacOS on an iPad so that we can all finally get the dang computer we want Apple to build?
makeitdouble
You can start with Windows XP
https://www.theverge.com/2024/7/22/24200536/windows-xp-ipad-...
walterbell
> It took two and a half hours for my iPad to crawl through installation.
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?
acchow
Apple definitely does not want bad reviews on their iPads because the VMs they are selling are crashing more often than their other offerings. Any product Apple sells for actual $ would have meet Apple’s standards of support and customer service, or they would be deteriorating their Goodwill.
Except their charging cables. Apple actively trades goodwill for those margins.
tambourine_man
Without JIT, it’s more a prof-of-concept than a useful tool, IMO.
makeitdouble
With the current iPad limitations, however slow it gets, running any arbitrary code locally can be a big deal.
If you wanted to debug and print out your original papercraft without remoting into another machine, that will probably be good enough.
striking
Prior research section reads:
> [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.
miramba
Oh, 1000 times this! Literally my research subject in the last weeks, a tablet with a dev OS. Sizewise I love the iPad Mini, but iPadOS is useless. Looking now at a Surface Go: slightly too large. If anyone has another suggestion for a small tablet with Win11 (I know there is none with MacOS), please post it here. Will order from China if needed.
creole_wither
GPD Pocket 3. It has an 8" screen. It is laptop form factor but the screen can be folded 180 and flat over the keyboard for use as a tablet. Spec page says it can run Windows 11 but comes with Windows 10.
miramba
Thank you and Joeri - this is indeed the closest to what I am looking for.
ankurdhama
sgerenser
Small tablet? It has a 14” screen.
Joeri
What about the GPD Pocket?
jbverschoor
The iPad Pro is the fastest machine out there (M4)
worstspotgain
If they called it a Macbook Air with an upside-down bulge and a detachable keyboard, would that be just as well?
walterbell
With touch screen, iOS and macOS?
SheinhardtWigCo
macOS when the keyboard is attached, and iOS when it is not, with instantaneous switching.
One can dream… but really, this is not all that far-fetched
worstspotgain
Touch screen but no iOS.
guax
Or add 4g to the MacBook air and 80% of people will stop asking for MacOS iPads.
amelius
Can we please get iOS on Linux so we don't have to buy the phone to develop for it?
azinman2
What is it about the iPad you want with macOS? It has one port (which is largely used for power), no built in keyboard, an incompatible input device (touch) by default, and often smaller screens. What’s the appeal?
kmeisthax
Apple doesn't sell a MacBook with a cellular modem, drawing stylus, or 4:3 screen. Also, iPads sometimes get the newest chips first (e.g. M4)
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.
prxtl
> But in 2015 with the introduction of the iPad Pro, Apple decided that the iPad was going to replace the Macintosh.
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).
walterbell
This question has been endlessly asked and answered, https://www.theverge.com/2021/4/22/22396449/apple-ipad-pro-m...
The answer is obvious to Apple iPad Pro + Magic Keyboard customers:
MOBILE MICROTASKING
No, dear Apple, it will not compete with your precious Macbook revenue, because an iPad is not a laptop. Your customers who are pleading for un-crippled iPads will keep buying desktops and laptops. But it will be life-changing for on-demand portable anytime anywhere access to OSS code and professional apps, for last-minute edits, quick checks during video calls, testing-while-learning and countless other scenarios. iPad enables flexible computing, i.e. unlimited use cases -- and revenue! Still the only mobile device with 4:3 HiDPI screen.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
kuhsaft
As much as I would like macOS on iPads, running macOS applications on an iPad without the Magic Keyboard would suck. Windows can do it though, so it's not really an excuse.
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.
gorkish
Bingo bango. In truth they just need to allow actual apps to use the virtualization that’s already in the goddamn things. It’s maddening.
pjmlp
Ferrochrome was canceled.
Uehreka
I have an M4 iPad Pro, it beats my M1 Max MacBook Pro on a lot of benchmarks, yet I cannot use it for programming, 3D modeling or VFX. Yes, I know that apps “technically” exist to do those things. No, those apps are not professional grade. I want VS Code, a Terminal, Blender and Adobe After Effects.
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.
cedws
According to the author's GitHub profile they are a fresh CS grad - seriously impressive work.
lukeh
I imagine a job offer from Apple won't be too far away!
ttul
They had better swing this person an offer before they go to the dark side!
paulryanrogers
Apple didn't make an offer to the HomeBrew founder. So maybe don't hold your breath.
thisislife2
Why would they when Homebrew was amateurish compared to MacPorts built by Apple engineers? (For e.g. it didn't follow accepted unix conventions or macOs conventions on installing libraries for a long time. See this discussion thread https://news.ycombinator.com/item?id=34818192 and this comment https://news.ycombinator.com/item?id=34844292 for more details). But credit where credit due - the founder is a better marketer than developer and more people know about Homebrew than MacPorts.
saagarjha
Apple hired Max Howell to work for them on SPM.
valval
[flagged]
ChrisMarshallNY
Very cool!
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.
ChocolateGod
Another reason it was a Simulator and not an Emulator to begin with could be because a lot of iOS (or iPhone OS) components at the time were forks of existing Mac OS X libraries.
kridsdale1
The reason to begin with was the Mac OS was x86-32 and the iOS environment was arm. Building for intel let the ui devs have high performance by leveraging the existing network stack and graphics compositor. But most of the libraries live parallel in the sim, not using the OS ones. That wouldn’t allow you to simulate different iOS versions.
astrange
Developers still use Intel Macs, and you can't virtualize ARM iOS on that.
agsnu
The overwhelming majority use ARM Macs these days
saagarjha
Doesn’t sound like a strong enough reason for the visionOS team.
ChrisMarshallNY
Yeah, I was thinking about the ARM Macs. They are common enough, now, to make it worthwhile.
MuffinFlavored
I really do wonder now that both iPhones, Macs, and iPads are all "arm64" (Apple Silicon no less) how different the bootloaders are for iOS vs MacOS. Once you are past the bootloader, why would they be maintaining two different operating systems/lots of differences if they don't have to, especially since they seem to control the hardware?
kuhsaft
The hardware was drastically different between Macs and iPhones when iOS was released. That was in 2007. Apple only unified the hardware in 2020. Over the *13* years, the operating systems have diverged so much that unifying them is a massive effort. The linked blog post by Zhuowei Zhang shows some of the differences. The user-space components are just so different that it's not as simple as running a macOS app on iOS.
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.
azinman2
You can run iOS apps directly on M1 Macs. Some developers flip a bit to disable this, but there any many that don’t.
saagarjha
They are very similar. The differences are largely in that macOS generally will permit some things that iOS will not.
kuhsaft
They aren’t actually too similar. They both use XNU, but the memory model is completely different. On macOS memory can be paged to/from disk. On iOS it isn’t and applications must free memory when asked or be terminated [0].
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...
ChrisMarshallNY
Very different user experiences, and also, the Mac development ecosystem is well-established. I suspect a lot of Mac AAA apps are done in C++.
Probably a lot of iOS AAA apps are still in ObjC.
It is unwise to pull the rug from established developers.
pjmlp
More like Objective-C++, as otherwise it is lots of fun calling macOS APIs from C++.
And no, C++ isn't as prevalent on Apple platforms as on other vendors.
Hence why you will find out most of the C++ related documentation is for IO and Driver Kit, the Metal Shading Language dialect (based on C++14), LLVM, and that is about it.
Even Metal is actually implemented in Objective-C, with Swift and C++ bindings, and the C++ bindings are really low effort versus the Swift tooling.
hadad
the guy that create qemu-t8030 manage to get springboard running [1] , but doesn't made the code public. Is wonderful if the progress can combined with this one
hadad
Another qemu attempt is this one [1] , q22-qemu (iphone x)
1. https://www.xia0.sh/2024/03/09/Boot-Newer-iOS-with-QEMU-Step...
kuharich
Past comments: https://news.ycombinator.com/item?id=40219423
jbverschoor
Related: https://worthdoingbadly.com/hv/ (Hardware-accelerated virtual machines on jailbroken iPhone 12 / iOS 14.1)
heavyset_go
Slightly tangential, but has anyone virtualized ARM macOS on x86-64?
grishka
You can't. The term "virtualize" is generally used to mean running an OS via hardware virtualization, where your host CPU natively runs its code but forwards all I/O to a hypervisor. You can only do that with an OS built for the same CPU architecture as your host system.
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.
amarshall
TL;DR: emulating any ARM binaries on x86_64 via QEMU is so slow that it is unusable for any general use.
This is also less of a QEMU problem and more just that ARM does not emulate well on x86_64 due to their designs.
userbinator
I have tried emulating ARM Windows on x86 with QEMU. It is fast enough to see whether something works and not much more (imagine Windows 11 on a 400MHz equivalent processor to understand what the performance was like --- and the host was a fairly recent Intel i7.)
ARM Linux is close to usable, however.
amelius
Curious, does QEMU use some kind of ahead-of-time translating scheme? Or do they rewrite instructions as they see them?
aliher1911
You can try to virtualize generic ARM in qemu and see that it won't reach Raspberry Pi performance. Recent versions should have it available out of the box afaik. Virtualizing Mn cpus would be even less useful.
3abiton
You should look into the hackintosh project.
amarshall
Hackintosh currently has no way of running ARM-based macOS, so it is of no help here.
aspenmayer
fl0id
But that’s not arm on x86 is it? My understanding was that it ‘just’ enables things to work on unsupported intel macs, by enabling stuff that still works on newer Intel Macs.
MYEUHD
Apple already provides an iOS simulator in XCode. So, what's the benefit of this project over the apple-provided one?
ykl
The simulator is not actually running real iOS or the iOS build of your app. Instead, when you run an app in the simulator, your app is being compiled to the current Mac’s native instruction set and links/runs against a set of Mac frameworks and libraries that _simulate_ and in some cases only stub in the expected iOS behavior. So as an example, you can’t just take an iOS binary off of the App Store and run it in the iOS Simulator (especially not on an Intel Mac). You also can’t use the simulator to probe and learn anything about how real iOS works internally, because the simulator isn’t really running full iOS. If you drill down in the simulator’s frameworks far enough you eventually just find yourself back in macOS.
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.
lisper
Since you are someone who seems to know what they're doing I hope you'll forgive a random unrelated question: do you happen to know if it's possible to call out to M1 code inside Rosetta2? It seems like this should be possible since Rosetta2 is (supposedly) a transpiler and so it's (supposedly) really running M1 code under the hood, but I haven't been able to figure out a way to call out to native M1 code.
ykl
That's a great question. The short answer is: no, you can't, but not necessarily for the reason you might expect. The long answer is: Rosetta 2 is indeed a transpiler generating native arm64 code, but transpiled code running via Rosetta 2 vs. native arm64 code in macOS use two different ABIs. Transpiled Rosetta 2 code uses a arm64-ized version of the System V x64 ABI that contains a direct mapping between x64 and arm64 registers, whereas native arm64 code uses the standard arm64 ABI. There's a lot of magic going on in the Rosetta 2 arm64-ized System V ABI that is necessary to make Rosetta 2 work.
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.
saagarjha
This is not supported. It’s possible in theory but the theory here is “breaking out of the emulator and fiddling with runtime metadata”.
wahnfrieden
Note that that reply isn't authoritative in terms of Apple choosing or not to stray from reusing code/frameworks across macos for simulating/emulating and ios
reboot81
An early Christmas gift to all clickfarms!
jamesy0ung
Discussion of this is on the nick's funny device emporium Discord server. https://discord.com/invite/4HXCHWhf6r
Get the top HN stories in your inbox every day.
> Corellium and their virtual iPhone cloud product (only publicly-available “complete” solution)
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.
[1] https://support.corellium.com/subscriptions/pricing