3 ms·

>>API parity Generally, an API that Apple is developing gets dogfooded by Apple for at least a year before it is released for public use. Sometimes they decid

>>API parity Generally, an API that Apple is developing gets dogfooded by Apple for at least a year before it is released for public use. Sometimes they decide the API just isn't there yet, like Marzipan, and they put it through another year of revisions and dogfooding before they make it public. Apple has operated this way forever.

wlesieutre 7y ago
7 years of Music being the exclusive audio app with Siri support is a particularly crappy example. I'm sure it takes some work on Apple's side to make that work for 3rd parties, but I'm also sure Apple knew that Spotify users (and many other music apps) wanted it and could have done it sooner.
- GeekyBear 7y ago
  Apple has been adding more domains to the SiriKit API with every iOS update since the API was added in iOS 10. >Apps adopt SiriKit by building an extension that communicates with Siri, even when your app isn’t running. The extension registers with specific domains and intents that it can handle. For example, a messaging app can register to support the Messages domain, and the intent to send a message. https://developer.apple.com/siri/ https://developer.apple.com/siri/ Originally it only supported VoIP calling, Messaging, Payments, Photos, Workouts, Ride booking, Car commands, CarPlay (automotive vendors only), and Restaurant reservations. The next iOS version adds SiriKit support for playing music.
  - shkkmo 7y ago
    So... Apple added support for domains that don't provide them a competitive advantage well before they added support for the domains that do. Is this supposed to make it look better?
    - GeekyBear 7y ago
      Wait, are you trying to claim Apple doesn't have their own entry in any of those domains? Ever heard of FaceTime or iMessage? How about Apple Cash?
      - shkkmo 7y ago
        FaceTime and iMessage are features that are used to sell iPhones (and the ecosystem in general), they are not products that exist to directly provide a revenue to Apple. I am not super familiar with Apple Cash, but my understanding of it is that it also falls more on the Feature side and doesn't exist to provide a revenue stream on its own (hence why there are no fees for debit cards). iTunes is clearly more of a product as it creates a significant revenue stream for Apple. It makes sense that Apple cares less about competition with its features as that leads to a better user experience and more iPhone sales while Apple cares more about competition with products as that cuts directly into their income.
shkkmo 7y ago
Apple could also make those APIs usable by the public and mark them as "Unstable". Or Apple could choose to not release versions of its apps that depend on thos parts API until those parts of the API are released to the public. Just because Apple has operated this way "forever" doesn't mean that it isn't anti-competitive and deserving of attention from anti-trust regulators. I'm not of the opinion that Apple should not be able to both operate and compete in a marketplace, but if they are doing both there need to be some rules put in place to prevent anti-competitive behavior.
- dwaite 7y ago
  > Apple could also make those APIs usable by the public and mark them as "Unstable". No they couldn't. Because those APIs would become frozen and required by nature of large software vendors deploying software that uses them. Functional compatibility of an API which was documented as not finished would have to be maintained across OS releases. I've seen unintended dependencies have a deprecation plan in macOS that takes years. For the most radical example, there is still a copy of libssl.0.9.7.dylib. The 0.9.7l version came out in 2006. But it turns out OpenSSL does not provide binary compatibility even amongst patch releases. This was likely why on Mojave, using "Marzipan" in your own apps required making operating system security changes (from recovery mode, no less).
  - shkkmo 7y ago
    > No they couldn't. Because those APIs would become frozen and required by nature of large software vendors deploying software that uses them. Functional compatibility of an API which was documented as not finished would have to be maintained across OS releases. Yes, they can. There is nothing stopping Apple from marking an specific APIs as "Unstable" with the understanding they could be removed or modified at anytime.
    - edoceo 7y ago
      API becomes a contract, documentation or not. There is blowback when the contract changes. This blowback is what stops unstable API from becoming public. Brreaking change for ApI used by 10k devs? Big blowback.

wlesieutre 7y ago

7 years of Music being the exclusive audio app with Siri support is a particularly crappy example. I'm sure it takes some work on Apple's side to make that work for 3rd parties, but I'm also sure Apple knew that Spotify users (and many other music apps) wanted it and could have done it sooner.

GeekyBear 7y ago
Apple has been adding more domains to the SiriKit API with every iOS update since the API was added in iOS 10. >Apps adopt SiriKit by building an extension that communicates with Siri, even when your app isn’t running. The extension registers with specific domains and intents that it can handle. For example, a messaging app can register to support the Messages domain, and the intent to send a message. https://developer.apple.com/siri/ https://developer.apple.com/siri/ Originally it only supported VoIP calling, Messaging, Payments, Photos, Workouts, Ride booking, Car commands, CarPlay (automotive vendors only), and Restaurant reservations. The next iOS version adds SiriKit support for playing music.
- shkkmo 7y ago
  So... Apple added support for domains that don't provide them a competitive advantage well before they added support for the domains that do. Is this supposed to make it look better?
  - GeekyBear 7y ago
    Wait, are you trying to claim Apple doesn't have their own entry in any of those domains? Ever heard of FaceTime or iMessage? How about Apple Cash?
    - shkkmo 7y ago
      FaceTime and iMessage are features that are used to sell iPhones (and the ecosystem in general), they are not products that exist to directly provide a revenue to Apple. I am not super familiar with Apple Cash, but my understanding of it is that it also falls more on the Feature side and doesn't exist to provide a revenue stream on its own (hence why there are no fees for debit cards). iTunes is clearly more of a product as it creates a significant revenue stream for Apple. It makes sense that Apple cares less about competition with its features as that leads to a better user experience and more iPhone sales while Apple cares more about competition with products as that cuts directly into their income.

shkkmo 7y ago

Apple could also make those APIs usable by the public and mark them as "Unstable". Or Apple could choose to not release versions of its apps that depend on thos parts API until those parts of the API are released to the public. Just because Apple has operated this way "forever" doesn't mean that it isn't anti-competitive and deserving of attention from anti-trust regulators. I'm not of the opinion that Apple should not be able to both operate and compete in a marketplace, but if they are doing both there need to be some rules put in place to prevent anti-competitive behavior.

dwaite 7y ago
> Apple could also make those APIs usable by the public and mark them as "Unstable". No they couldn't. Because those APIs would become frozen and required by nature of large software vendors deploying software that uses them. Functional compatibility of an API which was documented as not finished would have to be maintained across OS releases. I've seen unintended dependencies have a deprecation plan in macOS that takes years. For the most radical example, there is still a copy of libssl.0.9.7.dylib. The 0.9.7l version came out in 2006. But it turns out OpenSSL does not provide binary compatibility even amongst patch releases. This was likely why on Mojave, using "Marzipan" in your own apps required making operating system security changes (from recovery mode, no less).
- shkkmo 7y ago
  > No they couldn't. Because those APIs would become frozen and required by nature of large software vendors deploying software that uses them. Functional compatibility of an API which was documented as not finished would have to be maintained across OS releases. Yes, they can. There is nothing stopping Apple from marking an specific APIs as "Unstable" with the understanding they could be removed or modified at anytime.
  - edoceo 7y ago
    API becomes a contract, documentation or not. There is blowback when the contract changes. This blowback is what stops unstable API from becoming public. Brreaking change for ApI used by 10k devs? Big blowback.