All Articles Tagged daring fireball

Daring Fireball received a response from Apple Senior VP of Marketing, Phil Schiller, regarding the App Store incident involving the Ninjawords iPhone dictionary app.

Gruber quotes “the salient parts” of the email in full, but the gist seems to be that, unlike other dictionaries approved for the App Store, Ninjawords drew from Wiktionary — an open internet source — and thus the App Store suggested they wait until iPhone 3.0 was released with parental controls before re-submitting it. Not knowing the release date of 3.0 and not wanting to wait, the Ninjawords developers went ahead and filtered it themselves, thus ending up with a filtered app that took long enough to approve it timed itself into the 17+ rating anyway.

However, other dictionaries with the same “objectionable content” haven’t been flagged as 17+, so the capricious nature of the App Store — the very thing developers fear most — remains. Check out the above link to Daring Fireball for more on that aspect.

For his part, Schiller closes his response as follows:

Apple’s goals remain aligned with customers and developers — to create an innovative applications platform on the iPhone and iPod touch and to assist many developers in making as much great software as possible for the iPhone App Store. While we may not always be perfect in our execution of that goal, our efforts are always made with the best intentions, and if we err we intend to learn and quickly improve.

On the heels Tim Cook’s comments about improvements needed to the App Store, if observable actions follow the sentiments, perhaps developers and users alike will begin to regain some faith in the approval process. Until then, it remains an unsightly blemish on Apple’s otherwise brilliant mobile platform.

(No word yet on whether Gruber asked him about Google Voice…)

Palm faithful rejoice, Gizmodo — via an unnamed source — claims that Palm Pre still syncs with iTunes 8.2 release, same as it reportedly did with the pre-release version.

Meanwhile, Daring Fireball weighs in on the situation again, this time wondering if what Palm is doing is illegal, and if Apple stops it, whether that would be illegal. PreCentral.net, for their part, looks beyond the what to the why:

we’re increasingly getting the feeling that Palm is either trying to goad Apple into a legal showdown or they are so confident in their patent portfolio that they feel they can throw these features in Apple’s face.

To which Gruber aptly footnotes:

And, when judging the likelihood of Apple filing such a lawsuit, consider the perspective of a certain highly-competitive quasi-paranoid Apple founder and CEO who is famously sensitive to what he perceives as being “ripped off”. The one and only company to ship a product that successfully masquerades as an iPod via USB is the company whose engineering division is run by a former Apple senior VP and has hired a slew of former Apple engineers.

In — as they say — deed.

Daring Fireball has been looking into Google’s new Gmail WebApp for the iPhone and the technologies behind it. We already know the iPhone packs a version of Apple’s Safari Web Browser which is, in some ways, even more advanced than desktop Safari on the Mac. SQLite database caching, for example, for example users continue to archive or star messages even when there’s no internet connection. What’s more interesting to him, us — and likely users — is how that technology improves functionality.

Says Gruber:

I use the native iPhone Mail app to read email on my iPhone, but I’m tempted to start using the Gmail web app for one reason: I waste a lot of time switching back and forth between Mail and Safari after tapping a URL in an email. When using the Gmail web app, tapped links simply open in a new Safari tab. The iPhone Mail app needs a built-in web view, like what most popular iPhone Twitter clients offer.

Google’s Alex Nicolaou has blogged about the process.

We once wondered what the future of WebApps would be in a post-native apps world. Looks like Google expects — and is out to prove — things still look very bright.

Anyone else considering ditching the built-in mobile Mail app for some web-based Gmail?

Someone told Daring Fireball that Apple not only asked Google to remove the multi-touch from the Android/HTC T-Mobile G1 smartphone, but also to remove the 3.5mm headphone jack.

The first part was reported earlier and makes the kind of sense that only tricky mega-corp coopetion can make (iPhone eyeballs are more valuable to Google than the G1’s multi-touch at this point). The second part… not so much. Specifically, Daring Fireball’s source mentioned Apple’s use of the remote buttons on the headset to control media playback as the reason for Google avoiding the jack entirely on the G1. (Note: while this sounds familiar, a Google search didn’t turn up any links for Apple patenting anything associated with such processes, so if anyone can point us towards that info, please let us know in the comments).

