"What’s weirdest about Apple’s antitrust and PR problems related to the App Store is that the App Store is a side hustle for Apple. " -- that seems to be a feature not a bug -- Apple incorporating more and more capability into the base iPhone OS / software stack is what keeps people coming back. There was a mentality years ago that the iPhone was the good hardware plus a bunch of apps -- but over time many of the most important apps have been built in apps / services from Apple directly. So in many ways, if Apple allowed the app store to be more open, then it would allow 3rd parties to actually build a bunch of value there without much control from Apple -- so it would make more money for Apple at the expense of creating a more vibrant set of 3rd party apps that almost assuredly work on both the iPhone and Android phones. So in many ways, Apple probably would be happy with close to zero revenue in their App store as long as people were 100% locked into buying new iPhones and airpods and ipads next year.
The App Store absolutely enforces Apple’s preferred position in its marketplace.
Apple stifles direct competitors in media (music streaming, TV/movies/video, video games, books). They force competitors like Netflix to pay obscene royalties or abstain from selling subscriptions within their apps at all. This wouldn’t be a restriction on a third party App Store.
Another example: you’re not allowed to install a browser with an alternative rendering engine. Apple is forcing their browser engine to have enough marketshare so that developers won’t ignore it. Make no mistake, they absolutely would lose significant browser engine marketshare and developer attention without this arbitrary restriction because a significant amount of users would prefer to install Chrome with Chrome’s rendering engine. If Safari becomes irrelevant to the web then Apple loses economic control to competitors, it’s basically following Microsoft’s 90’s browser strategy with a little twist here. A third-party App Store would allow for consumer choice in that regard.
Don’t forget that mobile games are a more lucrative market than all consoles and PCs combined, and Apple is collecting a significant chunk of that revenue via royalties for in-app purchases and advertisements in the App Store. It’s a multi-billion dollar business just for Apple.
Make no mistake, this is not a side project. Apple’s services revenue is larger than Mac and iPad sales combined and has the potential for much higher operating margins.
The fundamental problem is that Apple cannot have it both ways; you cannot have both a marketplace where you tax merchants in and you compete against them at the same time. If you want a cut of Spotify's revenue because you are enabling a great platform for them, awesome, but you cannot have Apple Music at the same time. If you do, your management of Spotify/Tidal/whomever should be regulated: fees capped, rights restricted, etc.
Apple has tried to do this too many times (Apple Books anyone?) and only succeeded in a few places and they've usually leveraged their OS/market position to do that --see Apple Music vs Spotify. At the end of the day it's Apple's customers that get hurt (because we massively prefer Spotify over Music but are not getting a first-class experience). Same for Siri, or Mail (what a POS that is) or Notes (why can't we map the swipe-from-bottom right to a better note-taking app?).
I say all of this as an Apple fan and a customer. Cut it out, stop trying to be 90s Microsoft.
> because a significant amount of users would prefer to install Chrome with Chrome’s rendering engine.
I'm not convinced that users care about rendering engines. Non-Safari (not non-webkit) browsers already enjoy a modicum of popularity on iOS due to offering different UI/features on top of the rendering engine.
You’re right, the end users don’t care. That’s not the point.
The point is that forcing all iOS devices to use the WebKit rendering engine prevents competitors from closing off the web to Apple technology.
E.g., Google has to make sure its mobile sites work with WebKit because they can’t just tell their iOS users to download Chrome to make it work. Any website that works for Chrome on iOS will also work for Safari because they share the WebKit browsing engine.
If Google could release a version of Chrome on iOS that used its own browsing engine they could basically leave their critically popular websites broken on Safari and tell their users to download Chrome to fix it.
Somewhat tangential, they could also get around the Apple App Store by leveraging the Chrome Web Store and extensions as an alternative.
The biggest reason for running chrome on iOS is getting access to your Chrome password manager. I don't think web rendering engines are much of a concern, but I've never run into an issue that was web rendering related.
I’m not talking about the end user caring about browsing engine, I’m really talking about the technology risks.
If Apple allows Chrome based on Chromium, Google or other tech giants could basically pull a Microsoft in the 90s and make their websites not work on Safari. “Sorry, Office Online only works on Edge” or “Gmail for web only works on Chrome” would basically snuff out Safari.
By forcing everyone to use the WebKit rendering engine, iOS is a giant lever that keeps Apple relevant and influential when it comes to steering web tech and standards.
Apple's services revenue includes an annual lump sum payment from Google in the neighborhood of $18B per year. In 2023, that was roughly 22% of the revenue, and probably a majority of the profit.
And how much less would that payment be if iOS gave you a choice of default web browsers in randomized order that leveled the playing field?
That’s really my overall point here. Everything that is locked down about the iOS ecosystem helps keep that lump sum payment high.
For example, you can’t add a custom search engine to the OS preferences. There’s just 5 choices. How much did it cost DuckDuckGo to get on that list? (Probably more than $0)
> There was a mentality years ago that the iPhone was the good hardware plus a bunch of apps -- but over time many of the most important apps have been built in apps / services from Apple directly
I don't think this was ever correct. The iPhone has always been strong on good hardware and software working together.
The "wows" of the original iPhone announcement were things like slide to unlock, pinch to zoom on images, and rotating the iPod app to get cover flow.
> The iPhone has always been strong on good hardware and software working together.
Yes, but they also have taken advantage of third party developers doing market research for them, just as Microsoft did with Windows in the 1990s. I wouldn't be surprised if that was actually a key reason why the App Store was included in the first place.
> Apple incorporating more and more capability into the base iPhone OS / software stack is what keeps people coming back.
I'm reminded that, in a different way (but to the same purpose) several years into Android, Google started shifting features from the OS to their own Services app to keep phones up-to-date with App updates rather than needing OS updates.
We’ll have to see how it plays out. It’s also possible that iOS having a distribution model similar to that of the Mac opens it up to a bunch of high quality single-platform indieware similar to that macOS has enjoyed for decades, which could help maintain its reputation for better apps.
macOS has shifted and it’s harder than ever to distribute indieware. Devs must compile with and up-to-date version of Xcode which means they must legally abide by Apple’s TOS even if they don’t pay for the yearly license (and agree to the further agreements), and if they choose to circumvent the App Store the user must know how to unlock the restrictions needed to run unsigned apps and also push through the fear-inducing security warnings.
As an HN user that’s “easy” but how many first-timers will be comfortable enough to get to the point where they can actually run that 3rd party app?
Xcode doesn’t require the yearly fee, it’s downloadable for free, and you can get a barebones compiler toolchain with a terminal command. Devs who distribute outside of the Mac App Store can notarize their apps to make them run without the security warning stuff. I’ve done it to distribute a screensaver on Github, it’s not too bad, no worse than the hoops one needs to jump through to build and distribute apps with some cross-platform UI frameworks.
I rarely download apps these days, but the ones I do are important: my car app, bank security code app, spotify app, Sonos app, just things I need for devices I own but are otherwise free.
I would be perfectly happy with a device control ecosystem rather than an app store. It might actually be a better experience.
I'm surprised the US didn't go after airtags. This, to me, is the number one reason for owning an iPhone, and something that can't be replicated on Android. Apple is really leveraging their market share here in a way that Android doesn't (for some reason, they totally could and should).
> I would be perfectly happy with a device control ecosystem rather than an app store.
The crucial thing is that you can achieve this without needing to prevent users from installing their own apps. Any attempt from Apple to prevent users from installing their own apps is purely because they're terrified at the idea of needing to compete with third-party developers.
I don't know, I know plenty of idiots who would take their freedom to install anything and...install anything...and then blame Apple when their iPhone starts running very poorly, or when their private info is exposed, or so on. They would want both freedom and safety.
Surprised this is not mentioned already, but it’s a decades-old Apple play to allow some 3rd party innovation, then take it’s core feature and “reimagine it” as an 1st party feature.
Further: when it’s been difficult to compete directly, Apple has tools that allow it to control the 3rd party directly: Developer agreements and white-listed internal APIs (and restricting what can be done with them) to name two.
And, since they have seen the financial benefits of that control, they have spend years not only building more tools but also refining their legal position.
Can anyone now imagine an iOS app surviving if it had killer features that made Apple look bad by comparison? Or one that is defiant of Apple’s brand image?
Nah. That little slice of their P&L also includes a lot more than App Store revenue. AppleCare, Apple Music/TV purchases, rentals and subscriptions, Books, Apple Pay fees, Google Search revenue and whatever else you can plausibly call a service under umbrella in addition to App Store revenue.
They don’t break out the exact mixture, but we know the Google Search deal is an enormous chunk of it.
Apple doesn't break it down, so this is all analysts-guessing, but the guesses I've seen for the share of Services revenue that App Store represents have been in the 25-35% range.
per apple they paid $60 billion to iOS developers. Given 70/30 split, that's $26 billion of revenue to Apple.
For context in 2022 Adobe made $17.6 billion.
So 30% cut of iOS store is 40% more than Adobe revenue.
And I'm guessing the bandwidth + review team overhead is many times lower than, you know, actually paying software developers, marketers, sales people etc. to write and promote software.
Great. AAPL Services revenue for that time period was $68.42B.
Apple also launched the Small Business Developer program that year reducing their cut for qualified businesses down to 15% after the first year of an active subscription (it’s stupidly complicated for what it is), but at the high end, under their prior cut of 30%, Apple would have earned between $25B and $26B. If after the small developer program Apple only took home a 25% cut averaged out, then that’s about $20B. If they get 20%, then they get about $15B.
Some of that extra cut that developers get comes back to Apple in App Store ad dollars though, so best estimate with available data: between a fifth and a fourth of Apple’s 2021 services revenue of $68.42B was their cut of the App Store + App Store ads which puts it ahout on par with their Google Search money for that year ($18B).
Calling the App Store Apple's side hustle is weird as best and practically wrong. Someone's blog is a side hustle to their full-time job. Not blogging for days likely wouldn't affect their ability to make ends meet. But how would the whole Apple ecosystem function without this "side hustle"?
"To put it another way, the Epic case may have shown that Apple’s policies around the App Store were (mostly) legal, but that didn’t mean they were right; now the DOJ, looking for another point of vulnerability, is trying to make the case that Apple’s right approach in delivering an integrated experience is in fact illegal."
It is legal but it is not right, but the government is trying to prove that its right approach is illegal? What does it even mean?
There are multiple interests in this ecosystem. Consumers', Apple's, shareholders', small developers and big developers. And they have different interests, often conflicting. By "being right", right by whom? Who is to say that they know how to appease every party in this ecosystem?
In a nutshell: "In short, I suspect the DOJ doesn’t want to follow in Epic’s footsteps, but they do want to sue Apple, so they framed Apple’s defining characteristic — integration — in the most uncharitable light possible to make their case. To put it another way, the Epic case may have shown that Apple’s policies around the App Store were (mostly) legal, but that didn’t mean they were right; now the DOJ, looking for another point of vulnerability, is trying to make the case that Apple’s right approach in delivering an integrated experience is in fact illegal."
This is what I've been warning about in these threads from the beginning: every time a government does something to Apple, certain people on HN cheer them on because any government action is seen as a good step.
Unfortunately, as illustrated here, that's not actually the case. The current course of government action against Apple (on both sides of the pond!) will not lead to the iPhone as we know it minus the specific things that irk us as app and web developers. What the EU is doing and what this lawsuit seeks to do will end Apple as we know it.
For some people that might be an acceptable outcome, but I think a lot of people are laboring under the false assumption that these actions will give them exactly what they want without any downsides.
It's perhaps not surprising that the security benefits of the App Store are under systemic pressures, as aftermath of Apple inconveniencing many organizations by adding so many privacy features to iOS. Many of the numerous organizations that leverage user data will want new capabilities for obtaining information from iOS, to replace or even to expand beyond what was previously available.
I wonder if that translates into anything that Apple can be pushed into? Government surveillance aside, does the existence of additional marketplaces strongarm Apple into rolling back any of those features?
There has been a bit of suggestion that a powerful competitor, running their own marketplace might be able to force Apple's hand to do something it hasn't done up until now. If Meta runs their own Marketplace and offers Instagram only through that store, I don't think they gain any actual API differences - only a different set of EULA terms for distribution maybe?
Additional marketplaces aside, one of the specific complaints mentioned in the article is that some iOS system APIs are private, usable only by apps that Apple itself produces.
"private APIs and system-level integrations that Apple claims provide for better battery life, messaging management, etc.; the DOJ says that these integrations should be modularized and made available"
While messaging management makes it sound like the DOJ potentially wants Apple to give 3rd-party apps read access to users' SMS messages, the battery life API seems innocuous, yet batteries have already seen use in fingerprinting:
"Fingerprinting happens when an app takes innocent-looking but technical information from your iPhone, like the volume, battery level and IP address. Combined, those details create a picture of your phone that can be as unique as the skin on your thumb." [1]
Apple responded [2] to this type of fingerprinting by requiring app developers to give good reasons for requesting it, but a 3rd-party App Store would offer limited if any oversight from Apple.
"'To prevent the misuse of these APIs […] developers will need to declare the reasons for using these APIs in their app’s privacy manifest,' Apple says. 'This will help ensure that apps only use these APIs for their intended purpose.' ... The data includes points such as IP address, screen resolution, language setting, fonts used, operating system type and version, processor type and speed, network information, battery level, etc."
When will the US do something against Google and Android? We at Appwrite are trying to build a decent alternative for Firebase push notifications, but in 2024 still forced to send our own customers to signup for our competitors service to be able to do it properly. I hope its just a question of time and not convenience.
Chrome needs to be addressed, too. It’s achieved near-monopoly status (especially if lumping in Chrome reskins like Edge) and posing meaningful competition to Google’s cross-promotion, marketing, and army of engineers working on the project is for practical purposes impossible. Prying away significant marketshare would be incredibly difficult even for the best non-Blink browser imaginable.
Edge is not a Chrome reskin, it's a Chromium reskin, and I think that distinction matters a lot here. The point of Chromium is that there is effectively no promotion or marketing in it. I think the fact that Microsoft push pop-ups to get users to move to Edge from Chrome is testament to that.
Now from a technical perspective, more diversity in browser engine might be nice, but this doesn't really contribute to the competition discussion.
The distinction doesn’t matter that much in my mind, because Chromium reskins give Google just as much power over the web as Chrome reskins would. If for example the marketshare of Edge and Chrome suddenly traded places, very little would change in terms of Google’s control of the web.
Chromium/Blink being FOSS with Google also by far being the most dominant contributor essentially allows them to wield the same sort of power over the web that Microsoft once did, except this time it’s been whitewashed with an “open” gloss that helps keep the regulators off their backs.
> If for example the marketshare of Edge and Chrome suddenly traded places, very little would change in terms of Google’s control of the web.
I think it'd make a bit of a difference, because Microsoft would now have the threat available of changing rendering engines and taking all their users with them (via Windows automatic updates). It'd be expensive and risky, so they wouldn't really want to do it, but they'd have it as leverage against any Google decisions.
If said project has a monopoly marketshare which the parent company can then use to drive profits in its main lines of business, then yes I think it can. In this case the engineering resources presents a moat of sorts — it means that anybody hoping to meaningfully influence the project or fork it needs to dedicate as many or more resources, which is difficult or impossible for most organizations. Without that, the most that forks can hope to dissent on are things that can easily be toggled on/off or patch parts of the codebase that don’t change often, which is very limiting.
It’s still not good though, because it essentially rules out the creation and growth of new browser engines. A group shouldn’t need to be a multinational gigacorp to pull that off.
Let’s say there’s a hypothetical world where Safari had 90% market share like Chrome does. Would the fact that WebKit is open source make a difference? Chrome is to Chromium as Safari is to WebKit after all.
If Safari had 90% market share because it was a great browser available on every OS promoted on some of the most visited websites (which, in this thought experiment, would be owned by Apple), while people were able to choose their browser on iOS, and browser vendors were able to choose the browser engine and if a version of Safari without sync were open source, that would make a difference.
Two major differences: Chromium itself is a standalone browser, not just a rendering engine. You need to compare Blink to WebKit. Also WebKit is the only engine allowed in the App Store and iOS. There's no such limitation in the Play Store and Android.
Push notifications are a tricky one because they only really work when there's one central distribution point, for performance/battery/etc. Apple does it this way too, and almost every mobile platform does the same thing. Yes you can sit in the background and hold a connection open or poll on some platforms, but it's not a good experience.
I see a thriving third-party ecosystem around push notifications as a marketing channel. Yes the low level APIs end up going via the central platform, but they are remarkably low level, and the business value comes from the automation, easier integration, tracking, rich notifications, etc. Companies like Urban Airship have been around for well over a decade doing this.
Are these central platforms holding you back? If so I'm interested to know what you're unable to do that you would be able to do better.
(This is all my own opinion, mostly from developing for iOS in a previous role, not that of my employer where I'm nothing to do with push)
All good, but why couple it with GCP? It used to be a separate, independent service (GCM) and how convenient it was to couple it with Firebase and call it FCM...
In practice, even the US DOJ holds back, for fear their lawyers won't be as good as Apple's (or other company's). Which, on one hand, shows the relative impartiality of the court system. On the other hand, it means that just as much as a corporation would likely loose a lawsuit against a tech giant, the US government also fears that outcome.
Also, unlike a civil matter, losing an antitrust case could be disastrous for the government. The Microsoft case, for example, was a technical victory, but a practical loss that put fear in the government to use antitrust action for almost 2 decades. From their perspective, it way too much work (5 years of litigation) for too little an outcome (yay, we've decoupled Internet Explorer and got a few concessions). And the main reason why, was because the judge squawked and broke ethics rules, which was awfully unpredictable and unpreventable.
The general policy of the FTC from the 1980s until about 2020 was that mergers and market concentration are good for consumers and the economy as a whole. Just to take one example, Facebook buying Instagram 100% should have been blocked, but the DOJ under Obama, carrying on the policies of Reagan, Clinton and Bush, decided not to pursue it.
> Facebook buying Instagram 100% should have been blocked
On what grounds? Instagram was a small startup with about 30M users when Facebook proffered a deal. People legitimately thought they were overpaying at the time and while it was a hot app, it became the cultural phenomenon it is today under Facebook’s stewardship.
WhatsApp had a much bigger user base but was still a small startup with about 50 employees and was losing money. The scummy thing was the role Onavo played in Facebook identifying it as an acquisition target, but that’s not the same as illegal. I think this is still a weak case.
> It's definitely possible -- you don't have to use Firebase to deliver push notifications. You can roll out your own notification solution or consider a paid product such as Pushy (pushy.me) which does not rely on Firebase Cloud Messaging. Full disclosure - I am the Founder & CEO at Pushy.
So clearly someone else has done it and built a business around it.
Ever since Tim Cook said Apple is going to become a services company, that's when Apple stopped progressing. The Apple car is dead. The Vision Pro is DOA. Apple is a decade behind the others in AI which forced them work with Google. What other product category is there for them to take a crack at? This is why Apple is fighting tooth and nail to keep their App Store revenue going because if that growth stops showing up on quarterly earnings, their stock will crash and hell will break loose.
It would be interesting to know if there were ways regulation could promote new competitor businesses, instead of handicapping Apple.
It seems to me that in a healthier marketplace, Apple could argue that consumers were choosing them because their practices result in a better product. But in a duopoly (as with smartphone OSes), the argument rings hollow.
It will be interesting to see where the courts rule, and where we decide the line between integration-for-better-UX and monopoly-enforcement is. I do wonder if that line would appear different if there were more competitors, and if there are additional, or creative ways that new competitors could be promoted.
Demanding sideloading is not handicapping in any measure. It is about removing a harmful and arbitrary restriction that Apple imposes on its users. It should not be up to Apple to decide which apps a user can run on their own device.
(And don't even get me started on how Apple readily removes access to apps after demands from Putin's Government.)
On the one hand, as a developer, I agree with you.
On the other hand, as a user, and one who has to do de facto IT support for my family, I strongly disagree. Having an off-store method of installing apps is just dangerous. You could argue that it's a question of Apple having an incomplete security model, in which they enforce through human review that apps do not perform malicious behavior. But Apple is just pretty good at this -- the rare app that slips through their net is usually quickly caught and killed, and their security on-first-use opt-ins "Allow this app to access your camera", along with enforcing that apps for whom the permission is denied must still function, is critical, compared to the Android "Allow this app to access all device state forever including private information and your entire DNA sequence" that you get on app install.
On the gripping hand, advanced users, like developers, can basically sideload whatever the hell they want. The barrier here is a lot stronger than a checkbox in settings saying "allow sideloading apps" and thus is intrisically more difficult to access, and then only by people who know what they're doing anyway.
People who are happy with Apple's policies should be able to enjoy them and stay perfectly safe from malware and scam apps (sarcasm). Nobody is forcing them to install a third-party app.
Others should be able to use their devices as they please.
Also, the argument that 'you knew what kind of device you were buying' doesn't work, because Apple has shown time and again that whatever app is available at the moment of the purchase of the app can be later removed from Appstore by Apple for whatever reasons.
An argument to danger also works for banning kitchen knives. That something is dangerous is only an argument against it if the danger outweighs the usefulness. Given Apple’s restrictive App Store policies, sideloading on iOS would be very useful indeed, more useful than on Android.
To sideload on iOS via the developer tools you need a Mac, and the builds will expire. So it’s not a viable alternative to sideloading due to the cost and inconvenience.
The comparison to knives, whose function and danger is completely obvious by inspection, is not really apt. Compare it to a home furnace or water boiler instead. These are regulated, both from the state and from independent testing labs. You can make and install your own if you know what you're doing, but no reputable installer or contractor will even consider installing some jury-rigged non-compliant contraption.
A checkbox that says "I understand the risks involved" is never going to cut it, because there is 1) no way that the overwhelming majority of users understand the risk, and 2) the existence of the option puts us in a world where completely naive users are told "to install the cat-picture-a-day app, first click the 'allow sideloading' button and ignore the warnings, and then go to cat-picture-a-day.ru and install!"
As the article notes, we saw this with malware and browser toolbars in the 90s, and we see it now with misbehaving sideloaded Android apps (and "repurposed" Android apps). I personally am happy to pay the premium to get a quality device that forces developers into a constrained environment for my benefit.
>I personally am happy to pay the premium to get a quality device that forces developers into a constrained environment for my benefit.
I too like the walled garden. I don't really see that as an argument against sideloading however. Presumably the first-party app store would continue to operate with the same restrictions and I'd happily avoid opting-in to sideloading.
The people who want it are happy and I'm no worse off.
The problem is that if the sideloading avenue exists, what do you do when your bank says "from now on use our sideloaded app instead of the app store version"? Or when whatsapp (or telegram, or whatever) does this.
The App Store is a forcing function for app developers, because it's the only way to reach IOS customers. Without that forcing function, some app developers will circumvent, and if a critical mass does it, then you no longer have the option of opting out.
Apple can presumably make the warnings scary enough to make app developers reluctant to leave, but alternative less restrictive app stores and big-name developers will lobby to have those warnings removed for being deceptive.
If some game announced you could only get it through an alternative app store, I wouldn’t play that game.
Banking is critical functionality on the other hand. Under those circumstances, I’d change banks. The likelihood of any major bank attempting that seems awfully low and I’m sure it’d attract the widespread condemnation it deserves.
Android has sideloading. I don’t doubt some apps try to push users to an alternative marketplace but important everyday apps are where you’d expect them to be.
And what do you do when your bank says "Apple no longer allows us to put our app on the Appstore"? This is not a hypothetical question but an issue millions of users are dealing with every day.
Apple should not have that kind of power over owners of the devices Apple manufactures.
Then… don’t? The regulations are not about killing the App Store. It will still be possible to use the App Store while sideloading is a thing. See google play.
> Having an off-store method of installing apps is just dangerous.
I can't help but find this to be extremely infantilizing. The whole point of a democratic society is that we believe that we can educate people rather than relying on some authoritarian dictator to decide the limits of our freedoms. What you appear to be suggesting that your family is too stupid to be educated? Are you sure about that?
I think my reply to the sibling comment covers most of this.
But I am not suggesting that my family is too stupid -- rather, that the level of expertise required to safely determine whether a given app is safe to sideload is not only beyond the reach of a casual user, it's beyond the reach even of an experienced expert. Is my family too stupid to understand quantum field theory? I don't know -- maybe? Does the framing of "too stupid" make sense with that question?
What's the "sharp edge of the knife" here? For use of web sites, the assumption has been that the user agent is responsible for preventing websites, no matter how malicious, from performing harmful operations. Even before there was a formal concept of "sandboxing" this was the basic assumption, and the biggest violation of it always came from "hey, download this executable and run it on your machine".
Maybe someday we'll have sufficient app isolation that there will be no worries about the idea of running completely untrusted native-code apps on your device. But this is not that day.
It looks like the off-store app installation method that Apple is developing has exactly the same system protections as App Store apps, including the capability to kill malicious apps. Just as with websites, I think the biggest threat would be deceit: phishing, credit card and identity theft, subscription schemes, etc.
Yes, that change I wouldn’t call handicapping; although I’m sure Apple would.
On the other hand, I think it’s reasonable to suggest that greater interoperability could result in some features being degraded or unavailable (maybe certain things happen slower, or consume more battery life, for example). We might still decide this is worth it overall, but it could genuinely handicap the UX.
Really? Can you give an example? I don't see why performance or battery life would need to be impacted for users of the default services. In other words, if you want to keep using Apple-only stuff, you would get the same outcome as today.
"I don’t think the developers are wrong, but even if they are wrong, it’s not good for Apple that they’re so unhappy, and feel so aggrieved. It’s not good for Apple that developers don’t see the App Store as a platform that works in their interests. Like the Apple logo, “developer goodwill” has no price tag."
I think many echo this sentiment. What exactly does one get for their 30% tax? Great docs? Awesome development platforms that are integrated with industry-standard CI/CD and revision management? Super responsive Apple devs who publish loads of useful "application notes" every week?
Apple builds incredible user experiences, which gains them loyal customers who collectively have massive market power, which Apple can then effectively wield to get its way — a way that involves maximizing the user experience. It’s a virtuous circle.
More biased than interesting, they've done lots of things that aren't particularly user friendly... the long history of proprietary connectors and dongles for example.
Even that’s a mixed bag, though. When it came out, Lightning was a legitimate large step up from micro-USB and their old 30-pin iPod connector, and on MacBooks MagSafe was loved enough by users that it managed to come back from the dead and co-exist with USB-C PD.
Another example is Firewire. Like MagSafe, Apple invented it and it was a big step up from previous hard drive connectors, at a time when USB was thoroughly incapable of high speed. Then like MagSafe, Apple cancelled Firewire and they did so before USB was fully able to replace it. That's no longer true today, but for a few years it was difficult or impossible to attach a hard drive at full speed to a Mac.
No. Apple moved to USB PD on their notebooks starting in 2015 with the 12” MacBook and 2016 in their existing products. Most phone lines that would switch to USB-C hadn’t even fully made the transition yet.
Bringing MagSafe back was just them listening to customers for once.
Not sure. I’m not aware of any EU regulations on laptop charging (though I have not looked), and Apple was actually one of the earliest implementors of USB-C PD in laptops so if such regulations exist, MacBooks have likely always complied.
This ignores the ideas of inertia and lock-in. Once a company has monopoly or duopoly control, they can allow UX to deteriorate quite significantly because there are no viable alternatives that offer a meaningfully different experience.
It's not fundamentally new, this is the underlying reason lobbying is an accepted part of how capitalism interacts with democratic governance. The struggle remains how to decide when that power is being abused in uncompetitive ways.
> Leaving aside the fact that green bubbles actually serve a product function — they are not encrypted, while blue iMessage bubbles are
Yes, that's itself an attempt to lock people in, which is particularly absurd considering Apple's privacy branding -- Apple sacrifices the privacy of its users communications with Android users to lock them in.
I don't understand this line of thinking. Even if Apple were to build an iMessage client for Android, do you really believe that the average Android user would install it just to have conversations with those particular users? How would they even know that a user is on iMessage without it already being their default SMS app? Is Apple then really obligated to build an Android app that can facilitate base-level SMS conversations? How is that good for their business or valuable to their customer base?
I don't know about the average Android user, but I imagine you'd get a lot of users.
I don't really use Apple products, but I do have lots of friends/family that I can't convince to use anything other than iMessage to chat on their phone. I'd literally be the only contact they'd bother talking to not on iMessage. So right now, our experience sending pictures/videos is pretty terrible. I'd install iMessage on my Android device in a heartbeat if it meant I could actually send decently sized photos and videos to them. Doubly so if it meant I could actually participate in their Facetime calls and they could easily Facetime me.
I understand that that perspective might be prevalent here on HN. But really, let's try to understand the target market of this theoretical iMessage Android client. It's specifically for folks who:
1. Are committed to only using Android phones (i.e. can't be convinced to get an iPhone).
2. Communicate (or are forced to communicate) over the default messaging experience with primarily iPhone users (remembering that the iMessage / SMS default is mostly just a U.S.-centric thing and cuts out most of the rest of the world).
3. Are willing and able to download a third-party messaging app to address this specific use-case.
Do you think this is an incredibly rare group of people? Android has ~40% market share in the US, so there's a lot of Android users out there. It seems extremely likely for an Android user to have some iPhone users they communicate with. And at least in my experiences, people with Android devices are generally willing to install 3rd party chat apps given how terrible Google has been with really making a solid single chat platform for Android. The kind of people who aren't willing to install some chat app are more likely to be iPhone users, given the default chat options on Android are highly fragmented you pretty much need a third-party app to have a decent chat experience.
I'm largely someone who fits into #1 but I'm the end I'd like grandparents/great aunts/cousins/etc to easily visit my kids digitally, and it would be nice to just be closer to them. I'm not going to radically change my entire digital life to do so, but installing a (hopefully free) app would be nice and something I'd do in an instant.
I think it wouldn't be like >50% of Android users using it or anything, but I imagine there's a lot of people similar to me in this case.
> Even if Apple were to build an iMessage client for Android, do you really believe that the average Android user would install it just to have conversations with those particular users?
Absolutely yes. Apple could also make the Android iMessage app fall back to SMS (IIRC the Android FB Messenger app does something similar) if the user wasn’t on iMessage if they wanted to.
Sure, they could do that. But once again, I must ask: How is making an SMS Android app in 2024 good for their business or valuable to their existing customer base?
Well, if secure communications is what they're customer base is interested in, it would make sense to provide them a means to use Apple's app to communicate securely with their Android friends.
[best Don Draper impression] That's what the regulation is for!
It obviously isn't in Apple's business interest. Regulations primarily exist to force companies to work in the consumers interest even if it's against their business interest. If every regulation was in line with business best interest there wouldn't be any point making them.
That's a strange characterization given that when you see a green bubble there was literally no way for them to have made it private.
Even if Apple had jumped on RCS at the same speed as Android did, and assuming that absolutely every SMS user switched over promptly, there's no end-to-end encryption built into that protocol either.
Given the exact thing they're being sued for here, I can't imagine that the approach Google has taken with RCS of "we've built special end-to-end stuff into our first party messaging app that'll work when you're talking to other people using that app" would have helped them. Even if they also made an iMessage app for Android, that doesn't seem to address your complaint. Or no more than "you could use Signal instead" does.
