The Economist - Turning the page:
The tie-up with Barnes & Noble makes three of a kind for Microsoft: cheap deals with struggling but established partners in markets where it is weak and sees a chance to do much better. In 2009 it struck an agreement with Yahoo! in online search. Last year Nokia became the prime conduit for Windows in smartphones. With Barnes & Noble it is having another stab at e-reading. Unlike the books on the Nook, this tale is still being written.
Yahoo! and Nokia, eh? auspicious.
Ben Brooks - Apple's Cut:
This is the heart of the issue. Consumers don’t, can’t, and shouldn’t have to know the people and motives behind purchases in apps — all consumers should need to do is trust that Apple has done their job vetting all of this.
Apple failed to do that with Path and other apps that uploaded user contacts, but I have yet to see a scenario where in-app purchases turned out to be a scam. Apple vets the in-app purchases closely because they know that consumers trust them to do just that — and because Apple must spend the time and resources to vet these goods, Apple feels they are entitled to their cut.
I think Apple is entitled to their cut too — just so long as they continue to do an excellent job vetting the apps.
But they're not doing an excellent job. They're claiming to do a job that isn't possible, then sticking inappropriate band-aids over problems retroactively if there's enough press outrage.
There was no possible way for Apple to prevent "Pathgate" short of entirely preventing apps from getting at the phone's address book data. The consumer trust in Apple is.. not misplaced - the App Store is a safer and nicer place than the Android store / Google Play / whatever it's called - but it's not fully justified. There hasn't been a major in-app purchase scam yet.
So now Apple are rejecting iPhone apps that link to the Dropbox "create account" page:
Reason for rejection is the fact that if the user does not have Dropbox application installed then the linking authorization is done through Safari (as per latest SDK).
Once the user is in Safari it is possible for the user to click "Desktop version" and navigate to a place on Dropbox site where it is possible to purchase additional space.
Apple views this as "sending user to an additional purchase" which is against rules.
Devin Chalmers has a similar story:
Through five rounds of rejection and revision, over eight weeks, we and our appeals team kept bowdlerizing our signup links and verbiage to no avail: every week the big red dot would descend again on our iTunes Connect icon
Eventually it became clear that, from the reviewers' perspective, there was a problem with that, at all: it wasn't the (already redacted) signup links that we were being rejected for, but any GitHub link. At all.
In the specific case of Dropbox, they have an SDK that will let you sign into an existing account. According to MacStories:
[..] the Dropbox team has already released a “beta” version of the 1.2.2 SDK, which removes the option to create an account on Dropbox.com. The beta SDK was seeded a few hours ago, and there’s the possibility Apple will reverse its decision on those rejections once they see the removal of the incriminated links.
So, if I'm trying to write a client app against a third party API, I have exactly one option - put a username/password login form for that service directly into my app - not exactly good security practice - and offer the user no help at all in creating accounts on this service.
If I'm integrating against, say, the Flickr API, which doesn't offer this ability, I'm stuffed. No more third party Flickr clients on the App Store, I guess. Or I could write to Yahoo! and ask them to provide a login flow that doesn't provide any links that lets my users escape and get to a page that'll let Yahoo! ask for money. Good luck with that.
As someone who wants to write apps against third party APIs, I now limited to writing clients against:
- free services that have no intention of ever charging money (i.e., services that are going to go out of business)
- or paid services that are willing to not try to up-sell their customers during account creation and won't ever change this policy (i.e., services that are going to go out of business)
And if I have a web service with an API and would like people to write against it, my options are limited to one of
- Don't charge money, or provide the option to charge money, and never plan to charge money
- Don't provide any easy way for users who are new to the service and are coming from a third-party client to give me money
- Don't have an ecosystem
[Sam] Spade is a thoroughly modern man, fluent in all methods of modern communication, travel, and exchange. He moves around the city with ease using taxi cabs. He frequently communicates with his secretary and other characters via phone booths, organising his and their tasks and travel arrangements to maximise his chances of obtaining the falcon. When he finally gets his hands on it, he stashes it in a baggage claim terminal, and rather than keeping the ticket on his person he posts it to a remote mailbox that he has access to.
[Spade] successfully navigates the labyrinth of San Francisco – a complex, interconnected place – and is not only unfazed by the systems he is forced to interact with, but makes them an extension of his own abilities and exploits them to his advantage.
Found in the middle of "The City By The Bay" a piece otherwise about the use of stealth in computer games, and how it allows for a more complex type of world than the more normal "shoot people in the face" approach.
Anyway, it seems that Jason Bourne was not the first.
Firefox is now at version 12.0. Basic AppleScript support (such as getting the URL of the current window) hasn’t worked since version 3.5, and it was intermittently broken in some earlier versions.
-- Michael Tsai
Realistically, Shelf is going to stop being useful at some point in the next couple of years.
The Apple App Store doesn't permit the sort of AppleScript usage that it relies on, so it's never going to be an App Store app.
As a result (and also as part of a longer-term trend, really), no-one really cares about AppleScript any more. Not that Firefox was ever an exemplary citizen in this respect.
Google are killing the social graph API that provided most of the discovery for it.
Increasingly few of the services that I'm interested in provide RSS feeds to their data, preferring to be iPhone apps or walled gardens.
[Decal] is short for decalcomania. The word decalcomania is derived from the French word decalquer, and was coined by Simon François Ravenet about 1750; it became widespread during the decal craze of the late 19th century.
At SXSW there was a lot of Instagramming going on. I wanted to see what sort of pictures people were taking, but there didn't seem to be an easy way of doing it and I was too busy eating to fix it myself at the time. But now,
Behold: LOCALGRAM .
Localgram asks your browser where you are, then shows you recent nearby uploads. That's it. It'll look decent on the desktop, and decent on an iPhone. It might work on other things. Internally, this is a single Instagram API call, with maps and pictures on it. It's so ridiculously simple that it barely seemed worth building, which is why I built it.
Playing with this around London, I've come to two conclusions.
Other people's Instagram photos are really boring. Good grief. Without the filters of the phone app, it's just an undifferentiated stream of graffiti, food, and duck face.
It's surprising to me that so many photos are geotagged. Photos at a foursquare venue have maps on the photo page, but it seems that even photos without a first-class venue can have a location associated with them and visible through the API. The default web photo page doesn't display the location at all. I hadn't realised that photos retained their location. I wonder how many other people don't know this.. Of course, this might be because some of the locations on these photos are clearly complete rubbish..
I'm playing with Instagram a lot recently. I like the live nature of the photo stream. I like their API (I like OAuth2). I don't like their lack of feeds and app-only approach, but I can fix the first one of those myself.
I'm also playing with the lovely Toner maps tiles from Stamen, because I was looking for a gratuitous excuse to do something with them. I'm using modestmaps.py (thanks to some prodding from Aaron) to render out the static maps - hopefully this won't kill anything - I'm not really set up to be a maptile server here. We'll see.