Sarah Perez (MacRumors):
An app developer’s lawsuit over App Store rejections, scams and fraud has ended in a settlement agreement after court filings show a request to dismiss the suit earlier this summer. The plaintiff, app developer and former Pinterest engineer Kosta Eleftheriou, made a name for himself in recent months calling out some of the most egregious App Store scams. This later culminated in a lawsuit of his own against Apple, filed in California’s Superior Court in Santa Clara County in March 2021, where he alleged his own app had been unfairly rejected from the App Store and then later targeted by scammers, leading to lost revenues.
[…]
His complaint alleged that not only had Apple rejected his FlickType Apple Watch keyboard app from the App Store, it then approved competitor keyboard apps and others that used an integrated version of FlickType keyboard to publish to the App Store. This seemingly contradicted Apple’s claim that the FlickType keyboard offered a “poor user experience,” given that Apple’s own app review team was greenlighting the same technology, when integrated into other apps like Nano for Reddit, Chirp for Twitter, WatchChat for WhatsApp, and Lens for Instagram.
Neither side is saying what they agreed to.
Previously:
Antitrust App Store Apple FlickType iOS iOS 14 iOS App Lawsuit Legal
Simon Willison (Hacker News):
SQLite: Past, Present, and Future is a newly published paper authored by Kevin P. Gaffney, Martin Prammer and Jignesh M. Patel from the University of Wisconsin-Madison and D. Richard Hipp, Larry Brasfield and Dan Kennedy from the core SQLite engineering team.
The paper compares SQLite and DuckDB, and describes some optimization work to make SQLite perform better for analytical queries.
[…]
The primary difference is that DuckDB is optimized for analytical queries: queries that apply aggregate calculations across large numbers of rows, rather than being optimized for fast scanning and lookup of individual rows of data.
Database Optimization Programming SQLite
Apple (Hacker News, MacRumors):
Xcode Cloud, the continuous integration and delivery service built into Xcode, accelerates the development and delivery of high-quality apps. Get started by configuring a workflow in Xcode and receive 25 compute hours per month at no cost until the end of 2023. And now, Account Holders can subscribe for more compute hours in the Apple Developer app.
Apple:
A compute hour is an hour of time used to execute a specific task in the cloud, such as building an app or running automated tests. For example, running 5 tests of 12 minutes each equals one compute hour. Xcode Cloud runs tests in parallel with other actions, such as analyzing, archiving, and building, so you’ll get results quickly.
After next year, the 25 hours/month plan will cost $14.99. I don’t have much sense for how much one compute hour gets you in practical terms. Hopefully it’s by CPU rather than by core, but I don’t know what CPU it uses. Right now, the full build/analyze/test suite for all my apps, takes about 40 minutes on an i9 MacBook Pro. The most attractive part of Xcode Cloud is the ability to test on different configurations without having to manage them yourself, but of course then you multiply the compute hours by the number of configurations.
I’ll probably sit this one out, not because of the price but because I’m not sure the benefits are worth the hassle. Xcode Bots looked great but was so frustrating and buggy that I wish I’d never touched it. It was just an incredible waste of time to have it keep breaking and require restarting the server Mac or deleting and reconfiguring the bots.
Jenkins has a rougher interface and is a pain to set up, but once it’s working it stays working. You have to manage the Mac and Xcode versions, though—in addition to Java and Jenkins—and make sure it doesn’t fill up your whole SSD with workfiles.
I decommissioned the Mac that I had been running Jenkins on because of a swollen battery and never got around to setting it up on the replacement server Mac. So far I haven’t really missed it. What were all the stats and graphs and status e-mails really doing for me? Right now, I just have a secondary Mac within arm’s reach and a script that does a git pull and analyzes/tests everything. Since this is the backup Mac that I need to maintain anyway, there’s no extra admin burden for the Mac or privacy concerns with putting my repo in the cloud. The difference is that I invoke the script manually a few times per day rather than having Xcode/Jenkins run automatically after every commit. If something breaks, I can look at it directly on that Mac.
Previously:
Update (2022-09-14): Marcin Krzyzanowski:
Xcode Cloud is so annoying. None of these errors is an actual error. 🤷♀️
First is the SwiftPM package bug.
The second is just bananas.
imagine a world where Xcode Cloud uses the same Xcode we do. because this is only Xcode Cloud error, not local Xcode builds.
Apple Services Mac macOS 12 Monterey Programming Testing Xcode Xcode Cloud
Alyssa Rosenzweig:
Here’s a little secret: there are two graphics APIs called “Metal”. There’s the Metal you know, a limited API that Apple documents for App Store developers, an API that lacks useful features supported by OpenGL and Vulkan.
And there’s the Metal that Apple uses themselves, an internal API adding back features that Apple doesn’t want you using. While ANGLE implements OpenGL ES on the documented Metal, Apple can implement OpenGL on the secret Metal.
[…]
Compared to the desktop GPUs found in Intel Macs, Apple’s own GPU implements a slim, modern feature set mapping well to Metal. Most of the “extra” functionality is emulated.
Previously:
Apple M1 Linux Mac macOS 12 Monterey Metal OpenGL Private API Programming
