A browser engine is indistinguishable from any other app feature, maybe except if it has a JIT compiler. So the complexity is like allowing, say, emulators with a JIT feature. Big fucking deal.
> Today, iOS users already have the ability to set a third-party web browser — other than Safari — as their default. Reflecting the DMA’s requirements, Apple is also introducing a new choice screen that will surface when users first open Safari in iOS 17.4 or later. That screen will prompt EU users to choose a default browser from a list of options.
Any idea if this means you can actually choose a different browser, or are you choosing a different WebKit wrapper (e.g. the current version of Chrome on iOS)?
"New frameworks and APIs for alternative browser engines — enabling developers to use browser engines, other than WebKit, for browser apps and apps with in-app browsing experiences."
It does, but on closer reading looks restricted to EU, they certainly aren’t suggesting a , say, gecko based browser could be published globally outside the EU.
> Apple is giving app developers in the EU access to NFC and allowing for alternative browser engines, so WebKit will not be required for third-party browser apps. Apps will be able to offer NFC payments without using Apple Pay or the Wallet app through Host Card Emulation. Apps can also access field detect, and a default app can be set to activate when an iPhone is placed near a terminal.
Although this only changes things for us developers. Regular users really don’t care what browser is running the web pages they’re looking at, everyone who downloads chrome does so to get their synced bookmarks and history.
> Regular users really don’t care what browser is running the web pages they’re looking at, everyone who downloads chrome does so to get their synced bookmarks and history.
This is ahistorical. Regular users switched to Firefox and Chrome in droves from IE. And it wasn’t to sync their bookmarks. It was because they provided a much better experience.
If Blink or Gecko are able to provide a better experience than WebKit on iOS that would certainly prompt many users to switch to browsers using those engines.
Seems unlikely given that out in the free world we’ve seen a consolidation around Chromium. The web is mature enough at this point that the choice of browser engine mostly isn’t a differentiating factor.
You're missing the point. People can feel that a twin turbo inline 6 drives much smoother and more powerfully than a 1.3L 4 banger even if they don't know the first thing about what's under the bonnet. The engine changes the entire experience.
And most people don't care at all what's under the bonnet.
They want something that reliably gets them from A to B and back, with occasional side trips to C, D and E. They want something that does that in a way that matches their personal style. They want something that isn't going to cost them an arm and a leg to run.
Forty, fifty, and sixty years ago people cared a lot more. Starting really in the mid-90s, that changed. Nowadays, there are probably as many gearheads as there were decades ago, but as a population they represent a smaller percentage. And there's a tiny percentage of people who care only so that they can mod their engines to run less efficiently so they can pwn the libz.
Inasmuch as people do care about the 1.3 4 banger — they choose it because it generally runs more reliably over time with fewer litres burned per 100km.
If you do not see those statements as complementary, that is on you, not on me.
Most people who buy cars don't actually give a shit how many cylinders, spark plug configuration, or hamsters are involved in the engine. They want to know that it will work and not cost them too much in fuel, maintenance, insurance, and repairs. They want it to "look good" for their sense of style, and they want it to be a "safe" car.
In order, it's usually price, style, then fuel efficiency (not engine, but whole car fuel efficiency), insurance cost, and everything else. For some people, it ends up being style, price, then everything else.
I think you're wrong: people who buy a shitty second-hand car to go to work and have little money to spare on it: indeed, really 0 interest in the car as long as it runs long enough to generate profit to break even.
But if you are going to spend 10k$+ on a car, then you start caring, A LOT. I've seen the change from when I was a student willing to take any crap on wheel, vs when I had some money to burn on a car and I spent weeks looking at everything to end up buying a 10k$ 20yo Porsche 911 :D See, I didn't even look at the fuel cost: only the engine perf per dollars. And it cost me an arm and a leg to run, in Hong Kong where the fuel cost is the highest in the world !
People don't work as rational machines balancing perfectly cost and profit in a constant manner over time. It's more a constraint compromise game with a repressed desire for luxury that seem to drive us: you'll buy what you can afford and within those boundaries you will choose comfort and design over economic optimization. Like when people buy an iphone, evidently they didn't look at all about cost for performance and choose something economically suboptimal but luxurious.
Accept it and you'll start liking them more I think.
I said: “They want something that reliably gets them from A to B and back, with occasional side trips to C, D and E. They want something that does that in a way that matches their personal style. They want something that isn't going to cost them an arm and a leg to run.”
I did indicate that personal style comes into it, and I don't think that it's not an emotional decision. But there's a reason that Camry, Corolla, and Accord show up in bestselling car lists every year (and similar models elsewhere in the world), and it has nothing to do with "caring about what's under the bonnet".
There is a subset of people who do care about the engine, but they don't do so because they actually know a damned thing about how the engine runs, but because a big engine makes them feel powerful in their oversized pickemup trucks that never carry a load in the bed.
Your assertion that people who buy an iPhone aren't looking at cost for performance is partially correct, but only insofar as most (I mean > 99% of people including people in tech—including myself) wouldn't be able to objectively measure phone performance worth a damn. Anecdotally, I know a number of people who have switched from android devices to iPhones because they see their friends holding onto the same iPhones for years without complaints, yet they can't see the benefit of holding onto their android phones and realize that they may be spending a bit more up front, but are getting more possible useful years of phone updates than had been available in Android until promises made (and several years to see if they are kept) just few months ago.
Yes, I also know people who are enamoured of their Android devices and have their own smugness about what they think that they've gotten over the "sheeple" who buy Apple devices, but most people really don't give a shit about the phone operating system any more than they do about whether the engine in their car is 3, 4 or 6 cylinders (people who by v8s are intentionally buying a v8) or whether it happens to just be a family of hamsters running around underneath—as long as it runs.
i still think the claim regular car users don't really care about the engine specs holds true ... you'd be hard pressed if you can tell the difference between an inline 4 and v6 these days tho (apart from how many more times you are hitting the gas station; some inline 4s even perform better than v6s)
That's exactly what I predicted for NFC when Apple announced Apple Pay. Apple kept developers from using any of the NFC APIs until they were ready to roll out Apple Pay, and then only allowed non-payment NFC after that. It gave them 10 years to establish Apple Pay.
Being the system default was obviously very convenient for customers and there would be a very high bar for any other payment app to compete, but Apple wanted to make absolutely sure there was no possible competition.
> Regular users really don’t care what browser is running the web pages they’re looking at, everyone who downloads chrome does so to get their synced bookmarks and history.
Well first version it will be different WebKit wrappers, as they are the only option available on iOS right now.
But they simultaneously open the door to other browser engines, so I imagine Firefox at least will release their app with a new browser engine down the line.
> To reflect the DMA’s changes, developers will be able to use alternative browser engines — other than WebKit — for dedicated browser apps and apps providing in-app browsing experiences in the EU.
So now European users could be using Firefox with mobile gecko engine, but no one in the US will ever test with that because they're not allowed to have it. Fun!
Firefox mobile extensions on mobile was basically a graveyard during their mobile overhaul. But it sounds like they are slowly making it easier to support mobile extensions with a metaphorical (or maybe literal) push of a button.
AFAIK, from various interactions I’ve had on here and on Lobsters, Big Tech developers seem to often have Firefox as a target. But people in startups don’t.
And European users will have 3000 instances of Chrome now that every app is going to bundle it. I'm all for alternate rendering engines but without giving users a choice the bloat is going to be massive. I don't trust developers to not be bloating their apps and I can almost guarantee we'll see custom versions of Chrome to enhance dev tracking capability on users.
I don't expect many EU apps to bundle Chrome because they can't use it outside the EU and the benefits of bundling a different browser engine for in-app browsing would be limited for the types of basic browsing that is typically done inside a non-browser app. Additionally, Apple is imposing additional requirements on apps that embed alternative browser engines, including requiring apps to be updated within 15 business days of a browser engine update and requiring the app to only be available in the EU.
As a result, I would expect Chrome/Firefox/Edge/Opera to ship their own browser engines on iOS but am doubtful that many other apps will embed Chromium/Gecko with the possible exception of apps that only operate in the EU.
You don't need custom versions for Chrome for tracking. Plenty of apps force links to open in-app, inject JS and then you have to make a few additional taps to get it to open in untampered Safari
Can’t speak for other Fanboys™ but I have to help my in-laws with their Pixels weekly, which also happens to coincide with the one time a week I want to blow my brains out.
Luckily I’m extremely close to having them inducted into the fruit cult just by having them play around on my dev iPhone when I’m not working.
So fingers crossed it happens before get pushed over the edge.
As an aside: what kind of OS allows apps to create read-only contacts in the Contacts app, ffs…
My comment will seem a bit rude, but do all of you guys just have idiots for inlaws? My parents are in their 70s now and are by no stretch of the imagination technical in any way, yet I've literally never had to help untangle them like I see people talk about here constantly. Hell, my 97 year old grandpa uses his ancient android phone just fine, what on earth are people doing out there?
Apples rules make it clear you can't bundle Chrome. Your alternate browser has to be fundamentally a browser, not something else that happens to have a browser as an extra feature
> actually choose a different browser, or are you choosing a different WebKit wrapper
I understand the "WebKit wrapper" for iOS criticism and do want different rendering engines available (e.g. Firefox's) and yet...
The worse thing about Firefox for iOS is the wrapper part, not the lack of rendering engine choice part. The UI of Firefox on iOS is inconsistent and buggy, and syncing doesn't sync well, etc. I doubt using FF's own rendering engine instead of WebKit would help the situation, as it'd drain engineering resources away from making the "wrapper" more usable.
I've always used Firefox, on Mac, Linux, Windows, Android, everywhere I can, but I find myself using it less and less on iOS... and it's not because of the rendering engine!
But since this change for the DMA will allow FF to use its own rendering engine (in the EU), hopefully maybe it'll reenergize the development of FF and improve the "wrapper" part more - even for non EU users!
Writing this on FF for iOS, the biggest reason I want to use the Firefox engine is for Firefox extensions. WebKit doesn't support extensions except the App Store ones in Safari, I want to use traditional extensions from AMO. Just let me use uBlock on my phone!
I do agree, the Firefox iOS UI is clunky, but I find it useful for stuff where I want to sync passwords or tabs. I use Safari for browsing the web casually because it's nicer, and the feature of swiping between tabs is so convenient.
WebKit does support the same extension API as Firefox - it’s an open standard. How you install them, bundled in a native app from the App Store, is the annoying clunky part.
WebKit does not support blocking Web Request, which is what uBlock Origin uses (See compatibility matrix at the bottom of https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...)
In fact, it is all about blocking Web Request, not say, Manifest V2 vs Manifest V3 (Firefox supports MV3 but adds blocking Web Request support.)
Just to correct the common misconception. It is browser vendors that need to build web extension API support on top of WebKit. Orion browser [1] did this both for macOS and iOS . The support is still in beta and improving with each new release. iOS support remains limited to what is possible to achieve with a JS wrapper. Nothing prevents Firefox from doing the same and offer at least partial web extension support on iOS.
> This change is a result of the DMA’s requirements, and means that EU users will be confronted with a list of default browsers before they have the opportunity to understand the options available to them. The screen also interrupts EU users’ experience the first time they open Safari intending to navigate to a webpage.
How will users be able to understand the options in front of them unless they are presented with it in the first place?
It would've been so nice if the EU had required there be an automated way to choose Accept All and Only Necessary options. They could've even reused the existing DNT header!
A Berlin court ruled that DNT counts as an opt out. Linkedin was the defendant that lost, but it is a precedent. There are also talks of outright banning targeted advertising in its entirety and only allowing other forms such as contextual ads.
It makes Apple look bad overall to me; what's worse for Apple is that I'm a dev: they're supposed to be making themselves look good to people like me so that I'm attracted to their platform, but their churlishness is putting me off.
My micro-ISV stopped shipping an iOS app a few years ago when Safari's support for PWAs made it viable to reimplement our app as a PWA so that we no-longer needed to deal with App Store hassle (faffing around with a Mac Mini we'd only use a few times a year, confusing certificates/entitlements/etc, not to mention the capriciously enforced store app review policies).
...but I'm probably just being nostalgic for the early days of indie iOS apps. Those times are long gone, perhaps Apple actually isn't interested in attracting small devs to their platform anymore?
There are literally thousands of options for configuring your device in the Preferences app. Should we put all of them in front of the user's face the first time they set up their phone? How would they know those options exist otherwise?
Knowing that you can configure your phone's behavior should be a basic point of technology literacy. I know that it isn't at 100% today, but what percent of users are now going to have yet another forced decision to make before using their phone for the first time, just so a minority of technology illiterate users can be "educated".
Apple themselves don't seem to have a problem with displaying a red notification dot/badge on the "Settings" app to anyone who doesn't set up any card in Apple Pay on their new devices, at least.
> There are literally thousands of options for configuring your device in the Preferences app. Should we put all of them in front of the user's face the first time they set up their phone?
This is an absurd comparison. The choice of picking the default web browser, a complex pieces of critical software on everyone's mobile device, is categorically different than almost every single one of the other preferences on the device. You'd have to be completely insane to claim that e.g. the preference of whether a double-tapping space on the soft keyboard should insert a period is remotely comparable to choosing the default web browser.
What factual objections do you have? Apple can control the safety of their SW and cannot vouch for not-their-sw, so from Apple's point of view this is 100% accurate.
Let’s not forget. This is also the exact same argument Apple used for not having an App Store in the first place and only allowing web apps.
The chutzpah of using this argument to keep the App Store locked down when Apple used the same argument to not have an App Store in the first place is incredible.
The DMA introduces zero risk. Users are absolutely able to use the Apple App Store, Safari/Webkit, etc like this as they did before.
So no, Apple isn’t factually correct.
In fact, it’s very possible that Gecko or Blink have more secure engines than WebKit. It’s very possible someone can create an App Store that is even more vetted than Apple’s and eliminates scam apps and games whose only purpose is to separate you from your money.
So it’s not only not accurate, it’s probably diametrically the opposite of accuracy and is false.
But the worry here is that you can be tricked into installing all sorts of dangerous malware. Especially now that casual users have been trained to believe that apps are safe.
The DMA absolutely opens up all sorts of new vectors of attack. The question is ultimately a philosophical one -- whether you think the increased freedom is worth the increased risk. Not just for yourself, but for the average non-tech-expert consumer.
You might think the tradeoff is absolutely worth it, but that doesn't mean that it still hasn't significantly increased security risks.
You need to think about this more carefully: there absolutely is an increase in risk by allowing other parties to run native code on your devices. This guarantees that people will be socially engineered into installing malware, intrusive vendors like Facebook will try to force users to add their stores to bypass privacy restrictions, and employers/schools/etc. will try to force their users to use their spyware for similar reasons.
Now, a not unreasonable position is that this is acceptable but that should be an honest discussion starting with accepting the risk so you can gauge whether it’s a reasonable trade off or whether there are other mitigations. For example, notarization is a useful way for making it harder to install code on someone’s device which the OS vendor cannot see if it’s later associated with malware or which cannot be traced back to a source developer. The next time someone is breached, it’s useful to be able to tell whether the Firefox.app they have installed is an official Mozilla build or pretending to be one.
These EU laws start with the current circumstances and motivation why the law exists. An objection to why DMA is bad can be found in the first two recitals:
> (1) Digital services in general and online platforms in particular play an increasingly important role in the economy, in particular in the internal market, by enabling businesses to reach users throughout the Union, by facilitating cross-border trade and by opening entirely new business opportunities to a large number of companies in the Union to the benefit of consumers in the Union.
> (2) At the same time, among those digital services, core platform services feature a number of characteristics that can be exploited by the undertakings providing them. An example of such characteristics of core platform services is extreme scale economies, which often result from nearly zero marginal costs to add business users or end users. Other such characteristics of core platform services are very strong network effects, an ability to connect many business users with many end users through the multisidedness of these services, a significant degree of dependence of both business users and end users, lock-in effects, a lack of multi-homing for the same purpose by end users, vertical integration, and data driven-advantages. All these characteristics, combined with unfair practices by undertakings providing the core platform services, can have the effect of substantially undermining the contestability of the core platform services, as well as impacting the fairness of the commercial relationship between undertakings providing such services and their business users and end users. In practice, this leads to rapid and potentially far-reaching decreases in business users’ and end users’ choice, and therefore can confer on the provider of those services the position of a so-called gatekeeper.
It's a bit long for HN comments (although 257 words is about a minute of reading) but I didn't really know what could be fairly cut out
Weird how nearly every top-level comment pointing out the salty tone of the press release has been flag-killed. It's actually really unique: You almost never see corporate PR dripping with attitude like this one.
The number of Apple fanboys in tech that cheer every anti-consumer move by Apple really boggles my mind. Other companies rightfully get called out, ex: Unity recently, but for Apple they will make excuse after excuse.
You mean the ones which are incoherent or profane? Most of this thread is people talking about the tone so if there’s some conspiracy trying to flag things they’re remarkably ineffective.
Likely because they anticipate increased competition to the App Store now, and want to pre-empt the attractiveness for developers of moving to the Epic Store or the Facebook Store etc.
> To help keep users safe online, Apple will only authorize developers to implement alternative browser engines after meeting specific criteria and committing to a number of ongoing privacy and security requirements, including timely security updates to address emerging threats and vulnerabilities.
This criteria seems arbitrary. Doesn't this allow Apple to arbitrarily prevent competitor engines like Blink and Gecko?
I don’t think it will used against Blink and Gecko for obvious compliance reasons. But this clause will help Apple pressure them to keep security updates timely (which is a good things for the users).
On the other hand they will likely use this to deny all ‘niche’ browser engine without a structured organization behind them (think Ladybug, maybe servo etc.)
> A new version of Safari shipped 17 times in the last 28 months — version 15.0, 15.1, 15.2, 15.3, 15.4, 15.5, 15.6, 16.0, 16.1, 16.2, 16.3, 16.4, 16.5, 16.6, 17.0, 17.1, and now, today’s Safari 17.2.
> A new version of Safari shipped 17 times in the last 28 month
> Yes, not as frequent as monthly releases, but Apple shipped 7 Safari updates on iOS in 2023.
That's a very recent change: prior to 2022 Apple had far fewer updates to Safari on both macOS and iOS - and still witholds Safari updates from older iOS versions - for example, there was only 1 macOS Safari update per year between 2008 and 2015, and only 2 updates per year from 2015 to 2022; while things were just as sparse on iOS.
We're litigating Apple's release cadance from 9 years ago?
I get it. Apple used to update Safari infrequently. In the past two years they've increased how frequently they update. "Apple patch their browser twice a year at best" is no longer true.
No, it seems like we're litigating the cadence for a period of 15 years, ending only 2 years ago.
Here's the options:
1. Apple was wildly irresponsible with the security and privacy of their users for a decade and a half, despite this childish press release about how EU is making their users less secure.
2. The risk profile of browsers only changed in the last couple of years, and until then it was totally safe for iOS browsers not to be patched regularly.
3. Apple doesn't particularly prioritize their users' security, but are setting up one more malicious compliance roadblock for anything that could threaten the tens of billions in pure profit they squeeze out of the Safari monopoly.
None of those options apply: Apple did (and still does) ship regular security updates for iOS users which included Safari, but did not include Safari web-platform feature updates (i.e. CSS+JS+etc support) unless it was a significant iOS update (such as the yearly major-number increase or the "half-term" point releases) until 2022.
Apple's handling of Safari mirrors Microsoft's stated plans for Internet Explorer back when Windows XP (and IE6) launched in 2001: they said they'd treat the browser as a core OS component that would only receive major web-platform updates with major OS releases (hence why we had to wait five years between IE6 and IE7, during which Firefox saved us from a mediocre web experience).
...could be worse: could have been like Outlook which has been stuck on Word's HTML rendering engine since 2007 right through until today's "New Outlook" rewrite - that's that's got to be an unbeatable record for the "world's most stagnant web-browser".
Its usual BS from Apple. Imagine Microsoft blocking all non-store applications from running on Windows "to help keep users safe". No I'm not cheering for Microsoft to do the same. Its strange, but I want Apple to be more like Microsoft in this regard.
Exactly, they're conflating choice with complexity. As you said, you can have any level of control, via various permission levels.
I think what would be helpful if there was a concept of a "system admin" profile that you could apply onto any device/computer. Non-technical users may want Apple to be the 'sysadmin' and only use the Apple store, use Apple recommended apps, etc. - Kinda like the an MDM profile.
Any other vendor, as a paid/managed service, could supply a more permissive app store, and manage updates, etc. Companies who issue work devices would have their own "profile" to manage the device.
Windows was created before t security in computing was a thing.
It’s an completely invalid comparison.
But even if we accept that comparison, how about OSX? OSX has been tremendously secure through its existence and it allowed users to do whatever the F they wanted to do with it until recently.
Device Name: App can access the device's name, like "John's iPhone."
Device Model and OS Version: App can identify the device type (e.g., iPhone 14) and iOS version.
Carrier Information: App can access network provider details.
Wi-Fi Information: App can determine if Wi-Fi is enabled, but not specific network names or passwords. Battery Level: Accessible without explicit permission: Apps can access the current battery level without needing explicit user consent.
2. Contextual Information:
Current Language: App can adapt content based on language settings.
Time Zone: App can display time-related information accurately.
3. Necessary Functionality:
Push Notifications: Apps can receive push notifications without explicit permission, but users can control this in Settings.
Local Network Access: Apps can automatically access devices on the same local network (e.g., a printer).
Background App Activity: Some apps can function in the background for tasks like downloading updates or syncing data.
4. Permissions Granted During Installation:
Keyboard and Siri: Apps can request full access to the keyboard and Siri without additional prompts.
5. Accelerometer:
No permission required: Unlike many other sensors, the accelerometer on iOS devices does not require explicit user permission for the app to access its data. However, there are some limitations:
Foreground access: Apps can only access the accelerometer while they are actively in the foreground. Background access is restricted.
Privacy concerns: While user consent isn't explicitly requested, some users might still find accelerometer access concerning due to its potential to reveal information about device movement and tilt. Transparency in app descriptions and responsible data handling are crucial.
6. Barometer:
No permission required: Similar to the accelerometer, the barometer also doesn't require explicit user permission for access. It functions alongside the Core Motion framework, used for motion and environment-related data.
Thanks, but I like my example, even if you find it inconvenient. I don't find it strange at all that the most popular operating system gets exploited the most. Luckily, Windows is not in the top 5 for reported vulnerabilities.
Apple sells billions of iPhones because grandma can’t accidentally install ransomware or a key logger by clicking on the wrong link. There’s nothing you can do to rewrite Windows’ multi-decade reputation for this.
It’s the “cool” phone brand because it’s a quality product beloved by hundreds of millions of diverse people worldwide. Not having to deal with basic security issues is one of the thousands of reasons why.
This thread is about Apple's poor decisions, and general bad track record of putting money over user freedom. They are in the wrong for preventing users from installing apps of their choice on a device they paid for.
You defending them with a ridiculous talking point about scary viruses and grandma doesn't work anymore, sorry!
Or not publishing documentation (they were also forced by the EU to do so ironically) that has allowed the likes of OpenOffice to read Office docs and become a legitimate alternative, because of security (Office docs are a security risk and showing hackers how they work makes them a bigger security risk…).
I think it seems pretty clearly meant to include major competitors like Firefox and Chrome and Edge if Microsoft wants, but you can't just include a random build of Chromium that you never update.
And this seems understandable to prevent a proliferation of 100's of "browsers" trying to steal your data. You actually have to be developing something legit -- not just reskinning a browser engine and leaving it.
That is fine as an app store policy, but they also want to impose those requirements for apps outside the appstore. That is a problem, if I want to run a sketchy browser downloaded from github apple should not be able to prevent this
> That is a problem, if I want to run a sketchy browser downloaded from github apple should not be able to prevent this
You can already do that today (yes, on iOS) by using your own developer-signing certificate (because if it's from github, you can build it from source; or re-link/assembly prebuilt linkable binaries if you really feel like it).
Remember the vast, vast majority of iOS users are people like (I assume) our parents - or people we knew in the late-1990s/early-2000s with an excessive number of Internet Explorer toolbars and Bonzi Buddy. I support Apple's mission to keep crap like that off their platform, but Apple sleepwalked into prompting this regulation of their app-store because they weren't the good-stewards they said they'd be - so I'm ambivalent about the whole thing.
Tbh my mom doesn't even understand how to install an app from the app store. And she comes running for everything that she is not used to. I am not concerned that she would download anything from outside. But I do get your point that many people are incapable of evaluating what aoftware is trustworthy (and hell you cant always know there is a risk even with open source software that seems trustworthy unless you actually read all the source code, which I very rarely do and only for small programs or small parts of programs). However I do not think it is Apple's responsibility or right to be the guardian here.
That still requires you to pay Apple for a developer account ($99 USD/year), requires you to own a Mac, and requires you to abide by all of Apple's rules. Meaning that Apple _can_ still prevent you from installing a sketchy browser downloaded from Github since they control everything about the build-and-signing system on the iPhone.
> You can already do that today (yes, on iOS) by using your own developer-signing certificate (because if it's from github, you can build it from source; or re-link/assembly prebuilt linkable binaries if you really feel like it).
Not if you want a browser with a JIT Javascript compiler, which for better or worse is a basic requirement for a broadly usable browser.
No, these emulators achieve JIT via a method intended for remotely debugging apps. AltStore has a way of automating this, but it requires an active server connection when the app is launched.
In AltStore's case, this means you need to be on the same wifi network as the computer running AltServer. I don't know whether it would be theoretically possible to do this over WAN, but it definitely isn't practical at a large scale.
The entitlements for browser development are almost certainly not going to be given out to people on the free tier and probably not even to all paid developer program accounts. Any entitlement that's available to free tier becomes something that you can sideload with AltStore, which works almost exactly as you suggest.
They do the same thing with the VPN entitlement. If you want to filter network traffic on-device, you have to apply for it and identify yourself to Apple. If they didn't do this China would be banning iPhones left and right.
A whole bunch of tech guys fundamentally don’t understand how naïve many users are and how hostile the environment is.
What we need is a fundamentally different model for device security in our users. Their device is insecure and everything they might do online will expose them to an attacker.
But that overturns 40 years of UI improvement so people can use their devices without thinking.
No it's not understandable. The iphone is a Turing complete computer. I should be allowed to install whatever I want on it.
If I want to install a reskin of firefox then I should be able to do that. It's certainly not up to Apple to decide this for me.
Why? It’s one thing to say that you will never buy something because you can’t use it the way you want. It’s quite another to say that thing should adhere to your standards whether you buy it or not. It sounds even sillier if you make your demand after you already bought it.
“I should be allowed to…” will always reek of entitlement. Pick your hardware and platform on your likes and needs. There are plenty of options to choose from.
While I agree with you, I think it is already possible to make a "browser" on iOS today that tries to steal your data. The only thing stopping it is manual review, not any technological measures. In fact, if the point of an app is to steal your browsing data, it is easier for them to stick with WebKit and WKWebView than to invest in a new browsing engine. Existing APIs provide plenty of opportunity to inject almost annything into web views.
These requirements are things like "Use memory-safe programming languages", "Adopt the latest security mitigations", if you ship your own certificate trust you should "provide information on how a root certificate authority (CA) can apply to become part of the program".
All seems like pretty basic conditions designed to ensure that only Mozilla and Google can comply.
To be honest, the browser engine stuff seems significantly more robust and permissive that I was expecting.
Pretty funny to see "use memory-safe programming languages, or features that improve memory safety within other languages" as a requirement when WebKit itself is built on top of C++ code.
I wonder if Apple would be allowed to ship WebKit if they enforce this requirement under the spirit of the EU laws that made them change their minds.
> Use memory-safe programming languages, or features that improve memory safety within other languages, within the Alternative Web Browser Engine at a minimum for all code that processes web content
> Pass a minimum percentage of tests available from industry standard test suites: 90% from Web Platform Tests and 80% from Test262
Why is it any of Apple's business how many test suites a third party browser can pass?
Why can't iPhone users run Links if they want to? Why can't they run a browser without Javascript support? Why can't they try out Ladybird to see how development is progressing?
Like, even from a pure Apple-is-greedy perspective I don't understand the point of this.
Browsers that bring their own javascript engine will likely also need to support JIT in order to be able to compete with Safari on performace. Doing JIT on iOS requires a special entitlement grant from Apple in order to map memory pages as executable. An application that has permission to map memory pages as executable is a coveted target for spyware and malware as it provides a much better starting point for pivoting to root and pwning the entire OS. Most other regular apps, even if they have a buffer overflow somewhere, will require a lot more fiddling in order to execute arbitrary code, and are thus a lower risk for users to install.
In short, browsers will have higher privileges that normal apps, as they can execute arbitrary code in memory, so they are naturally held to a higher standard.
To be honest I am happy about this. I don't trust a random banking / government / public transport app contracted out to the lowest bidder to be safe from all buffer overflows or other memory safety issues, so making sure they are sandboxed away from executing arbitrary code is a good thing.
> An application that has permission to map memory pages as executable is a coveted target for spyware and malware as it provides a much better starting point for pivoting to root and pwning the entire OS
No more than any other app. It runs anyway in the app sandbox, and can only access the resources that are accessible from the app sandbox itself. For the application to gain root privileges it would need to exploit a flaw in the sandbox itself, something difficult these days.
Android allows applications to map memory pages as executable (in fact you can also launch any Linux executable as a subprocess) and there was never an issue about security: if you don't have a rooted phone you don't have chances to get code running as root, since everything runs in the app container.
And if there is a flaw that allows escaping from the app sandbox, it can probably be exploited without being able to map memory pages as executable anyway, since it will probably be a flaw in a kernel system call or library function.
So really: this was always a limitation that Apple did impose to not allow in practice competing browsers in the Apple store, since a browser to be efficient this day needs to compile code as JIT, as well as not allowing applications that benefit for JIT execution (such as emulators or compilers).
There's been plenty of flaws in the app sandbox, but without the ability to execute arbitrary code they are often much much more difficult to exploit since you won't be able to invoke the particular system call or function you want to hit with just the right arguments.
For now. The EU Product Liability Directive updates and Cyber Resilience Act is going to force software and hardware makers to take a much harder look at their security choices.
I read that as "expanding protections to reduce (privacy and security) risks ..." but I guess you're reading it as "expanding protections to reduce (privacy) and (security risks) ..."
Sadly no information here about the mechanisms for how alternative app stores will work, which is the most interesting part for me. Will the .ipa format be standardized like .apk and will we be able to make iOS apps without having to use macOS?
Whether runtime generated or downloaded from the internet, you cannot run instructions directly on the processor without requesting executable virtual pages in memory from the OS. Executable pages are also a major security vulnerability: https://en.wikipedia.org/wiki/JIT_spraying
> Notarization for iOS apps — a baseline review that applies to all apps, regardless of their distribution channel, focused on platform integrity and protecting users. Notarization involves a combination of automated checks and human review.
Does anyone know if notarization is something you could turn off? If you can't, then I'm pretty sure the EU won't like this; obviously "malicious compliance."
Apple and the EU have been discussing the implementation for some time so it seems extremely likely this has all been OKed already. In particular, I’m sure the issue of apps (FB app with a virus or spyware) on a random App Store is a concern to the EU.
Not defending Apple per se (they sure don’t need help) but going with the public statements of both Apple and the EU leading up to this.
If they actually okayed it, then I hope the EU reconsiders. In effect, Apple's tight grip on what apps you could run remains. I am also disappointed that those changes are EU-only, I hope most governments impose similar laws so that Apple just gives up and makes it global.
IMHO it seems like it's there only to enforce that "Core Technology Fee" and even then I don't buy that argument. Malware already slips through Apple's "strict" App Store review process.
Malware also slips through sandboxes and other security measures. That doesn‘t mean they are useless. App review and notarization helps a lot with security. But there will always be errors.
My concern mostly lies with "what will qualify as malware". When we think of malware we think of things the user would consider malware, i.e. the traditional use case of notarization. Is Apple thinking the same or is malware just apps that do things they don't like and haven't been otherwise forced to approve (e.g. like JIT is now allowed for browser engines)? Overall though I'm optimistic on it, just also cautious.
Sure, but if Apple assumes that any non-notarized app is malware, then they're not just preventing malware - they're requiring non-malware to notarize every install. And since this is coupled with a new policy where non-app store installs cost money, this means it will be enforced through the notarization mechanism.
It's not the notarization itself that's an issue, but the fact that it's also the enforcement mechanism for collecting fees per-install. It's basically a mafia protection racket where you need to pay Apple to say you're not malware.
I think in this case some antivirus companies from EU could do notarisation.
Of course, companies that have a good track record and would actually do the proper job. No need to depend on Apple to do it. We do not have a single SSL CA, for example.
“Officials from the European Commission, the EU’s executive body, have been holding meetings in recent months with Apple and other tech companies to discuss the new rules. Apple hasn’t provided a final package describing its solution to the commission or tested its plans with market participants.
Once it does, the commission will review the full package to look at whether it will make the market more open and contestable, and whether the company’s plans meet all the individual provisions of the law, according to a person familiar with its plans.”
Notarization has been enforced for all apps on the Mac for years. Would the DMA have an issue with requiring signed drivers? Seems a similar baseline. Personally I’m totally ok with that. I haven’t seen a single instance of them not notarizing something or revoking it for something that wasn’t actually malicious.
Gatekeeper/notarization are intended to stop malware, which Unreal Engine is not. Apple may well have a valid business dispute (over another application on another platform), but it's an abuse of the system and control they have to obstruct a Mac owner from running non-malware software on their own computer.
Luckily the court stopped them retaliating in this case, but it gives me reason to be concerned about expansion of the "it's Apple's device and will always act in Apple's interests over the owner's" mentality from iOS towards Mac desktops.
Plenty of contracts include dubious and outright illegal things, depending on the jurisdiction. I'd say Apple is violating the public trust as they increasingly corner the market in apps and phones.
Anyone can sue over unlawful contract terms without needing to breach the contract.
The one finding in Epic’s favor was that Apple violated California’s Unfair Competition law by preventing Epic from linking to an outside payment method.
>Through a combination of automated checks and human review, Notarization will help ensure apps are free of known malware, viruses, or other security threats, function as promised, and don’t expose users to egregious fraud.
I wouldn't be 100% confident there. I wouldn't be surprised if porn got through, but plenty of other companies have blocked such content under "security threats".
Apple doesn't care about porn on iOS devices, they just don't want it in the App Store. Unless a PornHub app is full of malware, it shouldn't have any problem getting notarized.
You can install any app you want on the Mac, notarized or not. You might get some kind of warning, but that's irrelevant.
And Apple only allows certain kinds of apps through their notarization process. They can't have pornogrpahy, they can't allow things that could break copyright etc.
No, notarization can be turned off on the Mac in ~15 seconds. Open a Terminal and type `sudo spctl --master-disable`. Enter your password and press enter.
You can also right click an individual unnotarization .app bundle and select `open`, then affirm your intention in the scary warning prompt.
P.S. The Mac also lets you disable SIP, install unsigned kernel extensions, and rewrite kernel memory to your heart's content. This is admittedly a bit more involved.
Does Apple charge Mac developers a price per notarization? Because it sounds like that's effectively what they're doing here with iOS developers, since they require notarization and also require a fee per install for distributing outside the app store.
It's a protection racket - pay us and we won't flag your app as malware.
Not really. It’s a condition. You can also choose the old rules.. you can also chose to not develop for iOS. There is no gun to your head if you don’t develop for iOS
But the "old rules" were explicitly deemed illegal. Is there a limit to your logic? What if Apple had set the per-installation fee to $50 instead of $0.50? Developers have a choice! If they don't want to pay $50 per installation, they can choose the old rules. There is no gun to their head.
Where is the line? Surely at some point, the choice is so unreasonable that Apple has effectively forced developers into "the old rules," thus circumventing compliance with the new rules, which may as well not exist if no developers can afford to play within them...
Develop for other OS-es. Don't develop for a platform you dislike and have so many issues with.
I never write code for Windows and actively tell any client I have to not use it if they want my product. If they don't want it so much - there are plenty of alternative. If they really want it - they will use the OS I write the app for.
It is in plans though.
I think EU should make alternative notarisation entities though, antivirus companies could do it.
If we care about "privacy and security" here.
I think perhaps notarization is OK, for example you have to pass requirements to publish on other closed platforms like games consoles. What I think is very underhanded is charging per install for 'core services' rather than per app review. It's not like the app has to be notarized/reviewed for every install.
How else are they gonna obligate developers to pay the core fee then.
Once tooling catches up, in theory, developers don't have a contractual relationship with apple anymore, except to get notarized.
The devices belong to the users apple sold the hardware and licensed the software to them not app developers. They could charge the users but obviously this would be a terrible idea.
Getting notarized will either directly require payment of the platform fee or will force the use of the official tools which will mandate that.
Nonprofits, governments etc don’t have to pay a fee, so in effect it means we will have the AppStore, and a few free, open-source alternatives.
That is absolutely a win to the common people. And it’s not like other companies taken a hit - they can either stay on the AppStore and have their finances go through their “taxing”, or create an alternative store and find a proper monetizing strategy. They can calculate what makes sense, but it makes it hard for Facebook/google to exercise their network effect for creating a new app store at the expense of users.
The announcement indicates that notarization for iOS platforms will include human review. They are basically dividing the App Store review process in half, with the platform safety side (for all apps) and the content/quality side (only for App Store).
> for example you have to pass requirements to publish on other closed platforms like games consoles
But those would be the requirements of those platforms.
I can make and publish games for the Pico-8 console without any requirements. Could you imagine if Microsoft had the ability to veto any Pico-8 game I wanted to make?
The entire point of this legislation is to open up the Apple's mobile platforms to competition. It's not (supposed to be) a closed platform. With notarization requirements, third party app stores are just an extension of Apple's app store with a different logo!
I guess as usual this will come down to porn. if those apps get rejected despite being non-malicious that shows how this "notarization" process truly is.
To be honest, it's not even like I care that much about the additional payment. Scummy but expected. It's more that the current prices, similar to Unity, seem to pretty much punish any innovative idea that takes off, to a point where Apple will not just make the product unproftiable but bankrupt the developer in the process. Most mobile apps are free so people underestimate how quickly you can hit 1M. At least make it something like $0.05 at a million and ramp it up at 5m or 10m to these larger prices. by 10m downloads you are much more likely a larger business or have figured out a way to properly scale your app.
oh and don't count updates, discouraging devs from maintaining their apps. Devs don't profit from an existing user updating, why should Apple?
I'm well aware of how the notarization process works on macOS. I considered supporting it for an open source project I was working on, but I abandoned the macOS version after I realized that I would have to pay Apple's annual $100 fee.
Notarization could theoretically be used for "good", even though I strongly dispute its effectiveness. It only ensures that someone's card is on file to potentially aid in investigation after the damage has been done. In the case of malware, that card is likely to be stolen anyway.
The more likely option is that Apple will start abusing notarization as a way to take down apps it finds objectionable in some way, even though they do exactly what they say on the tin.
Apple has a history of bad faith & malicious non-compliance, what they "think" is pretty much irrelevant at this point. We know what the spirit of the regulation is, and I trust that the EU regulators are interested in effecting those changes, otherwise what's the point of this entire ordeal if Apple only has to pay lip service to anti-trust intervention?
I am getting the same vibes from this as I did when Google was found guilty of abusing monopoly power. People lost their minds because “Apple is so much worse!” Never mind that the two lawsuits filed by Epic against Google and Apple were over different things and had different results because of it.
The DMA targeted different companies in different ways all under the rubric of combatting “gatekeeping.” They then went on to say how different companies were guilty of that crime in different ways. It would not surprise me at all if Apple has complied with what the EU singled Apple out for. It also wouldn’t surprise me if casual observers have conflated all the different flavors of gatekeeping that the DMA has directed at all companies.
Apple has probably calculated the risk of a legal challenge as 99%, the risk of losing it is 80%, but they expect a small/affordable penalty and at least a couple of years where they can hold onto their rent seeking in the iPhone space.
I don't see how this isn't effectively an app store in itself. If Apple can forbid an app from running on user devices, then they need to approve every app that is installed. More importantly, they are effectively blackmailing developers to pay them "per install," which is only enforceable through the notarization process.
That sounds an awful lot like an app store.
I agree, the EU will not like this. Too bad it'll take another 3-5 years to fix.
I don't have any IOS devices, but I'm expecting maybe $50 (and I'm being generous) to come as a result of a similar lawsuit on Google over over-charging for IAPs.
While I don't disagree that the EU won't like it, I don't see this as malicious compliance. The only reason this hasn't been in iOS up until now was distribution was already restricted through the app store. There was already signing going on. This just moves the signing to being an explicit step because distributors won't be signing for the App Store.
The problem with disabling notarization, is that it's something any trojan-horse malware author would have a glossy slideshow walking you through doing as part of the install process for their "meet sexy singles in your area and double your money instantly!" app.
And then you'd run the app, and it wouldn't blow up your phone, but just be a bit disappointing and something you'd delete — but meanwhile, the app would have used some 0day exploit to get a foothold outside the app sandbox, and so now your phone would be a silent node in a botnet, able to be C&Ced to DDoS targets or act as a VPN for nefarious account registrations or so forth.
(Did you know that there are many such botnets made of Android devices? But none so far for iOS devices. There's a reason for that!)
---
If it's not clear, by the way, Apple's "notarization" is, under the covers, just plain-old code signing. Just like every modern consumer OS has for apps, regardless of whether you get them from an app store or from the web. So that the platform can protect users from obvious viruses by just revoking the code cert.
Mind you, notarization is code-signing that requires you to submit your binary to Apple... but it's my understanding that this notarization still operates in two phases — a quick, synchronous phase, and a slower, asynchronous phase — and that the synchronous checks in the notarization process, before you get your cert signed, are only checks against the known signatures of various exploit techniques. (Again, just like every other consumer OS comes up with some way to get done — whether that be through required submission at signing time, or by submission of novel software by virus scanners that find the software on your disk, or even by web browsers as they download the software. Just try to develop Windows software, on Windows, without implicitly submitting binary "samples" to Microsoft through some route or another. It's very hard!)
Apple is somewhat unique among platforms, in having certain other virus-signature like patterns that their notarization backend takes note of, that won't trigger synchronous rejection, but rather will trigger Apple employees to do an async review of the application. (AFAIK, when this happens, you still get your app's cert signed right away; the cert might just get blacklisted some time later, if it turns out under closer human scrutiny that you were in fact doing something malicious.)
It is my understanding that the things Apple flags for human investigation, consist of use of certain system framework calls, that only very powerful and low-level system software should be doing — think, the sorts of calls unique to Virtual Machine hypervisor software, or to third-party file-system driver software. Rootkit code-smells, in other words.
Note that none of this is about what your app does for the user. Apple's notarization system — as Gatekeeper on macOS, or as part of Enterprise MDM iOS app deployment — has never suppressed or censored any app due to its nature. It's only about what it's doing that it's not supposed to be doing "according to what's on the tin." Apple is doing the same thing through notarization that the FDA does to foods and drugs: holding companies to their claims of their products being fit-for-purpose and non-adulterated.
(And although this is currently entirely a thing Apple is simply trusted to do in good faith, there's nothing stopping the EU from mandating that Apple's notarization going forward, consist of exactly these kind of technical checks and no more. I think that'd be a great idea, personally.)
This falls squarely under the exemptions for security reasons under article 6 sub 4 of the DMA.
> The gatekeeper shall not be prevented from taking, to the extent that they are strictly necessary and proportionate, measures to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.
Furthermore, the gatekeeper shall not be prevented from applying, to the extent that they are strictly necessary and proportionate, measures and settings other than default settings, enabling end users to effectively protect security in relation to third-party software applications or software application stores, provided that such measures and settings other than default settings are duly justified by the gatekeeper.
The "duly justified" might not be that far reaching. Sure, notarization seems like a valid cause, but there is no reason why it should be exclusively the provider of one specific app store who offers notarization. In particular, if it happens that it is more onerous or restrictive on non-Apple stores, that justification starts looking very shaky.
Looking forward to being required to use Chrome for basic browsing.
I already see numerous sites that with chrome variations on the old "we only support IE", but at least until now devs had to at least allow at least one other browser. Now they'll just say "here's a link explaining how to install chrome".
Which we know from the IE dominated era does not matter, people just switch to the browser they have to use. The overwhelming majority of users do not know what a user agent string is, let alone how to change it they just see an increasing number of sites saying "you need to use IE/chrome".
Moreover, again from the IE era - and we already see this with chrome - people make their sites work in IE/Chrome and then label any browser doing something different as broken so as people are increasingly forced to use chrome the degree to which spoofing does not work steadily increases.
> To qualify for the [MarketplaceKit] entitlement, you must:
> [...]
> Provide Apple a stand-by letter of credit from an A-rated (or equivalent by S&P, Fitch, or Moody’s) financial Institution of €1,000,000 to establish adequate financial means in order to guarantee support for your developers and users.
All I want is a F-Droid-esque store with sane apps. You know, open source apps, centrally built. No in-app-purchases and Chinese geotracking framework for something that is 25 lines of code to talk to some bluetooth gadget.
> The gatekeeper shall not be prevented from taking, to the extent that they are strictly necessary and proportionate, measures to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.
Looks like Apple tries to make a case to exploit this statement, which sounds exactly like a malicious compliance.
Ok, so I get that you want to be able to install random binaries on your phone, but I want to understand how you think that could happen without undermining the platform security model?
The inability of binaries to do malicious things on iOS is the result of the sandboxing and entitlement mechanisms of the platform. The store review and approval process is what stops applications from including entitlements that undermine the platform security. If you remove that step from the process there is nothing stopping an application shipping with the system entitlements that allow the application to read or write to other app data, or the entitlements to talk to system services without prompting permission dialogs, etc.
If you want to remove the review and approval systems that the App Store has (and it sounds like are going to be required for 3rd party stores?) you have to have an answer for that. Otherwise you just end up with the android malware problem.
You tell the user what entitlements or permissions are being requested at the point of the app trying to use them, stop treating the users like stupid children and let them make an educated decision about how to use the hardware that they own.
There are limits on Android anyway, what your side-loaded apps can do without you using a custom ROM or rooting the device is restricted somewhat.
Have you ever seen a random windows user? Do you think Grandma understands that?
I’m all for allowing power-users to side loads apps, but average user definitely needs to be thought as a child that will use 1234 as their password, and click ‘ok’ on every pop-up without even reading it.
Require the super scary "break app sandbox" entitlements to be activated behind an adb-command-mutated flag (or whatever the iOS equivalent of adb is) after jumping through the USB debugging hoops?
Which Android malware problem? Android has a permission system, every permission an app has needs to be approved by the user, and some permissions only system-apps can request.
There is no need for an app store review process to stop apps from requesting the "write to other application's data" entitlement; this can be enforced by the phone itself.
This is complete nonsense, the permissions are enforced by the OS, not by the store approval process, same for accessing the various parts of the file system.
To enforce permissions the OS needs to know what those permissions are.
That's what entitlements are, and the App Store review is what ensures you don't have bogus entitlements.
There are entitlements that, for example, control whether or not you can read the user's message database, the entitlement has to exist so that messages app and daemons can access that database. The App Store review process automatically rejects submissions with those, and other similar, entitlements. There are entitlements that allow reading and writing arbitrary data from arbitrary applications, because (for example) there are OS daemons and services that need to read/write all of that data (the settings app can report disk usage, there's the daemons that install and uninstall apps, etc), and again those entitlements are gated by store review.
The entire trust/security model for iOS starts at the store review disallowing system entitlements, and gating even allowed entitlements on appropriate notice in the app description.
Hopefully you can look at that list and get an idea of how removing the gate on applications being able to specify whatever entitlement undermines a huge component of the platform security model.
On Android system apps have permissions that user applications cannot have, this is easy to enforce by the OS, same thing for iOS, if Apple does not allow user apps to have a certain permission it would be just disable from the sandbox environment, it's not the store approval process that disallow user apps to became system apps or that would be hilarious honestly, at that point why even jailbreak the device.
Also I don't know what you mean by bogus entitlements, if it's not meant to be used by user apps than it wouldn't be available to user apps, if the app needs to have access to a certain feature that required a permission, it would need to ask gently the OS and the OS would need to approve it (maybe even after asking the user), or the app would not simply to be able to access it, so it's in the app's interest to have the permissions laid out correctly so that the OS knows. From the previous message you seem to believe that the app could just simply bypass the dialog asking the user for permission.
> The gatekeeper shall allow and technically enable the installation and effective use of third-party software applications or software application stores using, or interoperating with, its operating system and allow those software applications or software application stores to be accessed by means other than the relevant core platform services of that gatekeeper.
> The gatekeeper shall, where applicable, not prevent the downloaded third-party software applications or software application stores from prompting end users to decide whether they want to set that downloaded software application or software application store as their default. The gatekeeper shall technically enable end users who decide to set that downloaded software application or software application store as their default to carry out that change easily.
> The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services
How is requiring them to have access to $1M acceptable, or compliant with the legislation?
> The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper
Apple state the $1M requirement is to allow for providing support to customers. There is no allowance for doing that in the regulation, and no reasonable argument can be made that lack of customer support has an impact on the integrity of the operating system or hardware. I can understand scanning software or asking for it to be uploaded and signed, that could be justified. Not this.
As a government regulation, yes, you might need some liability insurance if you want to sell food for example. Apple is acting like it's a government here.
Separate any discussion about the "tone" of the article, could someone who is better at reading between the lines better than I explain the changes to Out-Of App Store payments?
Is it a 10-max 20% fee to Apple, no matter the distributor, in the EU? Or are those rules only for the App Store, and anything else won't be touched by commissions to Apple?
It sounds like the percent fee is for apps downloaded from the app store plus the 3% if you use apple payment processing. Then theres a .5 euro annual fee per user over 1 million no matter which market the app was downloaded from.
> Core Technology Fee — iOS apps distributed from the App Store and/or an alternative app marketplace will pay €0.50 for each first annual install per year over a 1 million threshold.
This seems unusually high. I would expect that a large number of apps meet this threshold.
Am I correct in thinking this applies to apps that aren't monetized?
> A first annual install may result from an app’s first-time install, a reinstall, or an update from any iOS app distribution option — including the App Store, an alternative app marketplace, TestFlight, an App Clip, volume purchases through Apple Business Manager and Apple School Manager, and/or a custom app.
It is not per update and the most significant thing is that it is also for apps that get distributed outside the app store. Which is the real issue and that is definitely insane
This counts one install per 12 month period, whether update or fresh install (new user). So it’s €0.50 per user device. For application providers that opt into the new terms and release updates every two weeks like clockwork even if there are no meaningful updates for 300Mb application bundles (Facebook, Duolingo, a few others)…this is likely a fair cost (and my suspicion is that yes, there's a premium, but it's probably not Apple's usual 20%+ premium on products since many applications would not be subject to this fee at all, even under the new terms).
> Am I correct in thinking this applies to apps that aren't monetized?
You are correct according to their calculator [0]. If I say I have 2M annual installs (1M over the "free tier") and no in-app purchase it will cost $45,290/mo
Looking at Unity wanting to charge 20 cents and the game development industry falling over itself to explain how that will never ever work for them... I dunno, maybe other app types (firefox, a mastodon client, osmand, local public transport.. looking at random examples from my homescreen) make enough money from their users and this will be doable for them when microtransaction-laden games couldn't make 2/5ths of that price work out
Unity wanted to charge for every single "install", where that category was defined so broadly that even loading the game in a web browser was an "install", and someone downloading and deleting and downloading the app over and over on a device was also repeated "installs".
Here Apple is tracking an install across the entire user account per year, so even if you have tons of devices and install the app on every single one of them, that's still just one "install".
Unity kept revising it over and over again so these two got removed IIRC:
> that even loading the game in a web browser was an "install", and someone downloading and deleting and downloading the app over and over on a device was also repeated "installs".
Hi, bad person here, happily building apps for their devices.
They missed out on €0 because government entities, non-profits and educational institutions are exempt from the install fee.
Alternatively you can also just stick with the App Store and pay 15%/30% over revenue without install fee, which would also be €0 in your hypothetical.
Free apps aren’t exempt. The fee is only for EU users. If you take the EU iOS market share of 33.3% [1] and the number of EU citizens (448 million) [2], you get ~150 million — and that’s assuming 1 smartphone/citizen, which is probably too much.
> that’s assuming 1 smartphone/citizen, which is probably too much.
sure kids <5 years old probably don't own smart devices. But many those EU citizens will own also ipad, apple watch and probably some older devices that they use from time to time (as a backup)
Non-iPhone installs don’t count. Installs outside the EU don’t count either.
It’s only first unique install in a 12 month period on iPhones in the EU and then only the ones that are above 1M that are charged €0.50 in monthly installments.
ok maybe iPad and apple watch doesn't count but still multiple iPhones belonging to the same user counts as separate install. And it's not only unique first install:
"A first annual install may result from an app’s first-time install, a reinstall, or an update from any iOS app distribution option — including the App Store," [0]
so updates and reinstalls count as well - just all installs, reinstalls, updates in 12 month period counts as one. But next year if you just make a bug fix to still support new iOS version that update will be paid as well to all your user install base.
So apple wants to require they approve your app and then charge you €0,5 for every time it is installed for the privilege of avoiding using their infrastructure. It is honestly insane. I don't know the DMA in detail but I hope it is not and gets smacked with fines. And I hope if this is allowed the DMA gets updated so this is no longer allowed.
Yeah well you are benefiting for Apple’s hardware and software so you need to pay. Can’t be a free-loaded just because you want to earn that extra bit of money while increasing the attack vector for the end user.
Apple defenders keep approaching these conversations like, "okay, you think you want to actually own your phone, but have you considered that sideloading would be just like <insert other awesome thing>?"
Nobody likes the pre-bundled garbage smart TV system; TVs where you can install arbitrary apps and use the same remote to operate them would be a better experience. As TVs have gotten more universal standards and APIs that any device can hook into, they've gotten better. We're all glad that TVs have arbitrary HDMI in, we like being able to use any game console with our TVs without needing to care about whether the console manufacturer has an agreement with the TV manufacturer, we don't like when we get a TV home and figure out it doesn't work with a service we already own.
"Apple is like those 'smart' TVs you buy where you get home and discover that for some bullcrap reason Youtube doesn't work and your home assistant can't control the volume" -- may not be the strong defense of Apple you think it is?
Do the people making these comparisons not understand that the comparisons all sound really good? It's like, "do you expect to be able to install any app on a console? Do you expect your smart phone hub to be able to work with any smart device? Or what, you buy an e-reader and expect to be able to just put any book on it?"
Yes, I do. I don't know, don't threaten me with a good time.
At least the security arguments make some sense, even an argument that Apple has some special right to profit off of "access to the users" is more defendable. But I feel sometimes like Apple apologists are living in an alternate world where they think that if Microsoft launched a console that could play both Xbox and PS5 games that consumers would all be saying, "we don't want that, that feature makes the Xbox worse."
Why do you have the expectation to install whatever you want on a smart TV? Just because there is a computer chip inside it?
I find it somewhat absurd that if you put a computer chip inside of a gadget you are now suddenly expected to support/enable installing literally anything.
If the consumer cares so much about that, they can buy something else.
> Just because there is a computer chip inside it?
Sort of, yes? I mean, if you've got a general purpose computing device stuck inside of a TV, it's kind of nice to be able to use it as a general purpose computing device.
And I mean, we have open standards for things. I'm not saying that companies should have to manually support everything, but if you ask me if it's a desirable feature or if it would be better for TVs to use common platforms that can be targeted regardless of hardware, what do you want me to say? That it's a bad thing if I can control the volume on my TV using a universal remote? That it's good that different smart assistants don't work with the same music services? Because having a smart assistant say that you can't use a music service because some CEOs got into a fight with each other actually stinks and I hate that.
> I find it somewhat absurd that if you put a computer chip inside of a gadget you are now suddenly expected to support/enable installing literally anything.
Okay, but you understand that every consumer would view that as a feature, right? You understand that when you say, "imagine if every app worked on your TV" pretty much everyone is going to say, "that sounds great, yes please."
Never before has any console or TV ever advertised less compatibility as if that is a desirable feature that customers should want. Never before has Microsoft gotten up on stage and said "we have a hundred launch titles" and then Playstation gotten on stage and said "hah, that's amateur talk, we have 45 launch titles, we're clearly winning this fight."
You're arguing that this is a slippery slope, but you're also arguing that there's chocolate cake and puppies at the bottom of the slope. Generally speaking, using cross-compatible standards that allow people to interop with devices without asking the manufacturer's permission is a thing that I want, yes. I like that cars use the CAN-BUS standard, that's a good regulation. I like that I can have 3rd-party repair shops for my car, I like that I can buy a stereo system and hook it up and it doesn't matter if the stereo manufacturer has an agreement with Toyota. I like that Samsung and LG TVs both use HDMI ports and I don't have to ask "which computers can I plug into this" when I buy a TV. And of course consumers generally like that we use universal USB standards now and we've gotten past every device having incompatible cords. These are all great things to have.
You can argue whatever you want, you can argue that this is an abridgement of Apple's rights. People might believe that.
But just be aware that your slippery slope sounds less like a slippery slope and more like some kind of prize, and if you're not careful people might start to say, "wait, you're saying that if we open up iOS devices we could then do the same thing to consoles, and I would stop needing to buy 3 separate consoles just to play different games? And I could buy cheap controllers instead of needing to spend 60-80 dollars for an official one? And I could play games with people who are on different consoles? So where do I sign up for that?"
I wonder what happens if you travel from the US to EU and then back. Will you be able to install alterative browser while in EU and then it gets blocked?
It will apply to EU citizens probably, so who have the location of the Apple account in a EU member state. You can change the location, but only once per half year.
> Core Technology Fee — iOS apps distributed from the App Store and/or an alternative app marketplace will pay €0.50 for each first annual install per year over a 1 million threshold.
If I'm reading this right (and I did double check this with ChatGPT [0]) if you have an app with two million unique installs annually, you owe Apple 500 000 euros. That seems to include free apps as well.
Is there any record of another browser engine being summited to the app store and the outcome? AFAIK when I worked at Mozilla I'm not aware that Gecko was ever submitted even though I saw a working local build.
Even the WebKit wrapper browsers (including Chrome and Firefox) didn’t have access to JIT until iOS 8 when WKWebView was introduced. UIWebView is in-process and not allowed to use JIT.
2,614 comments
[ 3.0 ms ] story [ 484 ms ] threadBut, this is still better than not doing it at all.
Apple is the one gatekeeping
Any idea if this means you can actually choose a different browser, or are you choosing a different WebKit wrapper (e.g. the current version of Chrome on iOS)?
The changes include more than 600 new APIs, expanded app analytics, functionality for alternative browser engines
> Apple is giving app developers in the EU access to NFC and allowing for alternative browser engines, so WebKit will not be required for third-party browser apps. Apps will be able to offer NFC payments without using Apple Pay or the Wallet app through Host Card Emulation. Apps can also access field detect, and a default app can be set to activate when an iPhone is placed near a terminal.
Although this only changes things for us developers. Regular users really don’t care what browser is running the web pages they’re looking at, everyone who downloads chrome does so to get their synced bookmarks and history.
https://www.macrumors.com/2024/01/25/ios-17-4-alternative-ap...
This is ahistorical. Regular users switched to Firefox and Chrome in droves from IE. And it wasn’t to sync their bookmarks. It was because they provided a much better experience.
If Blink or Gecko are able to provide a better experience than WebKit on iOS that would certainly prompt many users to switch to browsers using those engines.
- fullscreen on iPhone
- WebBluetooth
- WebUSB
- WebMIDI
- WebSensor
- Web Push notifications - that are less limited than in current safari
- WASM simd
- WASM multithreading
- WebGPU
This will make PWA apps less crippled.
i know these guys https://fingerprint.com use so many of these when fingerprinting.
Regular users care about the experience of the browser. A superior rendering engine can potentially improve this experience.
That's probably true for quite a lot of people in those categories.
They want something that reliably gets them from A to B and back, with occasional side trips to C, D and E. They want something that does that in a way that matches their personal style. They want something that isn't going to cost them an arm and a leg to run.
Forty, fifty, and sixty years ago people cared a lot more. Starting really in the mid-90s, that changed. Nowadays, there are probably as many gearheads as there were decades ago, but as a population they represent a smaller percentage. And there's a tiny percentage of people who care only so that they can mod their engines to run less efficiently so they can pwn the libz.
Inasmuch as people do care about the 1.3 4 banger — they choose it because it generally runs more reliably over time with fewer litres burned per 100km.
> They want something that isn't going to cost them an arm and a leg to run.
Pick a lane.
Most people who buy cars don't actually give a shit how many cylinders, spark plug configuration, or hamsters are involved in the engine. They want to know that it will work and not cost them too much in fuel, maintenance, insurance, and repairs. They want it to "look good" for their sense of style, and they want it to be a "safe" car.
In order, it's usually price, style, then fuel efficiency (not engine, but whole car fuel efficiency), insurance cost, and everything else. For some people, it ends up being style, price, then everything else.
But if you are going to spend 10k$+ on a car, then you start caring, A LOT. I've seen the change from when I was a student willing to take any crap on wheel, vs when I had some money to burn on a car and I spent weeks looking at everything to end up buying a 10k$ 20yo Porsche 911 :D See, I didn't even look at the fuel cost: only the engine perf per dollars. And it cost me an arm and a leg to run, in Hong Kong where the fuel cost is the highest in the world !
People don't work as rational machines balancing perfectly cost and profit in a constant manner over time. It's more a constraint compromise game with a repressed desire for luxury that seem to drive us: you'll buy what you can afford and within those boundaries you will choose comfort and design over economic optimization. Like when people buy an iphone, evidently they didn't look at all about cost for performance and choose something economically suboptimal but luxurious.
Accept it and you'll start liking them more I think.
I did indicate that personal style comes into it, and I don't think that it's not an emotional decision. But there's a reason that Camry, Corolla, and Accord show up in bestselling car lists every year (and similar models elsewhere in the world), and it has nothing to do with "caring about what's under the bonnet".
There is a subset of people who do care about the engine, but they don't do so because they actually know a damned thing about how the engine runs, but because a big engine makes them feel powerful in their oversized pickemup trucks that never carry a load in the bed.
Your assertion that people who buy an iPhone aren't looking at cost for performance is partially correct, but only insofar as most (I mean > 99% of people including people in tech—including myself) wouldn't be able to objectively measure phone performance worth a damn. Anecdotally, I know a number of people who have switched from android devices to iPhones because they see their friends holding onto the same iPhones for years without complaints, yet they can't see the benefit of holding onto their android phones and realize that they may be spending a bit more up front, but are getting more possible useful years of phone updates than had been available in Android until promises made (and several years to see if they are kept) just few months ago.
Yes, I also know people who are enamoured of their Android devices and have their own smugness about what they think that they've gotten over the "sheeple" who buy Apple devices, but most people really don't give a shit about the phone operating system any more than they do about whether the engine in their car is 3, 4 or 6 cylinders (people who by v8s are intentionally buying a v8) or whether it happens to just be a family of hamsters running around underneath—as long as it runs.
Being the system default was obviously very convenient for customers and there would be a very high bar for any other payment app to compete, but Apple wanted to make absolutely sure there was no possible competition.
As a regular user - I do.
But they simultaneously open the door to other browser engines, so I imagine Firefox at least will release their app with a new browser engine down the line.
https://developer.apple.com/support/dma-and-apps-in-the-eu/#...
[0] https://kagi.com/orion/
Orion uses WebKit and has uBlock origin so I'm not so sure it's a limitation of WebKit itself.
Write enough code and you can make these extensions run on IE6. :P
Just get the Wipr Safari extension, haven’t seen an ad since I got it the year extensions were introduced.
As a result, I would expect Chrome/Firefox/Edge/Opera to ship their own browser engines on iOS but am doubtful that many other apps will embed Chromium/Gecko with the possible exception of apps that only operate in the EU.
Luckily I’m extremely close to having them inducted into the fruit cult just by having them play around on my dev iPhone when I’m not working. So fingers crossed it happens before get pushed over the edge.
As an aside: what kind of OS allows apps to create read-only contacts in the Contacts app, ffs…
I understand the "WebKit wrapper" for iOS criticism and do want different rendering engines available (e.g. Firefox's) and yet...
The worse thing about Firefox for iOS is the wrapper part, not the lack of rendering engine choice part. The UI of Firefox on iOS is inconsistent and buggy, and syncing doesn't sync well, etc. I doubt using FF's own rendering engine instead of WebKit would help the situation, as it'd drain engineering resources away from making the "wrapper" more usable.
I've always used Firefox, on Mac, Linux, Windows, Android, everywhere I can, but I find myself using it less and less on iOS... and it's not because of the rendering engine!
But since this change for the DMA will allow FF to use its own rendering engine (in the EU), hopefully maybe it'll reenergize the development of FF and improve the "wrapper" part more - even for non EU users!
I do agree, the Firefox iOS UI is clunky, but I find it useful for stuff where I want to sync passwords or tabs. I use Safari for browsing the web casually because it's nicer, and the feature of swiping between tabs is so convenient.
Just to correct the common misconception. It is browser vendors that need to build web extension API support on top of WebKit. Orion browser [1] did this both for macOS and iOS . The support is still in beta and improving with each new release. iOS support remains limited to what is possible to achieve with a JS wrapper. Nothing prevents Firefox from doing the same and offer at least partial web extension support on iOS.
[1] https://kagi.com/orion
How will users be able to understand the options in front of them unless they are presented with it in the first place?
You can't make people care and constant notifications are just fucking horrible / doesn't help IMO.
And I'm honestly not sure most people would understand anyway ...
My micro-ISV stopped shipping an iOS app a few years ago when Safari's support for PWAs made it viable to reimplement our app as a PWA so that we no-longer needed to deal with App Store hassle (faffing around with a Mac Mini we'd only use a few times a year, confusing certificates/entitlements/etc, not to mention the capriciously enforced store app review policies).
...but I'm probably just being nostalgic for the early days of indie iOS apps. Those times are long gone, perhaps Apple actually isn't interested in attracting small devs to their platform anymore?
Knowing that you can configure your phone's behavior should be a basic point of technology literacy. I know that it isn't at 100% today, but what percent of users are now going to have yet another forced decision to make before using their phone for the first time, just so a minority of technology illiterate users can be "educated".
This is an absurd comparison. The choice of picking the default web browser, a complex pieces of critical software on everyone's mobile device, is categorically different than almost every single one of the other preferences on the device. You'd have to be completely insane to claim that e.g. the preference of whether a double-tapping space on the soft keyboard should insert a period is remotely comparable to choosing the default web browser.
What a line...
Isn't this the main argument for a locked down app store? That Apple CAN ensure the safety of third party apps on its store?
The chutzpah of using this argument to keep the App Store locked down when Apple used the same argument to not have an App Store in the first place is incredible.
So no, Apple isn’t factually correct.
In fact, it’s very possible that Gecko or Blink have more secure engines than WebKit. It’s very possible someone can create an App Store that is even more vetted than Apple’s and eliminates scam apps and games whose only purpose is to separate you from your money.
So it’s not only not accurate, it’s probably diametrically the opposite of accuracy and is false.
This is just not true.
Maybe for experienced tech people like on HN.
But the worry here is that you can be tricked into installing all sorts of dangerous malware. Especially now that casual users have been trained to believe that apps are safe.
The DMA absolutely opens up all sorts of new vectors of attack. The question is ultimately a philosophical one -- whether you think the increased freedom is worth the increased risk. Not just for yourself, but for the average non-tech-expert consumer.
You might think the tradeoff is absolutely worth it, but that doesn't mean that it still hasn't significantly increased security risks.
You need to think about this more carefully: there absolutely is an increase in risk by allowing other parties to run native code on your devices. This guarantees that people will be socially engineered into installing malware, intrusive vendors like Facebook will try to force users to add their stores to bypass privacy restrictions, and employers/schools/etc. will try to force their users to use their spyware for similar reasons.
Now, a not unreasonable position is that this is acceptable but that should be an honest discussion starting with accepting the risk so you can gauge whether it’s a reasonable trade off or whether there are other mitigations. For example, notarization is a useful way for making it harder to install code on someone’s device which the OS vendor cannot see if it’s later associated with malware or which cannot be traced back to a source developer. The next time someone is breached, it’s useful to be able to tell whether the Firefox.app they have installed is an official Mozilla build or pretending to be one.
> (1) Digital services in general and online platforms in particular play an increasingly important role in the economy, in particular in the internal market, by enabling businesses to reach users throughout the Union, by facilitating cross-border trade and by opening entirely new business opportunities to a large number of companies in the Union to the benefit of consumers in the Union.
> (2) At the same time, among those digital services, core platform services feature a number of characteristics that can be exploited by the undertakings providing them. An example of such characteristics of core platform services is extreme scale economies, which often result from nearly zero marginal costs to add business users or end users. Other such characteristics of core platform services are very strong network effects, an ability to connect many business users with many end users through the multisidedness of these services, a significant degree of dependence of both business users and end users, lock-in effects, a lack of multi-homing for the same purpose by end users, vertical integration, and data driven-advantages. All these characteristics, combined with unfair practices by undertakings providing the core platform services, can have the effect of substantially undermining the contestability of the core platform services, as well as impacting the fairness of the commercial relationship between undertakings providing such services and their business users and end users. In practice, this leads to rapid and potentially far-reaching decreases in business users’ and end users’ choice, and therefore can confer on the provider of those services the position of a so-called gatekeeper.
It's a bit long for HN comments (although 257 words is about a minute of reading) but I didn't really know what could be fairly cut out
Full text: https://eur-lex.europa.eu/eli/reg/2022/1925/oj
Maybe somebody more familiar with the details can explain. It's hard to compare when the structures are different like that.
> To help keep users safe online, Apple will only authorize developers to implement alternative browser engines after meeting specific criteria and committing to a number of ongoing privacy and security requirements, including timely security updates to address emerging threats and vulnerabilities.
This criteria seems arbitrary. Doesn't this allow Apple to arbitrarily prevent competitor engines like Blink and Gecko?
On the other hand they will likely use this to deny all ‘niche’ browser engine without a structured organization behind them (think Ladybug, maybe servo etc.)
https://webkit.org/blog/14787/webkit-features-in-safari-17-2...
Yes, not as frequent as monthly releases, but Apple shipped 7 Safari updates on iOS in 2023.
https://webkit.org/blog/13691/webkit-features-in-safari-16-3...
https://webkit.org/blog/13966/webkit-features-in-safari-16-4...
https://webkit.org/blog/14154/webkit-features-in-safari-16-5...
https://webkit.org/blog/14416/webkit-features-in-safari-16-6...
https://webkit.org/blog/14445/webkit-features-in-safari-17-0...
https://webkit.org/blog/14735/webkit-features-in-safari-17-1...
https://webkit.org/blog/14787/webkit-features-in-safari-17-2...
Did you notice the new Safari 17.3 Apple shipped 3 days ago?
> Yes, not as frequent as monthly releases, but Apple shipped 7 Safari updates on iOS in 2023.
That's a very recent change: prior to 2022 Apple had far fewer updates to Safari on both macOS and iOS - and still witholds Safari updates from older iOS versions - for example, there was only 1 macOS Safari update per year between 2008 and 2015, and only 2 updates per year from 2015 to 2022; while things were just as sparse on iOS.
The data is all here: click on the "Date relative" view on any of the items on https://caniuse.com/?search=webkit
I get it. Apple used to update Safari infrequently. In the past two years they've increased how frequently they update. "Apple patch their browser twice a year at best" is no longer true.
Here's the options:
1. Apple was wildly irresponsible with the security and privacy of their users for a decade and a half, despite this childish press release about how EU is making their users less secure.
2. The risk profile of browsers only changed in the last couple of years, and until then it was totally safe for iOS browsers not to be patched regularly.
3. Apple doesn't particularly prioritize their users' security, but are setting up one more malicious compliance roadblock for anything that could threaten the tens of billions in pure profit they squeeze out of the Safari monopoly.
Apple's handling of Safari mirrors Microsoft's stated plans for Internet Explorer back when Windows XP (and IE6) launched in 2001: they said they'd treat the browser as a core OS component that would only receive major web-platform updates with major OS releases (hence why we had to wait five years between IE6 and IE7, during which Firefox saved us from a mediocre web experience).
...could be worse: could have been like Outlook which has been stuck on Word's HTML rendering engine since 2007 right through until today's "New Outlook" rewrite - that's that's got to be an unbeatable record for the "world's most stagnant web-browser".
I think what would be helpful if there was a concept of a "system admin" profile that you could apply onto any device/computer. Non-technical users may want Apple to be the 'sysadmin' and only use the Apple store, use Apple recommended apps, etc. - Kinda like the an MDM profile.
Any other vendor, as a paid/managed service, could supply a more permissive app store, and manage updates, etc. Companies who issue work devices would have their own "profile" to manage the device.
It’s an completely invalid comparison.
But even if we accept that comparison, how about OSX? OSX has been tremendously secure through its existence and it allowed users to do whatever the F they wanted to do with it until recently.
all legitimate Windows devices actually get updates.
kernel exploit on your Android phone? welp hope your oem does something
1. Basic Device Information:
Device Name: App can access the device's name, like "John's iPhone." Device Model and OS Version: App can identify the device type (e.g., iPhone 14) and iOS version. Carrier Information: App can access network provider details. Wi-Fi Information: App can determine if Wi-Fi is enabled, but not specific network names or passwords. Battery Level: Accessible without explicit permission: Apps can access the current battery level without needing explicit user consent.
2. Contextual Information:
Current Language: App can adapt content based on language settings. Time Zone: App can display time-related information accurately.
3. Necessary Functionality:
Push Notifications: Apps can receive push notifications without explicit permission, but users can control this in Settings. Local Network Access: Apps can automatically access devices on the same local network (e.g., a printer). Background App Activity: Some apps can function in the background for tasks like downloading updates or syncing data.
4. Permissions Granted During Installation:
Keyboard and Siri: Apps can request full access to the keyboard and Siri without additional prompts.
5. Accelerometer:
No permission required: Unlike many other sensors, the accelerometer on iOS devices does not require explicit user permission for the app to access its data. However, there are some limitations:
Foreground access: Apps can only access the accelerometer while they are actively in the foreground. Background access is restricted.
Privacy concerns: While user consent isn't explicitly requested, some users might still find accelerometer access concerning due to its potential to reveal information about device movement and tilt. Transparency in app descriptions and responsible data handling are crucial.
6. Barometer:
No permission required: Similar to the accelerometer, the barometer also doesn't require explicit user permission for access. It functions alongside the Core Motion framework, used for motion and environment-related data.
https://www.cvedetails.com/top-50-products.php
You defending them with a ridiculous talking point about scary viruses and grandma doesn't work anymore, sorry!
And this seems understandable to prevent a proliferation of 100's of "browsers" trying to steal your data. You actually have to be developing something legit -- not just reskinning a browser engine and leaving it.
You can already do that today (yes, on iOS) by using your own developer-signing certificate (because if it's from github, you can build it from source; or re-link/assembly prebuilt linkable binaries if you really feel like it).
Remember the vast, vast majority of iOS users are people like (I assume) our parents - or people we knew in the late-1990s/early-2000s with an excessive number of Internet Explorer toolbars and Bonzi Buddy. I support Apple's mission to keep crap like that off their platform, but Apple sleepwalked into prompting this regulation of their app-store because they weren't the good-stewards they said they'd be - so I'm ambivalent about the whole thing.
That still requires you to pay Apple for a developer account ($99 USD/year), requires you to own a Mac, and requires you to abide by all of Apple's rules. Meaning that Apple _can_ still prevent you from installing a sketchy browser downloaded from Github since they control everything about the build-and-signing system on the iPhone.
https://developer.apple.com/help/account/create-certificates...
https://developer.apple.com/support/certificates/
Not if you want to use a JIT compiler or multiprocess support
Not if you want a browser with a JIT Javascript compiler, which for better or worse is a basic requirement for a broadly usable browser.
It’s just a niche, so no one bothered porting a whole ass browser with its JIT compiler and GC and whatnot to ios for that 3 users. Now it can change.
In AltStore's case, this means you need to be on the same wifi network as the computer running AltServer. I don't know whether it would be theoretically possible to do this over WAN, but it definitely isn't practical at a large scale.
Tailscale unfortunately doesn't support it...yet?
https://github.com/tailscale/tailscale/issues/1013
They do the same thing with the VPN entitlement. If you want to filter network traffic on-device, you have to apply for it and identify yourself to Apple. If they didn't do this China would be banning iPhones left and right.
A whole bunch of tech guys fundamentally don’t understand how naïve many users are and how hostile the environment is.
What we need is a fundamentally different model for device security in our users. Their device is insecure and everything they might do online will expose them to an attacker.
But that overturns 40 years of UI improvement so people can use their devices without thinking.
“I should be allowed to…” will always reek of entitlement. Pick your hardware and platform on your likes and needs. There are plenty of options to choose from.
That's the point, but they sound nice
These requirements are things like "Use memory-safe programming languages", "Adopt the latest security mitigations", if you ship your own certificate trust you should "provide information on how a root certificate authority (CA) can apply to become part of the program".
All seems like pretty basic conditions designed to ensure that only Mozilla and Google can comply.
To be honest, the browser engine stuff seems significantly more robust and permissive that I was expecting.
I wonder if Apple would be allowed to ship WebKit if they enforce this requirement under the spirit of the EU laws that made them change their minds.
> Use memory-safe programming languages, or features that improve memory safety within other languages, within the Alternative Web Browser Engine at a minimum for all code that processes web content
Emphasis added.
Why is it any of Apple's business how many test suites a third party browser can pass?
Why can't iPhone users run Links if they want to? Why can't they run a browser without Javascript support? Why can't they try out Ladybird to see how development is progressing?
Like, even from a pure Apple-is-greedy perspective I don't understand the point of this.
In the end it's not a big impact on apples revenue if some people run chrome or Firefox.
The store part on the other hand is really sketchy.
In short, browsers will have higher privileges that normal apps, as they can execute arbitrary code in memory, so they are naturally held to a higher standard.
To be honest I am happy about this. I don't trust a random banking / government / public transport app contracted out to the lowest bidder to be safe from all buffer overflows or other memory safety issues, so making sure they are sandboxed away from executing arbitrary code is a good thing.
No more than any other app. It runs anyway in the app sandbox, and can only access the resources that are accessible from the app sandbox itself. For the application to gain root privileges it would need to exploit a flaw in the sandbox itself, something difficult these days.
Android allows applications to map memory pages as executable (in fact you can also launch any Linux executable as a subprocess) and there was never an issue about security: if you don't have a rooted phone you don't have chances to get code running as root, since everything runs in the app container.
And if there is a flaw that allows escaping from the app sandbox, it can probably be exploited without being able to map memory pages as executable anyway, since it will probably be a flaw in a kernel system call or library function.
So really: this was always a limitation that Apple did impose to not allow in practice competing browsers in the Apple store, since a browser to be efficient this day needs to compile code as JIT, as well as not allowing applications that benefit for JIT execution (such as emulators or compilers).
https://v8.dev/docs/wasm-compilation-pipeline
Apple approves alternative marketplaces.
Apple approves all apps on all marketplaces.
A JIT compiler is not above the App’s sandbox permissions.
Does anyone know if notarization is something you could turn off? If you can't, then I'm pretty sure the EU won't like this; obviously "malicious compliance."
Not defending Apple per se (they sure don’t need help) but going with the public statements of both Apple and the EU leading up to this.
It's not the notarization itself that's an issue, but the fact that it's also the enforcement mechanism for collecting fees per-install. It's basically a mafia protection racket where you need to pay Apple to say you're not malware.
“Officials from the European Commission, the EU’s executive body, have been holding meetings in recent months with Apple and other tech companies to discuss the new rules. Apple hasn’t provided a final package describing its solution to the commission or tested its plans with market participants.
Once it does, the commission will review the full package to look at whether it will make the market more open and contestable, and whether the company’s plans meet all the individual provisions of the law, according to a person familiar with its plans.”
We’ll see how that goes.
[0] https://archive.is/Hk39s
Apple did threaten to cut off Epic's ability to notarize Unreal Engine[0], until ordered not to by the court[1].
[0]: https://www.macrumors.com/2020/08/17/apple-terminate-epic-de...
[1]: https://www.theverge.com/2020/10/9/21492334/epic-fortnite-ap...
In fact they did so deliberately to help them in their court cases.
Luckily the court stopped them retaliating in this case, but it gives me reason to be concerned about expansion of the "it's Apple's device and will always act in Apple's interests over the owner's" mentality from iOS towards Mac desktops.
The one finding in Epic’s favor was that Apple violated California’s Unfair Competition law by preventing Epic from linking to an outside payment method.
Epic could have sued over that at any time.
Do you think they would notarize a PornHub app?
I wouldn't be 100% confident there. I wouldn't be surprised if porn got through, but plenty of other companies have blocked such content under "security threats".
App Store Review = Content and Quality
Notarization = Safety and Security
And Apple only allows certain kinds of apps through their notarization process. They can't have pornogrpahy, they can't allow things that could break copyright etc.
You can also right click an individual unnotarization .app bundle and select `open`, then affirm your intention in the scary warning prompt.
P.S. The Mac also lets you disable SIP, install unsigned kernel extensions, and rewrite kernel memory to your heart's content. This is admittedly a bit more involved.
It's a protection racket - pay us and we won't flag your app as malware.
Where is the line? Surely at some point, the choice is so unreasonable that Apple has effectively forced developers into "the old rules," thus circumventing compliance with the new rules, which may as well not exist if no developers can afford to play within them...
I never write code for Windows and actively tell any client I have to not use it if they want my product. If they don't want it so much - there are plenty of alternative. If they really want it - they will use the OS I write the app for.
Once tooling catches up, in theory, developers don't have a contractual relationship with apple anymore, except to get notarized.
The devices belong to the users apple sold the hardware and licensed the software to them not app developers. They could charge the users but obviously this would be a terrible idea.
Getting notarized will either directly require payment of the platform fee or will force the use of the official tools which will mandate that.
That is absolutely a win to the common people. And it’s not like other companies taken a hit - they can either stay on the AppStore and have their finances go through their “taxing”, or create an alternative store and find a proper monetizing strategy. They can calculate what makes sense, but it makes it hard for Facebook/google to exercise their network effect for creating a new app store at the expense of users.
In that sense, the old system is OK as well, no?
OK is an understatement.
But those would be the requirements of those platforms.
I can make and publish games for the Pico-8 console without any requirements. Could you imagine if Microsoft had the ability to veto any Pico-8 game I wanted to make?
I think the issue here is just the additional payment, not the notarization. That part is hopefully rejected as a non-solution to the issue.
To be honest, it's not even like I care that much about the additional payment. Scummy but expected. It's more that the current prices, similar to Unity, seem to pretty much punish any innovative idea that takes off, to a point where Apple will not just make the product unproftiable but bankrupt the developer in the process. Most mobile apps are free so people underestimate how quickly you can hit 1M. At least make it something like $0.05 at a million and ramp it up at 5m or 10m to these larger prices. by 10m downloads you are much more likely a larger business or have figured out a way to properly scale your app.
oh and don't count updates, discouraging devs from maintaining their apps. Devs don't profit from an existing user updating, why should Apple?
Notarization could theoretically be used for "good", even though I strongly dispute its effectiveness. It only ensures that someone's card is on file to potentially aid in investigation after the damage has been done. In the case of malware, that card is likely to be stolen anyway.
The more likely option is that Apple will start abusing notarization as a way to take down apps it finds objectionable in some way, even though they do exactly what they say on the tin.
I think this is another classic case of people getting mad over what they think the law should be vs. what the law actually is.
The DMA targeted different companies in different ways all under the rubric of combatting “gatekeeping.” They then went on to say how different companies were guilty of that crime in different ways. It would not surprise me at all if Apple has complied with what the EU singled Apple out for. It also wouldn’t surprise me if casual observers have conflated all the different flavors of gatekeeping that the DMA has directed at all companies.
That sounds an awful lot like an app store.
I agree, the EU will not like this. Too bad it'll take another 3-5 years to fix.
Sounds like we’re getting a fat paycheck from Apple via the EU in the meanwhile then.
I don't have any IOS devices, but I'm expecting maybe $50 (and I'm being generous) to come as a result of a similar lawsuit on Google over over-charging for IAPs.
And then you'd run the app, and it wouldn't blow up your phone, but just be a bit disappointing and something you'd delete — but meanwhile, the app would have used some 0day exploit to get a foothold outside the app sandbox, and so now your phone would be a silent node in a botnet, able to be C&Ced to DDoS targets or act as a VPN for nefarious account registrations or so forth.
(Did you know that there are many such botnets made of Android devices? But none so far for iOS devices. There's a reason for that!)
---
If it's not clear, by the way, Apple's "notarization" is, under the covers, just plain-old code signing. Just like every modern consumer OS has for apps, regardless of whether you get them from an app store or from the web. So that the platform can protect users from obvious viruses by just revoking the code cert.
Mind you, notarization is code-signing that requires you to submit your binary to Apple... but it's my understanding that this notarization still operates in two phases — a quick, synchronous phase, and a slower, asynchronous phase — and that the synchronous checks in the notarization process, before you get your cert signed, are only checks against the known signatures of various exploit techniques. (Again, just like every other consumer OS comes up with some way to get done — whether that be through required submission at signing time, or by submission of novel software by virus scanners that find the software on your disk, or even by web browsers as they download the software. Just try to develop Windows software, on Windows, without implicitly submitting binary "samples" to Microsoft through some route or another. It's very hard!)
Apple is somewhat unique among platforms, in having certain other virus-signature like patterns that their notarization backend takes note of, that won't trigger synchronous rejection, but rather will trigger Apple employees to do an async review of the application. (AFAIK, when this happens, you still get your app's cert signed right away; the cert might just get blacklisted some time later, if it turns out under closer human scrutiny that you were in fact doing something malicious.)
It is my understanding that the things Apple flags for human investigation, consist of use of certain system framework calls, that only very powerful and low-level system software should be doing — think, the sorts of calls unique to Virtual Machine hypervisor software, or to third-party file-system driver software. Rootkit code-smells, in other words.
Note that none of this is about what your app does for the user. Apple's notarization system — as Gatekeeper on macOS, or as part of Enterprise MDM iOS app deployment — has never suppressed or censored any app due to its nature. It's only about what it's doing that it's not supposed to be doing "according to what's on the tin." Apple is doing the same thing through notarization that the FDA does to foods and drugs: holding companies to their claims of their products being fit-for-purpose and non-adulterated.
(And although this is currently entirely a thing Apple is simply trusted to do in good faith, there's nothing stopping the EU from mandating that Apple's notarization going forward, consist of exactly these kind of technical checks and no more. I think that'd be a great idea, personally.)
> The gatekeeper shall not be prevented from taking, to the extent that they are strictly necessary and proportionate, measures to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper. Furthermore, the gatekeeper shall not be prevented from applying, to the extent that they are strictly necessary and proportionate, measures and settings other than default settings, enabling end users to effectively protect security in relation to third-party software applications or software application stores, provided that such measures and settings other than default settings are duly justified by the gatekeeper.
https://news.ycombinator.com/item?id=39132487
Apple is allowing alternative browser engines in iOS 17.4 – but only in the EU
I already see numerous sites that with chrome variations on the old "we only support IE", but at least until now devs had to at least allow at least one other browser. Now they'll just say "here's a link explaining how to install chrome".
Moreover, again from the IE era - and we already see this with chrome - people make their sites work in IE/Chrome and then label any browser doing something different as broken so as people are increasingly forced to use chrome the degree to which spoofing does not work steadily increases.
> [...]
> Provide Apple a stand-by letter of credit from an A-rated (or equivalent by S&P, Fitch, or Moody’s) financial Institution of €1,000,000 to establish adequate financial means in order to guarantee support for your developers and users.
Just let us sideload IPAs, please.
All I want is a F-Droid-esque store with sane apps. You know, open source apps, centrally built. No in-app-purchases and Chinese geotracking framework for something that is 25 lines of code to talk to some bluetooth gadget.
The ruling is mostly there to prevent google and meta from creating alt stores (which is a benefit to us).
Unless you are lucky enough to have a MacDirtyCow-vulnerable device+OS, of course, but if you are going there why not just jailbreak?
Looks like Apple tries to make a case to exploit this statement, which sounds exactly like a malicious compliance.
The inability of binaries to do malicious things on iOS is the result of the sandboxing and entitlement mechanisms of the platform. The store review and approval process is what stops applications from including entitlements that undermine the platform security. If you remove that step from the process there is nothing stopping an application shipping with the system entitlements that allow the application to read or write to other app data, or the entitlements to talk to system services without prompting permission dialogs, etc.
If you want to remove the review and approval systems that the App Store has (and it sounds like are going to be required for 3rd party stores?) you have to have an answer for that. Otherwise you just end up with the android malware problem.
There are limits on Android anyway, what your side-loaded apps can do without you using a custom ROM or rooting the device is restricted somewhat.
I’m all for allowing power-users to side loads apps, but average user definitely needs to be thought as a child that will use 1234 as their password, and click ‘ok’ on every pop-up without even reading it.
There is no need for an app store review process to stop apps from requesting the "write to other application's data" entitlement; this can be enforced by the phone itself.
That's what entitlements are, and the App Store review is what ensures you don't have bogus entitlements.
There are entitlements that, for example, control whether or not you can read the user's message database, the entitlement has to exist so that messages app and daemons can access that database. The App Store review process automatically rejects submissions with those, and other similar, entitlements. There are entitlements that allow reading and writing arbitrary data from arbitrary applications, because (for example) there are OS daemons and services that need to read/write all of that data (the settings app can report disk usage, there's the daemons that install and uninstall apps, etc), and again those entitlements are gated by store review.
The entire trust/security model for iOS starts at the store review disallowing system entitlements, and gating even allowed entitlements on appropriate notice in the app description.
You should really read the apple platform security documentation, but to give you an idea of what entitlements exist on the system I found this one for iOS 13: https://gist.github.com/jankais3r/1f839820f83be90d419140a6b8...
Hopefully you can look at that list and get an idea of how removing the gate on applications being able to specify whatever entitlement undermines a huge component of the platform security model.
Also I don't know what you mean by bogus entitlements, if it's not meant to be used by user apps than it wouldn't be available to user apps, if the app needs to have access to a certain feature that required a permission, it would need to ask gently the OS and the OS would need to approve it (maybe even after asking the user), or the app would not simply to be able to access it, so it's in the app's interest to have the permissions laid out correctly so that the OS knows. From the previous message you seem to believe that the app could just simply bypass the dialog asking the user for permission.
> The gatekeeper shall allow and technically enable the installation and effective use of third-party software applications or software application stores using, or interoperating with, its operating system and allow those software applications or software application stores to be accessed by means other than the relevant core platform services of that gatekeeper.
> The gatekeeper shall, where applicable, not prevent the downloaded third-party software applications or software application stores from prompting end users to decide whether they want to set that downloaded software application or software application store as their default. The gatekeeper shall technically enable end users who decide to set that downloaded software application or software application store as their default to carry out that change easily.
> The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services
How is requiring them to have access to $1M acceptable, or compliant with the legislation?
> The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper
Apple state the $1M requirement is to allow for providing support to customers. There is no allowance for doing that in the regulation, and no reasonable argument can be made that lack of customer support has an impact on the integrity of the operating system or hardware. I can understand scanning software or asking for it to be uploaded and signed, that could be justified. Not this.
Good business if you can swing it!
Edit: Upon looking into this further, it appears that only marketplaces can be installed from a web browser. [1]
[1]: https://developer.apple.com/documentation/marketplacekit
Instead, they've gone for hostility and pettiness and, no doubt, fully intend to maliciously comply.
> The screen also interrupts EU users’ experience the first time they open Safari
And it will be the last time.
Is it a 10-max 20% fee to Apple, no matter the distributor, in the EU? Or are those rules only for the App Store, and anything else won't be touched by commissions to Apple?
This seems unusually high. I would expect that a large number of apps meet this threshold. Am I correct in thinking this applies to apps that aren't monetized?
Assuming this doesn't count updates - the service is probably costing Apple €0.10 on average. Apple has a very hefty margin on everything it sells.
If each update costs €0.5 - I suspect this is going to lead to a massive decline in European apps. That's simply too expensive for almost every app.
There's probably less than 1000 apps this would make any material money off of.
This is just another way for Apple to try to tax Facebook, Google, and a handful of other big apps.
> The first time an app or game is installed by an Apple account in the EU in a 12-month period.
[0] https://developer.apple.com/support/fee-calculator-for-apps-...
It does
You are correct according to their calculator [0]. If I say I have 2M annual installs (1M over the "free tier") and no in-app purchase it will cost $45,290/mo
[0] https://developer.apple.com/support/fee-calculator-for-apps-...
Looking at Unity wanting to charge 20 cents and the game development industry falling over itself to explain how that will never ever work for them... I dunno, maybe other app types (firefox, a mastodon client, osmand, local public transport.. looking at random examples from my homescreen) make enough money from their users and this will be doable for them when microtransaction-laden games couldn't make 2/5ths of that price work out
Here Apple is tracking an install across the entire user account per year, so even if you have tons of devices and install the app on every single one of them, that's still just one "install".
> that even loading the game in a web browser was an "install", and someone downloading and deleting and downloading the app over and over on a device was also repeated "installs".
The Apple change isn’t really comparable (not saying it’s good or bad) because Apple are introducing a new pricing structure.
Most genuine critics of Unity’s proposed changes were fine if it wasn’t replacing what existed.
Apple is a scumbag company. Any developer who continues to support Apple by building software for their ecosystem is a bad person.
They missed out on €0 because government entities, non-profits and educational institutions are exempt from the install fee.
Alternatively you can also just stick with the App Store and pay 15%/30% over revenue without install fee, which would also be €0 in your hypothetical.
Free apps aren’t exempt. The fee is only for EU users. If you take the EU iOS market share of 33.3% [1] and the number of EU citizens (448 million) [2], you get ~150 million — and that’s assuming 1 smartphone/citizen, which is probably too much.
[1] https://gs.statcounter.com/os-market-share/mobile/europe [2] https://en.wikipedia.org/wiki/Demographics_of_the_European_U...
sure kids <5 years old probably don't own smart devices. But many those EU citizens will own also ipad, apple watch and probably some older devices that they use from time to time (as a backup)
It’s only first unique install in a 12 month period on iPhones in the EU and then only the ones that are above 1M that are charged €0.50 in monthly installments.
"A first annual install may result from an app’s first-time install, a reinstall, or an update from any iOS app distribution option — including the App Store," [0]
so updates and reinstalls count as well - just all installs, reinstalls, updates in 12 month period counts as one. But next year if you just make a bug fix to still support new iOS version that update will be paid as well to all your user install base.
[0] https://developer.apple.com/support/core-technology-fee/
So apple wants to require they approve your app and then charge you €0,5 for every time it is installed for the privilege of avoiding using their infrastructure. It is honestly insane. I don't know the DMA in detail but I hope it is not and gets smacked with fines. And I hope if this is allowed the DMA gets updated so this is no longer allowed.
Should LG be able to charge you every time you watch a movie or show on your TV?
A TV is made for watching what I want. A smartphone is for running the apps I want.
Apple defenders keep approaching these conversations like, "okay, you think you want to actually own your phone, but have you considered that sideloading would be just like <insert other awesome thing>?"
Nobody likes the pre-bundled garbage smart TV system; TVs where you can install arbitrary apps and use the same remote to operate them would be a better experience. As TVs have gotten more universal standards and APIs that any device can hook into, they've gotten better. We're all glad that TVs have arbitrary HDMI in, we like being able to use any game console with our TVs without needing to care about whether the console manufacturer has an agreement with the TV manufacturer, we don't like when we get a TV home and figure out it doesn't work with a service we already own.
"Apple is like those 'smart' TVs you buy where you get home and discover that for some bullcrap reason Youtube doesn't work and your home assistant can't control the volume" -- may not be the strong defense of Apple you think it is?
Do the people making these comparisons not understand that the comparisons all sound really good? It's like, "do you expect to be able to install any app on a console? Do you expect your smart phone hub to be able to work with any smart device? Or what, you buy an e-reader and expect to be able to just put any book on it?"
Yes, I do. I don't know, don't threaten me with a good time.
At least the security arguments make some sense, even an argument that Apple has some special right to profit off of "access to the users" is more defendable. But I feel sometimes like Apple apologists are living in an alternate world where they think that if Microsoft launched a console that could play both Xbox and PS5 games that consumers would all be saying, "we don't want that, that feature makes the Xbox worse."
I find it somewhat absurd that if you put a computer chip inside of a gadget you are now suddenly expected to support/enable installing literally anything.
If the consumer cares so much about that, they can buy something else.
Sort of, yes? I mean, if you've got a general purpose computing device stuck inside of a TV, it's kind of nice to be able to use it as a general purpose computing device.
And I mean, we have open standards for things. I'm not saying that companies should have to manually support everything, but if you ask me if it's a desirable feature or if it would be better for TVs to use common platforms that can be targeted regardless of hardware, what do you want me to say? That it's a bad thing if I can control the volume on my TV using a universal remote? That it's good that different smart assistants don't work with the same music services? Because having a smart assistant say that you can't use a music service because some CEOs got into a fight with each other actually stinks and I hate that.
> I find it somewhat absurd that if you put a computer chip inside of a gadget you are now suddenly expected to support/enable installing literally anything.
Okay, but you understand that every consumer would view that as a feature, right? You understand that when you say, "imagine if every app worked on your TV" pretty much everyone is going to say, "that sounds great, yes please."
Never before has any console or TV ever advertised less compatibility as if that is a desirable feature that customers should want. Never before has Microsoft gotten up on stage and said "we have a hundred launch titles" and then Playstation gotten on stage and said "hah, that's amateur talk, we have 45 launch titles, we're clearly winning this fight."
You're arguing that this is a slippery slope, but you're also arguing that there's chocolate cake and puppies at the bottom of the slope. Generally speaking, using cross-compatible standards that allow people to interop with devices without asking the manufacturer's permission is a thing that I want, yes. I like that cars use the CAN-BUS standard, that's a good regulation. I like that I can have 3rd-party repair shops for my car, I like that I can buy a stereo system and hook it up and it doesn't matter if the stereo manufacturer has an agreement with Toyota. I like that Samsung and LG TVs both use HDMI ports and I don't have to ask "which computers can I plug into this" when I buy a TV. And of course consumers generally like that we use universal USB standards now and we've gotten past every device having incompatible cords. These are all great things to have.
You can argue whatever you want, you can argue that this is an abridgement of Apple's rights. People might believe that.
But just be aware that your slippery slope sounds less like a slippery slope and more like some kind of prize, and if you're not careful people might start to say, "wait, you're saying that if we open up iOS devices we could then do the same thing to consoles, and I would stop needing to buy 3 separate consoles just to play different games? And I could buy cheap controllers instead of needing to spend 60-80 dollars for an official one? And I could play games with people who are on different consoles? So where do I sign up for that?"
Not that I'd ever buy an apple product, beside the best usb-c DAC on the market.
Right 1,5k euro I paid for an iPhone was a donation on my part, to actually pay for hardware and software now.
A Spotify user could cost €2 on per device terms if they installed on their Apple Watch, iPhone, iPad and AppleTV.
https://appleinsider.com/articles/22/06/06/apple-now-has-ove...
So, it's probably within a factor of ten of 340,000 developers. That's a lot of apps.
If I'm reading this right (and I did double check this with ChatGPT [0]) if you have an app with two million unique installs annually, you owe Apple 500 000 euros. That seems to include free apps as well.
[0]: https://chat.openai.com/share/905c5c45-657b-477c-a746-0468dd...