The "core problem" isn't Apple's rate - they're free to charge whatever they want. The real issue is that the App Store has no competition, so Apple could charge 90% and developers would have no choice but to abide or abandon the platform.
The evidence on the Android side doesn't seem to support this line of reasoning. There are multiple app stores on Android (including Amazon's), and sideloading is permitted, yet there is still a dispute over the platform fee rate that Google is charging for Google Play.
At the end of the day, it's a dispute over money, and specifically the platform commission rate: developers want a bigger cut of the retail app price on Google Play.
While Android is more open than iOS in that alternative app sources are allowed, it's still far from a level playing field. The Play Store has special privileges that third-party ones don't, such as being able to automatically update apps, rather than forcing the user to hit "install" for each individual app to be updated.
Your reasoning is faulty. There is no Android platform fee for app developers. In fact, alternative Android stores pay no fees at all. The Play Store has fees, and there's a dispute about them, but that doesn't make it analogous to the situation on iOS, which really has an iOS platform fee because it's impossible to install native code on the device you ostensibly own without Apple's ongoing permission.
... with a $700+ Mac purchased from Apple, and usually a $99/yr subscription purchased from Apple, plus a network connection to Apple's servers to obtain code signing permission, which must be periodically refreshed or your code will stop running, to ensure you are never independent of Apple's ongoing approval.
I'm pretty sure you can sideload without an Apple developer account($99) but you need to reinstall the app every 7 days and you can only have 3 installed at once. The processing on refreshing the install and swapping between more than 3 apps can be automated by using desktop software like AltStore.
Ha, was that a stealth edit? Fine, I’ll yield. You can have this win.
But really side loading is not as difficult as you’re making it out to be. The biggest hurdle for most is access to Mac, but renting a cloud instance an option too.
It's not about difficulty, like the number of mouse clicks or something. It's about who has ultimate control over your device. And with control comes the ability to extract rent.
Then you would agree it’s fair to rephrase your original post as
“It’s quite possible to install native code on the device you ostensibly own unless you want ultimate device control”?
Your phrasing doesn't make sense. Whether you "want" ultimate device control or not is irrelevant because you can't have it. The relevant thing is that Apple retains ultimate control, you never have it, and Apple uses that control to extract rent. My original phrasing is correct and doesn't need to be changed.
BTW I forgot to mention that the "Chromium for iOS" that you linked to is not a "non-Safari browser". It is the same Safari-wrapper version of Chromium that you can already get from the App Store. The "popular belief" is correct. There is currently no port of any alternative browser engine for iOS. Why would anyone bother to maintain an iOS port for software that can't be practically distributed?
No the popular belief is not correct. Perhaps the link the wrong, but you can mmap W^X and roll your own JIT, which is the only syscall preventing non-safari browsers.
> Why would anyone bother to maintain an iOS port for software that can't be practically distributed?
There is very little difference between a Mac and iOS app these days, and could be practically none at all if engineered correctly.
LOL you think it would be easy to just recompile Blink/V8 for iOS and get a browser you could actually use day-to-day? How many web browsers have you worked on? I have done several years of work on both Chromium and WebKit and I'm here to tell you that an iOS port of Blink and V8 good enough to actually use as a replacement for WebKit on iOS is going to require a huge coordinated effort of a large number of engineers, with a large ongoing maintenance cost afterward. It would probably require a ton of private APIs other than mmap W^X, too.
You're not going to be able to do it in your spare time. You probably wouldn't even be able to get a crippled and buggy version to build at all by yourself. Google's not going to invest in it for no reason while Apple expressly prohibits distribution. The only way there will ever be an alternative browser engine ported to iOS is if the EU actually follows through with forcing Apple to allow alternative browser engines on their App Store and/or alternative app stores, and Apple subsequently loses all of their inevitable appeals in court. Only then would Google (or Mozilla) be able to justify the investment.
... except even just in that page there's at least one important feature listed as not supported on iOS (pointer compression) and I'm willing to bet that there are many other issues you'd need to fix before you could call a fully functional V8 iOS JIT port "done". And V8 is only one of dozens of components in the whole browser engine. You are vastly underestimating the complexity of these projects.
Are you sure my first link I originally posted wasn’t a full rendering engine? I know I had read it was included a few years ago. Looks like a custom renderer to me:
I am absolutely certain. Chromium on iOS wraps WebKit and adds some features mentioned in the comments in that file, such as translation. But it's still just a wrapper and the rendering engine is still WebKit, not Blink. If you don't believe me, here is the implementation of CWVWebView where it creates the underlying WKWebView: https://source.chromium.org/chromium/chromium/src/+/main:ios...
>Please refer to the Apple documentation on how to get a code signing identity and certificates. You can check that you have a code signing identity correctly installed by running the following command.
It has a secure chain of trust in the sense that the machine is secured against user control. Face, meet boot.
The arguments on Android are sometimes even simpler to make (which I appreciate might not be intuitive at all), as there is a space where there SHOULD be competition and clearly CAN BE competition and yet there are arguments being made that Google is going out of their way to stifle this competition regardless, by such techniques as limiting the functionality of third-party markets (a big one was preventing them from supporting automatic upgrades), or their included anti-virus software flagging alternative markets (which reminds me that I haven't caught up on the Epic lawsuit against Google recently, and really really should).
You'll find me ranting about making a non-system permission for automatic updates on Android for years on this forum. Now it's there, and I credit Epic.
But like Windows having IE/Edge installed by default (& being sued for it), Google Play is the default store for Android, & 95% of public doesn't know otherwise.
To be fair (pedantic? devil's advocate?) Samsung ships all their phones with the Samsung store as well. I suspect there's a few other bit names that do similar. A great many Android users have alternative stores, some some probably use them without knowing the difference as well.
To be honest, I doubt many of them care, given all they want is apps from a trusted source, and most people probably trust Samsung if they are buying Samsung phones with specialized Android builds made by Samsung, if they even know the difference.
My comment doesn't detract from that demand. What I'm pointing out is that Apple will suffer from this at a much larger scale, therefore it makes sense that they will fight tooth-and-nail to stop it.
The 'platform fee' shpiel is a distraction from the real problem: iOS must allow alternative storefronts if it wants to survive long-term antitrust scrutiny. There is no other logical outcome.
That may indeed be true. However, the core dispute over
App Store fees will likely remain, irrespective of additional app stores or sideloading, just as it has on Google Play.
Solving the single app store antitrust issue doesn't solve the platform fee dispute.
it does, because those who don't want to pay the platform fee would move off to the other store-front (and not use any services provided by the apple appstore).
Amazon threw billions at creating an alternate storefront for Android devices. If they cannot achieve it, then who could? Maybe Samsung, and then it's a triopoly where which store still depends on who sells your phone.
This is the opposite of my recollection. I thought Samsung just started bundling their own app store, and was referencing that it may yet succeed. Maybe this is attempt 2?
Amazon tried selling phones with their own app store built in, but Fire Phones never took off for whatever reason.
Your point of view here will depend somewhat on your level of success.
In the current model, the barrier to entry is pretty low. $99 gets you xcode, plus you need done hardware.
Once you've made something you need to reach a market. A good market place (like a regular super market) brings together suppliers and customers. That market has costs.
One model for costs is to charge each app the same amount. Say, for example $5000 per app submission. Lots of successful suppliers would like this model because it raises the bar for completion, and means they pay less money.
Another model is free-to-enter, but takes a cut of the sales. Successful products end up paying much much more than stuff no-one wants.
Overall I think I prefer the second model. Wildly successful apps, and developers, are basically funding an equal-access marketplace.
Now, of course there are winners and losers. From published numbers its clear most apps make 0,for some definition of 0. Every developer thinks their app is special, but most are, well, not.
Good marketing helps, buzz in the tech-press, visibility on forums, shows and events, and do on. Some do nothing, waiting for their big apple-lottery break of being "promoted in the app-store".
Developers risen in a world of cost-free-everything believe that they are the sole value-add in the path from hardware to consumer. Apple should provide this appstore connection to the developer free of charge. Of course developers think this, and they're welcome to think this, but it doesn't mean Apple has to do it this way.
Developers have choices. They can choose to develop for Android instead. They can choose to use the Google store, or a different store, or make their own store.
If you develop for iOS you know the rules. If you see value in that market (and you like the low barrier to entry) then go for it. If you make money then pay your 30%. If you don't (and the odds are you wont) then delight in the money you saved by there not being an entrance fee.
But don't sign up for the competition, win the game, _then_ complain the prize money is too low.
You may like Apple, you may not. But its your choice to join their game, or not. There's no bait-and-switch here, the rules are clear and well understood. You either accept their position of strength, their ability to crush you on a whim, their ability to arbtitarily create winners and losers, their ability to earn royalties on your code (on their platform) or you don't.
> In the current model, the barrier to entry is pretty low. $99 gets you xcode, plus you need done hardware.
Hundreds of dollars in apple hardware and software compared to zero dollars for MSVC community, zero dollars for android developer studio, zero dollars for linux toolchain or whatever.
>Once you've made something you need to reach a market. A good market place (like a regular super market) brings together suppliers and customers. That market has costs.
The cost of hosting the app store is essentially the cost of hosting a web service that lets you download and buy programs. The developers could easily host their own app store as a web page if iOS just facilitated running programs downloaded from the internet or loaded externally. Apple has built themselves a dam upstream and is charging everyone downstream for water-rights-as-a-service.
>One model for costs is to charge each app the same amount. Say, for example $5000 per app submission. Lots of successful suppliers would like this model because it raises the bar for completion, and means they pay less money.
>Another model is free-to-enter, but takes a cut of the sales. Successful products end up paying much much more than stuff no-one wants.
The only fair model here is the one where 100% of apple's income comes from hardware sales alone. That is the only situation where you don't set up the user to be exploited by erecting these walls around what they can and cannot run on their own hardware.
> If you develop for iOS you know the rules.
They know the rules, and they know the rules are bullshit. What do you want them to do, throw their hands in the air and say "welp, them's the rules, I guess we can should never try to use our leverage or negotiate better rules cause that's just how it is I guess."
> Hundreds of dollars in apple hardware and software compared to zero dollars for MSVC community, zero dollars for android developer studio, zero dollars for linux toolchain or whatever
Apple’s software is free, and you need more than zero dollars for the hardware to run Android Developer Studio.
Also, on both platforms you may need a few (or more than a few) phones and tablets for testing (you may be able to test on a simulator, but that doesn’t guarantee things work on the real hardware, doesn’t give you a good idea about performance, and certainly is not a good option for apps that use on-board sensors such as accelerometers)
In the end, I think the difference in cost is between the cost of a PC and that of a Mac, so ballpark $500 in both cases, the phones to test on may cost more.
>The only fair model here is the one where 100% of apple's income comes from hardware sales alone. That is the only situation where you don't set up the user to be exploited by erecting these walls around what they can and cannot run on their own hardware.
And that is what we call the slippery slope.
Apple has created a successful product,
therefore developers want to make money from it,
therefore apple cannot charge a fee for access,
therefore apple cannot charge for developer tools,
therefore apple cannot charge for hardware (lest it makes the developers market smaller than it could be if phones were free)
>>What do you want them to do, throw their hands in the air and say "welp, them's the rules, I guess we can should never try to use our leverage or negotiate better rules cause that's just how it is I guess."
They can choose not to play. If Apple is not offering any value for their 30% then simply don't publish on IOS.
If all the developers stop developing for IOS then the rules would change.
Of course small developers have no power because individually they have no power, and they are not willing to pool that power collectively (ie unionize).
They're trying to get the govt to act as a collective bargainer on their behalf. Which is likely to fail,because Apple is better at govt than they are.
So yeah, I expect them to say "I can make more money elsewhere, so I'm leaving ios - the fact they don't suggests apple is adding plenty of value worthy of their 30%
But from what I hear of it Android is a mess, rife with malware, and a blatant rip-off of the success of iPhone and iOS. The sideloading support while convenient also opens up opportunities for abusive apps like spyware that unethical people use to track their household members without permission. I would not hold any of that up as a model.
Have you actually used it? Android with free software stores like F-Droid is pretty comfy. It's community-curated, so none of the garbage asset-flips that Apple loves to greenlight makes it onto the platform. It's also entirely transparent with regards to who gets removed, and doesn't allow you to use harmful proprietary software that infringes your personal liberty as a user. There are no ads when you search for things, and malware is removed when the community spots it, rather than when Apple decides to remove it.
Remind me of how Apple is doing a better job here, again?
