It sounds like it’s going to become a reality in a few hours: Google Maps for iOS 6.
My experience so far with Apple maps hasn’t been terrible. Data quality issues never actually affected me. I have missed the lack of public transit. That is the primary reason I plan to switch over. Public transit integration is critical in NYC.
I’m hoping it’s just a refreshed UI of what was in iOS 5 with as lean of a UI or leaner.
Earlier this month I complained about how annoying letterboxed iPhone apps are on the iPhone 5 since it shifts the keyboard. The one I used as an example was Google Voice, which has now updated. I thought it was worth mentioning since I did call them out explicitly on it as a shining example of this. Kudos to Google.
Apple switching from Google Maps to its own “creation” is a pretty interesting move. By “creation” I of course mean a mashup of TomTom data and OpenStreetMap data among other sources with their own vector maps and 3D imaging. The 3D thing is a cool effect, but that’s all it is, an effect. I can’t think of many, if any practical uses for it.
The maps from a visual standpoint are quite nice. They look great and are quite readable. At least as good, if not better than Google Maps. The quality of the data however is pretty terrible. The maps are sometimes incomplete and things aren’t placed correctly.
In my opinion the worst offense is the lack of public transit data. For larger cities like New York, San Francisco, London that is a high-profile gap. Given the size of the population in those cities (and how much of the press operates out of those), it just makes the problem that much worse. Given that data is pretty accessible (NY’s MTA even has a website dedicated to it), I can’t see how they let that one slip. Simply showing stations and what trains are there would have been a huge improvement.
The upside to all this is maps is really a web-based service. That means Apple can iterate on it 24×7 without having to release a ton of updates. That means the maps in theory will improve in quality over time without most people even realizing.
That said, cartography is really difficult stuff.
According to the US Department of Justice (DOJ) the iPhone is largely uncrackable at this point:
“I can tell you from the Department of Justice perspective, if that drive is encrypted, you’re done,” Ovie Carroll, director of the cyber-crime lab for the CCIPS division of the Department of Justice, said earlier this month during his presentation at DFRWS. “When conducting criminal investigations, if you pull the power on a drive that is whole-disk encrypted you have lost any chance of recovering that data.”
Of course there are a fair number of tools out there for iOS 4 and below including UFED Ultimate and XRY. There is a lack of iOS 5 tools, at least that are being publicly advertised.
However, there’s arguably little need for such a tool anymore. As users put data on in “the cloud”, law enforcement doesn’t even need the physical phone, they can just send a request to Apple (or Google) for the data they want. I suspect this is at least part of what Steve Wozniak was talking about when he mentioned “horrible problems” in the next five years. It’s worth noting Apple has almost zero transparency regarding law enforcement requests and how they are vetted. It’s not even clear a warrant is necessary to request data. The law certainly isn’t clear in that regard.
If anything, I think it’s becoming easier for law enforcement, not harder.
A nice little scoop from Apple Insider about iOS 6 shipping with a new setting. Wi-Fi Plus Cellular it will allow your phone to fall back to cellular when a Wi-Fi access point is slow. A rather nice little enhancement.
I’d actually love to see Wi-Fi be geofenced, so that it will automatically enable itself in certain locations. I don’t need Wi-Fi on all the times, but there are certain locations where iOS devices could utilize it. Why should I need to toggle it myself if the device knows where it is? I’d love if my phone knew it had access to Wi-Fi at home and could switch automatically when I’m home. It seems like this would be simple enough to do right. Apple does all the pieces already, it’s just a matter of doing it together.
For those not keeping score, Twitter, and Facebook have both come out publicly in favor of SPDY. Twitter is already using it in production. It sounds like Facebook will be soon. Mozilla implemented it in Firefox. Opera has SPDY. Google, the author of SPDY is using it in production.
This leaves Microsoft and Apple as the holdouts. Microsoft’s HTTP + Mobility is SPDY at it’s core. Microsoft hasn’t started supporting SPDY in any products, but it seems inevitable at some point. They are a holdout in implementation but not opposed to SPDY it seems.
Apple is the last major holdout. SPDY hasn’t been announced for iOS 6 or Mac OS X 10.8. As far as I’m aware Apple hasn’t made any statement suggesting support or opposition to SPDY. However I can’t see why they would oppose it. There’s nothing for them to disapprove of, other than it’s not using their IP. I’d be surprised if they don’t want to implement it.
However given SPDY is a rather backwards compatible thing to support, I don’t see this holding back adoption. Nginx is adding support for SPDY (thanks to WordPress creator Automattic), and Google is working on mod_spdy for Apache. That makes adoption for lots of large websites possible.
While the details of SPDY and the direction it will go are still in flux, it seems nearly certain that SPDY is the future of the web. Time to start digging into how to adopt it and ease the transition. The primary concerns I see are as follow:
Both of the above concerns increase complexity and cost of building websites at scale and for those who are on a very tight budget (the rest of us will manage). Because of this, I don’t think we’ll see a 100% SPDY or HTTP 2.0 web for quite some time. Don’t expect SPDY for shared hosting sites anytime soon.
In a world of increasing surveillance and user data being integrated into everything, the benefits of TLS will be realized. Both Facebook and Twitter acknowledge it’s importance in preventing user data from getting into the wrong hands.
I, For One, Welcome Our New SPDY overlord.
Google is pervasive about associating Chrome with being fast. It’s was their primary pitch when they first announced it. Back when Firefox went 1.0, it wasn’t so much about speed but “not sucking” as all the geeks liked to say. Given IE 6 was the competition, that was likely the best marketing on earth. Sure it was faster, but sucking fast wasn’t nearly as good as not sucking. Not sucking encompassed the missing features, broken rendering, crashing, constant parade of security problems. It summarized the product surprisingly well for not being an official slogan by any means.
Google now launched Chrome for iOS. On the desktop Chrome and Safari both use WebKit, Chrome applies it’s own touches to make things faster. Notably they have their own JS engine. Safari also has it’s own JS engine. This is the secret sauce of performance. In the iOS world however Apple being the totalitarian dictator decided that iOS will provide WebKit and JS. If your app has any web browser functionality it will utilize these API’s and not implement it’s own engine. Verbatim:
2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript
Google Chrome for iOS however is Google integration into a reskinned experience of Safari. It’s the same browser. Just a new UI bolted on with some Google features integrated in. It’s not a separate browser. It’s a UI.
That however doesn’t stop Google’s marketing machine (I’d argue Apple marketing’s top rival) from putting “fast” as the second word:
Browse fast with Chrome, now available on your iPhone, iPod touch and iPad. Sign in to sync your personalized Chrome experience from your computer, and bring it with you anywhere you go.
It goes on to clarify:
- Search and navigate fast, directly from the same box. Choose from results that appear as you type.
So Google isn’t truly misleading. It’s just very strategic wording.
The truth of the matter however is that Google Chrome on iOS is substantially slower than Safari. Safari uses Nitro to accelerate JavaScript, which powers most of the complicated websites that will slow down a browser on any modern device. Apple however restricts Nitro to Safari, and doesn’t let third party apps like Google Chrome use it. This is still the case as of iOS 5, and I believe is the case in iOS 6, though I haven’t personally verified that.
How much slower is Google Chrome on iOS in comparison to Safari? Well Here’s a SunSpider test I did on my iPad 3:
============================================ RESULTS (means and 95% confidence intervals) -------------------------------------------- Total: 1817.9ms +/- 0.2% -------------------------------------------- 3d: 214.7ms +/- 1.1% cube: 72.3ms +/- 0.7% morph: 57.9ms +/- 0.9% raytrace: 84.5ms +/- 2.2% access: 224.9ms +/- 0.6% binary-trees: 44.4ms +/- 1.7% fannkuch: 96.2ms +/- 0.6% nbody: 56.0ms +/- 0.0% nsieve: 28.3ms +/- 2.7% bitops: 141.0ms +/- 0.4% 3bit-bits-in-byte: 23.4ms +/- 1.6% bits-in-byte: 29.5ms +/- 1.3% bitwise-and: 37.8ms +/- 1.5% nsieve-bits: 50.3ms +/- 0.7% controlflow: 15.7ms +/- 2.2% recursive: 15.7ms +/- 2.2% crypto: 123.3ms +/- 0.6% aes: 70.5ms +/- 0.5% md5: 29.4ms +/- 1.3% sha1: 23.4ms +/- 1.6% date: 274.4ms +/- 0.7% format-tofte: 139.8ms +/- 1.1% format-xparb: 134.6ms +/- 0.7% math: 175.1ms +/- 0.3% cordic: 61.5ms +/- 0.8% partial-sums: 74.4ms +/- 0.7% spectral-norm: 39.2ms +/- 0.8% regexp: 70.8ms +/- 0.6% dna: 70.8ms +/- 0.6% string: 578.0ms +/- 0.5% base64: 78.3ms +/- 1.9% fasta: 68.1ms +/- 0.9% tagcloud: 109.5ms +/- 1.2% unpack-code: 207.5ms +/- 1.2% validate-input: 114.6ms +/- 0.7%
============================================ RESULTS (means and 95% confidence intervals) -------------------------------------------- Total: 7221.0ms +/- 0.1% -------------------------------------------- 3d: 802.7ms +/- 0.2% cube: 230.9ms +/- 0.6% morph: 297.3ms +/- 0.5% raytrace: 274.5ms +/- 0.1% access: 1112.0ms +/- 0.2% binary-trees: 98.4ms +/- 1.1% fannkuch: 609.6ms +/- 0.2% nbody: 247.9ms +/- 0.2% nsieve: 156.1ms +/- 0.4% bitops: 957.2ms +/- 0.2% 3bit-bits-in-byte: 210.4ms +/- 0.6% bits-in-byte: 232.9ms +/- 0.2% bitwise-and: 188.5ms +/- 0.4% nsieve-bits: 325.4ms +/- 0.2% controlflow: 129.5ms +/- 0.3% recursive: 129.5ms +/- 0.3% crypto: 493.3ms +/- 0.2% aes: 214.3ms +/- 0.4% md5: 140.2ms +/- 0.3% sha1: 138.8ms +/- 0.5% date: 381.1ms +/- 0.3% format-tofte: 214.2ms +/- 0.2% format-xparb: 166.9ms +/- 0.5% math: 770.7ms +/- 0.2% cordic: 316.6ms +/- 0.2% partial-sums: 243.2ms +/- 0.3% spectral-norm: 210.9ms +/- 0.4% regexp: 1340.2ms +/- 0.2% dna: 1340.2ms +/- 0.2% string: 1234.3ms +/- 0.6% base64: 175.7ms +/- 0.5% fasta: 205.6ms +/- 0.2% tagcloud: 284.0ms +/- 2.3% unpack-code: 370.1ms +/- 0.9% validate-input: 198.9ms +/- 0.6%
Quite a bit slower.
So really, if you’re using Chrome on iOS, it’s because you absolutely love the design and integration with Google’s services, and are willing to trade off considerable JavaScript performance for those perks.
That however doesn’t stop many people from thinking it’s fast. Just in the past few minutes I’m able to find these Tweets among the thousands streaming across the web. I won’t mention or link to them directly (you could find them however if you wanted):
“Chrome for iOS is FAST, takes the mobile browsing experience to a new level.”
“I like it! It’s fast and can sync with Chrome desktop, which I use all of the time.”
“Liking #chrome on #iOS very slick, fast and clean looking”
“using chrome on my iphone right now.. cant believe how fast it is”
“That chrome for iOS is freaking fast but so basic. No tweet button, no add-on. Man I kinda disappointed. I give ’em 1 ‘fore the update”
“Chrome for iOS? Hell yes!! So fast! #chrome”
“Google Chrome for iOS is fast.”
The most touted feature isn’t actually a feature. It’s technically not even there. The numbers and the technology insist that it’s not (they prove it’s actually slower). But that’s what everyone is ranting and raving about. You could argue Google’s UI is faster, but I’d be highly skeptical that Google’s found Cocoa tricks Apple engineers haven’t. Perhaps a UI transition or two makes you think it’s faster or more responsive, however even that I can’t find any evidence of.
All the hard work the Google engineers did squeezing their services into a compact simple to use UI are ignored in favor of this non-existent feature. And as a developer who can’t ignore such a thing, I will say they did a great job with their UI.
I present to you, the power of marketing!
Lots of little notes on today’s announcements…
Some interesting graphs on iOS 5.1 upgrade stats. iOS 5.0.1 and 5.1 are notable because they are the first upgrades to be delivered OTA. Unless this data is a unique segment and not representative of the larger ecosystem (I don’t think that’s the case), this is pretty impressive.
This is why the upgrade process is so important to client side applications, especially when you manage a platform. After installation keeping a user running the latest and greatest is critical. It impacts your entire ecosystem, which in Apple’s case includes the web, iOS developers, tech support, and yes even wireless partners.
Google’s biggest mistake was leaving hardware vendors and wireless providers in charge of managing upgrades. They are carrying a lot of baggage from old Android devices that Apple doesn’t. This is only going to be more amplified in the next 12-24 months as Apple users stay more current and Android continues to fragment.
An old but interesting interview with X-Plane creator Austin Meyer on Direct3D vs. OpenGL:
…I bet on OpenGL, and used that. As a result, here we are, 15 years later, and the people that use Direct3D can support Windows only. But, with OpenGL, I support Windows, Mac, Linux, Palm OS, Google Android OS, and oh yes: iPhone and iPodOS which are also OpenGL. So having X-Plane in OpenGL let me move over to iPod and iPhone very quickly. The port was done in 2 weeks, to be very exact. And you saw that i have moved 500,000 units on the iPhone and iPod since. I get $7 from each of those sales, and have moved 500,000 units in the last year and a half, so get out your calculator, do some math, and see if i made the right choice to bet against Microsoft 15 years ago.
Always bet on standards. Nobody remains on top forever. When you bet on proprietary tech because it’s in the lead, you’re betting that your demise will happen prior to the leader falling. Never bet against yourself.