ProtonMail vs Apple

Kee Nethery kee.nethery at elloco.com
Fri Aug 14 10:04:09 EDT 2020


Bypassing Apple in app purchasing is technically trivial, plenty of apps have done it for years and they have followed the App Store rules when doing so. Physical services (eg Plumbers) and physical products (eg Amazon) they cannot use Apple IAP. Digital goods and services (eg Epic) are required to use IAP. Those are the terms of service. Of course Epic got booted. Nothing surprising about it other than that they thought they would get away with it.

Kee Nethery

> On Aug 14, 2020, at 2:32 AM, JeeJeeStudio via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Waaah, now even EPIC with Fortnite has been kicked off the appstore,
> because they found a way to sell things past the appstore. And then Apple
> don't get 30%....
> 
> https://tweakers.net/nieuws/170916/apple-verwijdert-fortnite-uit-app-store.html
> It's in dutch but you get the message.
> or this one
> https://www.theverge.com/2020/8/13/21366438/apple-fortnite-ios-app-store-violations-epic-payments
> 
> Op zo 9 aug. 2020 om 16:52 schreef Andre Garzia via use-livecode <
> use-livecode at lists.runrev.com>:
> 
>>> Do Apple's actions and policies monopolistically harm consumers?
>> 
>> Yes it does. There is a ton of innovation that is user friendly that is
>> prevented from being present in iOS due to Apples practices. A simple
>> example is new browser engines, you can't have them. Which means you can't
>> have more private engines than what Safari uses. This also makes it harder
>> to bring lots of API innovation to iOS which would benefit users because it
>> would allow for better and more powerful web apps.
>> 
>> Since you can't sideload apps, you as a user need to have Apple permission
>> before installing software on the device you purchased and should own. You
>> as a developer are allowed to sell software outside of Apple's blessing,
>> even if you have customers interested in the software you make. Apple is a
>> gatekeeper and a very picky one.
>> 
>> Gatekeepers are harmful to consumers and sellers. Since you as a developer
>> can't simply compile software and sell it own your own page without Apple
>> double blessing, you're not really in control of your platform and Apple
>> may exercise the right to cut you out of the platform at any time. This is
>> harmful.
>> 
>>> Consumer behavior itself argues against that. Quite the contrary,
>> consumers are willing to pay a premium for Apple products and services
>> 
>> That is totally not true because you can't measure it. You can't measure
>> "iOS with a more open ecosystem" vs "iOS with its current draconian
>> ecosystem" because that you don't have the more open version to match it
>> against the current one. The choice here is not between Apple and Android.
>> Apple could still offer the same software, services, and hardware, and be
>> more open. People would still choose them. No one chooses the option with
>> less options and gatekeepers if they have an alternative. The tight
>> integration between iOS and macOS devices is wonderful and people are happy
>> to pay a premium for such quality. If you ask any Apple user why they buy
>> Apple, no one will answer: "Because I like the way they don't allow
>> developers to compete with Apple itself" which is why the EU and other
>> companies are crying wolf in the direction of one infinite loop. People
>> will say they choose Apple because of the attention to detail, the quality
>> of service, hardware, and software, none of which would be gone if Apple
>> was more open.
>> 
>> The key to understand this is that all that you like about Apple can still
>> be there, including the App store. If you want to stay in an environment
>> like what we have today, it should be possible to do so. But you should
>> also have options for when you want to step outside. There should be
>> alternative stores or alternative ways to distribute software.
>> 
>> I'm not saying "burn iOS and Apple". I'm saying the current practices
>> benefit no one but Apple and are harmful to a healthy ecosystem. They could
>> still be Apple and not be a bully. For example, the need of notarizing apps
>> is going to make distributing FOSS on macOS a bit harder. Once Apple moves
>> to its own ARM CPUs, it will be harder for every third-party vendor to
>> compete with Apple solutions as they'll be able to cram custom silicon like
>> T2 and lock down the machine in a way that has not been done in ages.
>> 
>> If I was LC I'd be throwing some more people into making sure LC runs
>> really well under Linux and Windows, both of which are second class
>> citizens when compared to macOS. Heck the IDE under windows is horribly
>> slow, I have no idea how it performs under Linux. When dealing with Apple
>> you always need a plan b.
>> 
>> On Sat, 8 Aug 2020 at 22:16, Jim Lambert via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>> 
>>> BrianM wrote:
>>>> One thing that seems to be missing in this discussion is the point of
>>> view of the ?client?, the one who downloads the app and pays for it
>>> 
>>> True.
>>> In the U.S. the laws against monopoly (the Sherman Act of 1890, the
>>> Clayton Act of 1914 and the Federal Trade Commission Act of 1914) are
>> there
>>> to promote competition amongst companies for the benefit of consumers.
>> Or
>>> our end users.
>>> 
>>> Do Apple's actions and policies monopolistically harm consumers? Consumer
>>> behavior itself argues against that. Quite the contrary, consumers are
>>> willing to pay a premium for Apple products and services.
>>> 
>>> Andre notes that Apple exercises a monopoly WITHIN the iOS system. But
>>> that is a misnomer. Apple has a proprietary system not a monopolistic
>> one.
>>> And they strictly control it. It's simply not true that "there is nothing
>>> iOS users can do about that." Yes, there is. Consumers who don't want to
>>> buy into Apple’s closed system are free to buy elsewhere. Consumers can
>>> choose Android or any other alternative products. No one is forcing
>>> consumers to buy and use Apple products, which is what would happen if
>>> Apple had an actual monopoly. In fact, some consumers prefer Apple's
>> strict
>>> proprietary control and are willing to pay mucho dinero for it.
>>> 
>>> Now look at it from the developers' point of view. Apple makes us jump
>>> through many more hoops than Android developers do. Apple constantly
>>> changes these hoops which can seem inexplicably capricious. But is it? Or
>>> is it a constant effort to assure safe computing for their consumers?
>>> 
>>> There seems to be an assumption that the 30% cut Apple takes is
>>> outrageous. But what does a developer get for that Apple %? If you think
>>> you can replace what Apple offers for less money, then just sell your app
>>> on Android and rake in the extra bucks. What's stopping you?
>>> 
>>> The reality is that the vast majority of smartphone apps make little or
>> no
>>> money, regardless of OS.
>>> So is it painful to surrender 30% of nothing? ;)
>>> 
>>> But back to the purpose of this list, aren't we lucky to have LiveCode, a
>>> development platform that gives us the power to develop for whatever
>>> platforms make sense for us?
>>> 
>>> Jim Lambert
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>> 
>> 
>> --
>> https://www.andregarzia.com <http://www.andregarzia.com>
>> Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list