The app ecosystem is the lock-in, and creates a very high bar to entry for other players outside the Apple-Google duopoly.
Note that Google has created a dependency on proprietary Google Play Services, and owns the Play Store, so even leveraging AOSP is not sufficient to overcome the barrier to entry.
There are two established players. Apple can charge whatever they want, and Google can copy their strategy, because they know users have nowhere else to go (the number of people who will permanently switch to independent degoogled phones is too small to affect the duopolists' business)
The phones do lots of things, and a lot of them well, so overall satisfaction doesn't mean that App Store pricing is satisfactory, nor fair.
Apple forbids developers from itemizing pricing and telling users how much Apple takes, interfering with informed consumer choice.
The cut is well known on HN, but I'm not sure that most users are fully aware that they're overpaying 10x on transaction fees, and the major consequences that it's a cut of revenue and not profit — the developer takes all the risk, and needs to cover all the development costs from their part, and can be even in the red, while Apple has a guaranteed profit with a guaranteed margin from every sale. Apple can be easily making more profit than the developers themselves.
We all know what Apple's take is. People complain about it all the time.
The perforative terms you use to describe customers you can't seem to attain are related.
If you describe your desired customer as a cult than you may hold them in too much disdain to achieve a quality product.
Demonizing Apple does not improve product quality in anyway.
Using a numeric ID + ignored path part is easy to implement, but actually using the textual part without an exposed ID seems more elegant to me. Tip for implementing that:
* have a separate table that maps slugs to IDs, allowing many-to-one relationship, because content's title will be updated, and you don't want to break old links.
* long slugs will get truncated by users. A zero-cost way to recover from that is `select id where slug >= ? order by slug limit 1`
* in either case don't forget to redirect to the canonical URL, so that people can't create duplicate or misleading URLs on your site.
I don't like slug-only URLs because they are hard to make concise. If the textual part can be compressed into one or two words, like what qntm does in his website, then it is okay, but most schemes do not really care much about slugs...
the problem with that, as mentioned in the article, is that that breaks if the content of the page changes. So on stack overflow for example, what happens if someone changes the title of their question? you either break the url or use an old version of the title, thus being misleading.
In theory, AVIF supports palette-based blocks, so it can express perfectly sharp edges and even transcode a GIF with perfect accuracy. In practice these modes are not used.
A blurry alpha channel is just having soft edges. A naive encoder will cause some of the previously transparent background bleed into visible pixels, usually causing darkened halos around the edges. This is a common problem in video game assets, and the fixes are the same: either bleed color around the edges (make transparent pixels have the right RGB values), or use premultiplied alpha color space. AVIF (also in theory) supports marking images as having premultiplied alpha.
Video compression may only cause issues at the edges due to chroma subsampling, in which case bleeding chroma to transparent pixels would help. All other cases would be errors in the pipeline, such as incorrect gamma handling, wrong supersampling implementation, or mixing up whether content is premultiplied or not.
Also premultiplication is just a way to cache the multiplication operation:
// using normal image
// note that everything after the plus depends entirely on the image
out = current * (1-img.a) + vec4(img.r*img.a, img.g*img.a, img.b*img.a, img.a)
// using premultiplied image
out = current * (1-img.a) + img
Which might make sense if you're drawing same bitmap very many times.
> Apple could add an API for 3rd party subscriptions to integrate with that screen.
They could. And the third parties would absolutely ignore it or make it a front door to their own subscription management, which could mean anything from something as simple as the current iOS subscription management (highly unlikely) or a link that opens a browser page that tells you to call a given phone number to cancel your subscription that is always "experiencing high call volumes" and "thanks you for your patience" after half-an-hour on the phone.
A service that is effectively un-cancelable really is the dream product: the person doesn't want it, so they don't actively use it (meaning you have no expense in providing it), but also don't want the hassle of putting up with your "are you sure?" tactics to cancel. Businesses make hundreds of millions of dollars annually on hard-to-cancel subscriptions in the US.
I'm just saying, it's a strawman argument to claim that Apple is doing this to "protect users". That's what they want you to think, but they're actually doing this to make a massive amount of revenue at the cost of literally everyone in the market, users and creators alike.
Edit: Econ 101 - the more inelastic the demand, the more the tax burden falls on consumers. One would assume that demand for Patreon is relatively elastic, at least when compared to things like food, housing, transportation, etc. Thus most of this tax burden will actually fall on the producers (i.e. Patreon and the creators), which explains why they're not willing to just take the 30% cut and will instead charge more for Apple users.
I would prefer to see them forced by legislation (like the Digital Markets Act) to allow some sort of fair, reasonable, and non-discriminatory licensing on the App Store. Ideally they would be required to allow third-party marketplaces and self-signed app distribution, then marketplace competition could push their take rate towards 0%.
I understand that some things are hard to cancel and some companies are malicious about this. Back in the pre-app days, this came up with "free samples" and gym memberships. The general solution back then was to either (a) not get scammed or (b) use a unique credit card that you could easily cancel. With the advent of things like Privacy cards, you can pretty easily do this without an App Store intermediate.
That said, they could keep the benefit for users and the fee for Apple Pay, but then not require that apps exclusively use Apple Pay. They could even require that all apps call an API to issue some scary warning that the subscription will not be manageable in your Apple Pay dashboard, make sure you trust this app developer, are you sure you want to continue? etc etc
Plus there are plenty of other billing services that can do this. I already mentioned Privacy cards. If you sign up for PayPal recurring payments, they also have an authorizations dashboard that you can easily use to revoke payment permissions. Neither of these companies needs to charge a 30% fee to offer that. Both charge somewhere around the "standard" CC fee of 3%.
Honestly, that's the one thing I don't want out of all of this... a secondary iOS app store.
There's real value for me, the family IT guy, not having to worry about my parents, who are in their mid-60s and not tech-savvy, getting told by their "friend" through email to download malicious software to their iOS devices. Right now, you just can't do that. If something wants to execute code on an iOS device, it has to do so through somewhat-sanitized means. It's not 100% foolproof, but getting malicious executables onto an iPhone without someone knowing about it is currently beyond the capability of most threat actors.
Is it as open or cheap as us tech people would like? No. But if I want that, I go buy an Android device.
That's fine, but that doesn't happen on Android where the restrictions are more lax. (Well, it does, but in rates that are too low to justify imposing the excessive measures iOS employs)
I empathize with your struggle, but it's a pathetically weak argument against letting Apple continue abusing their position. If your parents are clicking on random email or SMS links, that's an issue outside of your OS security policy. They could be autofilling their credit card details on a malicious site in Safari or iMessaging their SSN to someone with a spoofed CallerID. My parents both use Android and let me tell you, worrying about them activating Developer Mode on their phone is the last thing I go to sleep worried about. In a post-Pegasus world you and I both know there are bigger fish to fry.
Do your parents a favor, talk to them about digital security if you're actually worried about them. Your other choice is to let reductive paranoia consume you until you're only comfortable when their web browser and contacts list is locked in a straitjacket.
Without commenting on the appropriate level of charges, Visa and Apple provide very different services. For example, with Apple, you get administration of taxes in many locales as well as dealing with currency exchange. Also, I don't think sellers have to deal with chargebacks, although Apple might have their own version of a chargeback, but I am not sure.
> Also, I don't think sellers have to deal with chargebacks, although Apple might have their own version of a chargeback, but I am not sure.
They absolutely do, just through Apple, "Disputes".
Apple will refund the user the full purchase price (that's fun, $10 app, you get $7 after the Apple cut, and on refund, you have to refund $10, so you're actually out money).
And too many disputes will get your developer privileges restricted or revoked.
What would you pay to have access to the most affluent mobile users with CC's preloaded and ready to buy? That's what Apple is charging for. It must be worth quite a bit since people either pay or complain up and down they are forced to pay it or they don't have a business.
IIRC, the judge in the EPIC case even said there was no issue with 30%.
You mean for Apple to charge that on top of the Visa charges, which Apple is paying out of the 30% now, I assume? Apple is the merchant of record for App Store txns and pays all the transaction fees, as well as all their other costs, out of the 30%. (I don't know how much all that adds up to, but the total is strictly greater than sum of the credit card fees.)
> how many customers you can serve per parking spot/charging station. With gas, hoards of cars can be serviced quickly
For gas stations the throughput matters, because cars are blocking the queue. BEV charging is more comparable to parking. This is simply solved by having more charging stations (dispensers) at parking spots.
BTW: even in shittiest EVs, DC charging doesn't take hours. You probably have been misdirected to an AC charger designed to be used overnight. Unfortunately, many satnavs still treat charging stations as all equal like gas stations, and send you to the nearest one, instead of the fastest one.
> You probably have been misdirected to an AC charger designed to be used overnight.
It’s possible, I don’t recall. But those were the only available spots, in a European country with large ambitions to transition. Half were out of service, and many were occupied, which we often found out after driving to them for 15 min. With scarce spots, charging has to be fast to clear out space.
Getting to the point of convenience is a very solvable problem, but it’s still not there in many places and situations. I think fast charging will remain as an important part of that solution.
The big difference is that EVs are designed to be charged unattended (you plug in, and go do something else). Nobody needs to be monitoring the "pumps".
Charging locations are often combined with other businesses, which means it's usually not taking new space, only converts the parking space that would have been used to park a car anyway.
Large DC fast charging installations usually have a central hub that does the expensive things (AC-DC, batteries), and then the power is distributed to simpler dispensers that do communication with the car and cooling on the car's end. The whole setup is expensive, but the number of dispensers isn't the main limiting factor. The costly limiting factor usually is the maximum power the system can deliver at once. That directly dictates the maximum throughput (number of cars they can serve over time), regardless whether that power is delivered via few fast chargers or many slower chargers. The number of dispensers cancels out in the equation.
1000km in the slow-charging Leaf takes 14 hours. 1000km in quick-charging cars takes 9h-9.5h, compared to 8.5h in a gas car[1].
For the trivial case of a city-only car with a home charger all battery metrics are irrelevant, so even the terribly outdated Leaf is adequate.
But when leaving the perimeter of the home charger, the car will need to be recharged. Charging speed is primary factor that makes long road trips in BEVs take longer than in gas cars.
Battery sized large enough for a longest road trip adds a lot of weight and cost, which is a waste in daily city driving. Quick to recharging makes long trips possible, without need for a huge battery.
> 1000km in the slow-charging Leaf takes 14 hours.
> 1000km in quick-charging cars takes 9h-9.5h, compared to 8.5h in a gas car[1].
There are so many variables here. 1,000 cumulative km for my normal usage requires no waiting since I charge at home, so the it’s the ICE car that eats up time since I have to visit a fuel station.
On a 1,000km road trip I would be stopping anyway, so as long as it charges within the 30 min window it would not be additional time here either.
While that's true in the ideal case, there are still many areas in America where you need significant range to make it from one charger to the next. I have a Leaf which can fast-charge via Chademo, but the low range means that if I go anywhere rural I often have to spend several hours at a level 2 charger because it doesn't have the range to drive directly to the next fast charger.
People are OK with added weight and cost. You can't sell a truck without the added 500lbs and $12k of 4x4 shit under the front end. It lives there dragging down tow capacity, fuel, and driveability the entire life of the the vehicle, rarely used if ever.
Not exactly the same, but Mozilla had a whacky idea of compiling C to WASM and then WASM back to native code, which gives a natively running program that is sandboxing its own memory accesses:
