July 21, 2010

It’s happened. An app that grossly violated Apple’s terms of service (by enabling free tethering) made it through Apple’s review process, onto the App Store, and into the #2 most-popular spot before being taken down. Although this app wasn’t malicious to users, it’s absolutely malicious to Apple’s agreements with AT&T and other phone-companies. It is a real demonstration that Apple can’t keep malware off the App Store.

A Few Sneaky Ideas

It’s not hard to come up with ways to fool App-Store reviewers.

You might just get lucky. With over 230,000 Apps in the store, reviewers are swamped. They’re only human and they might not notice some subtle evil — especially if it’s not on their naughty-behavior list.

Time-Bombs, apps that hide their bad-behavior for a few days, are undetectable without periodic audits, since they act normally during the pre-release review period.

Phoning home to a server that let’s an app know it’s passed review and can begin it’s life of crime, would let an app be even more precise.

With just a few minutes thought, I’m sure you can think of even more clever tricks, or combination of tricks.

Not a Fully Open Vulnerability

That’s not to say your iPhone is in as much danger as your PC. iOS apps don’t have the same free-reign that traditional computer programs have. That limits their usefulness, but it also limits the damage they can cause. An iOS App can’t stop you from killing it, and it can’t mess with other apps, so it can’t “take over” your phone. But it can do anything it likes with your Contacts, and secretly abuse the phone’s always-on network connection, and get up to other sorts of minor mischief.

I don’t have room here to fully analyze the risks of a rogue iPhone’s program. But generally, the danger isn’t too great: a little more than a what website can do, a lot less than what a PC program with administrator access can do.

Ultimately, Apple’s best defense against malware isn’t control of the App Store review process or iTunes payments (although they help), but control over iOS. A well-designed operating system limits what kinds of malware are possible. The review process can screen for egregious mistakes. But it can’t catch everything, and it’s least-able to catch the most clever malware, which ultimately, are the programs we should be most worried about. Apple’s review process doesn’t provide real security against modern malware.

View objects make bad keys. Views have state related to the screen: their frame, position in the view hierarchy, animation layers, etc. When you copy a view object, the copy won’t (always) be isEqual: to the original, because it’s not on the screen in exactly the same way.

Of course, this isn’t a complete list of every way key-copying can trip you up. But if you understand what copy means in Cocoa, and remember how NSDictionary works, you’ll be able to avoid or quickly solve any issues.

How to Document Such Behavior Better Than Apple Did

Given what we know about NSDictionary, what’s wrong with the following snippit from NSDictionary.h?

Answer: aKey needs to implement NSCopying, so it should be of type (id<NSCopying>) instead of type (id). That way, the header is self-documenting, and, if like most smart programmers, you’re using autocomplete to type out Cocoa’s long method names, the auto-completed template will be self-documenting too.

I have a hard time wrapping my head around that number. Nearly five thousand “apps”. Near as I can tell, it’s a solid 2% of the whole App Store. With an (optimistic) 5-day-per-app approval time, it would take Apple 86 years to approve them serially.

June 11, 2010

I wish I could take credit for this idea, but it’s from someone else, will Apple sell iAds that only show up in the iPhone simulator? Probably not, but it would be a hell of a targeted demographic.

For those of you who aren’t familiar with how building iPhone software works, we developers spend thousands of hours testing and debugging our programs in an iPhone Simulator application that runs on our Macs. The simulator can’t run Apps from the App Store, only programs compiled from source code with Xcode. So the only people using the simulator are programers, or otherwise deeply involved with building iOS apps. Apple could make it so that any iAds in the simulator would show special ads targeted to developers.

June 9, 2010

…one particularly outrageous moment stuck out for me. At about three minutes into the video, senior vice president for iPhone software Scott Forstall extolls the virtues of the Retina Display by declaring that “The text… is just perfect!” Meanwhile, the central image in the video at just that moment is this little typographic calamity:

I urge you to fast-forward the time code to 3:02 to hear this for yourself. Forstall is quite literally claiming perfection while a hand model holds up this terrible example of everything that’s wrong with Apple’s commitment to typography. While the letterforms on that virtual page may look gorgeous, it’s apparent to any designer that the text is far from perfectly typeset. It’s hideous, scarred as it is by unsightly “rivers” of bad spacing within the text. No self-respecting typographer would dare call that perfect.

October 22, 2009

There’s a lot of discord over Apple’s draconian “closed” handling of the iPhone and App store. And rightly so. But there are a few interesting lessons in the current situation. The one I want to discuss now is that,

Being able to program your own computer isn’t enough to make it open

As things stand today, Apple can’t stop you from installing any damn iPhone app if you build yourself.

To do that you have to join the iPhone developer program of course. And there’s a $99/year fee. That’s inconvenient, but it’s just using a subscription-based way of selling iPhone OS: Developer Edition.

That’s the kind of dirty money-grabbing scheme I’d expect from Microsoft. It’s a bit shady, because it’s not how most OSes are sold. But it’s not without precedent. And unless you are against ever charging money for software, I don’t think there’s an argument that it’s actually depriving people of freedom.

Yes, it’s an unaffordably high price for many. But the iPhone is a premium good that costs real money to build — it’s inherently beyond many people’s means, even when subsidized.

Observation: Only Binaries Matter

If you have a great iPhone app that Apple won’t allow into the store, you can still give it to me in source code form, and since I have iPhone OS: Developer Edition, I can run it on my iPhone.

But clearly that’s not good enough.

In fact, I’m not aware of any substantive iPhone App that’s distributed as source. By “substantive” I mean an app with a lot of users — say as many as the 100th most downloaded App Store app — or an app that does something that makes people jealous, like tethering (See update!), which we know is possible using the SDK. I realize this is a wishy-washy definition — what I’m trying to say is that distributed-as-source iPhone Apps seem to be totally irrelevant.

“It’s not open until I can put Linux on it”

I believe it’s technically possible to run Linux on an iPhone without jail-breaking it. (Although it’s not terribly practical.) Just build Linux (or an emulator that runs Linux) as an iPhone app, and leave it running all the time to get around the limitations on background processes.

Apple won’t allow such a thing into the App Store of course —but how does that stop you from distributing the source for it? As best I can tell, it doesn’t.

Conclusion

But the iPhone remains a closed device. User-compiled applications have 0 momentum. And I think that clearly shows the irrelevance of the rare “programmer user”, who is comfortable dealing with the source code for the programs he uses.

UPDATE 2010-01-21: iProxy is an open-source project to enable tethering! Maybe the programmer-user will have their day after-all.

July 19, 2009

It’s very clear that a program “for Mac OS X” works with any personal computer Apple sells, because they all have “Mac” in their name. Unfortunately, the flavor of OS X that runs on the iPhone and iPod Touch is officially called “iPhone OS” by Apple, which it implies an incompatibility with the iPod Touch, and any future device that doesn’t have “phone” in the name.

I don’t know a good way to unambiguously say that a program is for any iPhone OS device, without tedious enumeration.

“For iPhone OS” sounds like it excludes the iPod Touch.

“For all models of iPhone and iPod Touch” sounds terrible. It will sound even worse when Apple comes out with other iPhone OS devices (“…for iPhone or iPod Touch or iTablet or iFPGA…”).

Apple could help by renaming “iPhone OS” to “Mobile OS X”, but I don’t see this happening.

I personally lean towards using “for iPhone” in general writing, and clarifying, if necessary, in “systems requirements” fine print. This feels closest to how the press covers iPhone OS applications, and of course it’s how Apple named the OS.

She’s never lived in a world that wasn’t densely populated with Macintoshes. …She literally learned to use it by sitting on her mother’s lap while her mother was working. So for this child, the Macintosh is not a piece of technology, but simply more material in the environment to manipulate.

Another interesting point to note is that even though she can’t read, she’s able to recognize standard textual menu items.

And in fact we discovered that she was about 70% literate — that about 70% of the generic window commands that are found in any Macintosh application, she’s able to use. Not just in a visual program like Mac Paint.