Mike Ash: ARM64 and You
I’m linking to this, because it’s first class nerdery, giving real insight into CPU design and performance. I always operate many layers of abstraction above this, but I find it absolutely fascinating. By the way, the comments on this post are a tonic against the general pessimism about blog comments.
The big online privacy scandal of the past couple of weeks has been the discovery that the social networking app Path uploads your entire iPhone address book to its servers without asking for your permission. People were not only surprised that Path does this, but also that Apple lets them do it. Shortly after this was discovered, we learned that lots of other companies upload your address book as well. The Verge has a rundown of which applications access your address book and whether they ask for permission first.
The discussion I’m interested in is what access applications should have to your address book. One possibility would be for Apple to put the same warning on address book access that they put on use of location services, but as Chris Dixon points out, the more often you ask users for permission, the less attention they pay. I don’t like that solution.
Another option is to simply block access to the address book for apps entirely. I would not be opposed to this approach. Yes, social networking apps desperately want to hook you in by making sure you’re connected to your friends, and they want you to invite your friends to the service to grow their user base. What value do users get out of it, though? Automatically connecting to your friends is a small benefit, and in many cases there are other ways to determine who you’re friends with without pillaging your address book. Apple should strongly consider just blocking address book access entirely.
Short of that, the policy solution is to allow access only to applications once a user has acted to grant access for that application without being prompted directly. So, for example, applications that ask users to upload everything in their address book as soon as they sign up would not be allowed, but applications that have a “Search for contacts in my address book” button would be allowed. Whether Apple could enforce that policy is another matter. As a matter of policy, though, applications should not try to access your address book unless you try to use a feature that requires it.
Update: And I managed to get this post in right before Apple announced a policy change that will require explicit permission before an application can access the address book.
When Apple entered the mobile handset business, one of the biggest breaks they made with tradition is that they retained control of the software update process for the iPhone. Regardless of your carrier, which software runs on your phone is between you and Apple, and Apple does a very good job of maintaining support for old handsets with their software updates.
In many cases, with Android, it’s up to the carriers when your phone gets new software, and they have not broken with their long tradition of being very conservative when it comes to distributing software updates. A couple of weeks ago, I was able to update my 27 month old iPhone 3GS to iOS 5 the day it was released. Many people buy Android handsets and never get to run the most recent software, as shown on this chart.
For many customers, this is probably not a big deal. They’re fine with running the software that shipped with their phone as long as they own it, but I find it strange that enthusiasts are OK with it.
If voice-activated user interfaces like Siri in the new iPhone 4S really take off, third party application developers are going to want in on the action. As John Gruber points out in his iPhone 4S review, that poses an interesting set of problems:
People are going to start clamoring for third-party Siri integration as soon as they see Siri in action. But I’m not sure what form that integration could take. Best I can think is that apps could hook up to (as yet utterly hypothetical) Siri APIs much in the same way that Mac apps can supply system-wide Services menu items. But how would they keep from stomping on one another? If Siri supported third-party apps and you said, “Schedule lunch tomorrow at noon,” what would Siri do if you have multiple Siri-enabled calendar apps installed? This is similar to the dilemma Mac OS X faces when you open a document with a file extension that multiple installed apps register support for.
And here’s a specific example of what he’s talking about, that involves only the built-in applications:
Here’s an example. Wolfram Alpha has terrific stock-price information and comparison features. I link to them frequently for stock info from Daring Fireball. So I tried asking Siri, “What was Apple’s stock price 10 years ago?” But once Siri groks that you’re asking about a stock price, it queries the built-in Stocks app for data, and the Stocks app doesn’t have historical data that goes back that far. “What did Apple’s stock price close at today?” works, but asking for historical data does not. But Wolfram Alpha has that data.
Working around those sorts of problems is difficult with regular touch or point and click interfaces — it’s easy to wind up in Preferences Hell. Dealing with them at the voice level is going to be even more complex.
One of the most encouraging things about the original iPhone was that it was an Apple product, not an AT&T product. Apple maintained control over just about every aspect of the user experience, and customers relied on AT&T only for connectivity. This was great news for end users, because mobile carriers tend to do an awful job in terms of user experience. One of the reasons the iPhone was so starkly different from everything else on the market at the time was that it was so obviously free of the horrible sorts of interfaces that carriers always foist upon their customers.
I was among the many optimistic people who believed that the iPhone was the harbinger of things to come, and that soon there would be a plethora of handsets from a variety of manufacturers that, like the iPhone, reflected the design choices of the handset maker rather than the carrier. Aside from the discontinued Nexus One (which no carriers subsidized) and more recently the Nexus S (offered by T-Mobile), that hasn’t happened.
Now I’m seeing a similar prediction from Owen Thomas at VentureBeat, arguing that the Verizon picking up the iPhone in its pristine state is a sign that carriers will lose control of the handsets.
I’m not as optimistic about this as I once was. Android has not been helpful in this regard. Because of the way Android is licensed, carriers are free to manipulate it in any way that they choose before installing it on handsets, and manipulate it they do. Apple alone insists that carriers who offer its handsets do so without customizing the phone to suit their needs.
For a number of good reasons (one of which is that they won’t allow carriers to customize the iPhone software or put their logos on the hardware), iOS is unlikely to become the dominant OS in the handset market. Android is an excellent product, and Android handsets are going to be offered across the full handset price range soon enough. RIM and Microsoft aren’t going anywhere anytime soon. The question then becomes, is anyone other than Apple going to stand up to the carriers and demand that they control the user experience instead of the carrier. Right now, it doesn’t seem likely.
Derek Powazek talks about the burden that the app store approval process puts on iOS developers:
Apple’s App Store was a constant source of stress in the development process. Every time another story of Apple randomly booting an app from the store came out, the whole team quaked. The idea that we could do all this work and then Apple could deny the app, or even keep it in limbo forever, made us second- or third-guess every design decision. “Will this pixel hurt our chances of getting accepted?”
Consumer Reports cannot recommend the iPhone 4 due to the antenna issue:
It’s official. Consumer Reports’ engineers have just completed testing the iPhone 4, and have confirmed that there is a problem with its reception. When your finger or hand touches a spot on the phone’s lower left side—an easy thing, especially for lefties—the signal can significantly degrade enough to cause you to lose your connection altogether if you’re in an area with a weak signal. Due to this problem, we can’t recommend the iPhone 4.
We reached this conclusion after testing all three of our iPhone 4s (purchased at three separate retailers in the New York area) in the controlled environment of CU’s radio frequency (RF) isolation chamber. In this room, which is impervious to outside radio signals, our test engineers connected the phones to our base-station emulator, a device that simulates carrier cell towers (see video: IPhone 4 Design Defect Confirmed). We also tested several other AT&T phones the same way, including the iPhone 3G S and the Palm Pre. None of those phones had the signal-loss problems of the iPhone 4.
Aside from that, it’s their highest scoring app phone. Apple’s claim that the problem is the signal strength indicator isn’t going to cut it.
The fact that a blog exists on the topic of antenna engineering is proof that we live in marvelous times. AntennaSys weighs in on the much-discussed iPhone 4 antenna issue. I come away with the impression that it’s a flaw that users will have to live with, but that it’s one they’ll be able to live with. If you want to learn more about the iPhone’s display, check out this post by retinal neuroscientist Bryan Jones. Like I said, marvelous times.
I’ve been saying for some time that in the smart phone market, Google is Microsoft and Apple is, well, Apple. Apple was never going to be the dominant player in this market in terms of market share, simply because they only have one or two phone models at any given time, are only on one carrier in the US, and won’t license the operating system to any other handset makers. They want to sell enough high margin products that people love to be extremely profitable, and are very successful with that strategy.
Google, on the other hand, gives Android away to anyone who wants to put it on their handset, and have been rewarded with rapid growth. But I don’t think that Android’s user experience will ever match the iPhone’s. For one thing, because Android is used on so many different kinds of hardware, it will be difficult to achieve the level of integration that Apple has with the iPhone. And for another, the carriers and handset makers are guaranteed to make the Android worse, just as the PC makers have consistently made Windows worse over the years.
This is from Eric Burke’s review of the HTC EVO:
Android makes vendor customizations possible and this phone demonstrates just how poorly that can be done.
He has a list of examples. That’s just not something you have to settle for when the iPhone is out there.
© 2024 rc3.org
Theme by Anders Noren — Up ↑
Assessing iPhone security
In iPhones, the FBI, and Going Dark, security researcher explains which threats an iPhone protects you from. As a device, it’s secure, but how you use it determines how much information you expose. In short, the iPhone is normally used as part of a system with many potentially leaky components.