3 ms·

Apple likes to highlight all the ways their actions benefit developers, while ignoring all the ways their actions harm developers. Well if you get to add money

Apple likes to highlight all the ways their actions benefit developers, while ignoring all the ways their actions harm developers. Well if you get to add money to your bottom line for all the great stuff you do, you should also have to subtract money for all the crappy things you do. Off the top of my head: - Developers should get a “cut” whenever Apple makes arbitrary changes that completely break 3rd-party apps. If the app’s code doesn’t change but Apple does change something, their behavior is literally creating problems for developers with no cost to Apple. Let’s charge them! - Developers should get a “cut” whenever Apple is literally the reason for delay when trying to deliver things like critical fixes to customers. Let’s charge them! - Developers should get a “cut” whenever their reputation is completely trashed by users because Apple refuses to acknowledge their own mistakes. In other words, Apple is perfectly happy to let users think apps are trash, even if the reason for the problem is Apple. Let’s charge them! Apple doesn’t get to have only the good parts. I personally am sick and tired of all the ways they get to hide their awful behavior, and forcing developers to take the brunt of it.

donquixote25 5y ago
None those will ever happen unless developers/app companies for a union of some sort.
- pooper 5y ago
  I see no way Facebook, Google, Microsoft, Netflix, Uber, ... would join such a union. And if they did, would they have way too much influence on the union?
  - donquixote25 5y ago
    That's true. I guess if all the app developers pulled their apps out of the app store, the larger companies could just come in with their own version of all the apps.
lelandfe 5y ago
Charging for API compatibility issues sounds like a dangerous precedent.
- blowski 5y ago
  It exists in enterprise. You can have SLAs that an API will be supported for 5 years, for example.
  - e4e78a06 5y ago
    And enterprise apps are notorious for being stagnant and difficult to use. Not the newfangled SaaS stuff but the legacy stuff that has the SLAs you're talking about. Apple's decision to break apps that don't update is a user-centric decision. Just like deciding against GC and forcing automatic reference counting for more consistent UX performance is a user-centric, developer-hostile decision.
    - bduerst 5y ago
      >Apple's decision to break apps that don't update is a user-centric decision. Is it really though? Users are then stuck with their favorite apps being broken and unusable. We're not talking just about mandatory security updates here, some of the breaking changes are mundane.
      - e4e78a06 5y ago
        In the long run, it frees up the hardware manufacturer to make big changes that benefit the user. For example one of the reasons Apple was able to pull off the Arm transition was because they didn't have years of backward compatibility to deal with. They didn't have to deal with 32 bit apps, because those had been banned by Apple in a prior OS version. No super old legacy APIs, because they all were already removed in prior OS versions. Just compare the cluster-fuck that Windows on Arm is to the great experience of running x86 apps on an Arm Mac. > Users are then stuck with their favorite apps being broken and unusable. Yes, and they get mad at developers and the developers have to fix it when they otherwise wouldn't have. That means Apple can credibly roll out new APIs and features that are _better_ and force developers to adopt them. That's incredibly positive for users in the long run. Things like HW accelerated machine learning (still not available on Windows!), ARKit (Android equivalent is garbage), GPU accelerated UI (a dumpster fire on Android that no developer uses), etc. Think about this: if you're an AR app developer and Apple suddenly rolls out a new update that massively boosts performance IF you use the new API, are you going to use the new API and spend time porting over your existing functionality? Hell no. But if Apple forces you to, in the long run users get a way faster app, in exchange for some short run inconveniences because the app broke. A famous example that the Android community gripes about is Google's Camera2 API. It gives much better image quality but Snapchat refuses to use it. So Android image quality in Snapchat continues to suck because Google doesn't have the cajones to outright remove old APIs and force app developers onto new ones.
deleted 5y ago
[deleted]
MichaelBurge 5y ago
"Sure - we've discounted the 'Apple Tax' from 40% to 30% to account for all these costs we've been inflicting on you. No actual changes to your fees - we've been thinking of our precious developers and giving you that 10% discount since the very beginning."
arcticbull 5y ago
> - Developers should get a “cut” whenever Apple makes arbitrary changes that completely break 3rd-party apps. If the app’s code doesn’t change but Apple does change something, their behavior is literally creating problems for developers with no cost to Apple. Let’s charge them! So when Apple introduces new features and frameworks, should developers then pay Apple? This doesn't seem to make sense.
- latexr 5y ago
  > So when Apple introduces new features and frameworks, should developers then pay Apple? They already do, in the form of a couple subscriptions. A fixed one of $99/year and another one which is a tax of 30% on their revenue.
  - gowld 5y ago
    And they could pay more if Apple never made breaking changes.
