Although this is good news, Epic will still have to pay Apples Core Technology Fee.
For most developers this will be a deal breaker, because it also applies to free software which most of the time is only supported by donations.
For most developers this will be a deal breaker, because it also applies to free software which most of the time is only supported by donations.
Given with how much Apple got away for years, I am not surprised. Either many people don’t have particularly much insight or a severe case of Stockholm syndrome.
What bothers me the most is apples double dipping. You as the consumer basically pay a fee for apples technology. And then they expect the developers to pay the same fee, which will ultimately be paid by the consumer as well. Also ignoring the fact that Apples platform would be completely worthless if it weren’t for the developers building the apps the users want
iPhone sales alone are 3x Apple's entire R&D spend. And developers pay more than fair share of that because they need at least two devices (an iPhone and a Mac) if they want to develop anything, and a yearly fee.
Apple doesn't just double dip. It triple dips, and wants to quadruple and quantuple dip.
There’s hardly any order of dipping, if any.
Why doesn’t the web compete away Apple’s “dips”?
Because the web sucks at building apps? Because the web can barely render a few lines of text and several images without lag and jank? Because the web lacks useful and powerful primitives and controls to build anything but the most primitive UIs? Because...
Where is the multitude of amazing native-like web apps that we keep hearing about?
worldwide, and not by a large margin. I believe it's 60/40 last I checked.
Among US and a few other first world countries, it's nearly 50/50, with a very small advantadge to Apple. Slashing your consumer base in the biggest markets isn't an attractive proposition.
>Where is the multitude of amazing native-like web apps that we keep hearing about?
well Apple made PWA's harder to do in the EU, so ask them... They're doing what they did to Flash long ago, with much less justification this time around.
So. Let me get this straight. Android is dominant in the world. In first world countries it's 50/50 (though it's 69% in the EU). There are also desktops where Chrome is dominant.
And yet, somehow, there are still no amazing PWAs[1] that are the future as everyone claims, because somehow Apple prevents you from building them for those dominant platforms.
[1] Don't mention Figma or VSCode before you also mention how much effort went into implementing them.
There are plenty of great PWAs. People bring them up on a regular basis and you piss and moan when we say Facebook, YouTube, Twitter, Mastodon, Pinterest, Uber, Trivago, Starbucks, Dominos, Stitchfix, Adam & Eve or Hotels.com are usable online. You specifically complain because none of these apps are killer features to you. I don't know what to say; clearly they exist and you're trying to minimize the number of apps that technically qualify.
People refuse to take you seriously when you repeat this same tautology. Of course PWAs aren't popular on platforms that deliberately go out of their way to make them infeasible alternatives to a first-party service. It's not my fault that your purview of the technology is arbitrarily limited.
1. Funny how "on a regular basis" only comes after prodding these people multiple times, pointing out Android and desktop exists, and wading through numerous complaints how no, it's not true, and Apple prevents PWAs from existing.
Even in this discussion instead of naming PWAs right off the bat you first pretended that Android isn't dominant, and completely ignored Chrome dominance
2. It's also funny how "the amazing great PWAs" are inevitably not that great, are they?
Instead of being great and amazing they are just... "usable online". Each of those significantly much better as native apps. Without fail most of them would be much faster, fluid, less janky and resource-hungry if they were just static sites with links instead of ... whatever they are. Oh yes, they are usable.
> clearly they exist and you're trying to minimize the number of apps that technically qualify.
"Technically qualify". That's a great turn of phrase you used there.
So, we went from "boohoo limits the viability of non-native apps on its mobile devices" to "usable online" and "technically qualify".
I, for one, don't want to use apps that "technically qualify". I want actual fast fluid non-janky and non-resource hungry apps that are a joy to use even if they are the most mundane apps out there. That is precisely why I keep asking: given that Android dominates mobile space, and Chrome dominates desktop platforms, how come the best examples you can come up with barely "technically qualify"?
> People refuse to take you seriously when you repeat this same tautology.
People refuse to accept PWA fanatics when they keep saying grand words with very little to back them app. All you can do is complain about Apple.
> Of course PWAs aren't popular on platforms that deliberately go out of their way
You'd think that PWAs would be great and amazing on platforms that don't have any real or perceived limitations. And yet, all you can come up with is "usable online" and "technically qualify". But sure, do keep complaining how it's Apple who's preventing you from building great native-like experiences on the web.
With very few notable exceptions which are notable precisely because they are so few.
For content delivery, yes. For deeply-interactive apps, not in my experience: every vendor that went web-only that wasn’t just serving up text, in the end, forced me to a competitor.
But it's hard to deny there are quite a few technical shortcomings. Shortcomings only just now starting to dimish as WebASM/WebGPU gain traction.
The web can barely display simple text and images without jank because that is inherent limitation of the DOM that you cannot escape (that, and the absolute dearth of useful controls and utilities in the browser).
You could of course build stuff with canvas/WebGPL/WebGPU, but then you have to reinvent the whole world from scratch because those are low-level (and in case of Canvas quite limited) APIs
It means that at least 15 years ago it was more than powerful enough for all of the 2D Candy Crush style games which make up the overwhelming majority of mobile gaming apps.
> The web can barely display simple text and images without jank because that is inherent limitation of the DOM that you cannot escape
I've seen you repeat this phrase over and over again like a mantra on HN, but without examples I can't really gauge the performance problems you've run in to. The overwhelming majority of jank on the web that I've experienced is due to advertising bloatware (an adblocker is indispensable), and occasionally bad engineering (e.g. someone forgot to make an event listener passive, or isn't debouncing an event) not some inherent limitation of the platform. What are some examples of popular apps that you think require the full brunt of a modern chip? Every M3 iPad review I've watched ends up saying essentially the same thing: "this chip is powerful, but besides Geekbench benchmarks we have nothing to use it for".
I don't think it's an exaggeration to say that Zoom saves me 5 minutes out of every 30 in meetings, in fact it might be conservative. And this isn't just a question of the chips (though native Zoom does make better use of it) but also display, audio input/output, even global keyboard shortcut handling.
> but also display, audio input/output, even global keyboard shortcut handling.
I personally have never had a display or audio hiccup that I could attribute to a browser limitation. I don't even own a device with a display powerful enough to max out Youtube.com's 8K video resolution limit. I'm not sure why you've had issues with keyboard shortcuts. Keyboard events are well established and widely supported [3].
[1] https://news.ycombinator.com/item?id=20387298
[2] https://hn.algolia.com/?q=zoom+vulnerability
[3] https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
Definitely during the pandemic - good UX meant I got to feel more present with friends and family and that was well worth any security cost.
What I can tell you is that I felt at ease using Zoom in the browser knowing that I wasn't opening my computer up to a remote code execution vulnerability. Your UX concerns are a bit nebulous, but I'd be willing to bet that the risk assessment departments at most organizations could quantify the cost of a hacker gaining access to one of their employee's computers. I also used Zoom during the pandemic but I wasn't doing a ton of screen sharing (I was more interested in seeing my friends and family members faces rather than their screens).
Of course a lot of this is Zoom vs. Google Meet, I'm sure a lot of the things I like about Zoom work fine in the browser - but not as well as with the simultaneous video streams limitation.
You can cost out security, but a lot of the things that I love about Zoom's native app are truly priceless - it means I can see and hear more of people I care about. Another thing is supporting dual monitors with different screens, it makes it very easy to rearrange and see more than one person I want to see at a glance. You can do it with multiple browsers and so on, but it's more fiddly and you spend more time fussing with the screens, which means less time actually paying attention to the people.
We're getting really deep into the intricacies of Zoom and Google Meet here, and I feel like we're losing the larger plot. If you have a battle station set up for Zoom parties with multiple monitors with 50 simultaneous dancers that you need to keep an eye on, and you don't mind the security risks, then maybe you represent a specific edge case, but I think the vast majority of software users have different requirements that web browsers satisfy handily.
To reason by analogy, this is like me suggesting you wear a seatbelt while driving a car and you responding by saying: "well you're at risk the moment you step outside of your house, so if you really have no tolerance for injury you should simply not leave the house". You're saying instead of opening Zoom in the browser I should delete all personal data from my computer, and for what end? I'm doing this so that I can attend virtual dance parties efficiently? I don't understand how any rational cost benefit analysis could yield such a conclusion.
> "would I prefer to open myself up to attack, or would I prefer not to deliver this message at all?"
This is absolutely a false dichotomy. The choice isn't between sending data and not sending data, the choice is between sending data in the browser vs sending the same data within a desktop application.
> You need to do a complete threat model and explain how Zoom contributes to that risk,
The Zoom desktop clients have had RCE vulnerabilities where hackers were able to remotely execute arbitrary code on victims computers with zero user input required from the victims (they demonstrated this by remotely opening the calculator app). It's very obvious how Zoom contributes to that risk. "A zero-day vulnerability in Zoom which can be used to launch remote code execution (RCE) attacks has been disclosed by researchers. The researchers from Computest demonstrated a three-bug attack chain that caused an RCE on a target machine, and all without any form of user interaction [...] an animation of the attack in action demonstrates how an attacker was able to open the calculator program of a machine running Zoom following its exploit. As noted by Malwarebytes, the attack works on both Windows and Mac versions of Zoom [...] The browser version of the videoconferencing software is not impacted." [1]
> Practically speaking I have conversations in public places all the time and I don't stress about the possibility that someone might be recording me with a parabolic microphone.
Do you yell out your bank account number and routing number in public because you think the user experience of finding a private place to talk is too burdensome? Because that's metaphorically what you're arguing for.
[1] https://it.slashdot.org/story/21/04/09/209227/critical-zoom-...
There have been RCE vulnerabilities in browsers too. Do you have an example of a Zoom RCE vulnerability that wasn't fixed? The example you gave was one where Zoom was proactively publicizing their own work to recruit researchers to find vulnerabilities so they could be fixed before they caused actual issues - and Zoom fixed the issue, you're using Zoom's good behavior in security testing their app against them.
> Do you yell out your bank account number and routing number in public because you think the user experience of finding a private place to talk is too burdensome? Because that's metaphorically what you're arguing for.
No it's not, I wouldn't transmit my bank account number and routing number or similarly sensitive information over Zoom.
> This is absolutely a false dichotomy. The choice isn't between sending data and not sending data, the choice is between sending data in the browser vs sending the same data within a desktop application.
The choice is in fact between sending data and not sending data. I've given you one example (the limited number of simultaneous streams) where you're opting not to send data. You're just pretending that use case is invalid. There are other examples I could give, but they require more explanation and you seem determined to dismiss any examples I give.
We're not comparing the security of web browsers as a whole to the security of the Zoom desktop client, we're comparing the security of the Zoom web app to the security of the Zoom desktop app. Can you find a single example of an exploit that allowed a hacker to execute arbitrary code on a user's computer after visiting zoom.com (even one that was eventually fixed)?
And also, almost all computer users are running web browsers (they come preinstalled on most consumer operating systems). So by downloading Zoom you're adding an additional threat vector on top of whatever threat your favorite browser already represents.
> The example you gave was one where Zoom was proactively publicizing their own work to recruit researchers to find vulnerabilities so they could be fixed before they caused actual issues - and Zoom fixed the issue, you're using Zoom's good behavior in security testing their app against them.
Every reputable organization has a bug bounty program (including browser vendors). You don't get a participation trophy for having a bug bounty program. You're missing the entire point which is that Zoom offered $200,000 to security researchers to find a vulnerability in their products and both of their desktop clients produced critical vulnerabilities yet the browser version did not. Which I would infer means that the browser version is more secure. Once again, do you have any examples of Zoom exploits in the browser?
Zoom can't keep producing vulnerabilities and getting a pass because they eventually fix them. This exploit's existence was publicized before Zoom fixed it. What if it was sold on the dark web and exploited in the interim?
> No it's not, I wouldn't transmit my bank account number and routing number or similarly sensitive information over Zoom.
People are absolutely transmitting critical information via Zoom. Courts literally use Zoom to remotely administer proceedings. I've heard of companies that ask employees to hold up sensitive documents in front of the camera to verify their identity. Hiding your head in the sand and saying "just don't send sensitive info via Zoom" is disingenuous at best. And even if you did buy in to the "just don't send sensitive data bro" argument it doesn't matter because an RCE exploit could potentially expose information that you never transmitted via Zoom that just happens to be sitting on your filesystem.
> The choice is in fact between sending data and not sending data. I've given you one example (the limited number of simultaneous streams) where you're opting not to send data.
The overwhelming majority of your examples have been cases where you've begrudgingly admitted that there's a way to accomplish your goal in the browser, albeit less efficiently. You started this conversation by admitting that you can share your screen in the browser, but doing so via the desktop app saved you a few minutes. I haven't found any published documentation from Zoom in regards to the streaming limit and I'm not willing to call up 49 other people to test this for an HN debate, but like I said, the vast majority of users can fulfill their needs in the browser. The average Zoom user is not hosting digital raves. I couldn't even imagine wanting to have 50 videos playing on my screen vying for attention. And again, there's no technical reason for why you couldn't implement 50 streaming videos in the browser. Maybe Zoom should spend that $200,000 improving their browser product.
And again, this is about messages simply being undeliverable without the native app. If the web app takes an extra 5 seconds to join the meeting (I think it can actually be worse than this in a lot of cases - minutes lost) and I've just reached the meeting at 2pm and the meeting starts promptly at 2pm, and the native app causes me to miss 5 minutes of the intro... what is the cost there? I think in a lot of cases it can erase the benefits of video.
Courts are famously overloaded. If a court can get through 10 cases over a 4 hour session, each taking 24 minutes, and if each case loses 5 minutes of time due to using the browser app, then that's two whole cases worth of time they've lost. And it's not just about being able to handle a larger caseload: in a lot of cases inefficient communication results in incorrect communication and incorrect decisions.
Broadly though, you're taking it for granted that it's easier to make a browser app efficient than it is to make a native app secure. I'd actually wager there's a ceiling to how efficient you can make a browser app, and you can make the native app at least as secure as the browser app while also making it more efficient. Zoom has the money, they don't need to cheap out and do the browser app, and they shouldn't because efficient communication is a matter of life and death and their whole reason for being. Yes, it should be secure, but you can't just dismiss efficiency, being inefficient can cause security problems and it is often a matter of life and death.
> And again, there's no technical reason for why you couldn't implement 50 streaming videos in the browser.
Their docs specify that there are minimum system requirements for doing 50 rather than 25. This is an efficiency problem at the end of the day - the browser app is less efficient and can't handle as much info at a time with the same hardware.
The 'whole point' of a visual medium is not just to communicate ideas more quickly. Having eyeballs does not merely grant me a speed boost, it allows me to experience things that are simply ineffable otherwise. People didn't Zoom/Facetime their family members during the pandemic just because it was more efficient than texting them.
> And again, this is about messages simply being undeliverable without the native app. If the web app takes an extra 5 seconds to join the meeting
You're misusing the word undeliverable. Undeliverable means 'can not be delivered', not 'delivered 5 seconds later'.
> Zoom has the money, they don't need to cheap out and do the browser app
They're already doing the browser app. I'm saying they should do it well.
> Their docs specify that there are minimum system requirements for doing 50 rather than 25. This is an efficiency problem at the end of the day - the browser app is less efficient and can't handle as much info at a time with the same hardware.
You originally claimed that there was a hard limit to the number of simultaneous video streams that the browser version could handle, and that this was the difference between sending a message and not sending a message, and now you're walking that point back and saying that the browser version can't do it with the same hardware. So you're tacitly admitting that you were originally presenting a false dichotomy.
> being inefficient can cause security problems
There are multiple confirmed security flaws in the desktop Zoom apps (which you claim are more efficient), and your conclusion is "inefficient = insecure"? If anything, the opposite appears to be true according to your own claims.
> I'd actually wager there's a ceiling to how efficient you can make a browser app, and you can make the native app at least as secure as the browser app
Zoom themselves wagered $200,000, and the result was a critical RCE vulnerability in their desktop clients, and nothing in the browser version. But keep postulating with hypotheticals and ignore objective reality.
> if each case loses 5 minutes of time due to using the browser app [...] because efficient communication is a matter of life and death
First of all you've been throwing around this '5 minute' figure throughout this discussion, but there's simply nothing to substantiate it. Your entire argument hinges on this flimsy point derived from anecdotal evidence. I've never spent 5 minutes trying to set up Zoom in the browser. I predicted several days ago that this discussion would degenerate into anecdote trading, and here we are.
Second of all, if I were dealing with a serious court case then one of my primary concerns would be maintaining confidentiality. You completely ignored the entire point of my court example which was to illustrate the fact that security has serious implications, and you can't simply wave them off by saying "I wouldn't transmit personal information via Zoom". You're trying as hard as you can to avoid the most important aspect of using Zoom in court: security. Instead you wrote a thinkpiece about Zoom hypothetically taking 5 minutes to load. Imagine being a witness in a high profile case, on the brink of going into the witness protection program, with your literal life on the line, only to find out that your private information was leaked because someone didn't like the UX of the Zoom web app. And you have the gall to claim that bad UX is a matter of life and death. Are you being serious here?
You yourself said "I wouldn't transmit my bank account number and routing number or similarly sensitive information over Zoom", and yet you want the Zoom desktop app to be used in courts? That makes absolutely zero sense. Do you not believe courts deal with sensitive information?
Strange how we went from "The web is absolutely more than good enough for the vast majority of apps" to "majority of mobile gaming apps."
> I've seen you repeat this phrase over and over again like a mantra on HN, but without examples
I mean, almost every single web "app" out there suffers from this. The DOM isn't built for highly dynamic interactive applications. It's a system to deliver static text and images.
> What are some examples of popular apps that you think require the full brunt of a modern chip?
Now you're pretending I said something I didn't.
However, it's funny how the amazing fast web sites that are more than enough for the majority of apps struggle with even the most basic tasks even on maxed out machines. I mean, Slack's app needs up to 20% of CPU even on an M* Mac (last I tried it was M1 Max IIRC) to render a few animated emojis.
It's a single example, but it's quite representative of the state of the Web.
You've got your signals crossed. That was another commenter who wrote that statement [1].
> Strange how we went from "The web is absolutely more than good enough for the vast majority of apps" to "majority of mobile gaming apps."
We didn't go from one thing to another. I addressed a subset of the app market: gaming apps. Just like your Slack example addressed a subset of the app market: chat apps.
> I mean, almost every single web "app" out there suffers from this. The DOM isn't built for highly dynamic interactive applications. It's a system to deliver static text and images.
This is not a technical argument, it's a philosophical one. The council of browser elders never convened to proclaim that web browsers are only meant to deliver "static text and images", that's just your philosophical viewpoint. In fact, Apple is currently pushing WebXR to support the new Vision Pro, so apparently they didn't get the memo about "static text and images" [2].
> Now you're pretending I said something I didn't.
You said that the web is not performant enough. CPU speed is a pretty big component of performance.
> I mean, Slack's app needs up to 20% of CPU even on an M* Mac (last I tried it was M1 Max IIRC) to render a few animated emojis.
Slack's desktop app or Slack's web app? If you're talking about the Electron app, well then yeah bundling Chrome is never going to win efficiency awards, but now you're pretending I said something that I didn't. I'm not defending Electron apps. Everytime I discuss the web on HN someone does a bait and switch and starts talking about Electron. Don't conflate Electron with the World Wide Web.
If we're talking about chat apps, then I've watched high definition streams on Kick, Twitch, and YouTube where the chat is streaming in over Websockets faster than I can read it. The human brain at that point becomes the actual performance bottleneck. But tell me more about how the web can only handle a few lines of text (by commenting on a website).
[1] https://news.ycombinator.com/item?id=40891602
[2] https://webkit.org/blog/15443/news-from-wwdc24-webkit-in-saf...
[1] https://en.wikipedia.org/wiki/Distinction_without_a_differen...
i.e ads or search engine placement.
countless of public companies have it in their reports that mobile app users generate more revenue compared to web whether desktop or mobile.
and i'm not talking about game companies.
It's kind of crazy, because all of the super high numbers and companies that said they'd go bankrupt were looking at the Personal tier, which basically acted as a sales funnel towards the Pro tier, where the prices would not be as outrageous, even in the original version of the Runtime Fee: https://blog.kronis.dev/articles/unity-runtime-fee-a-look-at... (under "How bad is it, really?")
Of course, they since revised it so my article isn't relevant anymore, but if you look at the platform fee cost per install, then it becomes quite obvious and the initial pushback didn't seem to take this into account: https://blog.kronis.dev/images/1/6/-/f/e/16-fee-per-install-...
Aside from that, though, I guess companies will always try to take a part of the profits that anything offered through their platforms generates (Apple's App Store, Google's Play Store, Valve's Steam etc.). It's good to see things improving at least somewhat, though, since we can't express a lot of progress overnight.
It’s crazy that Unity’s PR people (and the CEO himself) were so objectively dumb and incompetent while being paid that much.
The retroactive part was probably indefensible but they did such a horrible job at explaining the actual fees initially that it utterly jaw dropping…
It’s fair to not like the Apple fees but the scenario isn’t equivalent.
One was a rug pull. If they did that all along it wouldn’t have been as big an issue.
Similar to Unity, these pricing ding the smaller people the most. But unlike Unity, the bigger players aren't joining the protest. I guess I was just foolish thinking businesses would at least think in the middle-term of "what if we want our own storefront one day ". I guess the EU might pick up that ball, but the Apathy from other devs is a bit disenheartening. The same Apathy that let these companies enshittify the net and turn into trillionaires as punishment
It provides new options. Granted they might not like the terms of the new options , as you clearly don’t. But nothing has been taken away from them in the process. It is completely unsurprising that there is apathy.
Unity tried to change the terms from under people which changed their livelihood prospective negatively.
If the only equivalence is that there’s a fee, then that applies to a lot more to the point it’s meaningless. Epic do a revenue share. Unity should have done a revenue share but did something more trackable without requiring regular audits.
Ultimately it wasn’t Unity’s actual fee that was the problem, had it been a new tier. But it retroactively changed things for people.
If you were apathetic/supportive of Apple and would stay on the App Store anyway, nothing changes. And I suppose a lot of businesses are in this group.
>But nothing has been taken away from them in the process. It is completely unsurprising that there is apathy.
Yes, that's my core problem. But the last two years should have taught me thst companies aren't looking in the long term these days. Epic is, sort of. if only because they have no option given their whole kerfuffle.
I don’t think that’s true. A very small proportion of smaller developers might have been disproportionately affected but Unity was just complete garbage at communicating the changes (not trying to downplay the retroactive bit, no excuse for that). Most people just didn’t bother reading the fine print or calculating the actual fees themselves and just looked at the published headlines.
I don't think it was a small portion. The main point was that the lowest cost plan was horrible and a ploy to get you to buy Unity Pro. If you weren't a free (as in freedom) app, it as a complete negative to be on the base plan.
> it as a complete negative to be on the base plan.
With the changes if you didn’t get pro after surpassing the revenue it would have gotten price but that wasn’t even an option previously.
I think it was actually a significant improvement for some people in that position:
- the cap was now per game/project instead of company
- you could still surpass the previous cap a bit and save some money by paying for install instead of immediately being required to get pro.
Everybody just seem to ignore that/ didn’t notice it because Unity did such a garbage job explaining the changes.
(I’m not really defending them, they only had to introduce this few because they almost literally burnt billions between by pointlessly buying random companies and going on some deranged hiring spree for no reason..)
If the app is taking donations or any sort of payment, then the Core Technology Fee applies after 1 million first installs in a year. If it’s a completely free app, this fee does not apply. This fee also does not apply for educational institutions, nonprofits, and government agencies (with a fee waiver).
Quoting from “ Understanding the Core Technology Fee for iOS apps in the European Union” [1]:
> Developers whose apps do not surpass one million first annual installs per year and nonprofits, educational institutions, and government entities with an Apple Developer Program fee waiver do not pay the CTF. The CTF is also not required for developers with a no revenue business that offer free apps without monetization.
[1]: https://developer.apple.com/support/core-technology-fee/
> Apple provides many conditions where developers do not pay the CTF: […] Developers that earn no revenue whatsoever. This includes offering a free app without monetization of any kind (physical, digital, advertising, or otherwise).
(from the link above)