Four things Apple needs to fix


1– Add iCloud versions/Time Machine or some other way of backup, once people migrate their data to iCloud traditional backup methods become impossible or at least highly impractical, add to that the ability to delete files from any device and the lack of backup starts to show all the signs of a usability nightmare.

I do not expect the majority of people to bump into this until they are deep into relying on iCloud for storage in the years to come, but they eventually will and
Apple should have something ready as soon as possible.

2– Fix iTunes (including AppStore, iBooks store etc) discovery and search, it is pretty much broken at the moment as plain text searches yield hundreds of results with irrelevant sorting by download counts.

Having so many featured and suggested categories is a weak solution and it makes no sense since it copies the model of the entertainment business which works totally different from that of software, it is no use to have billion apps in the store when the actual 0.1 of the apps get 99% of the users (just a illustrative estimation, not factually accurate)

It looks like they just copied their music store model piecemeal without giving it a second thought, and it should be pretty clear by now that a  custom approach is needed for the app stores, a good model to emulate would be Netflix, the way it works to highlight new or relevant movies to you, not just push the already hyped and popular blockbusters down your throat.

3– Fix AppleTV by adding the “passive” mode to every stream eg: shuffle for Music, play top Podcasts, play my Vimeo Feed, that is analogous to legacy TV behavior where we quickly select a passive stream (TV channel) with minimal effort, this has to be available in every content module in AppleTV, accessible with preferably a single user interface interaction/dedicated remote button

Preferably it should also be smart and pick content based the user is statistically probable to like, not just push the most popular content (see #2 above)

4– Fix OS X for the post-pc era by removing it’s features that were added specifically for the kind of audience that migrated to iOS devices.
Consciously and explicitly switch to a paradigm where they consider the users for OS X professional tech-savy users as opposed to the iOS users and start to design software accordingly, specifically adding more finesse to OS X and make it tend to the professional and technology savvy.

We have seen signs of this with the revival of Dock support for symlinks, Finder folder merge etc, but this should be made into a explicit direction for OS X in order to focus it on the post-pc users that are not merely using it for web browsing and content consumption.

With MountainLion they pretty much achieved the needed synergy between their two OS’es, from now on it is time to play on each individual one’s strengths.

Advertisements

basics of iOS and OS X API’s


The structure of OS X and iOS native* API’s is very straight forward/minimalistic, typically one does not need to know about anything that goes below the Foundation API however taking a look at the headers can help understanding it better and clearing common confusions between Foundation and CoreFoundation or what exactly constitutes CocoaTouch and Cocoa since the later is a explicit framework while the former is just a naming convention.

All the API’s are present as binary frameworks under /System/Library/Frameworks (with resources but without headers) and under your Xcode toolchain SDK (with headers but without resources) , the objc binary is at /usr/lib/libobjc.A.dylib while the headers are under /usr/include/objc/ and your Xcode toolchain.

I
Now let’s dig right into it, at the lowest level there is CoreFoundation and objc, they are independent of each other :

<objc/objc.h>
objc_class,objc_object,objc_selector etc

<objc/runtime.h>
objc_getClass,objc_getProtocol,class_conformsToProtocol etc

<objc/message.h>
super_class,objc_super,objc_msgSend,objc_msgSendSuper etc

(you can include all the above with #import <objc/objc-class.h>)

<CoreFoundation/CoreFoundation.h>
CFString,CFNumber,CFArray,CFRunLoop,CFStream etc (this is just C, there is no Objective-C syntax or anything at this level)

II
On top of these and including (relying on both) is Foundation, as the name implies you typically never use any API’s below foundation directly.

<Foundation/Foundation.h>
NSString,NSNumber,NSArray,NSRunLoop,NSStream etc, much of it is toll-free bridged to CoreFoundation

III
on top of Foundation there is AppKit for OS X or UIKit for iOS
(on OS X you typically include Foundation, AppKit and CoreData with #import <Cocoa/Cocoa.h>, there is no corresponding CocoaTouch shell framework on iOS)

<AppKit/AppKit.h>
NSView,NSButton,NSColor,NSEvent etc

<UIKit/UIKit.h>
UIView,UIButton,UIColor,UIEvent etc

This is pretty much all there is, from this on there are multiple optional frameworks you can use for specific cases, but the basics are just in the headers above, most API’s are Cocoa but there is still a big chunk of C API’s especially on the OS X side.

It’s worth nothing that there are two types of frameworks : private and public , the private ones are not safe to be used and not allowed in the Mac App Store , the public ones are safe to be used as long as they have headers in the SDK (they could be present in /System/Library/Frameworks but not in the SDK) typically such disparity is a rare occasion nowadays and it was more common prior to 10.6.

One more note is that public frameworks with headers might not have all their methods/classes documented, nevertheless using them should be pretty safe but the lack of documentation is a indication that they are more likely to change/go away than the documented ones.

*OS X and IOS also have the low level BSD API’s (found in /usr/include) most of which are cross-platform and outside the scope of this post.