I'm surprised the local caching hasn't gotten the media spotlight as that's been broken since 4.2.1. and is more important for web apps aiming to replace native apps.
I didn't realize Apple kept that from you, but OK. Alternative. Twitter clients normally send their user-agent as part of an API request. Twitter probably still has that data, and could check to see who sent a Tweet from Tweetie between a given period of time. Is there the possibility of false positives? Certainly, but it's better than nothing.
Is it? I'd be afraid of a backlash caused by some minority of users who had e.g. bought tweetie but never actually tweeted using it (just for reading tweets or whatever), had changed twitter accounts since, etc., plus the people claiming to be part of this group in an attempt to get something for free or whatever.
Realistically, they're probably going to have to do something about this much-hated "feature" for everyone anyway.
> Realistically, they're probably going to have to do something about this much-hated "feature" for everyone anyway.
The question is though, is it a feature for some? If so, how many? Twitter's audience is huge. A couple thousand vocal users might be on the minority side.
Twitter is big enough now that it's not going to be able to do anything right in the eyes of everyone. But, they have a ton of data about usage patterns, and other data we don't. I'm willing to bet that the decision to include such a "feature" was backed up by real data.
I'm sure they'll release an update to give you the ability to turn off the "feature" of course, and this whole discussion will be pointless.
The Shazam developer collected device IDs, so that beta testers can now install the free version and still get to the things you could do in the beta (unlimited tagging).
So, with a bit of preparation they could have handled Tweetie customers differently in the Twitter app.
There is a difference between criticizing the implementation of a policy (e.g. the AppStore review process is too slow, the AppStore review process sometimes makes embarrassing mistakes) and criticizing the policy itself (e.g. Apple's control over the AppStore is a bad thing). Gruber (and Marco et al) might criticize specific tactics by Apple but the Mac pundits largely agree with the strategy and the goals—whatever the strategy or goals may be.
You're confusing a strategy (i.e. provide a way for developers to make apps within Apple's rules) to a tactic (i.e. only make web apps, not native apps). It's worth noting that Gruber would later defend Apple's decision to initially offer only web app development because, according to Gruber, obviously the tools for native apps were just not ready and the AppStore was still in development.
By Gruber's own admission, he wants Apple to succeed. Everything else is secondary.
You're splitting hairs. Or rather, drawing arbitrary lines in the sand. And how could anyone in their right mind not defend Apple's choice to at the time not offer tools that didn't exist then? That doesn't make you biased, it makes you reasonable.
He has also admitted that he wants Google and Android to succeed. That doesn't mean he agrees with all their strategies, no matter how selectively you want to define "strategy".
If you agree with Apple's strategy (i.e. create apps only within Apple's rules) then it of course makes sense to later defend Apple for only allowing web apps while the AppStore and Apple's development tools were not ready. But if one doesn't stick only to Apple's strategy, then other options present themselves like allowing developers to release their own native apps until Apple got its act together. Developers were ingenious enough to develop, and even sell, native iPhone apps before the AppStore came along.
Gruber wants Google and Android (and Palm and webOS) to succeed so they can keep Apple sharp and on top of the game; Gruber doesn't want Apple's competitors to succeed in and of themselves, his desire is predicated on more success for Apple.
Gruber's views are sufficiently nuanced to allow some disagreements with Apple on minor issues while still remaining in agreement of their overall goals. I'm not the one 'splitting hairs' by pointing that out, indeed it's actually Gruber's arguments that appear so (his dismissal of the Readability blog post because they seem like a content publisher—even though Readability isn't—is an example of him drawing arbitrary lines in the sand)
Apple already had measures in place to block that 'loophole' without these new rules—or new interpretations of the rules, if you will. Apple banned an update to ReadItLater, last year, because the reviewer believed the developer was attempting to circumvent the in-app purchase: http://readitlaterlist.com/blog/2010/08/version-2-2-rejected...
I got an iPad in April, at launch, and gave it away at Christmas. I wanted a tablet to replace two distinct sets of physical objects that haven't yet gone digital: my moleskine/writing pads and my library of magazines and reference books. The iPad is useless for scribbling and the reading experience (the screen, the weight, the UI) is poor. The iPad doesn't autodeliver new content and I fear Apple has killed the inchoate market for digital newspapers, magazines and the like with the new heavyhanded rules for digital subscriptions. The iPad had great promise but it is unfulfilled.