Amy Howe (via Jason Snell):
The Supreme Court heard oral argument this morning in a dispute between technology giant Apple and a group of iPhone users over the sale of apps from Apple’s App Store. The iPhone users are seeking massive damages from Apple, complaining that the company is violating federal antitrust laws by requiring the users to buy apps exclusively from the App Store. But as it comes to the justices, the case is about whether the iPhone users can bring their lawsuit at all: Apple contends that they cannot, because it is only selling the apps at the prices set by app developers.
[…]
Frederick insisted that the iPhone users and the app developers would have different claims against Apple: The iPhone users would be suing to recover the difference between the price that they paid and the price that they would have paid in a competitive market for apps, while the developers would be seeking lost profits.
Ben Thompson (Hacker News):
Along those lines, Apple argues that developers set the price of their apps, which determines Apple’s 30% cut, and to the extent developers set prices higher to compensate for that cut they are passing on alleged harm to consumers — which means consumers don’t have standing to sue.
[…]
I believe that Apple has power over developers (supply) precisely because it has all of the consumers (demand); it follows, then, that it is far more likely that developers are pricing according to what the consumer market will bear and internalizing the App Store fee, as opposed to pricing their products artificially high in order to pass the cost of that fee on to customers.
[…]
The plaintiff’s case only makes sense in a world where there are a scarcity of apps with pricing power such that consumers are forced to bear 100% of Apple’s add-on; the reality is that apps are already as cheap as can be and it is developers that are being directly harmed by Apple’s policies.
[…]
To that end, one of the more humorous aspect of yesterday’s oral arguments was the way discussion presumed that Apple was an abusive monopoly; this was a matter of convenience, as the question at hand was if Apple were an abusive monopoly, then who was harmed directly — which means it was easier to discuss the the latter question while assuming the former was true. To be frank, though, the language felt appropriate: Apple is an abusive monopoly in terms of iOS apps.
Daniel Pasco:
First: drive prices into the ground by encouraging devs to go as low as possible, universal apps, and giving away your own apps.
Then: claim prices are set by the devs
Matt Drance:
I am really conflicted on this case as it is being argued. It seems to fundamentally misunderstand everything you’ve laid out.
The plaintiffs are asserting that app prices could and should be lower if not for the App Store’s walled garden.
And the dev-advocate passage about “lost profits” is regarding the compulsory 70/30 cut, not the race to the bottom.
Steve Troughton-Smith:
I very much hope that Apple loses its App Store antitrust cases. It is unacceptable that Apple can be allowed to unilaterally block completely legit, valid, desired apps from respected devs, like Valve’s Steam Link, from their platforms. They should not get to make those calls
App Review’s ruleset needs 3rd-party oversight. Most of its restrictions are totally OK. Many points would absolutely not hold up to outside audits. None of this “you can make coding apps but they have to be education-focused and not take more than 80% of the screen” bullshit
Previously: That 30% App Store Tax.
Antitrust App Review App Store Apple Business iOS iOS 12 Lawsuit Legal Top Posts
cocobandicoot (via Meek Geek):
I took a screen recording of how long it takes to open Safari on a brand new 5400 RPM iMac. Apple, this is ridiculous.
My workplace purchased a fleet of 5400 RPM computers for some basic typing and Web browsing needs. Every single one of them is this way. Opening Microsoft Word literally took over a minute before the icon stopped bouncing in the Dock.
Listen: I get it — I understand that some people don’t need top of the line computers. But regardless of who uses this computer, this is a poor user experience.
I used to be able to tell friends that even a low-end Mac would be a good experience. That they could get a base model and it would still be decent. That Apple doesn’t sell a “bad” computer; rather, they have “good, better, best” tiers. That is not the case anymore.
And this iMac isn’t even the base model! Insane.
I spent many years using Macs booted from hard drives, including a 4,200 RPM one in a MacBook Pro. You would think a modern iMac would be faster than that, both because of the CPU and because the larger capacity drives have a higher data density. But it sure seems like macOS performs worse than it used to if you don’t have an SSD.
Is this because there are more background processes that are accessing the disk? If so, is there anything that can be done about that? Within my apps, I try to limit concurrent operations on the same physical disk. You might think GCD would do something like this system-wide, but it doesn’t.
iMacs now use 2.5-inch notebook hard drives, presumably to make them thinner, but that doesn’t explain why Apple has chosen to use 5,400 RPM models rather than 7,200.
There are also software bottlenecks even on an SSD. Some customers have reported Mail on Mojave taking over a minute to launch, seemingly related to FSEvents monitoring a DataVault.
Update (2018-11-27): Colin Cornaby:
It’s really frustrating when you boot Windows from the same Mac and it’s running pretty well with a slow disk
Update (2018-11-28): Jonathan Fischer:
I bought a 2017 4K iMac a month or so after they launched, and I opted for the Fusion drive. It was miserable. My family complained, constantly. Finally swapped in an SSD last week and suddenly I’ve never used a faster computer.
nut_bunnies:
Guarantee the reason they don’t use 7200 rpm drives in the iMac is because it would be too loud for their standards. The terrible thermals in many of their computers are due to this, for example
Tijmen:
Sadly this has been the case since Mavericks I think. At that time we just had to upgrade our iMacs with SSDs as they became borderline unusable.
Update (2018-11-29): Steve Troughton-Smith:
It’s ridiculous just how badly macOS performs on a spinning disk. It was unconscionable to ship a product that performs this badly five years ago, never mind in 2018, yet the iMac line still comes with spinning disks by default
Update (2018-12-03): Eric Schwarz:
A family member’s 2012 Mac mini (8GB RAM and an i7) was painfully slow and replacing the hard drive with an SSD restored its performance to like-new (or better). The fleet of 2015-era iMacs at work have also gotten really awful, mirroring what others have said in the linked stories, so they’re getting SSD upgrades, as well.
Apple moving to an all-SSD future is completely reasonable, but making machines that are new or still under their factory warranty run worse than they should seems like a bad look, even if MacBooks are way more popular. It’s especially concerning when other operating systems appear to be fine.
Apple Mail FSEvents Grand Central Dispatch (GCD) iMac Mac macOS 10.14 Mojave Safari Solid-State Drive (SSD) Storage Thermal Top Posts
Yan Zhu:
wow, apparently the popular “event-stream” npm module has been backdoored for months because the maintainer transferred the ownership rights to some unknown person
dominictarr (Hacker News):
he emailed me and said he wanted to maintain the module, so I gave it to him. I don’t get any thing from maintaining this module, and I don’t even use it anymore, and havn’t for years.
Kenn White:
Holy hell, Node. A package with 2 million downloads a week and the maintainer hands over control to a rando stranger? And now it’s mining cryptocurrency. Wow.
Felix Krause:
Step 1️⃣ Go through the most popular inactive open source libraries
Step 2️⃣ Reach out to author and ask to help out
Step 3️⃣ Get push access and release a compromised version
Step 4️⃣ Reach 2 million applications within a week
It shows again how much work open source maintenance can be, if your library is successful you have a ton of responsibilities and can cause severe damage
Matt Drance:
I hope the folks at @github are looking into some procedural ways of mitigating this sort of thing, because it is way too easy to accomplish given the breadth of interconnected libraries out there.
This is not GitHub’s responsiblity, or their fault, but GitHub knows how forked something is, including, I’d imagine, degrees of dependency separation. It could coordinate with npm, brew, et al to classify “community critical” repos. A sort of verified status.
From there you could, among other things, make it harder for an exhausted maintainer to toss the keys to a bad actor. Some sort of two-factor method for ownership transfer. Like a nuclear launch failsafe. Maybe some of this exists, but clearly we need better.
[…]
FWIW, there are some scary details in the comments of that link above that imply the original maintainer still “owned” the repo but lost commit access. This is a terrible scenario akin to identity theft. I don’t know how that’s possible, but it needs to be looked into.
Chris Adamson:
I think blame also goes to an entire culture of developers who blindly import OSS libraries without vetting whether the code is any good or is being actively maintained. I saw this a lot at my last job.
Gary Bernhardt:
There are basically two camps in that thread.
1) This is the original maintainer’s fault for transferring ownership to someone they didn’t know and trust.
2) Ownership transfer was fine; it’s your job to vet all of the code you run.
Option 2 (vet all dependencies) is obviously impossible. Last I looked, a new create-react-app had around a thousand dependencies, all moving fast and breaking things.
Option 1 (a chain of trust between package authors) seems culturally untenable given the reactions in that thread, including from well-known package authors.
There was an option 3: don’t decompose your application’s dependency graph into thousands of packages. People who argued that position were dismissed as (to paraphrase heavily) old and slow. That ship has sailed, and now we’re here.
Update (2018-11-28): dominictarr:
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn’t create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I’ve since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I’ve written way better modules than this, the internet just hasn’t fully caught up.
[…]
One time, I was working as a dishwasher in a resturant, and I made the mistake of being too competent, and I got promoted to cook. This was only a 50 cents an hour pay rise, but massively more responsibility. It didn’t really feel worth it. Writing a popular module like this is like that times a million, and the pay rise is zero.
Update (2018-12-03): Carlos Davide (via Hacker News):
Not so much for Tarr, though, who got the crap end of the Internet for handing over the package without properly vetting the stranger. How Tarr would have been able to do so in a way that is 100% safe is not clear to me at this stage, but lets roll for a bit with the assumption that a small amount of extra care on Tarr’s part could have avoided this mess.
This would mean that the original author of any FOSS package or application, by publishing it, would have to accept as fact that any misuse of said software would forever be their responsibility, or at least until that responsibility is, diligently and ceremoniously, transferred to someone else, hot potato style.
You know, like we do in the corporate world.
[…]
Code is the only thing you can trust, and by not reading it, you’ve forfeited the most important benefit provided by this ecosystem: the choice of not having to trust the authors regarding behavior or continuity.
[…]
We may have reached a stage where FOSS doesn’t represent everything it used to anymore, simply because there is too much of it. Too many lines of code, too many competing solutions, too fast a rate of change. We want to keep those security updates coming in straight from upstream, but how are we going to do audits every week on our current constraints?
Update (2018-12-12): The Changelog:
Adam and Jerod talk with Dominic Tarr, creator of event-stream, the IO library that made recent news as the latest malicious package in the npm registry. event-stream was turned malware, designed to target a very specific development environment and harvest account details and private keys from Bitcoin accounts.
They talk through Dominic’s backstory as a prolific contributor to open source, his stance on this package, his work in open source, the sequence of events around the hack, how we can and should handle maintainer-ship of open source infrastructure over the full life-cycle of the code’s usefulness, and what some best practices are for moving forward from this kind of attack.
GitHub Node.js Open-source Software Programming Security
Jason Snell:
Apple started in leaning into extensions last year, but with its official announcement that it’s getting out of this category, a few other companies have finally jumped in. The result is that there are two apps—available for free from the Mac App Store—that are worth checking out if you’re interested in printing photo books or calendars from within Photos for Mac. They are Mimeo Photos and Motif. (Unsurprisingly, the companies behind both apps seem to have been past suppliers for Apple’s book-printing services… so this is their way of staying in the game.)
[…]
If I had to sum up the differences between the apps, I’d say that Motif feels more modern and is easier to use, since it puts project photos (rather than page thumbnails) on the main interface and isn’t reliant on a bunch of slide-out drawers to access photos and layout controls. While Motif offers more layout flexibility than Apple’s old tools did, if you want to have ultimate control, Mimeo will give it to you.
[…]
Mimeo Photos has the edge over Motif on the calendar front. It’s got more available template themes and offers the capability to customize individual dates portion on the calendar, with text or photos, which is fun. (Unfortunately, it won’t let you drop photos on the overflow dates from the previous or following months, which was always something I did with Apple’s old calendar.)
Previously: Apple Discontinues Its Own Photo Printing Service.
Update (2018-11-29): Jason Snell:
A couple people have asked about this. If you want to reprint books you designed in Photos in the past, you can - Mimeo will let you upload your Production PDF (exported from Photos) and will reprint your book.
Update (2018-12-07): I found that when creating a photo calendar with Motif, most operations do not support undo. Scrolling through the thumbnail picker works in a non-standard way; you can only two-finger trackpad scroll when the cursor is over the scroll elevator (rather than anywhere over a thumbnail). There is no easy way to swap two photos placed on a page.
Update (2018-12-10): I’m not having a good experience with Motif. I finally finished creating my photo calendar, laying out all the photos and fine-tuning the zooms and crops. I clicked the Done button. This brought me back into the regular Photos view. I had planned to save a PDF of the project, as I always do before printing, although it turns out that Motif doesn’t support that. When I opened the calendar again to order it, everything I had worked on for over an hour was gone. All it showed was a single photo for January (I’d made a layout with six or so), and the photo displayed was not even one of the ones from this calendar project; it was one I’d ordered an 8×10 print of a few years ago.
I briefly when to Shutterfly, as it’s worked OK for me in the past, but aborted because I didn’t like its calendar layouts. It ended up being easier to redo everything in Motif because then I could use the same layouts as before, and it was still pretty fresh in my mind how I’d done them. After finishing each month I clicked Done and verified that it had, in fact, saved. This time, everything worked as expected, and I was able to place the order. The in-app order form is actually more cumbersome to use than a Web form, as type-selecting doesn’t work in the address combo boxes.
Update (2018-12-19): I received my first calendar from Motif. The printing is sharp and detailed, but the photos look very dark compared with how they looked on screen, and also compared with prints of those same photos from other services.
Update (2018-12-21): The new Motif 1.8 update says that it can convert Apple book projects to Motif book projects.
Update (2018-12-27): Motif sent a replacement calendar. Some of the photos in it are still way too dark, but most of them look better.
Mac macOS 10.14 Mojave Mimeo Photos Motif Photos.app Undo
Supertop (via Ryan Christoffel):
Castro has reached a size where the demands of running the business have been pulling us in too many different directions. We haven’t been able to focus as much on the core work of designing and building a product. Selling to Tiny gets Castro access to more resources, contacts and expertise. By growing the team we can specialize our roles to be more focused individually and get more done collectively. We can get back to what we’re good at and what we love doing.
Previously: Castro 3’s Business Model, Pocket Casts Acquired.
Supertop:
Castro 3 has been downloaded more times in 3 days than Castro 2 was in 2 years. 😘
See also: Castro 3 Review.
Marco Arment:
Don’t worry, Overcast is not currently in any discussions for acquisition or investments, and I don’t foresee either happening anytime soon.
I don’t need anyone’s money, I don’t want any bosses, and a full-purchase price would be so large that few acquirers can and would pay it.
No more crazy business-model changes are on the horizon for Overcast — the podcast ads sell well, have no significant downsides, and actually benefit all three parties (users, advertisers, and Overcast).
Acquisition Business Castro iOS iOS 12 iOS App Overcast Podcasts
