Naiyas

AppleInsider said:

The proposed class is vast and includes anyone who purchased an iOS app or app license from Apple, or who made an in-app purchase, from Dec. 29, 2007, through the present.

One pretty fundamental flaw in their argument is they don’t even know when the iOS App Store started. If they can’t get that date right then how many other holes are there in their arguments.

beowulfschmidt said:

AppleInsider said:

Lacking a replaceable battery is standard for smoke and carbon monoxide detectors.

Since when?  Both the upper and lower story smoke detectors in my house, and the CO detector upstairs have batteries that I replace about every six months.  Are new devices entirely disposable or something?

I believe the author of the article is writing from a UK/EU perspective. For many years now it has been a legal requirement that fire safety devices that contain a battery battery (smoke/CO alarms etc) are required to be sealed and have a warranted 10 year lifespan. This means that they cannot have replaceable batteries and therefore become disposable.

I don’t recall the exact details, but I believe it comes down to real world events that showed that such fire safety devices have been to blame for fire deaths as they have either not had their batteries replaced and/or their sensor become ineffective after 10 years. So to force fire safety improvements the batteries limit the life of the device naturally at the point it should be replaced anyway.

Not great for electrical waste (and kind of hypocritical of the EU that originally brought in the regulations) considering it’s views in other areas on the same subject.

The major downside (for me) is that it is almost impossible to find a smart smoke detector that is legally compliant for a 3-storey town house as the smoke detectors are legally required to be mains powered as the primary source with a battery backup and I’ve yet to find a single smart alarm that meets this requirement that is HomeKit compatible.

22july2013 said:

I didn't see mentioned in the AI articles whether Apple can now revoke Epic's developer license, as it did last year, but with Epic at that time winning an injunction against Apple for that action being overreach at the time. So now that the case is over can Apple go ahead and revoke Epic's developer license?

According to the judgement passed down Apple is cleared to revoke all developer licences for Epic including all of its subsidiaries and affiliates should it choose to do so as a consequence of one of Epic’s companies breaching the terms of its developer licence.

The existing injunction has now expired. Whether Apple decides to do so is another matter given the prevalence of the Unreal Engine in games/apps unrelated to Epic directly.

IMO, I don’t think Apple will retaliate in such a way as I suspect they are going to focus on meeting the conditions of the judgement. They have yet to say they will appeal and I doubt they will as they will need to counter Epics appeal and let’s face it, they effectively won all elements of the case except for the area we all knew they had shaky ground.

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.