Journal()

This is not about the iPad

When I started using the iPhone, both as a user and a developer, I finally saw freedom. Freedom from the ridiculous way in which software - Mac or PC - is made today. Here was an entirely new UI paradigm that finally - finally! - did not have the horrible and messy baggage of desktop operating systems. The very same menus, windows, pop up buttons, etc. that, in the 1980s, were the saviors of computer users everywhere, rescuing them from the abyss of the command line interface, are now the devil. We all know this because we know how incredibly hard it is for people like our parents and less "tech-savvy" friends to even become close to proficient at using them.

The iPhone came and showed us that we don't need all that! Hell, it didn't even have Cut, Copy and Paste for more than a year, and I almost never felt it missing. And yet, when they finally added it, the way they did it just blew me away with how clever and minimalist it was. (In contrast, look at how Windows Mobile or Palm Pre tackled the same problem, and you'll see how they're still burdened with the baggage of desktop OSs - it's just all too easy to give in to following the tried-and-true way, right?)

This is big. Forget about the iPad itself, but look at what it is saying. It is saying that we can have a fully usable desktop operating system (for that is what the iPad has, believe it or not), while simultaneously throwing away most of the crud that makes a desktop operating system what it is today. Many will complain that there is no Finder. But I don't want a fucking Finder! I've had it with manually managing a ridiculous file hierarchy on my computer. I've also had it with hunting for commands in menu bars, toolbars, contextual menus, and pop up buttons! I absolutely love the UI innovativeness that both iPhone and iPad are brimming with; this is the kind of fresh slate that was previously thought of as impossible to attain, and the kind of fresh slate that any other company would give an arm and a leg for.

And I have to give Apple kudos for playing it off as well as they have done. If this had been directly pitched as a successor to the Mac OS, there would have been massive booing, since it didn't run any Mac software, couldn't work with any of the existing peripherals, and so on. What they've done instead is to let their brand new OS with its brand new UI paradigm mature alongside the Mac OS, letting this new OS build its own base of both users and developers (140,000 apps!), so that when they ship the successor to the MacBook in a couple of years and it runs what we know today as the iPhone OS, no one will raise an eyebrow, because it will be the most natural thing in the world. I look forward to that day.

Labels: English, Mac

2 comments

Oh Skar, you are still a Mac lover after all! I agree with you completely. From an HCI standpoint Apple is re-inventing how we interact with these devices in an easy, sexy and intuitive way. The next task? Figure out how to make development for these devices as easy as using them!

By Jorge, at January 28, 2010 5:36 PM
I agree with you. I have subscribed your feed. If a saw your post early I will quote some of them in my post:)

By Shawn Lee, at January 28, 2010 6:06 PM

Post a Comment

Google Latitude

Of the newly introduced Google Latitude for iPhone, which is a web application:

We worked closely with Apple to bring Latitude to the iPhone in a way Apple thought would be best for iPhone users. After we developed a Latitude application for the iPhone, Apple requested we release Latitude as a web application in order to avoid confusion with Maps on the iPhone, which uses Google to serve maps tiles.

This is one of the major issues with developing apps for iPhone. Apple tells you they won't accept it after you have done all your hard work, and this ought not to be underestimated. The only thing that is a bit surprising is that Apple has the balls to give the same crap to Google.

Labels: English, Mac

0 comments

Post a Comment

More Rejection

This time it's not my story but this guy's. Basically, they're rejecting his iPhone app because it requires a companion Mac application. This is beyond fucked up. This is just kicking the man in the groin. I mean, not only has Apple provided precedent for this kind of application (the Remote app, which needs iTunes as a companion), but that it makes no sense at all! Rejecting based on objectionable content is one thing, but this is just ludicrous. Might I remind you that making these applications takes months of hard work and if it's rejected, that's it, the work all goes to waste. End of story. Not to mention, Apple is never willing to talk to you nicely - emails are ignored and those annoying "can't comment" responses honestly make me want to take up a career in violence.

In other news, I've resubmitted Qingwen to the App Store with even more new features and bug fixes, and now I await even more of Apple's senseless displeasure. Maybe they'll want me to take Mao Zedong's entry out or something because they find it offensive. Seriously, I don't know what's going on with this whole App Store approval situation. I just hope that either Apple gets its act together or other competing platforms like the Palm Pre come up to speed quickly and offer a friendlier solution.

Labels: English, Mac

0 comments

Post a Comment

With Hands Tied Behind My Back

I started reading Garrett Murray's post about his annoyances with the way the iTunes App Store works, and I have to say, it's made me way more pissed off at Apple and the way they handle App Store submissions than I ever imagined.

