Archive for February 2011
Monday, February 28, 2011
Philip Hodgetts:
As expected, AV Foundation from iOS 4 will be added to Lion. My take is that signals the end of QuickTime as we’ve known it. But it’s not only that there’s a new Framework for for working with time-based audiovisual media – there’s a lot more to QuickTime than that, and it’s all the interactive and additional technologies in QuickTime that don’t appear to have a future. Features that were important when QuickTime MOVs were the preferred (at Apple) distribution format.
One of these days I should learn how to use Quartz Composer.
AVFoundation iOS Mac QuickTime Video
Thursday, February 24, 2011
John Gruber:
The iTunes Store was and remains a business in its own right. Its mission isn’t selling music, or movies, or TV shows, or apps, but building an end-to-end system, a platform that allows people to easily buy anything digital. If you think the App Store shouldn’t be “a huge revenue stream” then you’re not seeing things the way Apple does.
And yet, CFO Peter Oppenheimer responded to criticism of the iOS subscription policy by saying that Apple runs the store “just a little over breakeven.”
Colin Wheeler (via Brent Simmons):
Out of all the API calls I saw in grand central dispatch the one that initially impressed me least was dispatch_once. However after reading its documentation and using it a bunch I realized how useful this one API call is. Not only it is a dead simple way to ensure that code only gets executed once, but it is also thread safe.
Design Patterns Grand Central Dispatch (GCD) Mac Programming
Tuesday, February 22, 2011
Matt Linderman:
Is this the future fate faced by most acquired tech companies? Is the cash worth it to founders who have to watch their creations slowly decline into obsolescence? Is freedom better than building and honing a big, popular product? When a company is bought, does it deserve acquisition congratulations or condolences?
Depressing, but it’s not clear to me that Yahoo is an outlier here.
Acquisition Yahoo
Matt Drance:
Whenever a policy change like this occurs, I ask, How does this strengthen the platform? How does this sell more iPhones? I can’t answer either of those questions, and that, to me, is the most interesting part of this whole debate.
Neven Mrgan:
I prefer the Apple that makes its money by creating great, high-end, high-margin products and selling them directly to consumers. I am less fond of an Apple that makes money by striking or demanding dubious business deals. Forget my personal biases - I’m just saying, the former Apple would be interested in delivering stuff I would buy with my money and put in my pocket or my living room. The latter Apple would have more to gain by fleecing the supply and shoveling whatevers at me.
Marco Arment on the Jobs SaaS e-mail:
And even if Jobs himself would take a few minutes (during his medical leave, no less) to answer these questions more verbosely for some guy in an email, it would raise a different question: Why don’t the published guidelines reflect this clarification, and what’s stopping whoever gets your submission on the App Review team from following the literal definition?
Manton Reece:
If the iPad grows like many of us expect it to, siphoning a third of the cash flow around everyday computers will create a completely different economic environment than exists today.
App Review App Store In-App Purchase iOS
Dr. Drang compares Simplenote, Elements, PlainText, and Nebulous Notes (via John Gruber). I’m currently using the built-in Notes app, which is fine on the iPhone but not great on the Mac (in Mail). I’d rather use EagleFiler and BBEdit, so I’m considering switching to a Dropbox-based solution.
Andrew McAfee (via Jeff Johnson):
I’ve been doing some poking around, and have found that it’s pretty straightforward for one person (let’s call him George Smiley, after John Le Carré’s master spy) to find out what music, video, and apps someone else (like me) has purchased or had gifted to them on iTunes.
Probably not a huge deal for most people, but it would be nice for Apple to respect the user’s privacy by default. We’ll see what happens when iBooks supports gifting. The Kindle solution seems reasonable.
Monday, February 21, 2011
Marco Arment:
This would be a great guideline — developers should offer IAP to buy content, since it’s so easy for users that they’re likely to make more money overall with it. But forcing all app publishers with purchase systems outside of IAP to suddenly and completely adopt it in parallel has no apparent practical or pragmatic justification. Instead, it just looks like greed.
If in-app purchase is so great, publishers would adopt it voluntarily, and the market would determine how much extra customers are willing to pay for the convenience. He also expands on the point I made earlier today:
One issue is that this policy assumes that all apps are made by someone with the ability and authority to collect IAP payments on the service’s behalf, which isn’t the case for third-party clients using a service’s API.
If Twitter charged a subscription fee, or even sold any content whatsoever, no third-party Twitter clients would be permitted on the App Store, effectively preventing that entire market.
Arment, correctly I think, says it’s a mistake to focus on whether the policy is legal or 30% is “fair.” The consequence might well be to prevent the creation (or continued existence) of many potentially great apps, and that’s bad for customers, developers, and Apple.
Chris Adamson:
The benign and simplest explanation for all of this is that Apple has painted itself into a corner, that it hasn’t really thought through all these issues. And if that’s the case, something will have to give: a bulk-submission tool, lax review of products, or (ideally) an abandonment of the new rent-seeking policy.
Right now, even if Amazon wanted to give Apple 30%, it would have to manually enter each Kindle book into the iTunes Connect Web site and submit a screenshot showing it loaded into the Kindle app. Then wait for Apple to approve it. And this assumes that Apple will raise the limit for the number of SKUs that they support; if they don’t, it would not even be possible to make the Kindle app comply with the new guidelines.
Amazon App Store In-App Purchase Kindle
Jim Dovey (via Manton Reece):
Having spoken with the developer, it transpires that there are no links and no exhortations to make purchases within the app. The cause of the rejection is a static-text label (in other words not a link) on the login screen…Just information. Nothing about payments, costs, or anything else. Just a small sentence so that people who download the app don’t immediately go “muh-huh?” After all, there’s not really any other indication in the app that it’s part of a web service, and we know that an awful lot of shoppers don’t read the app store blurb on the apps they download.
Readability’s response is to “go the other way…towards the web.” In this case, that’s their choice, but with a third-party client for another service (Dropbox, say) the app developer might not have the option of supporting in-app purchase. I don’t think people realize how many apps and services this could potentially affect. In theory, this means that even though Instapaper subscriptions don’t (yet) affect the app’s operation, the app will have to be re-engineered to support in-app purchase and give Apple a cut. Also consider that Readability provides some services for free, and yet because they also offer subscriptions, they will not be able to provide the free services in an app. This could apply to Dropbox, too. If storing and displaying your Web bookmarks is considered providing content, surely storing and displaying your files is, too.
I also liked this paragraph from a different post by Dovey:
When I purchase books from Apple’s iBookstore, they are providing a new service to me—the assembly and provision of an eBook. When I purchase one from Amazon or Kobo, Apple is providing no such service to me whatsoever. The argument that they have the right to claim some money because I’m using an Apple device is false, because I’ve already paid for that device—upwards of $700 in this case. I don’t get charged by Apple when I browse the internet or watch YouTube, so why does Apple need to take a cut when I download an eBook?
AnandTech:
So the long-awaited Verizon iPhone 4 is finally here. It’s functionally the same as the GSM/UMTS iPhone 4 on AT&T, except significantly less prone to unintended signal attenuation from being held thanks to receive diversity through two cellular antennas. Battery life is the same or better than the AT&T iPhone 4, GPS is slightly more precise, Verizon lets you turn your phone into a WiFi hotspot if you pay the fare, and SMS concatenation even works on Verizon’s network. There’s really nothing to complain about at all or point out as being inordinate about the CDMA iPhone—it’s simply an iPhone 4 on Verizon’s network.
They measured the antenna’s signal attenuation and found that it’s less susceptible to the death grip, as expected. However, when not in a case the Verizon iPhone 4 is worse than all the tested phones except the AT&T iPhone 4. I still think the problems with the antenna design go farther than what’s been acknowledged. My father returned his iPhone 4 because, even in a case, the signal strength was much worse than his original iPhone (which generally has worse signal than my 3GS), to the point where it was unusable. Fingers crossed that iPhone 5’s antenna is better, because I’m guessing that soon I won’t be able to run the latest version of iOS, and I really want a better camera.
Antenna iPhone iPhone 4
Friday, February 18, 2011
Popular Mechanics (via Jasper Hauser):
We aren’t paid on commission, but you fear for your job if you’re not selling enough. We’re supposed to sell AppleCare product support with just about everything, and honestly, those aren’t that hard to sell, since they aren’t a bad deal. But we’re also supposed to push MobileMe, and that’s really hard to sell. Nobody ever sells it.
Wednesday, February 16, 2011
The Tech Bastard:
Service providers have an option to fight back that hasn’t been discussed enough, though; with a simple change to pricing they could quickly force Apple’s hand and show consumers the costs that Apple is passing on to them. They could create a separate, higher priced offering for iOS users.
In other words, to access the content from iOS you would have to buy a premium subscription plan (or “iOS access” for a Kindle book), and the price for that is what’s the same between the in-app and Web stores. I think this satisfies the letter of the guidelines. This would make it clear where the increased costs were coming from, and it could prevent publishers from withdrawing, but customers would still be worse off compared to before Apple’s policy changes.
Charline Poirier (via Michael McCracken):
Over the 60 minutes of each session, I went through as many features of Thunderbird as possible with each participant. Participants were asked to:
- Install Thunderbird from the Software Centre
- Create an account
- Sign up
- Create filters
- Set up alerts
- Manage emails in folders
- Create a signature
- Change the colour of the font
- Create a contact list
- Search for a specific email discussing a form (which I had sent prior to the session)
- Respond to an email that contained an attachment: in particular, open the attachment, modify it and send it back to the original sender
Apple Mail handles some of these details better.
Tower, fournova’s $59 Git client, has shipped. It has many of the good points of GitX and can also send diffs and merges to BBEdit, TextMate, and other file comparison tools.
Eucalyptus developer James Montgomerie (via Jason Snell):
The intent behind Apple’s policies always seemed consistent to me in the past. The policies themselves may have been opaque and sometimes confusing, and were often inconsistently and capriciously applied, but the intent behind them didn’t seem to change. I certainly didn’t agree with all the policies, but they at least seemed reasonable. I could respect them. Apple seemed to have integrity. With this change though, that’s no longer true. Apple has simply changed the policy for what apps are allowed to do to one that’s not only different, it has a different intent behind it.
It is no longer possible to rationalize that the intent is to benefit the consumer, though I’m sure there are those in the mothership who sincerely believe that forcing people into the Apple monoculture is good for them. Montgomerie closes with some thoughts on 1984. Apple is forcing a choice between excellence and freedom. If only Nixon could go to China, only Apple can build the Orwellian world.
More food for thought:
- Having read and thought about the guidelines, it seems clear to me that the intent is to ban viewer apps.
- What does Apple define as “content” and thus subject to the compulsions of section 11? What will be considered content tomorrow? What use are the guidelines, if even their intent is subject to change?
- Since all content must be available for purchase through Apple, this means that all content must be approved by Apple. Apple already bans certain types of content. It claims not to curate the allowed types, but this policy could change, and Apple would be in a position where it could enforce a content ban.
- If content includes digital services, apps that provide native interfaces for services such as Flickr, FogBugz, Lighthouse, Basecamp, and others would be banned.
Update: Hank Williams explores point #4 and the effect on service businesses.
Tuesday, February 15, 2011
Apple is of course framing this as a new feature, but one can also look at it as removing features and destroying business models. Apple is changing the rules for existing apps and services. It’s a bait and switch. If you don’t comply and pay the Apple tax, you’re banned from writing a native app for the iPhone, iPad, and iPod. (Of course, you can still use the sweet SDK/shit sandwich and write a Web app that runs in Safari.)
Most of the press coverage I’ve seen is along the lines of the ArsTechnica headline, “Apple: if we get you subscribers, we deserve a cut,” which sounds reasonable. However, combining Apple’s various statements produces a very different picture:
- Apple is changing the rules for “content-based apps.” Today’s announcement was about subscriptions, but the changes also affect other digital content such as e-books. Who knows where the lines will be drawn or whether this will extend to all commerce conducted from iOS devices.
- Unless your content is free, you must re-engineer your app (and, probably, server back-end) to support Apple’s purchasing APIs.
- Apple takes 30% (in perpetuity for subscriptions that auto-renew) even though, unlike with the App Store, Apple is not providing a content store, hosting, or bandwidth.
- You may not link to your own Web store.
- You may not charge more to customers who buy through Apple. This makes it impossible to selectively raise your prices by ~43% so that you end up with the same margin after Apple’s 30% cut.
- If you have an existing app and don’t comply with the above, on June 30th you’re booted from the App Store.
Publishers that have a significant number of non-Apple customers probably don’t want to raise prices across-the-board. Yet with current margins they may well lose money if they have to give up 30%. In some cases it may be possible to remove features from the app. For example, have the app be just a viewer, and make the user type the URL in Safari (no linking, remember) to browse and purchase content. (It’s actually not clear whether even this will be allowed.) Other publishers may be forced to withdraw from the App Store. I don’t understand what Apple expects Amazon, Netflix, and others—and their customers—to do.
Apple is setting the rules so that if you want to compete with iBooks or iTunes (even if you were around first) either your app will not be as smooth as Apple’s or your prices will be higher.
The technology itself has the potential to be great for customers (and publishers) by making it super-easy to buy content. Apple’s policies, however, seem to ensure that customers will either see their app experiences degraded or their prices increased.
See also: Kyle Baxter, Ryan Carson, Macworld, and Hank Williams,
App Store App Subscriptions Apple Business In-App Purchase iOS
Sunday, February 13, 2011
Laurent Luce walks through the PyDict C code (via Keith Devens). CPython is a good codebase to study.
Optimization Programming Python
Saturday, February 12, 2011
Uli Kusterer:
When you look at today’s Macs, it appears this has already happened. Not only is there still no keyboard tutorial, the mouse tutorial is gone as well. Heck, you don’t even get a nice little character in an Apple sweater grabbing the menu bar with his hand and pulling out a menu, or zooming and closing a window. It is assumed that everyone today knows what a window and a menu are, and how to use them.
Thursday, February 10, 2011
Tim Bray:
Before events took this bad turn, the contract represented by a link was simple: “Here’s a string, send it off to a server and the server will figure out what it identifies and send you back a representation.” Now it’s along the lines of: “Here’s a string, save the hashbang, send the rest to the server, and rely on being able to run the code the server sends you to use the hashbang to generate the representation.”
Do I need to explain why this is less robust and flexible?
Mark Jaquith in the comments explains why Twitter is doing this and how hopefully it will stop being “necessary.”
Wednesday, February 9, 2011
Daniel Jalkut:
With these changes in place, I have the flexibility to offer direct-download versions of my software to any MAS customer who asks for it, or for customers who I request the assistance of in testing a pre-release bug fix. In most cases, I can just ask the customer to run the app. In the worst-case scenario, when a receipt has not yet been “stashed” yet, I have only to ask the customer to run the MAS edition once before trying the newer release.
Great idea.
Tuesday, February 8, 2011
Matt Henderson:
To simulate the squint test, I’ve blurred both home pages. Have a look, and see if you can quickly identify the login links at Lending Club and Bank of America.
Bank of America Design Web
Friday, February 4, 2011
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.
Wednesday, February 2, 2011
