Naiyas

canukstorm said:

One of the most interesting tweets I've seen today

https://twitter.com/rjonesy/status/1436372845458771969

https://twitter.com/rjonesy/status/1436371919050362888

I noticed those points in the ruling too. I also noticed that 70% of apps are games, so by corollary 98% of the revenue comes from 70% of the apps.

But the really interesting statistic was that virtually ALL of the game revenue came from only 10% of the total iOS user base! There’s quite a bit to unpack there, but the questions that I’d like to get answered are:
1. How popular are games really? Yes they make lots of revenue but it’s only from a tiny minority of platform users.
2. Do the other 90% have any games on their devices? I would guess so but they are likely free, ad-funded, or they just play the big games for free without buying the in game credits and stop when they have to start paying.
3. Is Apple Arcade included in this revenue figure? If not, then subscription based gaming may actually increase the overall “paying” market size.
4. Are games actually too expensive to play given only 10% (I assume those who can afford to drop 1,000’s on in game credits) actually pay to play them?

Epic seem to think they can expand their market by offering a 20% discount on in-game credits, but I suspect the growth opportunity with their current business model is not actually as big as they think it is.

cropr said:

Bosa said:

the payment thing will not matter , 90 percent of developers will stay same because the cost of collecting your own payments will be much more of what Apple charges 

As a developer I can say it is the opposite.  Up to now I had to develop and maintain 3 interfaces to payment systems, 1 for iOS apps, 1 for Android apps and 1 (commission 2,7%)  for the rest: web apps, Windows apps and Mac apps.     As I see it now, the last one will be sufficient in the future.  Next to the lower commission, there is also a cost savings in development and also in administration, as I need only 1 reconciliation of the payments in my accounting system.

I think you need to re-read the judgement. You will still have to accept payments from the store payment API as the injunction makes quite clear that the ability to take external payments is in addition to taking payments from the store API.

radarthekat said:

get serious said:

Allowing links to external developer stores is fine. I would bet most mainstream users will opt for Apple's App store for convenience sake rather than saving 10-30% on an App. I wonder, will the AppStore auto update system be supported on external purchases? Or will the purchaser have to revisit the external site to get updates. Also surely the unsubscribe process for third party purchases will super simple <sarcasm>
Time will tell if store security, price and convenience will have a material impact on Apple's bottom line. 

Problem is, some developers won’t give customers the option to pay via the App Store.  They might take all in-app payments only via their external payment gateway.  And there will be an opportunity for someone to be that gateway outside the App Store for all iOS developers who want to take advantage.  A third-party payment gateway could slide in under the 30 or 15% Apple commission with a 10%, or 5% commission for handling transactions.  This will be great for developers, but will leave Apple with nothing for its work creating and maintaining the App Store, it’s work testing apps, it’s costs to host and provide bandwidth to download apps, and it’s efforts to design, develop and maintain the 150,000 APIs and associated developer tools.  Well, except the $99 developer fees.  Not sufficient to cover costs I’d guess.  

From my reading of the “injunction” that is not what it says. It says Apple cannot prevent a developer from offering and including a payment system in addition to Apple’s IAP mechanism. This says to me that a developer can still be barred from the App Store for not including Apple’s IAP if they offer their own payment mechanism.

It’s an anti-steering provision injunction which only stops Apple from barring apps that have external payment systems in addition to their own. It does not stop them from barring apps that have only external payment systems.

Overall I see nothing wrong in this proposal provided it applies equally to all electronic products... Smart TVs and the like included. Security updates should be made available for long after a product is sold and 5 years should be the minimum. If the security updates require a new OS update to take place then it is up to the manufacturers to make sure that such their strategy for meeting the requirement doesn't adversely impair the usability of their products. Many point to Apple's "battery-gate" saga, but slowing a phone down to provide new capabilities or even not providing them to retain existing capabilities upon upgrade is justifiable "provided it is advised and can be overridden by the end user should they choose to accept the consequences of their actions". In my mind this doesn't equate to "planned obsolescence" it the consequence of not having the latest hardware and has been the case since computers became consumer products.

As for feature parity in updates I don't believe there is anything that requires this to be the case even in the car manufacturer market which is why companies like Tesla, BMW, Mercedes, etc can sell the same product and then unlock extra features with a paid for software update. To draw a parallel, apps sold on the App Stores do this kind of thing ALL OF THE TIME under the banner of subscriptions or in-app purchases after all.

When you buy an electronic product you buy the hardware and it is the longevity of the hardware that is being legislated for here. It just so happens that the hardware can be compromised by software security issues which is the legislative vector of imposing such requirements. From my point of view this is a good thing that in no way restricts innovation but puts some of the onus on manufacturers to take responsibility for the products they produce and profit from.

retrogusto said:

“Top of the list was a "lack of fingerprint reader," which scored 31.9% of the vote. Fingerprints are still the main form of biometric identification in Android devices, though it is unclear exactly why Face ID is shunned by the voters in favor of the removed Touch ID.”

Touch ID works with masks, Face ID doesn’t (yet). It’s a significant issue, and it doesn’t look like it will be disappearing in the immediate future. Not significant enough that I would consider switching to Android for it—if anything, I’d just get an SE, which is a great phone and an incredible bargain—but if you don’t understand why anyone would want Touch ID these days, there is at least one very good reason. 

Strange that... my Face ID works fine with a mask, just had to add an alternative face and hey presto it's working fine! Touch ID is so last decade...