This is cool. For some reason Apple devices are particularly poorly represented in emulators when compared to other systems. The emulators do exist, and recently we've seen better options for the Macs from the 80s and 90s, but they are generally not as feature rich or well supported.
Pretty sure the "some reason" is just legal reasons. Afaik, Apple does not allow Apple software to be virtualized on non-Apple hardware. So while it may be technically possible, it may be legally questionable.
In my head, when I saw this post, I instantly thought "Time to Apple legal action.... 3, 2, 1...". But maybe I'm wrong or things have changed.
Many modern emulators need a BIOS-like ROM/flash image to even boot up; the situation is much less clear there, since these usually contain software and can accordingly be copyrighted.
Some emulators solve this by providing their own (re)implementation, but that’s not always easy.
And even when it’s “just” iOS: That is copyrighted too! So it’s the same problem – either there needs to be an iOS ABI-compatible OS, or it’s probably not possible to emulate any application legally, unfortunately.
You are correct on all points of course. My main point was that unlike projects that distribute those components there's really no grounds for Apple to DMCA down the emulator's GitHub repo itself.
Agreed, unless Apple wants to make some Oracle v. Google-like claim on that iOS or firmware reimplementation violating their copyright, or maybe the emulator being capable at circumventing their FairPlay DRM for apps…?
I really hope I’m wrong about this, but I feel like between this and iMessage, Apple might lean on DMCA before too long to protect their walled garden.
That's exactly who I was thinking of. I'm really hoping for some precedent to be set here at some point – right now there's a large amount of FUD looming over many emulation projects.
Doing this is a huge amount of engineering work. Things like the usb controller, modem, audio, touch sensor, and many many more are often custom hardware without any specs available that you somehow need to simulate. That's not even getting into the display tech. And these things change with each new hardware iteration. In the OP repo, there appear to be 25 of these things that the author had to reverse engineer an emulate. And that's for 15 year old hardware. Things like usb controllers require thousands of lines of dense C code. Then you have all of the CPU extensions leveraged by iPhones that generally have poor/nonexistent emulation support. This type of emulation/rehosting is a notoriously hard problem even for simpler devices like routers. Modern game emulators typically move up the stack and intercept high-level graphics etc APIs because emulating all of the hardware would be a ton of work (and doing so in performantly would be impossible). The simulator that comes with xcode works in a similar way. But by doing this, you lose a lot of the capabilities that you might want from an emulated device (kernel/driver debugging, etc).
There is a reason that Corellium can charge so much for SASS access to recent-model emulated iPhones.
Apple's whole deal is that you either submit to their lock in, or you gtfo. The only way to make an ios app is to:
1) Spend $100 a year for the privilege of being allowed to access their app store
2) Buy several $1000 iPhones (you'll be expected to test on every model they currently support by app store reviewers)
3) Buy one $2000 macbook per developer that needs to work on the iOS app (build tooling only runs on macos)
4) Good luck if you want to integrate this with your CI! Either another mac mini ($1000) or a subscription to some service that does it for you. Forget about using your linux boxes that you use for everything else. Apple says no!
5) Everyone who needs to log in to the apple developer portal also needs an iDevice. Apple is so secure they only support their own proprietary second factor push messages to iDevices!
You can see why they don't allow emulators or virtual machines. Think of the sweet, sweet $$$ they'd be losing out on!
Point 2 is not remotely true. I’ve been doing iOS development for almost a decade and have only ever tested against my phone (which is usually not the latest model) and an iOS device that represents the oldest thing the app supports. For testing everything in between the excellent iOS Simulator (which is far more usable than the equivalent in Android Studio) is adequate.
For development these days you can find a used/refurb M1 Air or mini that will do the job just fine for less than half the stated price.
As for 2FA they support FIDO keys and passkeys just fine.
Wtf?? The iOS Simulator is a joke, it doesn't remotely reproduce a real iOS Device. The permissions work differently and the graphics of it are very different too - profiling has to be on a real device!
You can load images that represent Android devices in the Android Simulator and reproduce bugs that exist on the device.
I work with both and the Android simulation allows you to go further - which is good since the diversity of devices is bigger.
Both still sucks in the end and you should test on a real device. This is particularly painful because usually the devices you don't use frequently you simply don't charge, so you kinda want to prepare to charge the devices before. You can still plug and run the app while charging but it may give a throttled experience - which when profiling games may slight alter the results (a flashdrive read bottleneck may disappear when comparing to CPU one).
Still, there‘s _usually_ no need to test an app on more than 1-2 physical devices. If it were a requirement to test an app on every device, then Android developers would be quite screwed.
Some exceptions exist, like medical apps or apps that rely a lot on continuous operation (I recently worked on an OBD app that allows drivers to gather their trip data, and it needed to continuously run in the background - you wouldn’t believe how hard Android manufacturers make this).
Medical apps are true high requirements yes - specially when interacting with other devices. But also games, depending on what you are doing, you definitely want to be testing on multiple devices, specifically if you are pushing the hardware in some way performance wise. When building game engines you will also be getting different reports with different qualities from other developers, and having real devices really speeds up reproducing issues.
I’ve had no trouble with Simulator, but the run down battery bit is indeed a problem. It’d be nice if one could get ahold of versions of phones/tablets that have a dummy battery that presents itself as fully charged when plugged in. No point in burning through lithium cycles on test devices.
A version that would run without batteries would be super sweet! I understand such dev-kit for phones/tablets may not benefit from economy of scale and may be expensive but it would be nice to have the option. They could be built to be stackable, so you put them in a furniture or maybe even in a rack of devices. But once you are developing for phones and tablets and you have one device on each system version, different sizes and all, it gets really boring getting each of the drawer and charging and testing and all. Once in a while I see some offer of a platform that has these things remotely accessible through as a service, but it's not the same as having the devices available for real touch.
> For development these days you can find a used/refurb M1 Air or mini that will do the job just fine for less than half the stated price.
Okay? So you still need to buy an extra general purpose computer just to be able to build for a phone? And this is somehow okay because you can "just" buy a refurbished one?
> As for 2FA they support FIDO keys and passkeys just fine.
The only reason App Review will ever mention testing against specific devices is when there’s been a screen resolution or form factor change, but simulators work fine for that. I’ve worked with multiple apps with many different reviewers across several such changes and they do not care if you have physical hardware to test against.
Xcode, etc are heavily reliant on macOS and would not be easy to port. Xcode itself is Swift+ObjC+AppKit and the simulators just run the iOS userland atop the shared bits between iOS and macOS. This means that a port entails porting all of AppKit or starting a whole new “Xcode for other platforms” codebase to run parallel with original Xcode as well as writing a full on iOS virtualizer for other platforms. Possible, but expensive with questionable ROI.
Apple definitely supports FIDO keys because I’ve been using YubiKeys to log into my developer account for a while now.
> The only reason App Review will ever mention testing against specific devices is when there’s been a screen resolution or form factor change, but simulators work fine for that. I’ve worked with multiple apps with many different reviewers across several such changes and they do not care if you have physical hardware to test against.
This is not my experience. We've had reviewers say "app doesn't work well on new (phone model)". When asking for clarification we were told we had to test on a real device. At that point you can either give in, or try getting more info out of the reviewer which is like pulling teeth and will take weeks.
> Xcode, etc are heavily reliant on macOS and would not be easy to port. Xcode itself is Swift+ObjC+AppKit and the simulators just run the iOS userland atop the shared bits between iOS and macOS. This means that a port entails porting all of AppKit or starting a whole new “Xcode for other platforms” codebase to run parallel with original Xcode as well as writing a full on iOS virtualizer for other platforms. Possible, but expensive with questionable ROI.
Okay, and? The entire point is that they're a greedy bigcorp and want money, so yeah. Of course they'll make everyone else bend over backwards so they can rake in the cash.
> Apple definitely supports FIDO keys because I’ve been using YubiKeys to log into my developer account for a while now.
Can you do this without ever associating an iDevice? I can't check because I've sadly already done so and would need to spend $$$ again on a new account, which I don't feel like doing just to prove a point. Please keep in mind this is about an "Account Holder" Apple Developer Account.
IME “doesn’t work well on X device” means “the app’s controls are spilling out of the safe area into notches, etc causing usability issues”.
Here’s documentation on FIDO keys with Apple IDs. Association requires at least a Mac, after which they can be used to sign on with any modern browser. iDevices don’t seem necessary. https://support.apple.com/en-us/HT213154
Are you really a developer if you're not swimming in computers? Maybe it takes putting a few years into the industry before the disposable income is high enough to make regular computing device purchases relatively painless, but...
This perspective reeks of privilege and is extremely (North) America-centric. Developers in other countries do not make enough to afford regular purchases of $1000+ devices painlessly.
let's create a hypothetical to explore : you create an app that helps victims of crime to find support structures in which to help them with whatever situations arise. The app gains momentum, and becomes successful.
Is it more ethical to avoid a platform based on principals if it then excludes a vulnerable audience from participating that you seek to empower?
it's not all as easy as "I'm a moral person, so i'm going to do this." in the real world.
It’s easy to have principles when you can just be strict when it’s about what someone else is doing and be loose when it’s about what you’re doing yourself.
That’s not a balance, it’s just hollow grandstanding.
You're right. I have always avoided Microsoft products on principle. (Until Github and ChatGPT, unfortunately.) Ever since “embrace, extend, extinguish”, and having to fix my family's Windows machines (which I vehemently advised against purchasing) while using Macs since 1984.
> Apple is so secure they only support their own proprietary second factor push messages to iDevices!
Don’t they support SMS 2FA as well? They do for my dev Apple ID that’s not logged in on any other device at least, and I see the option as a fallback on my personal ID too.
Last time I tried this was only an option after setting up the apple 2FA. So you still need the iDevice even if you don't plan on actually using it. eWaste at its finest!
I really don’t think that’s true. Apple sells music, movies and subscriptions on platforms other than their own (iTunes for Windows, Apple TV and Music for Android etc.), and these require Apple IDs as well.
I dislike many aspects of Apple’s service offerings, but not being able to log in on non-Apple devices was never one of them.
This page now claims that you need a "trusted device" or a "trusted phone number". If true, this is different from how it was in the past. Sadly I have no way to check, since I'm not paying another $100 to sign up with a new account just to prove a point.
For point 5, I don't think it's true. We have team members that can login to app store connect without any iDevice. I also regularly login from non-macs.
I agree with your other points. The lock-in, especially for CI, is terrible.
Other commonly emulated devices are not "general purpose" computers like phones, tablets and laptops. There is no need to emulate those systems generally since they can be ran in a VM (Linux, Android (mostly), and Windows).
I know your main point is comparing to consoles and that is probably fair to some extent, but still, I wanted to mention these.
> 1) Spend $100 a year for the privilege of being allowed to access their app store
Doesn't it require $100 a year to compile an app and install it on your own phone (because even hobby apps require signing)? I can't fathom why so-called "hackers" put up with this. I suspect because $
No, you can build and install for yourself. Self-signed apps last 7 days before they need to be re-signed. If you have a Developer Account your signed app lasts 1 year before re-signing.
People have even made it (generally) easy to re-sign IPAs; see tooling like https://sideloadly.io/.
In the interest of balance, since it's pretty easy to pile on when you think you're punching up:
> 1) Spend $100 a year for the privilege of being allowed to access their app store
Comparable to all curated store fronts.
> 2) Buy several $1000 iPhones (you'll be expected to test on every model they currently support by app store reviewers)
Not different than supporting any commodity device. You should have target devices for every variation you intentionally support.
> 3) Buy one $2000 macbook per developer that needs to work on the iOS app (build tooling only runs on macos)
That's not true, both the macbook line but also in general. I have worked in places that use VM's on MacMinis for iOS development, but there's also AppCode from Jetbrains.
> 4) Good luck if you want to integrate this with your CI! Either another mac mini ($1000) or a subscription to some service that does it for you. Forget about using your linux boxes that you use for everything else. Apple says no!
Mac Mini for CI, yes, if you're doing it as above then it's an additional VM on your MacMini.
> 5) Everyone who needs to log in to the apple developer portal also needs an iDevice. Apple is so secure they only support their own proprietary second factor push messages to iDevices!
That's not true, I use Linux to log in to my developer portal with the root account.
> You can see why they don't allow emulators or virtual machines.
They allow VMs and Emulators, they just require that it's official hardware.
If you are categorically opposed to owning any apple devices then I can see why you would feel a certain way.
To put it in perspective: I genuinely despise Windows, yet I need to spend a lot of money because making Windows software on any other platform is practically impossible, and "running a VM" isn't going to help because you must still license that VM.
The major differentiator here of course is that the license cost for the OS is part of the hardware cost in the Apple ecosystem and not separated out.
But ultimately every company that has a platform for software development is going to charge you:
A) Access to that platform
B) For the tools required to build on that platform in addition.
I recommend everyone votes with their wallet. (and they do, just in favour of the App Store, because it is significantly more lucrative to lean in and buy a pile of mac minis and a developer license agreement than to lose sales by not being apart of it.)
You could look at this as Win/Win or Lose/Lose depending, almost entirely, on your willingness to let Apple also profit from your work. (again: likening it to my experience with Windows).
Both the Microsoft Store and the Play Store require a single payment of ~25$. Publishing on the Amazon AppStore is free. I couldn't find any price information for Huawei AppGallery.
Apple is the only store that requires a recurring payment, and it's the single most expensive one.
- Xbox depends on how you manage to sell your thing to them, it can even be free
- Nintendo you also don't pay to be in, but the dev kit is 400 USD (unless this changed recently), you can dev in any machine
In the end math is still showing the Apple as the most expensive platform to develop for - I don't have information on PSN as I never did anything for it.
The Steam Direct Product Submission Fee (while refundable after you get $1,000 in sales, of which Valve will charge 30%); is only one of the fees you must pay. For example I have had to pay for additional beta codes and if you do not charge anything for your game but you get a lot of downloads then you risk getting into bad terms with Valve. (who, while darlings to gamers are pretty aggressive bullies to game developers).
> - Nintendo you also don't pay to be in, but the dev kit is 400 USD (unless this changed recently), you can dev in any machine
Nintendo is actually a little bit of an outlier, as they really want to promote indy games (not even requiring a business address!). One caveat though is that they really want you to show your project before granting you permission to buy a dev kit, so you need to make a PC game before you make a switch game.. which is weird.
> - Xbox depends on how you manage to sell your thing to them, it can even be free
My €70,000 p.a recurring fee for XBox dev kits in Ubisoft begs to differ.
Regardless; the economics are the same. If it's too much money then nobody would pay it, so there's clearly a value.
Apple aren't forcing you to use their devices, people want to because there's a large pool of people to sell to.
There are historical reasons for needing a dev machine on those stores. Apple really do not need it, you are probably right that they copied the bad stuff. The Android and Apple stores are contemporary though, they have different philosophy it is not all about competition.
And it's also why Apple is the only one to not implement standards such as the Web Bluetooth API. If you want to work with a bluetooth device you will have to submit to the apple app store.
Web Bluetooth is not a standard and is not on track to ever become a standard, e.g. "This specification was published by the Web Bluetooth Community Group. It is not a W3C Standard nor is it on the W3C Standards Track."
> Not different than supporting any commodity device. You should have target devices for every variation you intentionally support.
Android has convenient cross platform emulators. Apple insists you give them tons of money every time they release a new iDevice :-)
There is absolutely no reason to buy a physical device just to make sure your app renders correctly at some new resolution.
> That's not true, both the macbook line but also in general. I have worked in places that use VM's on MacMinis for iOS development
Please show me how to legally run MacOS in a VM on Linux while abiding by Apple's Terms of Service?
I'm currently (unfortunately) running CI on a Mac Mini and it is the most fickle system I have ever used. Needs manual intervention pretty much every month.
> but there's also AppCode from Jetbrains.
How do I use this to build an ipa file and upload it to Apple, without running on an iDevice?
> Mac Mini for CI, yes, if you're doing it as above then it's an additional VM on your MacMini.
How to run on linux like literally everything else does?
> That's not true, I use Linux to log in to my developer portal with the root account.
That means you have an iPhone for receiving the 2FA push message. Good luck logging in without any iDevices.
> They allow VMs and Emulators, they just require that it's official hardware.
Completely useless.
> If you are categorically opposed to owning any apple devices then I can see why you would feel a certain way.
I'm opposed to being gouged by a bigcorp, while I'm providing value for them. Android manages just fine, all you need is a Windows/MacOS/Linux laptop with the emulator. Completely free until you want to publish, at which point it's a one time fee of $25 instead of a yearly fee of $100.
I'm also opposed to needing a mac computer just to be allowed to publish for ios
You also won't constantly get screwed over by "reviewers" who spend 2 minutes looking at your app before complaining about something their collegue said was ok previously.
Need to push a critical bugfix? Not allowed unless you also fix these random unrelated "issues" that were fine the past 3 years!
> yet I need to spend a lot of money because making Windows software on any other platform is practically impossible
Cross compilation for windows is easier than it has ever been. It's not even possible for iDevices.
> isn't going to help because you must still license that VM.
> Android has convenient cross platform emulators. Apple insists you give them tons of money every time they release a new iDevice :-)
I've worked in places that do dual platform development, and Android has always been the one that needs a ton of testing devices just to achieve a minimally-acceptable testing coverage (and we would still end up with more issues in the wild, than on iOS)
[EDIT] Maybe this is a solo dev versus team thing? Solo dev tests on their Pixel, pokes around in the emulator for other OS versions, looks fine, submits to Google, Google accepts. App has issues on a couple major Samsung phones (their goddamn OS customizations, OMG) and maybe a major Chinese brand or two, but the App Store accepted it, so that's that to the developer.
They try to do the same with Apple and a single phone and get it thrown back with "this is broken on other models of phone" and perceive that Apple's a harder/more-expensive target to test for.
Meanwhile, a team supporting multiple popular apps has developed a kind of scar-tissue that results in a 10-device Apple test drawer and an 80-device Android closet, resulting in the opposite perception.
That list is a bit disingenuous as the mosts expensived points apply to every platforms: you'll need a PC to develop software for Windows, you'll need a computer too even for building Linux apps as manipulating bits using butterflies is quite inconvenient[1]. One might even use a Mac already, so it's not an additional cost in all situations. In the same vein physical devices are also mandatory for developing quality Android applications. Sure the 99$/year is annoying for hobbyists but it's not that of an expense for any business.
> For some reason Apple devices are particularly poorly represented in emulators when compared to other systems
Must be all that lockdown they do. Which is a damn shame, as some early iOS games and whatnot were actually really cool and no longer exist in a runnable form except on those devices (and that is assuming you already had them installed!)
> For some reason Apple devices are particularly poorly represented in emulators when compared to other systems.
Well, what would you use one for? Apple provides emulators for current iOS versions and the centralised App Store means versions of iOS apps for old OS versions aren’t readily available the way they are for Windows etc. Beyond maybe testing old versions of Safari it’s more of a historical curiosity than something with real use.
It’s kind of weird, given the number of user hours spent on, say, iOS 6 era Instagram, that we have no way of replicating the experience today.