- pooper 5y ago
  >> - Developers should get a “cut” whenever Apple makes arbitrary changes that completely break 3rd-party apps. If the app’s code doesn’t change but Apple does change something, their behavior is literally creating problems for developers with no cost to Apple. Let’s charge them! > So when Apple introduces new features and frameworks, should developers then pay Apple? This doesn't seem to make sense. I thought so too at first but that brings back one idea I had that most independent software vendors will probably hate and puts more control in Apple's hands but here it is anyway: Apple can add a way for developers to submit source code, assets, and machine readable build instructions in an Apple supplied format. Apple then builds the bits that goes on the App Store. Developers already pay USD 100 a year for the privilege of being on the App Store anyway, right? This way, if Apple introduces new features and frameworks, they can automatically update the code as needed and push updates to the users?
  - gowld 5y ago
    Then Apple could steal dev IP.
deleted 5y ago
[deleted]

donquixote25 5y ago

None those will ever happen unless developers/app companies for a union of some sort.

pooper 5y ago
I see no way Facebook, Google, Microsoft, Netflix, Uber, ... would join such a union. And if they did, would they have way too much influence on the union?
- donquixote25 5y ago
  That's true. I guess if all the app developers pulled their apps out of the app store, the larger companies could just come in with their own version of all the apps.

lelandfe 5y ago

Charging for API compatibility issues sounds like a dangerous precedent.

blowski 5y ago
It exists in enterprise. You can have SLAs that an API will be supported for 5 years, for example.
- e4e78a06 5y ago
  And enterprise apps are notorious for being stagnant and difficult to use. Not the newfangled SaaS stuff but the legacy stuff that has the SLAs you're talking about. Apple's decision to break apps that don't update is a user-centric decision. Just like deciding against GC and forcing automatic reference counting for more consistent UX performance is a user-centric, developer-hostile decision.
  - bduerst 5y ago
    >Apple's decision to break apps that don't update is a user-centric decision. Is it really though? Users are then stuck with their favorite apps being broken and unusable. We're not talking just about mandatory security updates here, some of the breaking changes are mundane.
    - e4e78a06 5y ago
      In the long run, it frees up the hardware manufacturer to make big changes that benefit the user. For example one of the reasons Apple was able to pull off the Arm transition was because they didn't have years of backward compatibility to deal with. They didn't have to deal with 32 bit apps, because those had been banned by Apple in a prior OS version. No super old legacy APIs, because they all were already removed in prior OS versions. Just compare the cluster-fuck that Windows on Arm is to the great experience of running x86 apps on an Arm Mac. > Users are then stuck with their favorite apps being broken and unusable. Yes, and they get mad at developers and the developers have to fix it when they otherwise wouldn't have. That means Apple can credibly roll out new APIs and features that are _better_ and force developers to adopt them. That's incredibly positive for users in the long run. Things like HW accelerated machine learning (still not available on Windows!), ARKit (Android equivalent is garbage), GPU accelerated UI (a dumpster fire on Android that no developer uses), etc. Think about this: if you're an AR app developer and Apple suddenly rolls out a new update that massively boosts performance IF you use the new API, are you going to use the new API and spend time porting over your existing functionality? Hell no. But if Apple forces you to, in the long run users get a way faster app, in exchange for some short run inconveniences because the app broke. A famous example that the Android community gripes about is Google's Camera2 API. It gives much better image quality but Snapchat refuses to use it. So Android image quality in Snapchat continues to suck because Google doesn't have the cajones to outright remove old APIs and force app developers onto new ones.

deleted 5y ago

[deleted]

MichaelBurge 5y ago

"Sure - we've discounted the 'Apple Tax' from 40% to 30% to account for all these costs we've been inflicting on you. No actual changes to your fees - we've been thinking of our precious developers and giving you that 10% discount since the very beginning."

arcticbull 5y ago

> - Developers should get a “cut” whenever Apple makes arbitrary changes that completely break 3rd-party apps. If the app’s code doesn’t change but Apple does change something, their behavior is literally creating problems for developers with no cost to Apple. Let’s charge them! So when Apple introduces new features and frameworks, should developers then pay Apple? This doesn't seem to make sense.

latexr 5y ago
> So when Apple introduces new features and frameworks, should developers then pay Apple? They already do, in the form of a couple subscriptions. A fixed one of $99/year and another one which is a tax of 30% on their revenue.
- gowld 5y ago
  And they could pay more if Apple never made breaking changes.
pooper 5y ago
>> - Developers should get a “cut” whenever Apple makes arbitrary changes that completely break 3rd-party apps. If the app’s code doesn’t change but Apple does change something, their behavior is literally creating problems for developers with no cost to Apple. Let’s charge them! > So when Apple introduces new features and frameworks, should developers then pay Apple? This doesn't seem to make sense. I thought so too at first but that brings back one idea I had that most independent software vendors will probably hate and puts more control in Apple's hands but here it is anyway: Apple can add a way for developers to submit source code, assets, and machine readable build instructions in an Apple supplied format. Apple then builds the bits that goes on the App Store. Developers already pay USD 100 a year for the privilege of being on the App Store anyway, right? This way, if Apple introduces new features and frameworks, they can automatically update the code as needed and push updates to the users?
- gowld 5y ago
  Then Apple could steal dev IP.

deleted 5y ago

[deleted]