Other smartphones have long used the 3.5mm headphone jack, and since the G1 is hardly a media powerhouse (it doesn’t even include a built-in video app), there’s little reason to believe HTC couldn’t have included a non-remote, standard 3.5mm jack.

(Aside: Our editor-in-chief, Dieter Bohn, has managed to confirm that both the BlackBerry Curve 8900 and Pearl both make use of some type of headset based media control, so there we go…)

Chris Ziegler over at Engadget Mobile weighs in, calling the entire Apple/Google story from VentureBeat FUD, and the sourcing on the 3.5mm piece sketchy, and while admittedly an unnamed Android source, absent corroboration, doesn’t pass the traditional media test, here’s the other thing:

HTC seems to love the ExtUSB in lieu of 3.5mm headset jack. It’s not just the G1, but an increasing array of their smartphones that are — and will be according to the 2009 HTC roadmap that was leaked — abandoning 3.5mm for the ExtUSB.

So, we’re not sold on this story yet, how about you? Does it seem likely Apple talked Google out of a 3.5mm jack, or that HTC just plain doesn’t like them and never considered it?

I must admit, I’ve stopped using NetNewsWire on my iPhone because I’ve just found it unmanageable. What was an awesome fire hose on my Mac just threatened to drown me on the much smaller machine. Enter Daring Fireball’s John Gruber with some awesome tips on making NetNewsWire on the iPhone far more functional:

What I want in an iPhone feed reader isn’t just a little bit different than what I want in a Mac feed reader, it’s a lot different. So what I did last week was start over from scratch on the iPhone. Rather than going through my full list of feeds and turning some off, I turned them all off, then went through and re-enabled about 20 feeds — the ones I like best, with the highest signal-to-noise ratios, and which would be most enjoyable in those I’m bored, give me something to read moments.

Now NetNewsWire is both snappier for him and more relevant to a mobile experience.

I tried it and I’m loving it. If you give it a try, let me know how it works for you!

• Our podcast feed
• Download Directly
• Subscribe via iTunes

Read the rest of this entry »

UPDATE: iPhone dev extraordinaire Erica Sadun investigated over at Ars and found the following: Google is both linking to Private Frameworks and using unpublished APIs. While the latter is likened to jaywalking, the former is apparently a ban-worthy offense. Yikes. Check out her complete investigation for more. And now that it’s public, the question shifts to what if anything Apple will do about it? Cave to Google over a killer feature and betray the confidence of other developers, or yank Google’s app, alienating a huge (if guilty) partner and likely creating another furor among users?

Original post:

Is Google using private (i.e., not publicly available via the official iPhone SDK) APIs to create the silky-smooth “raise the phone and talk” activation for their new Advanced Voice Search feature in the update Google Mobile App? That’s the latest question Daring Fireball’s been looking into, and here’s what they’ve found so far:

If you use something like the command-line strings utility to examine the UIKit framework, you can see that there’s an undocumented (and therefore private to Apple) method named proximityStateChanged. And if one were to strip the FairPlay DRM from the current Google Mobile application binary — which, of course, you wouldn’t do, because you’re not supposed to strip FairPlay DRM, but I’m just saying if one were to do this — a class dump of the application binary would show that Google Mobile does in fact implement proximityStateChanged.

DF posits three possible explinations: 1) No one at Apple noticed the private API usage, 2) Apple noticed but turned a blind-eye, or 3) Apple approved the use of a private API. Citing sources, DF claims #3 to not be the case, and perhaps that’s why Google promoted the feature so heavily, and stirred up interest so high Apple would feel pressure to approve it (though we wonder if Steve Jobs’ Apple ever feels that type of pressure?)

By contrast, DF states #1 is not without precedence, while #2 would be grossly unfair to other developers, and either way, users may suffer if Apple makes changes to their private APIs (which is one of the reasons to keep them private after all).

So what do you think? Which scenario is most likely? And what would you rather, that developers (Google or not) use officially unsupported features if it means better apps but also apps that might just break when the next firmware drops?

UPDATE:

The New York Times gets clarification from Opera (via Daring Fireball):

“We stopped the work because of the prohibitive license,” to Mr. von Tetzchner wrote in an e-mail.