Yes, in writing this post, I realize what a marvelous piece of work the iPhone platform is and how the runaway success of the App Store means that it's definitely doing a lot of things right. The thing is, most of that is from the customer's point of view. From the developer's standpoint, regardless of how many times Apple tells me that the App Store takes away all the pain of marketing and distributing my app, I have to say that this is not the way I want to be doing it.

What stirred all this poison? An email I got from Apple yesterday telling me that version 2.0 of Qingwen has been rejected because of two reasons: one is a minor bug that I've fixed and that the email did not even have accurate reproduction steps for, but the second is the one I'm pissed off about. Apparently, they've "reviewed Qingwen Chinese Dictionary and determined that [they] cannot post this version of [my] iPhone application to the App Store because it contains objectionable content and is in violation of Section 3.3.12 from the iPhone SDK Agreement which states 'Applications must not contain any obscene, pornographic, offensive or defamatory content or materials of any kind (text, graphics, images, photographs, etc.), or other content or materials that in Apple's reasonable judgement may be found objectionable by iPhone or iPod touch users.' Please refer to the attached screenshots." Here are the screenshots they sent me:

I hope you're looking at the screenshots and thinking something along the lines of "you've got to be kidding me". I'm sorry, did I mention it's a dictionary? Dictionaries have words, all sorts of words, including, yes, swear words like "fuck" and also words like "penis", which of course is such a lewd word that I should be smited (well, technically, smitten) for having included it in Qingwen? And all of this somehow falls under their so-called "reasonable judgment".

It's hard for me to imagine precisely who Apple is trying to "protect" by keeping these words off the iPhone. But that's not even the right question to ask. My question is, can they keep these words off the iPhone? Of course not! As is clear from the screenshots, Qingwen doesn't bombard you with words like "cock" and "penis" the moment you start it up. No, the Apple employee who took those screenshots specifically searched for those words. As far as I'm concerned, it's the same thing as opening a website that contains swear words (like the page you're reading, for instance) on the iPhone. If they don't want Qingwen on the iPhone because it can show you "objectionable material", then why allow Safari, Mail, YouTube and pretty much any other app, which can easily show you all sorts of even more "objectionable material"?

But that's not all. First of all, Qingwen 1.0 contained most of the words they've pointed out in those screenshots as objectionable and it's on the App Store right now! In fact, it's been downloaded more than 20,000 times since it came out earlier this year. Not only that, but every competing app I know of contains all these same words and these apps are all out on the store gathering downloads. Meanwhile, Qingwen is stuck on what is now a completely outdated version 1.0, not because of some hairy bug that I haven't fixed, but because of some bullshit company policy.

Here I am sitting with this idiotic email from Apple, while users are going on the App Store, giving Qingwen bad ratings and writing it bad reviews, and I have this new version of the app that addresses nearly all of their issues and more just sitting on its ass. And this is another chord that Murray's post struck with me. Loads of "customers" on the App Store are just complete asses. They download your app, don't even bother playing around with it for five minutes or contacting the developer, but instead go and post a negative review on the App Store, talking about missing features that are not even in the list of new features in version 2.0 because they're there already in version 1.0! And it's for this reason that I am no longer going to be distributing Qingwen for free. It was an app that I made for my own use and thought it'd be nice if other people also got to use it, but you know what, I'm done dealing with all the freeloading jerks whose only job is to make my day worse. From now on, if they want to bitch about it, they at least have to pay me first. And for those who feel it's an app they like and is worth having, well maybe it wouldn't hurt for them to dish out about the same amount of money as it takes to buy a Crunch bar.

Anyway, that's enough raging for today. I want to end the post on a lighter note because, really, overall Qingwen has been a great thing for me. Not only is it my first real-world app, but it's also been way more successful than I ever imagined. As I mentioned, it's had over 20,000 downloads last I checked, and that's way, way more than I ever expected to have in its entire lifetime. Also, if you visit Qingwen on the App Store, you'll see that most people have written extremely gracious reviews and it's a great feeling to see other people appreciating what you've made even more than you yourself do. Reading these reviews and watching the downloads counter is a bit like an addiction–I want more and more happy users–and for Qingwen 2.0 I've added at least a couple of significant features that I don't really use myself but which others have requested. And that is something that I wasn't expecting to do at all when I starting developing it, because I kept telling myself it's an app made only to suit my needs and mine alone. This is all the more reason as to why I wanted Qingwen 2.0 to make it to the App Store as soon as possible, because this is really the first release that I've actually developed more for my users than for myself. So, I do hope Apple gets a little smarter about this whole process, and soon.

