By John Gruber
OpenAI, Anthropic, Cursor, and Perplexity chose WorkOS over building it themselves.
My thanks to Sillysoft for sponsoring this week’s DF RSS feed to promote Lux Delux, a Risk-like world domination strategy game for Mac OS X, Windows, and Linux. Lux offers over 700 maps, including fantasy realms and historical scenarios, and has a map editor for building boards of your own. Lux also offers cross-platform network play. There’s even an SDK for programming AI opponents.
And there’s a version for the iPhone and iPod Touch. I’m a sucker for this type of game — I’ve lost a lot of time to both the Mac and iPhone versions of Lux.
Alexandre de Rochefort, finance director of French game developer Gameloft:
“We are selling 400 times more games on iPhone than on Android.”
Apologies for the self-link, but I’ve gotten a few questions today from readers asking, honestly, just what the problem is with private APIs. This piece I wrote last year addresses it.
As an addendum, I think there are many developers, especially those who aren’t coming to the iPhone from the Mac, who don’t understand how seriously Apple takes its public APIs. When Apple publishes an official API, it’s a serious commitment that says how something works and will continue to work in the future. Private APIs are subject to change or go away. The idea that something marked private works now so why not use it? is short-sighted. The iPhone OS isn’t just something that Apple has built to last for a couple of years. It’s a platform they’re building to last for the foreseeable future. They don’t want apps in the Store that aren’t future-proof.
Requires a two-year service contract with Verizon, of course, but that’s $50 lower than Verizon’s price. Even cheaper: Dell is selling it for just $120 (again, with a contract), at least in certain areas.
Animated time-lapse map of county-by-county unemployment rates in the U.S. since January 2007. Jarring.
This one seems to be a genuine incorrect rejection for private API use: Juicy Bits has a camera-based app that uses OS 3.1-only camera features, but still runs on OS 3.0 by disabling those features when the app runs on OS 3.0. This particular feature — customizing UIImagePickerController — was frequently abused by private API users in the past, prior to Apple’s introduction of official support for this stuff in OS 3.1.
According to Juicy Bits, they’re not doing that, but their app was rejected anyway:
We’re now wondering if the static analysis tool sees the 3.1.x API call in our app, notices that it runs on 3.0.x devices (that don’t support the new APIs), and flags or rejects it as a result. This would actually make sense! The only problem is that the tool appears to be ignoring the code where we check the device version before making that call, and that may be the nuance that’s causing all of our delays.
Gdgt has a VMware image of the open source Chrome OS version that Google released yesterday. Engadget put together a video showing how to install and use it. If you’re curious to see it in action (as I was), this is far easier than compiling it from source. Hooray for VMware.
But be warned — this release is far behind the version of Chrome that Google actually demoed during their event yesterday. This open source release is missing much of the cool stuff shown yesterday, and only fully works if you have a special google.com account — presumably only available right now to Google employees. You can get more from watching this aforelinked video than by running this image in VMware.
This YouTube video has the demo portion of yesterday’s Chrome OS announcement event. Best tour of the UI I’ve seen.
By the way, if you haven’t seen it before, RogueSheep’s Postage is a very slick iPhone app: it’s a simple little “virtual postcard” app with tons of polish and style.
This is admittedly a little technical. But the gist of it is that RogueSheep sort of got screwed by having their app rejected for this. Their app linked to a version of the Three20 framework that overrode, not called, a private API — i.e. it replaced a private method with its own method of the same name. And Postage, the app, wasn’t even actually calling it. Apple’s tool apparently can’t discern the difference, so developers need to be aware of this or risk automatic rejection.
RogueSheep’s Chris Parrish concludes:
Personally, I’d love to see Apple give us access to the analysis tool to run against our own builds before submission. Or if that’s not possible, perhaps a modification to the review process so this automated analysis happens sooner in the process so we don’t lose so much ground in the now 14-day wait for the review process to complete.
Making the static analysis tool available to developers would indeed be helpful. But I suspect it wouldn’t work in terms of game theory. Honest developers could make good use of having access to the tool, to help ensure their projects are free of private API violations. But dishonest developers would use the tool to figure out ways to slip private API calls past the checker. Parrish’s second request, for Apple to run the tool against submissions far sooner in the review process, strikes me as a good and reasonable one.
Update: Here’s a note from an informed DF reader:
Overriding private methods in a category is far worse than calling them directly.
Everything in your process will get the overridden behavior of the private method and assumptions about side effects go out the window.
One consequence of Apple’s crackdown on the use of private API calls is that some apps are using them, or at least including them in their binaries, without knowing it. One popular open source framework, Joe Hewitt’s Three20 (linked here on DF back in March), played a bit fast and loose with private APIs, and so now there are numerous developers with apps getting flagged for private API calls made from the Three20 framework. This Google Groups thread covers the problem and the work that’s being done to create a branch of Three20 that’s free of private API calls.
(Hewitt, of course, was in the news last week after he quit as lead developer of the Facebook iPhone app citing frustrations with the App Store process. It’s reasonable to wonder whether this had anything to do with Apple’s crackdown on private APIs, because the Three20 framework was originally extracted from the Facebook app. I exchanged a few emails with Hewitt on the matter, and that’s not the case — his frustrations with the App Store process lie elsewhere.)
John Herrman at Gizmodo explains the basic gist of the static analysis tool Apple is now running against App Store submissions, to identify (and reject) apps that use private API calls. Apple has been explicit from the get-go that doing so was a bad idea and reason for rejection, so I think this tool is a good idea, in general. The trick will be making sure it doesn’t generate false positives.