• more about

    #iphone

    Official Commodore 64 Emulator Returns To The App Store

    This Week's Best iPhone Apps

    iPhone vs. Droid: Whoever Wins, We're All Still Losers

    read more: #blackberrybold, #iphone, #iphone3g, #smartphones, #cellphones, #blackberry, #bold, #rim

    Video: BlackBerry Bold vs. iPhone Web Browser Showdown (It Gets Ugly)

    We've seen the BlackBerry Bold and iPhone head-to-head before, as well as the Bold's greatly improved browsing powers over past BlackBerrys, but not side-by-side in a web browser race. It actually gets pretty ugly, uglier than we thought it would. Update: So it looks like in Mobile Computer's test the Bold was either dropping off of Wi-Fi or wasn't on it at all. Update 2: Mobile Computer's editor got back to us to explain the test.

    He says that both were connected to the same Wi-Fi network, but the possibility didn't occur to him that he might have to manually configure the web browser to use the already established Wi-Fi connection, which is a poor design choice, if true. He also says he didn't disable cellular data to be absolutely sure, because turning that off apparently also turns off Wi-Fi.

    In his later test of the two phones, iPhone's EDGE to Bold's 3G, the iPhone still comes out on top, "albeit by a reduced margin," which definitely points to some rendering slowness on the Bold's part. He's going to re-run the Wi-Fi tests to be absolutely sure they were performed correctly. Takeaway: The Bold does render pages more slowly than the iPhone, but it's not draggy enough to go get a snack while you're waiting or anything.

    With both running on Wi-Fi and a cleared cache, in a test using Slashdot, the iPhone is actually able to open an entirely new page before the Bold finishes with the first one. The Bold renders everything correctly, it just takes a looooong time to do it. The Bold's got some fairly heavy duty hardware though, so an update from RIM could always give the browser a jolt. [Mobile Computer Mag via jkOntheRun]


    Send an email to matt buchanan, the author of this post, at matt@gizmodo.com.