Forumwarz (via John Gruber):
We were informed, strangely enough, that the nature of our application violated their “policies.”
We pointed out that we never saw anything in their policies that prohibited our content. Where we were supposed to obtain these policies? The response: “We are informing you of them on the phone right now.” In other words, after nine long weeks, Apple invented a policy to reject our game.
It’s actually a rather creative idea. Much more efficient that you don’t have to figure out which virtual loot to buy. Of course, Apple does allow fart apps with in-app purchased additional sounds.
The quality of the posts on the new cocoa-unbound list has been high. Recently there has been some discussion related to Brent Simmons’ On Switching Away From Core Data. Landon Fuller writes:
CoreData attempts to tightly weld these two different abstract representations together, attempting to allow developers to leverage their single application model as both an on-disk serialization as well as an in-memory representation. Unfortunately this abstraction is extremely leaky, and Core Data’s requirements spread pervasively through the application’s in-memory model…
I think this is a real issue. His solution is to avoid Core Data. My approach has been to sometimes use an additional layer of application objects atop the Core Data ones, along with my own notifications and change tracking. That is, leverage as many Core Data services as possible, but recognize that sometimes it’s more efficient or makes the code simpler to use it more like a “dumb” storage layer than a manager of your entire object graph.
Ben Trumbull on the common problem of objects that have unique IDs from outside of Core Data:
Import the new objects in batches instead of 1 at a time. Instead of looking up existing
with O(N) fetches, use an IN clause on a respectable batch size, like
500 or 1000. This is the database equivalent of the 1000 x read(1
byte) v.s. 1 x read(1000 bytes). “insert or replace” style uniquing
has substantial issues when it comes to object identity and
relationship maintenance. It’s pretty easy to bork your foreign keys
this way. People sometimes try to cheat out on that by then using
their unique criteria as the primary key itself. So they fix the FK
maintenance by some indirection. And pay for it by having slower
everything else all the time.
Chris Adamson on the news that news that “if an app offers customers the ability to purchase books outside of the app, that the same option is also available to customers from within the app with in-app purchase”:
What Apple seeks to collect is rent, specifically monopoly rent, the ability to extract excess payments not as a consequence of a mutually-beneficial trade, but because it owns the damn store and it sets the damn rules.
Jason Snell has a good article exploring the possible consequences of this “announcement.”
Mirco Wilhelm:
Since Flickr had deleted the account an[d] all the related object[s], they cannot reactivate anything more that the account itself, leaving me with an empty shell of what I did during the last 5 years.
He reported that another account had stolen images, and Flickr accidentally deleted his account, with no notice. Even though he had his own backup of the photos that could be re-uploaded, the metadata and links were all gone. Then the story got attention in some national newspapers, and Flickr found that it was, in fact, possible to restore the account. This episode does not inspire confidence in Yahoo.