Turns out it was an internal project.

ORIGINAL POST:

So we, along with half the interwebs, picked up a paraphrased comment by Opera’s president that pretty much indicated Apple had rejected popular mobile browser Opera Mini from the App Store.

Well, John Gruber over at Daring Fireball did some digging and found out that it just ain’t so:

My understanding, based on information from informed sources who do not wish to be identified because they were not authorized by their employers is that Opera has developed an iPhone version of Opera Mini, they haven’t even submitted it to Apple, let alone had it be rejected.

(“Unique” by Hamed Masoumi, licensed under Creative Commons)

On Monday, TiPb Senior Editor Dieter Bohn debuted his new bi-weekly feature, TiPb of the Avalanche, by asking about the iPhone App Store and the “Long Tail” business model.

Looks like he’s not alone. PCalc developer James Thomson (via Daring Fireball) recounted his struggles with Apple’s new policy of listing Apps by original release dates, ignoring update dates, and forcing older Apps to the frozen hinterlands of the last few pages in a list growing well past 5500. Under the old model:

Sales started to slow down over time, but with each of the 1.0.1 and 1.0.2 updates they went back up into the stratosphere as PCalc moved to the front page of the Utilities section again.

And now?

As it stands, the App Store is too crowded to find anything if you don’t know exactly what you are looking for by name.

So while, according to Apple Insider, the App Store may still be climbing faster than iTunes Music did, GigaOm is pishing the posh on the iPhone bump in general.

During Apple’s Q4 conference call, Steve Jobs said that the App Store would reach 200 million downloads today spanning over 5500 Apps in 62 countries. How will Apple’s (continuing?) tweaks on App Store organization help or hinder developers moving forward? And will they, as Dieter is suggesting, have to start putting as much time, money, and effort into marketing as they do coding? Or are there no easy answers?

During Tuesday’s “Spotlight on Notebooks” Keynote, Steve Jobs wasn’t the only jean-and-dark-shirt uniformed Apple exec on stage. COO Time Cook took an unusual turn, discussing Mac business. SVP of Design, Jonathan Ive, an even more unusual presence in front of the audience, introduced the new “brick” unibody concept. And Marketing VP Phil Schiller — who’s no stranger to Keynotes — took part in the Q&A at the end.

It wasn’t all Steve, all the time.

Because of this, Gizmodo’s Jesus Diaz says Steve may be thinking of leaving in the near future, to live out his days on the beach, content that he’s shown investors and customers that Team Apple will Boom! along quite nicely without him, much as Microsoft is… er… doing without Gates in the daily driver’s seat:

Steve Jobs is leaving Apple. Not tomorrow, but probably very soon. That’s why he started to say good bye today, doing something more important than just presenting new MacBooks, MacBook Pros, and an updated MacBook Air. Today’s event was a play in which he clearly told everyone that the company is more than himself. Since the very first minute, when he immediately sat down to let Tim Cook talk, he was saying: “Hey, look, Apple is more than Steve. These are The Guys, the Goodfellas, the A-Team. They share the same vision I have. And they are going to push the company forward when I change my office chair for a hammock and caipirinhas on my private beach in Hawaii”.

Daring Fireball’s John Gruber, however, says Steve isn’t going anywhere. He points out that Jobs has shared the stage before, often letting adepts take the more highly specialized presentations, like introducing Leopard at WWDC. Gruber says:

But so long as he’s healthy, working at Apple is exactly the thing Jobs wants to do. He’s consumed by his work, and I think it’s only in the last two or three years that Apple has gotten to the point where Jobs feels he has a decent set of crayons at his disposal. In Jobs’s mind, the iPhone is only the beginning of what a truly flourishing Apple can produce. Why would he leave now? “A hammock and caipirinhas on a private beach” would be living hell for Steve Jobs.

We’re with Gruber on this one. While Diaz is saying what many of us were likely thinking during the show, Jobs doesn’t strike us as the casual CEO. His investment in Apple is lifelong. He’s not Woz, he’s the Wizard, and they’ll have to pry his hand off Apple’s perfectly balanced, aluminum and gloss black steering wheel if that’s ever going to change.