Labels: English, Mac

5 comments

This whole App Store relation with the developers comes across as, like you said, "you've got to be kidding me".

All those words they find offensive, they're there in the shipping Dictionary.app in Mac OS 10.5, and for good reason too. It's a dictionary for crying out loud! Maybe the reviewer should've checked the meaning of a dictionary before reviewing you app.

Congrats on finishing and shipping (on your part) 2.0!

By Prateek, at April 22, 2009 2:15 AM
I'm not sure why they've changed their behaviour since iPhone OS 2.0. I remember 'f**k' was a word that the iPhone's auto-correction dictionary supported before 2.0. If I reset the dictionary on my 2.x device, I immediately see the auto-correction suggestion 'duck' for the word.

Dictionary.com's app requires network access if users want to access everything they would find on a real dictionary. The other $3.99 'Dictionary' app that uses only a built-in word database doesn't have the word.

If this censorship is for the benefit of kids then they should allow apps to use the Restrictions feature on the OS(is this allowed already?).

This is just the beginning. I wonder how long this manual approval process is going to continue. I think there will be a saturation point where they will have to open up the App Store.

By Abhishek Nandakumar, at April 22, 2009 12:05 PM
As I sit here waiting on my own v2.0 release (the longest wait I've had since August 2008), the only words that come to mind reading your post are expletives. How many of us have dictionaries based on CC-CEDICT in the AppStore with all of those same entries? That's not to mention all of the other dictionaries based on whatever source that likely have the same entries.

What's your plan? Are you going to censor the entries or resubmit and hope you get a sane reviewer?

By Jason, at April 24, 2009 6:37 AM
Well all I have to say is that you have done some fine work with your app and I am sad that apple doesn't see that. I bout a palm a year ago for $150 and student edition Pleco dict for like $90, just so I can have the functionality you have in your app. I could have bought a touch AND your software for way less. Keep up the good work and don't let the app store keep you down!

By The Cat Family, at April 29, 2009 10:00 PM
I was wondering why this wasn't free anymore and now I know. But I am going to buy it anyway because it sounds to be the best and looks like you put lots of work into it!

By John, at May 25, 2009 7:50 PM

Post a Comment

VoiceOver in the iPod shuffle

The new iPod shuffle released today has VoiceOver which can read out songs, artists, albums and playlists to you and it supports a ton of languages. Apple has a little section at the bottom of this page which demos all the languages they have and all this makes me think is, "Hey, where are all these languages in Mac OS X?" For example, Mandarin Chinese is definitely not available in Mac OS X, but it is available on the new iPod shuffle. And the fact that Apple claims you'll hear different voices depending on whether you're synching from a Mac or a PC, makes me wonder... Are these voices stored somewhere on my Mac? Can I use them? Please?

Labels: English, Mac

0 comments

Post a Comment

The Inexplicable Safari 4

Yesterday, Apple released Safari 4 (Beta) out into the world. Although I can't say I can feel the speed boost Apple claims with Safari 4, I believe all the benchmarks conducted by a bunch of tech blogs and they all say it kicks every other browser into the netherworld with varying margins (Internet Explorer 7 receiving the worst kick) in terms of its JavaScript execution engine. I also love the fact that my URLs are now much better auto-completed as I type them (à la Firefox 3) and that the History is now more extensive. The new developer tools are also pretty amazing and I look forwarding to using them, especially if it eliminates the need to use FireBug for testing websites. Also, I really like the fact that someone finally came to their senses and made the Windows version use Windows UI widgets and not look completely disgusting.

However, I am saddened - yes, saddened - to see how much time has been wasted on what I feel are completely useless feature additions to Safari. I absolutely do not understand why Apple is trying to make Safari be Google Chrome. Has Chrome picked up a particularly good slice of the browser market? No. Have people really expressed the opinion that the Chrome's "tabs-on-top" UI is vastly superior to the regular tabs in other browsers? No. In fact, most people I know played out with Chrome for a few days and then relegated it to their pile of unused software. As with Safari 4, the only thing I liked about Chrome was under the hood, that is, the fact that every tab ran in its own process. As for all the "UI innovativeness" that Chrome brought to the market, I don't have much to say. I certainly fail to see its merits.

And that is why I feel that Apple has wasted a lot of precious effort for nothing. Not only do the tabs on top look ghastly to my eyes, but they also don't make my tabbed browsing experience even an iota more pleasant. The "Top Sites" feature, which is also a direct rip-off from Chrome, is again something that I initially thought I'd find useful; but it never ended up falling into my workflow, and, believe me, adding a cool 3D effect to it is not going to change that. It was also the first thing I turned off in Safari 4.

Then there's CoverFlow, which was the second thing I turned off. I honestly don't know if there was any significant thought behind this at all. CoverFlow in Finder already gave off the vibe of "eh... this is kind of superfluous" and in Safari it seems to be shouting "we made this cool thing called CoverFlow and we're going to shoehorn it into every new app we make." Even in iTunes, where CoverFlow originated, I only used it for the first couple of weeks and can easily count on one hand the number of times I've used it in Finder.

And most painful of all, why the hell did they take out the progress-in-address-bar? Not only is the progress bar an essential feedback element, but Safari's was also most ingeniously implemented.

Thankfully, there seems to be some hidden preferences that can bring back some of Safari 3's goodness. However, I feel that Safari 3 definitely trumps Safari 4 as far as usability and sheer UI elegance is concerned and the Safari team should think twice about making Safari 4's the standard UI. At the least, these hidden preferences should be exposed in Safari's Preferences.

Labels: English, Mac

3 comments

One reason the new tabs might look so strange is that they’re set in Helvetica, rather than Lucida Grande. Someone deserves a chance encounter with the cluebat for this.

Interestingly, Apple claims that Safari was the first browser to have a combination URL/progress bar. As far as I know, Opera (surprise) was first with that feature: I noticed it way back in Opera 2, but it just wasn’t shiny like Safari’s. Safari more clearly copied MSN Explorer, which used an identical design, featured in a series of “MSN butterfly” commercials aired nationwide.

Too bad the actual progress bar was removed. Safari’s progress bar was much more accurate than the ones in Firefox and IE.

I’m not surprised at the superfluous eye candy. Apple likes these things (cf. glassy Dock).

By Minh Nguyễn, at February 25, 2009 7:25 AM
i actually like the tabs on top because i get slightly more vertical space to display actual page content. i just wish they disabled click-through for those tabs because you can accidentally close them when switching from another window.

By James, at February 28, 2009 12:26 AM
spot on with the review of Safari 4.0
Even i had to revert back to the old progress bar in address bar thingy.
N even the tabs don't come out so easily.. U have to click on the top right ( diagonal Lines ) to take a tab out..
N in Safari 4, i dont think there's any way to stop a page while its loading. Even +. doesnt stop anything..
is any way out ?

I might be heading to back to safari 3 soon.. Damn

By Arjun Goel, at April 20, 2009 12:08 AM

Post a Comment

NSWindow and Animation

NSWindow, it seems, was never designed with the aim of supporting animation, which becomes slightly problematic when that's precisely what you're trying to do. This is the result of all the research I've done on NSWindow in the past few days because I was trying to do some animations with it, which proved to be a nigh impossible task.

So, what can you do in terms of animation with NSWindow? NSWindow supports a few basic animations - opacity, frame size, frame origin and frame rotation. If you want to change any of those and have the window animate the action, it will gladly do so. You can do those either using NSViewAnimation, through the setFrame:display:animate: method and perhaps even through the animator proxy. Try this Quickie to help you get started with simple window animations.

Beyond that short list, the next best thing you can do is to create the impression that you are animating the window. This allows your animations to be more flexible but not as smooth and well-blended as they would be were they being performed on the window itself. One way to animate things is using the Core Animation API that was introduced with Leopard. What you need to do to get things started though is a bunch of CALayers which Core Animation can animate. Now, these layers need to be inside something and, generally speaking, anything that you want to show on the screen needs to be inside a window. So, the solution is to create a transparent window the size of the entire screen and use that as your canvas, set that window's contentView to have a backing Core Animation layer and then add images of your windows (but not the windows themselves of course) as CALayers to this big transparent layer as sublayers. Here's some code that demonstrates that:

- (void)awakeFromNib {
    /* screenWindow is an IBOutlet hooked up to a borderless
       NSWindow window and this stuff should ideally be done
       by subclassing NSWindow and making a TransparentWindow
       subclass and putting this code in its -awakeFromNib */
    [screenWindow setBackgroundColor:[NSColor clearColor]];
    [screenWindow setHasShadow:NO];
    [screenWindow setOpaque:NO];
    [screenWindow setFrame:[[NSScreen mainScreen] frame] display:YES];
    [[screenWindow contentView] setWantsLayer:YES];

    /* Get the layer from this empty window */
    NSView *rootView = [screenWindow contentView];
    CALayer *rootLayer = [rootView layer];
    
    /* Create the layer that will animate */
    CALayer *fakeWindowLayer = [CALayer layer];    

    /* Get the window's (another IBOutlet) contents */
    NSBitmapImageRep *imageRep;
    [rootView lockFocus];
    imageRep = [[NSBitmapImageRep alloc] initWithFocusedViewRect:[rootView frame]];
    [rootView unlockFocus];

    /* Now set the layer's contents and add it to the layer tree */
    fakeWindowLayer.contents = (id)[imageRep CGImage];
    [rootLayer addSublayer:fakeWindowLayer];

    /* ... Now do some animation with this layer ... */
}

I don't know whether you picked up on it or not but I never autoreleased or released the NSBitmapImageRep, which was for a reason. The reason is that the CGImageRef we get back from the NSBitmapImageRep is actually half-hearted and is directly dependent on the NSBitmapImageRep, so much so that if the NSBitmapImageRep goes away and you try to access the data in the CGImageRef, your program crashes or you get junk on your screen. I'm currently working on it and trying to find a solution to this, but, for the time being, a memory leak it shall remain!

Anyway, at the end of that code segment, you have a CALayer that looks exactly like the NSWindow (minus the shadow) and can be animated at will. All you have to do now is to hide the actual NSWindow, animate your fake window, and, at the end of the animation, unhide the actual window and make sure it's where the fake window was last seen. Complicated, but so far the only way I've found to "animate" NSWindows.

Labels: English, Mac

1 comments

Yeah, it's a shame it can't be easier to do nice NSWindow animations. Thanks for the nice tips in this post, I found them very useful.

By Ted, at April 15, 2009 8:22 AM

Post a Comment

Dealing with NSArray "out of bounds"

NSArray being one of the most frequently used Cocoa classes and being out of bounds being one of the most common errors one would get with an array, I'd have thought that the NSRangeException which NSArray promises to throw if an out of bounds error occurs would trigger the debugger (or, alternatively, the application to crash in non-debugging mode). However, it does not do so. All that happens is that you get this in your Run Log and your stack unwinds:

*** -[NSCFArray objectAtIndex:]: index (2) beyond bounds (2)

The fact that such a basic but critical error (who knows in how many devious ways an application could mess with your data once it has a bad state that made it go out of bounds?!) defaults to being silently acknowledged and subsequently ignored unnerves me, and frankly, it annoys me, because, just like any other developer trying to make a half decent program, what you want to do at that point is to jump to the stack trace and see what went wrong. Now, since we're very unlikely to convince Apple to change basic functionality it hasn't touched in about eight years, it's time for workarounds.

The first question that should come to mind is, "What the hell is actually going on? Is the promised NSRangeException being raised at all or is the documentation just lying? Giving the documentation the benefit of the doubt and assuming that it is being raised, what in the world is happening to it before it reaches us?" This kind of reasoning led me to search for ways to catch exceptions in the debugger. Some Google searching revealed that setting a symbolic breakpoint at -[NSException raise] might do the trick. So, I did. And it didn't. Cleanly flew by that breakpoint as if it was a man raising his kilt to hitch a ride.

What next? Look for an even more basic call to catch exceptions. Going by the fact that most fundamental Objective-C runtime methods eventually go into C functions and going by the example of objc_msg_send, I discovered objc_exception_throw and set a breakpoint on it. Worked like a charm! And now I have that breakpoint always set because I, like any sane developer, wants to catch his exceptions before they reach the end-user.

Incidentally, why the exception was not being caught by setting a breakpoint at -[NSException raise] now came to me with breathtaking obviosity ("obviousness" just isn't cool enough). I looked into the documentation for NSException once more and looked at the stack trace once more (the stack trace that now appeared thanks to my breakpoint). NSException, as it turns out, has three methods which can be called to raise exceptions, and, apparently the other two (+raise:format: and +raise:format:arguments:) do not all eventually call into -raise. Now here's the most ludicrous thing about this affair; read this bit from the documentation for -raise:

All other methods that raise an exception invoke this method, so set a breakpoint here if you are debugging exceptions.

Wow, just outright lying. Very spiffy, Apple, very spiffy indeed. Undocumented exceptions about exceptions. Is this supposed to be some sort of geek humor? हे भगवान!

Labels: English, Mac

1 comments

WOW. Just wow. You, sir, are a savior to all programmers having to deal with NSArrays. I would go apeshit every single time I had an out of bounds error. I can now rest easy with this new weapon you have shared with the world.

By J.C. Subida, at July 27, 2009 5:04 PM

Post a Comment