QEMU-iOS, an emulator for legacy Apple devices
github.comWhat’s sad about this is that without backups of the old App Store as it existed at that time, you can’t do much beyond playing with the calculator and notes apps.
Digital distribution and lock-in are a disaster for historical preservation.
> Digital distribution and lock-in are a disaster for historical preservation.
Agreed. This reality slapped me in the face quite hard after I was given an ipad 2 (circa 2011). I figured I'd use it as a couch-side device for spotify. Soon realized nothing worked on it, even with old version apps loaded. Server side shut it down.
That's partially because of web security, though, if I'm not mistaken. I have an old Windows PC and an old Mac mini that I use as servers and, outside of local stuff that's bridged to the outside network (and heavily crippled), I can't do much on them because of the changes to the TLS protocol for SSL certs. That means that the browsers won't connect to most modern servers, any apps that hardcoded instances of TSL can't connect to the internet, and, if I managed to get something to connect, it would be a huge security risk for anything on those machines.
So, if the connection is being shut down on the server side, it's likely because of the TLS version mismatch. I thought it would be a simple solution just via updated software but was told (by peeps on Reddit, so it's likely to be total nonsense) that, although it can be updated, it won't run reliably on older hardware unless that hardware can also support newer OSs. Win7 and below (?) don't support it and MS won't provide updates with it and MacOS versions before Lion don't have it. I've heard you can also update OpenSSL by breaking the symlinks to the OS's install and get it working again but that's more hassle than I cared to put in.
Also, most of those old iPads are able to be jailbroken. You can update OpenSSL on them and probably get Spotify working again.
Yes. Although I would disagree with the statement "it would be a huge security risk for anything on those machines"
Older TLS protocols have vulnerabilities yes, but most of them require a very motivated attacker with the ability to do a MITM.
I wrote a blog post about why I have decided to support older protocols, https://blog.nyman.re/2021/02/07/usability-security.html , the tl.dr. is that only allowing new TLS just means more forced obsoletion. For Banks and other sensitive things, yes it makes sense, for your personal blog, not so much.
I mean... Google still allows TLS 1.0 , if it was a "huge security risk", do you think they would?
The updating OpenSSL/breaking symlinks sounds interesting, do you have more info?
Personally I have a old iPhone 5S running iOS6 which I use for listening to podcasts. I ran in the the TLS issue there and my solution was to use a proxy https://bitbucket.org/ValdikSS/oldssl-proxy
Works well, and until maybe a year ago or I could even browse Apple's Podcast Store, but at some point that stopped working so now I'm stuck with the ones I have there.
(Cydia still works though... Thanks Saurik)
100% agree, same with online games.
I worked on a game called Minecraft Earth and it was a service-oriented game where you could collect things and play Minecraft in AR (fun project, not very fun game lol). It shut down a few years ago and we didn't get a chance to add an offline-only mode for even simple AR building, so now no one will ever be able to go back and play that game. It makes me really sad to see a whole product, a whole codebase just go poof.
You are probably not allowed to contribute to the open source private servers for Minecraft Earth and .ipa mods for people who still want to play?
https://github.com/Project-Earth-Team
ASA (which I worked on for Minecraft Earth) is also end of life in the next year, not sure how that will impact this.
> a whole codebase just go poof.
You didn't hold onto a copy?
You steal source code from your past employers?
I hear what you're saying here, but one of the ways we've been able to successfully preserve software was because, even though folks weren't supposed to keep this stuff around, they did anyway. Business goals rarely align with preservation efforts. While I do know that Microsoft does keep a vault of old software, production materials, etc (I believe they even have a position on staff for a Librarian, or at least they used to), for many other positions, that simply does not exist.
That's both a baseless accusation and a rude one at that.
Additionally, you are confusing stealing with making unauthorized copies.
It's called a rhetorical question.
Can we please stop with the mental gymnastics? Taking something without permission that doesn't belong to you is stealing. It may be justified stealing but it's still stealing.
It's not taking, though. It's copying.
Monks used to write books out by hand. If you were to go to a monastery, and copy a book line by line, you will have taken nothing at all. Nothing will be lost.
It's not taking, it's not stealing. It's just making a copy. You are the one doing gymnastics.
You're taking something that doesn't belong to you and copying it. It's stealing. In order to even make the "unauthorized copy" you mention, you have to take the thing first. That's the stealing.
There is no loss of data on either side. It's not stealing. Your argument is like saying that a picture of the Eiffel Tower is stealing.
Nothing is lost from copying.
Loss of data is irrelevant. If you don't have permission to take something or copy it, then you're stealing. Again, I think the benefits of what happened in this case are obvious so I'm not arguing the morality of this. I just think it's absolutely silly that people are bending over backwards to pretend that this isn't stealing and that the reason we have something that would have been otherwise lost is because someone had to balls to steal it.
It's stealing. You're taking something from the owner without permission. Just stop with the mental gymnastics.
It is not legally stealing whatsoever. Zero laws that cover "stealing" are applicable to copyright infringement.
No one gives a crap about your pedantry. I never said anything about "legally stealing". They took something that didn't belong to them and that they didn't have permission to give to someone else or copy. That's theft. It's stealing.
What if you already have access to it and don't need to "take" it from anywhere?
Having access to it is not the same as having permission to take it, make copies of it, or remove it or its copies from the owner.
If you're curious about emulating even older apple devices (Clickwheel iPod), I worked on an emulator for a few months called `clicky`. Very nifty project, given the weird and undocumented architecture of those early iPods
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.
As long as they're not distributing iOS or any proprietary ROMs with it then the emulator is perfectly legal.
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.
Just look at how hard Nintendo shut down any attempt at emulation.
And yet emulators of Nintendo platforms are widespread.
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.
Point 2 is a problem if you only have one MacBook but lots of things to tests. We have burnt so much cash and time on that.
> Point 2 is not remotely true
Guess you've been lucky. Congrats!
> 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.
Nope. Unless this is a very recent change which they haven't even documented yet. https://developer.apple.com/support/authentication/
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.
Where is this documented? I don't see anything about this on https://developer.apple.com/support/authentication/
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
Apple Developer Console "Account Holder" accounts have different requirements.
I have an account holder account which uses SMS 2FA - not ideal, but just fine.
2FA is a benefit for the site, not the user - I'm fine with them having a lousy and costly 2FA system.
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.
That's fair. I will say that the cost of entry has gone hugely down, relatively, over the years, though.
Some people have principles.
I wouldn't do development for a platform I have a principled stand against.
it's a balance.
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 is about the Apple Developer Console "Account Holder" account which has different requirements from a normal apple id. See https://developer.apple.com/support/authentication/
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.
Interesting, I wasn’t aware they have a separate tier for that!
Hopefully they’ll allow security keys there eventually then.
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.
How is this different to other commonly emulated devices?
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.
In practically every way. You don't run into any of this shit when developing for Android, Windows or (obviously) Linux.
> 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).
> Comparable to all curated store fronts.
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.
Those are borne of competition with the App Store (none proceed it) - and competition often undercuts by a lot.
Valve, Microsoft online, PSN are proper contemporaries.
When you think about it the Apple ecosystem is very similar to console ecosystems in general.
Heaven knows how many Xboxs and Playstations I had to buy as a game developer.
- Valve you pay 100 USD once per game
- 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.
> - Valve you pay 100 USD once per game
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.
Maybe, just maybe, the economics for publishing an AAA game are just a bit different than for small indie developers who wish to publish their apps?
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.
> AppCode from Jetbrains
is being discontinued, and won’t receive further updates.
Ah, I see.
After looking around (for literally a minute) it seems the recommendation is to use the Swift plugin with Clion which people claim "is the same".
https://www.reddit.com/r/Jetbrains/comments/zlyjuo/appcode_b...
> But ultimately every company that has a platform for software development is going to charge you:
This is why the web won, IMO.
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."
It is also not supported on any version of Firefox, for the same reasons. Here's Mozilla's "considered harmful" GitHub issue. https://github.com/mozilla/standards-positions/issues/95
PWA features could be a similar situation. They are also not a standard.
> Comparable to all curated store fronts.
Nonsense. Android is a one time fee of $25.
> 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.
Wrong again. Just use the free developer VMs: https://developer.microsoft.com/en-us/windows/downloads/virt...
> But ultimately every company that has a platform for software development is going to charge you:
Apple is the only one gouging me left and right. The others are far, far more reasonable.
> 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.
[1] xkcd.com/378
> For some reason […]
Likely because Apple themselves provide an emulator that accommodates most developers’ needs.
> 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.
Hopefully merged into the mainstream one day.