It would be a potentially smart move by Apple to allow installing other OSs in iOS hardware. The market share grab part of this segment is mostly gone so they probably wouldn't lose much and it would help with their arguments about the App Store and other iOS restrictions. They could say that in iOS those are the rules but if you want to do something else with the device you own you can install something else. It might even win them some customers. They would win my business if I could install an open-source OS under my control on a phone like I do on my laptop. LineageOS is not even close unfortunately because of poor hardware support.
That doesn't really match up with the ethos of Apple or why people buy their products though, so it doesn't make any sense for Apple to allow or endorse this.
Correct, it doesn't make a profit for Apple to sell devices, rather than just renting them. That's why it shouldn't be up to Apple to decide whether a device sold belongs to the buyer, or still belongs to Apple. If I buy it, it is mine, and I have the moral right to put whatever OS I what to on it, regardless of Apple's ethos.
"Correct, it doesn't make a profit for Apple to sell devices, rather than just renting them."
I've seen this argument again, but this is a redefinition of sell vs rent.
Apple sells the device with specific capabilities. You might want it to have others, but that's not the same as renting. If you don't like it, buy something else.
You do get to do "whatever you want" with the device AS provided. You can stomp on it, melt in in a fire, or whatever, and Apple wont ask you for the device back. That's a sale.
"I wanted another version of the device, one that is unlocked, and Apple doesn't sell me one" doesn't mean Apple doesn't sell you what it says on the tin.
They're selling iPhones, locks and all, not generic devices to have different OSes loaded.
I think it's more akin to selling a coffeemaker that only works with manufacturer authorized coffee beans. It's a coffeemaker and it may not produce the same quality coffee with other beans but it's perfectly capable of producing coffee from any beans you feed it.
That said, Apple has no incentive to work towards enabling this. Both Apple's profit and customer's expectation are in the vertical integration that Apple provides.
(I'm not in anyway saying iOS is not restrictive or that they shouldn't do it. It's just that there's no pressing reason for them to work towards achieving it.)
What's more, they have a pressing reason to not do it. The entire iOS devices ecosystem brings clients exclusively to the AppStore and its apps. They also have a network effect for purchasing more simply for device/OS interoperability (think iPhone + Watch). By allowing the installation of a general purpose OS they are giving up a chunk of the profit from those apps and they cut down their own user base, thus making the ecosystem slightly less valuable as a whole.
One option would be to allow the installation of an alternative OS only after the device is out of support at least for an image win but this might not justify the effort.
I hope this gets regulated in the future so manufacturers are forced to remove any locks preventing the installation of 3rd party software (even make resources available for developers) the moment they stop providing "adequate" support.
> I hope this gets regulated in the future so manufacturers are forced to remove any locks preventing the installation of 3rd party software (even make resources available for developers) the moment they stop providing "adequate" support.
I would personally prefer one step further and force to remove all locks if the customer asks it, it's their device, they are free to do whatever they want with it, it's both the right approach morally but also for environmental issues.
> I would personally prefer one step further and force to remove all locks if the customer asks it
They could but it would cost more than most users bargained for. Most likely a manufacturer would offer you the open device for the price of the device plus the expected loss of value from connected services (maybe something on top just for good measure), or a locked "subsidized" version that can or has to run only as we see today, and that will cost as much as one does now. And they could easily make a case for this even in court.
But once the support ends it's more or less implicit that the manufacturer abandoned the device and no longer expects profit (or expenses) related to it and keeping it locked is a harder case to make.
And I get a manufacturer's desire to profit from their own devices. But once they abandon them I see no other reasonable legal or moral claim a manufacturer can make. They should issue a final update that removes any protections, and make all relevant drivers and documentation freely available (or even for a modest one time fee) even if this means some binary blobs and a bunch of docs for how to interface with them.
I'm not sure if the reference was intentional, but there are (or, were?) coffeemakers that only work with manufacturer authorized coffee beans. Keurig infamously added a protection mechanism that required "special" coffee-pods to function.
This was, however, seen as outrageous, unlike the current state of smartphones, for better or for worse.
It is. At work some of us got a reusable pod to reduce waste. We were closely following it. It was also much easier to explain why that's bad to my non-engineer coworkers than explaining why iOS's complete lockdown is bad or even get them to care.
It is outrageous in a very literal sense. The whole reason people are mad is because they know that Keurig is allowed to do it and have basically zero power to make them stop.
I agree -- I meant it in contrast with smartphones, where it's seen as totally normal to have no escape hatch to run your own software.
Most "normal" people see that a coffeemaker putting "DRM" on your coffee is ridiculous, but that outrage never really extended to digital devices for some reason.
Ignorance. If people had no real idea how coffee was made either, you wouldn't see much outcry over locked-down coffee pods either. "You want to grind your own beans? What an eccentric nerd! My coffee maker works perfectly with the manufacturer pods, why would I ever switch?"
You can't if it's stuck in "Activation Lock" and you can't logon to the Apple ID. I have one of these situations. A perfectly good device is effectively bricked.
That means that they've lost both the iCloud (Apple ID) account AND the device password...
Well, at some point, they device might as well be bricked.
Otherwise device theft would be much higher (since they could use it, whereas now they can't), plus of course if lost/stolen people would have access to the data.
This is a good feature but normal users are getting locked out constantly. IMO a good middle ground is if you forget your password or lose access, you can start the process of a factory reset which triggers notifications to your apple account and your email telling you to cancel it if the device was legitimately lost or stolen but if nothing happens after a week your device gets reset.
Personally I know of 5 mobile devices which have been bricked by this security feature and I do not know anyone who has had anything actually stolen (including things like wallets with no protection).
Also to note that there is no proving ownership to get around the lock. You either have the password to log in or it’s bricked. You can go to apple or google with proof of purchase and they will not / can not unlock the device.
>Well last time I got angry down votes for saying this. But you are really renting if apple can lock you out.
Only in the same way that you're "only renting" a safelock if you can lock it and are not able to open it (e.g. by forgetting the lock, or having some key inside).
>My non technical wife managed to lock herself out of her device and icloud with no recourse as I didn't preserve the reciept.
That's a security feature. If there was a recourse then locking the device (when you're done using it for the moment) would be security theater.
Please don't misread. This is not about who can read the encrypted drive. It is more basic than that.
Apple locked us out of device we paid for. We just wanted to use it again completely wiping it off. Random Harry working for Apple can do that but we as legitimate owners can't.
So with respect to owning vs renting argument, How I am owning the device?
The problem here is that if you want to modify those aforementioned locks, you will be subject to legal persecution. Companies like Apple have been lobbying to enact laws that makes device circumvention illegal. That is the problem.
Yep and people buying Office and Windows in the 90s were absolutely fine with what Microsoft was doing back then. Most OEMs selling computers with Windows on it were also fine with agreeing to not also sell Linux PCs.
Everything was going well for Microsoft until it wasn't.
Apple's iPhone has a 90% market share among youths in the US and a 50% market share of active devices in the general market. Their general market share in the US isn't going to be shrinking anytime soon. As they get more and more popular, the rules will change for them.
It's not correct to say that Apple doesn't make a profit on devices.
In fact, Apple makes a robust profit on every mobile device they sell.
This is in contrast to, e.g, gaming consoles, which are (at least were) sold below cost, with the profit coming from games.
Apple also won't stop you from installing whatever on your gizmo, legally I mean. With mobile, they do several things which make it pointlessly difficult, and I would rather they didn't.
Commoditize your complement. That's what Google is doing with Android itself - flooding the market with a gaggle of surveillance-ready web browsers. But Apple could push back at an even deeper level by supporting user-loaded OS's, taking the Free community's focus away from the Android ecosystem.
The limited hardware combinations alone would be a boon to the Free community. Right now, I see Android as the Freer option, even though I've gone significantly out of my way to get there (Samsung Exynos + microG + fdroid). If I could do a similar amount of work on mainstream Apple hardware and end up with an OS that had no Google remnants, I can see my perspective changing quite readily.
Perhaps we'll see such a development when there emerges a Free OS that's a viable/cult-popular daily driver.
I'm not really sure how it would damage them though. Normal customers buy an iphone and it comes with the locked down ios as normal, now you just let people who know what they are doing mess around.
We can see from android, letting people install custom ROMs didn't really have any effect on the average user who will never try it. The hurdle of having to factory reset your phone to unlock the bootloader keeps normal people away.
I think Apple would have to publish "proprietary" hardware information to make this possible. Currently, people spend significant amounts of time reverse engineering the hardware to get software working with it.
On top of that, there's a cost of open sourcing besides revealing proprietary information--you generally need to audit and cleanup your code base (cleanup commit messages, code comments, etc) that could be, at best, embarrassing, or, at worse, reveal product flaws/bugs
I realized recently that Google Pixels are one of the only models of phones that supports flashing a 3rd party bootloader. I immediately bought a used Pixel 2 and I'm never buying a Samsung phone again for this sole reason.
This feature is a big deal because you need to do it in order to install Frida, which is a very useful reverse engineering tool. There are alternative ways to get frida running, but they are less convenient
I can guarantee that this will never happen as the whole point of Apple products is the hardware and software working seamlessly together - for the most part anyway.
That's a tough guarantee to make. Apple has already been putting in in some effort on their M1 macs to ensure that other operating systems can be booted, without compromising their bootloader's security. https://mobile.twitter.com/marcan42/status/13331260180689551...
While I don't think it's likely, it would be _possible_ for Apple to open this up on the phone side too
For each iOS device sold Apple can profit from selling services (iCloud sub, App Store, Music, TV+ etc) so allowing something like that would only result in loosing customers.
The customers Apple can win are those willing to buy a brand new $1K+ iPhone, switch OS and void (at least part of) the warranty. If they are not supporting a Bootcamp for Android probably is because they did the math and it was not worth it.
Apples old hardware isn't all that closed - most models have enough exploits it's very possible to get your own low level code running.
The key issue is that hardware drivers aren't there, and that requires a massive amount of reverse engineering work.
Apple could release documentation for the hardware, making things easier, but from apples point of view that opens them up to patent litigation (you can be sure trolls will scour the documentation for evidence of violated patents), and most internal documentation isn't of sufficient quality to release without at least someone reading it all over and removing swearwords...
Collecting the documentation together will be hard - it is probably scattered amongst hundreds of git repos, wikis, documents, spreadsheets, photos of whiteboards, on some engineers laptop, and mixed in with code and secrets.
Even then, without a lot of people putting a lot of effort in, you wouldn't see desktop linux running...
Overall, I can see why Apple doesn't help these guys - the disadvantages outweigh the advantages.
> Apples old hardware isn't all that closed - most models have enough exploits it's very possible to get your own low level code running.
This might be semantics, but the fact that unlocking the bootloader or running code with the highest level of privilege on an iPhone requires exploits in the first place is a pretty big sign that these platforms are pretty closed. Checkra1n is very nice but this is an oversight that Apple is unlikely to make again (the only way Checkra1n was found in the first place was Apple fixing the underlying issue on Apple A12 devices anyway).
Unfortunately I think the existence of Apple's Security Researcher Device program squashes any hopes that Apple would consider opening up store bought devices any further. The only real way I see Apple opening iDevices if some regulation to that effect would be enforced, but I don't see that happening any time soon either.
May be it would be possible to rip kernel with drivers from iOS image and run custom user software over it. It should be very close to UNIX anyway. People want to run userspace software, not just Linux kernel.
> The key issue is that hardware drivers aren't there, and that requires a massive amount of reverse engineering work.
I know Apple drops open source blobs for iOS. Do the kernels not include drivers? Especially as Apple takes over more of the BOM through vertical integration, there's less stuff they would need to suppress because of contracts (but of course that doesn't mean they do include other things).
It would also decimate their trustworthiness; how would anyone trust a secondhand iphone if it can be compromised like that? Could it be done in pure software, opening it up for malware?
I mean I get why one would want unrestricted access to hardware, custom software, etc, but at the same time I understand the resistance to allowing it. In Apple's case, security is really high up in their priorities.
Hence why GP said "after a fuse is blown". The implication is some sort of irreversible, hardware-based mechanism that would disable the security measures while making it abundantly clear that it had done so, so someone would know if the device had been tampered with.
To be fair, what’s stopping someone from blowing the fuse and putting on some “fake” (patched) software claiming it’s not blown? (Asking hypothetically here; I doubt anyone would, but it would be a “valid” concern for Apple)
Most hardware vendors that implement this sort of functionality add prominent warnings to the lowest level boot screens notifying the user the device is "unlocked" or in "dev mode" or some such. The idea is that the absolute lowest levels of firmware remain signed and controlled, while giving the option of loading unsigned code on top.
So in theory, you get the best of both worlds. I don't think there's anything really stopping Apple from doing this, but as many others have said, it's not really their jam ;)
I can easily see someone claiming that Apple keeping anything signed and controlled isn’t going far enough. Is there any data on how many people believe it should be “all the way”?
The Pixel devices do this well. If it doesn't trust the OS the bootloader shows a big scary warning. If the OS is signed by Google then it boots up without the warning.
So when you got your second hand device you just need to check the bootloader while booting. If it warns then you need to flash a stock iamge.
Not just Pixel, but most Android devices (both my previous Xiaomi and my current Samsung devices does this). I think it is probably part of Android CTS.
It just shows that this is possible, but we are talking about Apple here.
Right, and I'm saying that secondary market would have very few participants beyond those who already buy used phones today. Apple wouldn't even notice.
By all available stats, Macs are only used by about 25% of programmers. Windows is 50% and Linux is 25%.
This developer has purchased a (used) Macbook Pro but only touches it to build into iOS-land. The rest of my time is spent on Linux where I'm in charge and where I can get proper basic facilities like sane window and file management without the hassle.
ymmv but I have found development on a high spec'd ubuntu machine vs macos to be a much less irksome experience. For most of my developers hardware is the biggest constraint, not the os.
I am excited to start evaluating the m* macs once they get docker sorted though.
I don't work from an office or use a mouse, external monitor, or keyboard, so I've found the reverse is true: out of the box Ubuntu hardware comes in broken or flimsy packages.
I had a fellow dev whose camera was below the screen, so when we'd videoconference I'd be pointed at his chest, for example.
Every time he'd plug in his headphones and then unplug them his microphone would stop working.
It was death by a thousand cuts. Tiny inconveniences that stack up.
Although speaking of cuts, I'll admit I sliced my finger open (on the exhaust vent) when pulling my 2018 MBP out of my laptop bag. Talk about inconvenient design flaws. And yet, here I am recommending them. That's how good the other stuff is in comparison.
At this point, they should just be forced to allow the software to be replaced without waiting for someone to find an exploit. To be clear, I'm not talking about backdoors or something like that, just exactly the same as a laptop: if I want to install a new OS, I should be able to if I want to.
Just yesterday I have been wondering what it would take to run inside iOS userspace the API (and vm) environment AOSP is providing to apps. Isn't Microsoft working on something similar for Windows as a host? Clearly it would be the biggest violation of the "no language interpreters in iOS!" rule ever, but given the incredible decline of non-phablet Android the i12 mini is just so very attractive... and I'd rather bet on a userspace API container on top of the vendor OS than replicate the customary experienced of Android custom ROMs on devices with even less hardware support/documentation than usual.
People have done it with Linux; exposing the rest of Android is not out of the question. (The main issue here will be performance, since there isn’t much support for anything but interpretation.)
Oh, right, a JIT (or a client-side AOT) would require permissions for writing to self in an executable way that aren't available to native (but third-party) iOS apps, right? Not even if you compile the runtime with your own xcode for your own device. Easy to forget about that when you are used to a garden with marginally lower walls (I'm not pretending that stock android is the complete opposite, just marginally less locked)
In some cases that can't give sufficient performance or functionality. Sideloading of native apps within a secure sandbox as on Android would be an improvement.
Thanks! So I'm guessing the issue might be that Android mandates 4kb page sizes whilst the A10 CPU has a minimum of 16kb. Whilst Ubuntu and other standard distros don't care?
A lot of software breaks when you're not running 4kb pages. I run a POWER9 desktop, and the default page size is 64kb. A lot of ... interesting problems manifest.
Some filesystems like Btrfs and XFS (iirc) have elements that are page size dependent, and can only be opened on systems with the same page size as the one that made them.
Some stuff like Wine (and windows in general AFAIK) assumes 4k "alignment" and doesn't like it when it differs)
Of course, on P9 you can just change the page size to 4k and be done with it. Apple appears to have only implemented 16KB pages and nothing else, presumably to minimize silicon cost/maximize performance (?)
> Apple appears to have only implemented 16KB pages and nothing else, presumably to minimize silicon cost/maximize performance
I think it is because, due to quirks of the interaction of virtual address resolutions with cache addressing, it allows Apple to use a larger L1 cache.
Indeed, I've got a Blackbird board in a micro-ATX tower as my main bedroom computer. Got it a couple years back to replace the bulky secondhand rackmounts I'd been using as build hosts/hypervisors/fileservers etc.
I appreciate the open platform and documentation behind it -- the OpenPOWER people publish a lot of detailed technical docs, and all the source code is available, with everything down to the FPGAs controlling power-up easily modifiable, without having to reverse-engineer all the bits like cough other platforms.
It's just a shame it started off expensive and has gotten even more so the past couple of years. I suppose it's just what happens when you're producing such complex boards at such a tiny scale, and for such a niche audience.
No the page size on Windows is 4kb, however some things like file mapping do require 64kb alignment, due to ancient compatibility concerns with DEC Alpha.
I think the language they used is misleading. It's more likely Android has introduced some bugs from assuming page sizes are always 4kb.
"Whilst Ubuntu and other standard distros don't care?"
Many of the various different architectures Linux runs on have page sizes that aren't 4kb. It's typically defined in a constant called "PAGE_SHIFT" in the arch/<ARCH>/include/asm/page.h file for the architecture.
> Is that swap space? I assumed these devices didn't use swap.
That would have surprised me, and indeed they write [0]
> After a cheerful pre-boot 'Hello, world!' hand-coded in start-up code assembly, we ran into the first one: it turned out that the processor cores don't merely support 16kB pages, but they actually require them. The Linux kernel, however, took this in stride, and as soon as we switched the page size configuration option, it was happy to run.
That quotation doesn't mention swap (AKA the page file), only pages in general. Virtual memory is always divided into pages. Each of those individual pages can be backed by physical memory, the page file, or indeed other files (e.g. for memory-mapped I/O).
Sounds cool. This could be a way to put older devices to use for some of the things (certainly not all) that a Raspberry Pi is used for. The lack of any physical ports for expansion is a big drawback, but the processors are a lot more capable than typical SBCs (single board computers).
Older phones definitely beat Raspberry Pis on both price and features. For barely the same price as a Pi + a decent SD card you get the equivalent of a Pi + a touchscreen, internal NAND, mobile networking, GPS, sound (speaker & mic), a battery backup with built-in charging circuitry and accelerometer/gyroscope sensors.
You could get all that with the usb port. I have certainly tried plugging a USB OTG cable in to a usb to ethernet cable in to a pixel phone and it actually worked and had a special icon for ether net
USB-C would actually give you USB3 speeds which is more than enough for Gigabit Ethernet. I remember connecting an Android phone to a gigabit connection via a USB-C to Ethernet adapter and was able to get the full gigabit on an internet speed test.
I doubt many raspberry pi projects need any of that. You could run a basic web server on an iphone just fine or plug it in to your model car to control using a lightning to usb adapter.
> plug it in to your model car to control using a lightning to usb adapter.
You'll need GPIOs, and iPhone doesn't have it... Well, I do agree with you that an USB I/O expansion adatper is an usable solution. You'll get I2C, SPI and GPIOs without difficulty.
In theory this is true, but the dire software situation pretty much kills the idea in my mind.
Best case you'll be able to run PostmarketOS, but more likely you'll be constrained to a years old Android with an ancient kernel and a non-standard libc - that is after you mange to get the thing rooted in a convoluted process. You can also be pretty sure that thing is going to be running malware.
They would probably open up their old hardware if they could get carbon credit for it for being recycled to a usable device, but the economics is just too small as an incentives for that to happen.
Flash memory comes in multiple flavor, named after the logic gates that the organization of their transistors resemble. So there is NAND Flash, NOR Flash, and Vertical NAND Flash memory.
I agree that referring to "NAND Flash Memory" as "NAND" is rather confusing. Similar to referring to "crypto-currency" as "crypto".
And similar to referring to a "CMOS image sensor" as "CMOS" or referring to a "battery-backed CMOS SRAM" (for BIOS configuration) as "CMOS"... But due to historical reasons (e.g. CMOS made battery-backed SRAM possible, NMOS or PMOS drains the battery in no time), these terms are stuck forever.
NAND flash memory, like those used in SSDs, has limited lifetime, after too many writes they will just be dead (although in practice it means several terabytes of writes). Manufacturing defect is also possible.
