Ipod Touch Review
# # 8 GB capacity for about 2,000 songs, 10,000 photos, or 10 hours of video # Up to 40 hours of audio playback or 7 hours of video playback on a single charge # Support for AAC, Protected AAC (iTunes Store) and other audio formats; H.264, MPEG-4,
Ipod Touch Review
# One-year limited warranty # iPod touch has 8 GB capacity for about 2,000 songs, 10,000 photos, or 10 hours of video. # iPod touch has a 3.5-inch (diagonal) widescreen Multi-Touch display with 960-by-640-pixel resolution (326 pixels per inch). › See more technical details.
Ipod Touch Review
# iPod touch has one-year limited warranty. # IPod touch plays up to 40 hours of audio playback or 7 hours of video playback on a single charge. # Motion JPEG video codecs in M4V, MP4, MOV, and AVI formats
Tampilkan postingan dengan label Other blogs. Tampilkan semua postingan
Tampilkan postingan dengan label Other blogs. Tampilkan semua postingan
Selasa, 21 Desember 2010
The Little Grashopper Blog
Well, I'm not sure how I never ran across it before, but Philip Rideout, author of O'Reilly's iPhone 3D (a book I recommended last week), has a hell of a blog for people interested in OpenGL. A lot of the posts are specific to desktop OpenGL (and recent versions of OpenGL at that!), but there's tons of great information that applies to OpenGL ES as well. It's a veritable treasure trove of advanced graphics goodness from a guy who's been doing it for years.
Minggu, 29 Agustus 2010
Core Dump
I've decided to create a second blog at http://jeff-lamarche.blogspot.com where I'll put any posts that are not related to writing iOS software, Apple, or the mobile software industry.
My first substantive post should show up some time this evening if all goes well.
My first substantive post should show up some time this evening if all goes well.
Rabu, 25 Agustus 2010
Beta Builder
A week or two ago, Jeffrey Sambells had a blog post about using Xcode's Enterprise distribution for ad hoc distribution. It's a great idea that a lot of developers saw had great potential, but it had several manual steps.
Since that post, Hunter Hillegas of Hanchor, LLC and developer of Vegas Mate, has created an application to automate the entire process. The app is called Beta Builder, and it's free. If you do much ad hoc distribution, you should check it out.
Since that post, Hunter Hillegas of Hanchor, LLC and developer of Vegas Mate, has created an application to automate the entire process. The app is called Beta Builder, and it's free. If you do much ad hoc distribution, you should check it out.
Senin, 02 Agustus 2010
Time Moves On…
Justin from CarpeAqua has an interesting rant this morning about pull-to-refresh. I don't expect everybody to like every new mode of interaction that gets introduced (I certainly don't), and I've been known to rant myself at times, but I must admit I don't quite get the fervor with which some people, like Justin, hate experimentation with new methods of interaction.
In his post, Justin sums up his feelings by quoting a tweet by Marco Arment that reads:
I've got news for you: There's almost nothing in life you can't say that about. If you're holding up the potential abuse of something as a reason not to use it, then you're making excuses for your own desire for things to stay as they always were. In the history of human innovation, there's almost nothing that couldn't be abused or put to an inappropriate use.
Sure, you can do this with Objective-C 2.0+:
Even the greatest interaction ideas can be mis-used and over-used and, in fact, they usually are. I'd almost argue that they have to be. All ideas get refined as they are used more. It's natural behavior to explore, expand, and find the limits of any new idea. Thought experiments are all well and good, but until you get a new mode of interaction in front of a lot of people to try it, all you've got is your best guess based on your own opinion. In other words, overuse of the novel isn't, in the scheme of things, a bad thing. Over time, the overuse ends and we're left with something we understand much, much better and that works really, really well.
Basically, we don't know how to use new concepts "properly" until they've been used a lot, in a lot of different ways, by a lot of different people. There's nothing to guide the use of the novel. There's no way to find what works and what doesn't except by trying. And sometimes the things we try won't work, or won't work for all people. Sometimes they'll be downright bad.
A lot of our current desktop interaction model, things that we think of as universal and standard, weren't always standard or universal. I can remember when ⌘C, ⌘X, ⌘V, and ⌘P did not automatically mean cut, copy, paste, and print on the Mac. It took several years for key commands to truly become standard and universal on the Mac. Heck, many early versions of Mac applications didn't make much use of key shortcuts at all, and when they did, they weren't at all consistent in which keys they used to do what. You can't dictate what works in user interaction. You have to put it out there, observe and listen, and be willing to change based on what you see and hear.
Personally, I like pull-to-refresh as it's used inTweetie Twitter. I find myself doing it in Mail.app, even though it doesn't work there. To me, it's the perfect gesture for the iPhone in apps where you're primarily consuming small chunks of content in a table, like your inbox or twitter apps. When I'm using apps of this nature, I'm often in one-handed mode, using my thumb to scroll. My thumb can't comfortably reach the entire screen (e.g. a refresh button in the navigation bar), and I don't want to bring my other hand over every time I want new tweets. When I'm in editing mode, I'm naturally using my other hand, and that's great, but if I'm standing in line at the grocery store or waiting to board a plane and I'm just reading my timeline, I like that I can just flick my thumb to get more tweets. It's a benefit to me to be able to work one handed. It's a nearly ideal form of interaction for the way I use the application most of the time. Obviously, I'm not the only one who feels this way. You don't see lots of people rushing to copy features that don't work or aren't liked.
In other apps, or especially on the iPad, pull-to-refresh doesn't seem like it would be a natural form of interaction, but I've never tried pull-to-refresh in other contexts, so I don't know. But developers will try it (and are trying it), and many uses of pull-to-refresh that don't work well will die. Either the application will fail to sell, or the author will decide to change it to something that works better for his or her users. But we might just discover new and wonderful uses for the concept in the process.
That's how this whole messy process works. That's how we get progress in user interaction. We try things. Sometimes they work, often they don't. If, as developers, we only use things that are tried and true, nothing will ever change.
Progress in user interaction, like anything else where hard-to-predict humans play a major role, is messy and slow and imperfect and no amount of ranting about it will change that fact. If we want progress... if we want to keep moving forward, that's the price we pay. You can get angry about it, but you can't change it. You'd have about as much luck arguing with the weather.
1 No, not really. That was a joke.
In his post, Justin sums up his feelings by quoting a tweet by Marco Arment that reads:
The problem, like gradients, reflections, animations, and PHP, is not that it's a bad idea but that many won't use it properly.This argument reminds me of the arguments I've heard against dot notation in Objective-C. It amounts to "somebody might use it poorly, therefore it's bad".
I've got news for you: There's almost nothing in life you can't say that about. If you're holding up the potential abuse of something as a reason not to use it, then you're making excuses for your own desire for things to stay as they always were. In the history of human innovation, there's almost nothing that couldn't be abused or put to an inappropriate use.
Sure, you can do this with Objective-C 2.0+:
someObject.release;That's a perfectly legal way to release an object. Most, including me, would argue that it's not a good way; it's likely to cause confusion and makes the intention of your code harder to read. But, just because you can do this doesn't mean dot notation is inherently flawed (though a vocal minority of Objective-C developers argue exactly that). The same thing goes for gradients, reflections, PHP, animations and, yes, pull-to-refresh. Actually, scratch that… PHP really is bad¹. But the rest of them aren't.
Even the greatest interaction ideas can be mis-used and over-used and, in fact, they usually are. I'd almost argue that they have to be. All ideas get refined as they are used more. It's natural behavior to explore, expand, and find the limits of any new idea. Thought experiments are all well and good, but until you get a new mode of interaction in front of a lot of people to try it, all you've got is your best guess based on your own opinion. In other words, overuse of the novel isn't, in the scheme of things, a bad thing. Over time, the overuse ends and we're left with something we understand much, much better and that works really, really well.
Basically, we don't know how to use new concepts "properly" until they've been used a lot, in a lot of different ways, by a lot of different people. There's nothing to guide the use of the novel. There's no way to find what works and what doesn't except by trying. And sometimes the things we try won't work, or won't work for all people. Sometimes they'll be downright bad.
A lot of our current desktop interaction model, things that we think of as universal and standard, weren't always standard or universal. I can remember when ⌘C, ⌘X, ⌘V, and ⌘P did not automatically mean cut, copy, paste, and print on the Mac. It took several years for key commands to truly become standard and universal on the Mac. Heck, many early versions of Mac applications didn't make much use of key shortcuts at all, and when they did, they weren't at all consistent in which keys they used to do what. You can't dictate what works in user interaction. You have to put it out there, observe and listen, and be willing to change based on what you see and hear.
Personally, I like pull-to-refresh as it's used in
In other apps, or especially on the iPad, pull-to-refresh doesn't seem like it would be a natural form of interaction, but I've never tried pull-to-refresh in other contexts, so I don't know. But developers will try it (and are trying it), and many uses of pull-to-refresh that don't work well will die. Either the application will fail to sell, or the author will decide to change it to something that works better for his or her users. But we might just discover new and wonderful uses for the concept in the process.
That's how this whole messy process works. That's how we get progress in user interaction. We try things. Sometimes they work, often they don't. If, as developers, we only use things that are tried and true, nothing will ever change.
Progress in user interaction, like anything else where hard-to-predict humans play a major role, is messy and slow and imperfect and no amount of ranting about it will change that fact. If we want progress... if we want to keep moving forward, that's the price we pay. You can get angry about it, but you can't change it. You'd have about as much luck arguing with the weather.
1 No, not really. That was a joke.
Minggu, 18 Juli 2010
A few things iOS developers ought to know about the ARM architecture
The Wandering Coder has a great post today titled A few things iOS developers ought to know about the ARM architecture. There's some really good information about the different ARM architectures in different iOS devices and different generations of certain devices. Well worth the read.
Senin, 12 April 2010
Can We Stop with the "Evil" Thing?
I always enjoy reading James Higgs' commentary on iPhone issues even though we often disagree on issues. That is true for today's piece entitled iPhone OS 4.0: Now With Added Evil. He makes some good points, many of which I disagree with, but, I have one big pet peeve with his post, which is…
…can we please stop with this trend of calling things we dislike or disagree with "evil"?
Evil is baby killing… pogroms… serial killers… the Jonah Brothers. You know, bad shit. Evil is not restricting the choice of languages you can use when you write software for a single software platform from a single vendor. My gosh, people. Talk about skewed, first-world perceptions! This is, at worst, "annoying", "frustrating", or maybe even "bothersome". It's certainly not "evil" in any reasonable sense of the word. It's not even immoral, unethical, illegal or fattening, no matter how much you may dislike it.
(Sorry, James - you're not the only one to do this, yours was just the proverbial straw that broke the camel's back)
I appreciate that people don't like the recent SDK agreement changes, and I even understand why. But let's keep some fucking perspective, can we? We all signed an agreement that said Apple could unilaterally change the terms of the agreement by giving us notice, and we were okay with that because we wanted to be part of the App Store. Now that Apple has actually gone and changed it a few times, people are whinging like the world is ending. The door's not locked, people. Feel free to leave if it gets too onerous for you. If you're not willing to man up the way Dan Grigsby did, then register your complaints using the bug reporter and move on with your life.
I don't always like the decisions Apple makes. I think the app store censorship is sucky, the review process is still too arbitrary, and 3.3.1 is worded more broadly than it should be. But none of those are bad enough to make me leave the platform. I like the platform, and there's still so much opportunity here that I definitely want to stay. So, I've lodged my complaints and have moved on.
I really don't want to get sucked into the argument about 3.3.1, but I need to point out that there is a valid reason why Apple would choose to do this. Even if you don't agree with their decision, you should at least acknowledge that it's not arbitrary (something I've seen as an implicit assumption in many of the rants and arguments against 3.3.1)
If you use Apple's provided tools and frameworks, when you submit your app, all the code that makes up your app is available. Apple controls part of it, and you control the other part. With an intermediate layer, there's a third chunk of code that's a black box. Apple can't get to it and you can't get to it, either. Have you noticed that we're also not allowed to build frameworks for the iPhone the way we can on the Mac. Same exact reasoning.
The changes Apple is having to make to the frameworks to accommodate the multitasking APIs in 4.0 offer a good example of why Apple feels they need to do this. I can't discuss technical details of 4.0, but I will say that by tweaking the frameworks and APIs, Apple has been able to maintain a surprisingly high level of backwards compatibility with older apps. Guess which apps aren't playing nicely with the new multitasking functionality?
Yes, it's about control, but no, it's not arbitrary or without reason. You are welcome to disagree with Apple's judgment, but don't assume the changes ares being done for arbitrary reasons: to spite Adobe or because Steve Jobs is in a bad mood.
Let's look at a hypothetical situation. Let's say that instead of the handful of Flash-generated apps that Adobe snuck onto the App Store, let's imagine that there are 5,000 of them. Let's also say that hypothetically, for some reason, Flash-generated apps don't work with 4.0, and Apple can't reasonably make them work with 4.01. When 4.0 is released and all of those apps break, who's going to end up looking bad?
If you responded with anything other than "Apple", you're delusional or, at least, don't understand customers. Customers don't know or care how their apps were made. They know that yesterday, their apps worked, today they don't and the only difference is that they updated to a new version of the OS. What's the logical assumption for somebody who doesn't know the underlying technical details to make? There's only one: That Apple's new OS sucks. Would it be an accurate assumption? No, but that's the perception people would be left with, and to Apple, customer perception is king.
1- Yes, Apple could work with Adobe to get the Flash Packager changed, but a) Apple has some reason to anticipate that Adobe would drag their heels, since they've dragged their heels for ten years on moving Creative Suite to Cocoa, and b) they'd have to test a good portion of the 185,000 apps on the App Store to even know which third party library was at fault, which just isn't practicable.
…can we please stop with this trend of calling things we dislike or disagree with "evil"?
Evil is baby killing… pogroms… serial killers… the Jonah Brothers. You know, bad shit. Evil is not restricting the choice of languages you can use when you write software for a single software platform from a single vendor. My gosh, people. Talk about skewed, first-world perceptions! This is, at worst, "annoying", "frustrating", or maybe even "bothersome". It's certainly not "evil" in any reasonable sense of the word. It's not even immoral, unethical, illegal or fattening, no matter how much you may dislike it.
(Sorry, James - you're not the only one to do this, yours was just the proverbial straw that broke the camel's back)
I appreciate that people don't like the recent SDK agreement changes, and I even understand why. But let's keep some fucking perspective, can we? We all signed an agreement that said Apple could unilaterally change the terms of the agreement by giving us notice, and we were okay with that because we wanted to be part of the App Store. Now that Apple has actually gone and changed it a few times, people are whinging like the world is ending. The door's not locked, people. Feel free to leave if it gets too onerous for you. If you're not willing to man up the way Dan Grigsby did, then register your complaints using the bug reporter and move on with your life.
I don't always like the decisions Apple makes. I think the app store censorship is sucky, the review process is still too arbitrary, and 3.3.1 is worded more broadly than it should be. But none of those are bad enough to make me leave the platform. I like the platform, and there's still so much opportunity here that I definitely want to stay. So, I've lodged my complaints and have moved on.
I really don't want to get sucked into the argument about 3.3.1, but I need to point out that there is a valid reason why Apple would choose to do this. Even if you don't agree with their decision, you should at least acknowledge that it's not arbitrary (something I've seen as an implicit assumption in many of the rants and arguments against 3.3.1)
If you use Apple's provided tools and frameworks, when you submit your app, all the code that makes up your app is available. Apple controls part of it, and you control the other part. With an intermediate layer, there's a third chunk of code that's a black box. Apple can't get to it and you can't get to it, either. Have you noticed that we're also not allowed to build frameworks for the iPhone the way we can on the Mac. Same exact reasoning.
The changes Apple is having to make to the frameworks to accommodate the multitasking APIs in 4.0 offer a good example of why Apple feels they need to do this. I can't discuss technical details of 4.0, but I will say that by tweaking the frameworks and APIs, Apple has been able to maintain a surprisingly high level of backwards compatibility with older apps. Guess which apps aren't playing nicely with the new multitasking functionality?
Yes, it's about control, but no, it's not arbitrary or without reason. You are welcome to disagree with Apple's judgment, but don't assume the changes ares being done for arbitrary reasons: to spite Adobe or because Steve Jobs is in a bad mood.
Let's look at a hypothetical situation. Let's say that instead of the handful of Flash-generated apps that Adobe snuck onto the App Store, let's imagine that there are 5,000 of them. Let's also say that hypothetically, for some reason, Flash-generated apps don't work with 4.0, and Apple can't reasonably make them work with 4.01. When 4.0 is released and all of those apps break, who's going to end up looking bad?
If you responded with anything other than "Apple", you're delusional or, at least, don't understand customers. Customers don't know or care how their apps were made. They know that yesterday, their apps worked, today they don't and the only difference is that they updated to a new version of the OS. What's the logical assumption for somebody who doesn't know the underlying technical details to make? There's only one: That Apple's new OS sucks. Would it be an accurate assumption? No, but that's the perception people would be left with, and to Apple, customer perception is king.
1- Yes, Apple could work with Adobe to get the Flash Packager changed, but a) Apple has some reason to anticipate that Adobe would drag their heels, since they've dragged their heels for ten years on moving Creative Suite to Cocoa, and b) they'd have to test a good portion of the 185,000 apps on the App Store to even know which third party library was at fault, which just isn't practicable.
Jumat, 05 Maret 2010
Pull to Refresh
Dr. Touch (aka Oliver Drobnik) has a great tutorial on implementing Tweetie's pull-to-reload table implementation.
Note: After I originally posted this link, I received a handful of e-mails expressing concern about the use of Tweetie 2's sound files in the original article. Oliver has since changed the article to remove those instructions and has also contacted Loren Bichter tp make sure he didn't have any objections to the post (Loren is the developer of Tweetie). After receiving the original e-mails, I pulled the link to this tutorial, but I feel comfortable that any concerns have now been addressed and there is some really useful information in the blog post.
Note: After I originally posted this link, I received a handful of e-mails expressing concern about the use of Tweetie 2's sound files in the original article. Oliver has since changed the article to remove those instructions and has also contacted Loren Bichter tp make sure he didn't have any objections to the post (Loren is the developer of Tweetie). After receiving the original e-mails, I pulled the link to this tutorial, but I feel comfortable that any concerns have now been addressed and there is some really useful information in the blog post.
Rabu, 17 Februari 2010
Opposite World
A lot of the web consists of reasonably well-written articles that lead off with sensationalist, often completely incorrect headlines designed to lure people to the site. I'm not a big fan of the approach, but there's no denying it's widely used.
Today, I ran across an article on the iPhone that was rather the opposite. I completely agreed with the headline and the basic underlying premise. Yet, I found myself scoffing (and sometimes giggling) at the rather ludicrous assertions sprinkled throughout what had promised to be a very reasonable and interesting article.
The premise of the article is that you can't beat the iPhone by copying it. Bravo. Obvious, but correct. You absolutely can't beat it that way. But, the rest of the article lauds phones that are basically doing just that and exhorts mobile device manufacturers to produce "almost as good" knock-offs of the iPhone with different form-factors. The disconnect here is hard to grasp. I half-expected the article to be penned by Henry Jekyll.
Here was the first gem of the article:
The article then went on to talk about the Samsung Wave, a phone that has been lauded by both Samsung and every single person that Samsung has paid to talk about it, as a "brilliant new smartphone". Here it is:

Whoo-boy! Ain't that original. That doesn't look like Samsung is copying the iPhone at all. I mean, there are, you see, three columns of icons, not four. And there's a couple extra hardware buttons. Oh, and it says Samsung at the top, and has a slight taper. I'm so glad they're not copying Apple, like even down to the reflection of the phone in the official photo because that would just be derivative. And sad.
According to the article, this phone "presents a challenge to the iPhone…" because it has the same form factor (even though it's not copying the iPhone), has an app store (which isn't copying Apple's at all), and also has similar hardware (but again, they're not, and I repeat NOT copying the iPhone in any way, shape, or form).
Now, the author of this article is a "long-time developer of mobile products", so I guess I shouldn't expect him to get why the iPhone has been a success. I mean, he is part of an industry that had their collective asses handed to them by Apple, a company with no prior experience in the mobile space. But I am honestly wondering is if he came up with the headline on his own. Because, despite all the inanity in this article, I still agree with the headline.
The next gem is this:
So, next, the author says:
The article then ends with this amazing bit of wisdom:
The author so obviously doesn't get it. He's almost as far away from getting it as is it's possible to fucking be. As long as the mobile device industry keeps thinking like this, they will continue to play second fiddle (and third, fourth, and eighth fiddle) to the iPhone (and any other company that does get a clue).
Here's a hint: It's the fucking user experience. It's not the features, processor speed, or form factor. The iPhone had less features when it came out then the Palm and Windows Mobile phones that were already available, and it wasn't any cheaper or smaller. The iPhone became a sensation because it was easy to use and intuitive. You never had to train yourself to its idiosyncrasies. You never had to learn how the desktop computing paradigms were mangled down to fit on a small screen. You just picked it up and used it, and it was fun.
Make your phones easy. Make them fun. Make them as stress-free as possible, even for the stupidest, most un-tech-savy users. If you make phones that are easier and funner, you just might get yourself back in the game. But as long as you think of phones as a commodity with your whole "feature, cost, size" crap, you're going to keep on sucking hard.
But, hey! At least y'all got headline right.
Today, I ran across an article on the iPhone that was rather the opposite. I completely agreed with the headline and the basic underlying premise. Yet, I found myself scoffing (and sometimes giggling) at the rather ludicrous assertions sprinkled throughout what had promised to be a very reasonable and interesting article.
The premise of the article is that you can't beat the iPhone by copying it. Bravo. Obvious, but correct. You absolutely can't beat it that way. But, the rest of the article lauds phones that are basically doing just that and exhorts mobile device manufacturers to produce "almost as good" knock-offs of the iPhone with different form-factors. The disconnect here is hard to grasp. I half-expected the article to be penned by Henry Jekyll.
Here was the first gem of the article:
The first iPhone was maybe not a great phone, particularly feature-wise, but it has been universally acknowledged as a huge step forward in phone design.What, pray tell, would constitute a "great phone", if not one that changed the industry and which the author himself acknowledged as "a huge step forward in phone design"? Are we judging against something that doesn't exist? Because if something is a huge step forward, it would seem, by comparison, to necessarily by "great" by any reasonable standard.
The article then went on to talk about the Samsung Wave, a phone that has been lauded by both Samsung and every single person that Samsung has paid to talk about it, as a "brilliant new smartphone". Here it is:

Whoo-boy! Ain't that original. That doesn't look like Samsung is copying the iPhone at all. I mean, there are, you see, three columns of icons, not four. And there's a couple extra hardware buttons. Oh, and it says Samsung at the top, and has a slight taper. I'm so glad they're not copying Apple, like even down to the reflection of the phone in the official photo because that would just be derivative. And sad.
According to the article, this phone "presents a challenge to the iPhone…" because it has the same form factor (even though it's not copying the iPhone), has an app store (which isn't copying Apple's at all), and also has similar hardware (but again, they're not, and I repeat NOT copying the iPhone in any way, shape, or form).
Now, the author of this article is a "long-time developer of mobile products", so I guess I shouldn't expect him to get why the iPhone has been a success. I mean, he is part of an industry that had their collective asses handed to them by Apple, a company with no prior experience in the mobile space. But I am honestly wondering is if he came up with the headline on his own. Because, despite all the inanity in this article, I still agree with the headline.
The next gem is this:
The iPhone has not yet reached a level of emotional attachment where it will be bought even when reasonable substitutes exist.Any person who could say this is somebody who has never spent time with any of the 50+ million actual iPhone users. I'm an iPhone user. I spent a week using the next best phone currently available: the Nexus One. The Nexus One is not a bad phone by any stretch of the imagination, but there's no way in hell I'm going to say "aw, well, I just want a phone, I'll give up my iPhone for something that looks similar but isn't a copy". I am very deeply attached to my iPhone, and so are the vast majority of iPhone users I've met. And it's not just Apple geeks and iPhone devs. I know many people whose computers run on Windows, yet they carry an iPhone and adore it. I know people who hate computers, who love their iPhone. But what is a "reasonable substitute"? A phone with similar specs? A similar form-factor? To put it bluntly: There are no "reasonable substitutes" currently on the market.
So, next, the author says:
The real turning point however, will be when developers stop trying to copy the iPhone’s design, and accept that they can create something unique and cool outside the iPhone’s form factor.Then:
Increasingly, manufacturers are doing just that…What? The manufacturers like Samsung? Let me know how that works out for you, 'kay?
The article then ends with this amazing bit of wisdom:
In 1997, the dominant phone in town was the Nokia 6110. Manufacturers found the only way to beat it was to create phones with different form factors, costs, and feature bases. From that, we saw innovation and segmentation in three key areas — features, cost, and size. We may just be in for a new wave of innovation.Wow. Just… wow. What was that quote about people who don't learn from history? Hello? McFly? You just stated how mobile phone companies competed before the iPhone. You just brought up the staid, pathetic business model that the iPhone obliterated. Trying to bring it back isn't going to work. You can't compete on cost and make a profit in the long term. You can't compete on size, because it's already possible to make phones that are smaller than it's practical to actually use comfortably. That leaves, according to this amazing bit of wisdom… features?
The author so obviously doesn't get it. He's almost as far away from getting it as is it's possible to fucking be. As long as the mobile device industry keeps thinking like this, they will continue to play second fiddle (and third, fourth, and eighth fiddle) to the iPhone (and any other company that does get a clue).
Here's a hint: It's the fucking user experience. It's not the features, processor speed, or form factor. The iPhone had less features when it came out then the Palm and Windows Mobile phones that were already available, and it wasn't any cheaper or smaller. The iPhone became a sensation because it was easy to use and intuitive. You never had to train yourself to its idiosyncrasies. You never had to learn how the desktop computing paradigms were mangled down to fit on a small screen. You just picked it up and used it, and it was fun.
Make your phones easy. Make them fun. Make them as stress-free as possible, even for the stupidest, most un-tech-savy users. If you make phones that are easier and funner, you just might get yourself back in the game. But as long as you think of phones as a commodity with your whole "feature, cost, size" crap, you're going to keep on sucking hard.
But, hey! At least y'all got headline right.
Jumat, 29 Januari 2010
Adobe's Unhappy
I was going to respond to Adobe's self-serving, biased, and not entirely factually accurate blog post, but rather than incur more wrath from the legion of Flash "developers", I'm just going to link to Chris Rawson's piece at TUAW.
Regardless of how the iPad does, with over 70 million iPhone OS devices in the world that don't run Flash, content providers who currently use depend on Flash HAVE to be looking at other options. In many cases, the other option will be an alternative instead of completely supplanting Adobe, but either way, it's good for the web.
Regardless of how the iPad does, with over 70 million iPhone OS devices in the world that don't run Flash, content providers who currently use depend on Flash HAVE to be looking at other options. In many cases, the other option will be an alternative instead of completely supplanting Adobe, but either way, it's good for the web.
Kamis, 28 Januari 2010
GizModo Also Knows About Not Sucking…
Since I linked to them when they denigrated the iPad, it's only fair if I also link to them when they do the opposite, so here it is. Good article.
Senin, 25 Januari 2010
Flash and Fireball
Daring Fireball's John Gruber and I don't see eye-to-eye on everything, but we do when it comes to Adobe Flash.
Selasa, 19 Januari 2010
Greatly Exaggerated
Several people today tweeted a link to this blog post from John Casasanta of Tap Tap Tap about the death of Mac software. It's an interesting, post, and I'm having trouble deciding if I agree with it or not. I don't want to agree, that's for sure, but there are many valid points made.
My gut reaction, though, from which the title of this post is derived, is to paraphrase Mark Twain by saying the rumors of the Mac Software industry's death have been greatly exaggerated.
One of the assertions in John's post is that iPhone developers don't want to go back and develop for the Mac because the iPhone SDK is "shiny" while Cocoa is "old and crufty". I can't speak for any iPhone developers but me, but I really would like to spend more time with Cocoa. In the nearly two years since I jumped on board the iPhone ship, a lot of really cool things have happened to Cocoa, many of which aren't available to us on the iPhone yet. Blocks, GCD, and OpenCL mean that there are huge opportunities for new Mac applications, and mature garbage collection and instance variable synthesis mean even shorter development times. Heck, there are huge opportunities just to compete with and replace existing consumer applications, never mind for writing new applications. Can you imagine a Photoshop competitor that fully leveraged these new technologies1? Larger companies like Adobe with huge Carbon-based codelines have quite a challenge ahead of them getting their older applications to be 64-bit clean and running on Cocoa, which is a requirement for leveraging much of the cool new stuff. The large corporate software powerhouses are floundering in terms of modernizing their mainstay apps. To say there's not an opportunity there seems wrong to me. It may not be as easy or convenient of an opportunity as represented by the App Store, but there's definitely opportunity.
The Mac's market share is also higher than it's been at any time in at least ten or fifteen years and it seems to be trending up. In terms of actual installed base size, there are more people using Macs than ever in history. Even among people who don't use or like the Mac, the realization that it's not a "toy" operating system is slowly dawning on even the most ignorant of Apple haters. Well, okay, maybe not the most ignorant, but certainly everyone else.
More people are using Mac, so it's hard to imagine how the Mac Software market can be dwindling. If it is, it's likely a failure to take advantage of the opportunities that do exist. Perhaps we're all blinded by the bright, shiny App Store. Maybe stuff's not selling because there's not enough being written or marketed. Maybe we're all still buying into the gold rush stories subconsciously.
There's no doubt that the App Store is a rousing success and that it makes it far easier to reach customers, but hardly every iPhone developer is making a great living at this. TapTapTap is one of the great success stories, and the view from that perspective is very different from the the perspective of developers I've talked to who haven't recouped even enough to have made minimum wage for their time investment in their application. More than one iPhone developer are are looking for greener pastures, though many are having trouble finding one.
I do agree with John on many of the points in his post, however. I agree that it would be great if Apple opened up the App Store to Mac applications, but also agree that it seems unlikely that Apple will do it because they wouldn't have the same level of control. I also sincerely hope that John and I are both wrong on that. I find it odd that I can go into iTunes and buy movies, music, iPhone apps, and even donate to the Red Cross, but I can't buy Mac apps there. I can't even buy Apple's own Mac apps there like iWork and iLife. Last year, I ordered the latest version of iWork, both a single license for my business and a five-license family pack for home. I was able to just buy a serial number for the individual license, but for the family pack, I had to have a box shipped across the country to me. There's something wrong with that picture. I should have been able to just go into iTMS, specify the licenses I needed, then have the software download to my machine automatically. By now, we should have just as seamless and smooth of a buying experience for Mac applications as we do for movies, music, television shows, and mobile apps.
Even without a Mac App Store, though, opportunity is there in the Mac software world. In some ways, the opportunities are better than they've ever been because the potential audience is larger than ever and many of the people who are qualified to create quality Cocoa apps are myopically focused on the iPhone right now. Yes, there's more work involved with Mac apps. You'll have to find a distribution path. You'll have to advertise. You'll have to arrange a payment mechanism. But there are so many targets begging for a good competitor right now, and so many new as-yet uncreated markets that can now exist because of the amount of processing power we can easily leverage in Cocoa. There are many big, slow, corporate-owned, Carbon-based crappy-ass apps that keep making money because they have tons of cash to advertise and because there isn't a viable alternative or, at least, people aren't aware that there is a viable alternative.
We all started on a level playing field in the iPhone nearly two years ago. In fact, it wasn't even level at the start; smaller companies and individuals had the advantage of agility. Hell, a large corporation like Adobe or EA can't decide to enter a new market in the time that some of the earliest iPhone applications were designed, developed, and shipped. Heck, a large corporation often can't even decide who should decide to enter a new market in the time that many iPhone apps were written. TapTapTap was smart enough and capable enough to take advantage of that opportunity, but people entering the iPhone market today have to compete with the big names and the established small names.
Even though the distribution situation is considerably better on the iPhone than on the Mac, the overall competitive landscape really isn't all that different when you look at the market as a whole. How many of the top-ten grossing games right now are titles from big-name companies? Usually, it seems to run between seven and ten of the top ten are big-name titles. On the other hand, what percentage of successful Mac titles are produced by independents? I have to believe it runs at least 10-30%, and I would guess it runs higher.
I don't see the markets as being nearly as different as John does for somebody starting from ground zero today. There are differences, certainly, but there's plenty of room for success — and failure — in both markets.
1- Actually, I can. A couple of years ago, I abandoned Photoshop for Acorn, which is a native Cocoa image editor that rocks. There are a few features that some design professionals might need that it doesn't have (e.g. CMYK support), but what it does, it does so much faster than Photoshop CS4 that it's not even a close race, and yet it costs a fraction of what Photoshop costs. And think about this: Acorn is mostly written by one person. Compare that with the names in Photoshop's dialog box.
My gut reaction, though, from which the title of this post is derived, is to paraphrase Mark Twain by saying the rumors of the Mac Software industry's death have been greatly exaggerated.
One of the assertions in John's post is that iPhone developers don't want to go back and develop for the Mac because the iPhone SDK is "shiny" while Cocoa is "old and crufty". I can't speak for any iPhone developers but me, but I really would like to spend more time with Cocoa. In the nearly two years since I jumped on board the iPhone ship, a lot of really cool things have happened to Cocoa, many of which aren't available to us on the iPhone yet. Blocks, GCD, and OpenCL mean that there are huge opportunities for new Mac applications, and mature garbage collection and instance variable synthesis mean even shorter development times. Heck, there are huge opportunities just to compete with and replace existing consumer applications, never mind for writing new applications. Can you imagine a Photoshop competitor that fully leveraged these new technologies1? Larger companies like Adobe with huge Carbon-based codelines have quite a challenge ahead of them getting their older applications to be 64-bit clean and running on Cocoa, which is a requirement for leveraging much of the cool new stuff. The large corporate software powerhouses are floundering in terms of modernizing their mainstay apps. To say there's not an opportunity there seems wrong to me. It may not be as easy or convenient of an opportunity as represented by the App Store, but there's definitely opportunity.
The Mac's market share is also higher than it's been at any time in at least ten or fifteen years and it seems to be trending up. In terms of actual installed base size, there are more people using Macs than ever in history. Even among people who don't use or like the Mac, the realization that it's not a "toy" operating system is slowly dawning on even the most ignorant of Apple haters. Well, okay, maybe not the most ignorant, but certainly everyone else.
More people are using Mac, so it's hard to imagine how the Mac Software market can be dwindling. If it is, it's likely a failure to take advantage of the opportunities that do exist. Perhaps we're all blinded by the bright, shiny App Store. Maybe stuff's not selling because there's not enough being written or marketed. Maybe we're all still buying into the gold rush stories subconsciously.
There's no doubt that the App Store is a rousing success and that it makes it far easier to reach customers, but hardly every iPhone developer is making a great living at this. TapTapTap is one of the great success stories, and the view from that perspective is very different from the the perspective of developers I've talked to who haven't recouped even enough to have made minimum wage for their time investment in their application. More than one iPhone developer are are looking for greener pastures, though many are having trouble finding one.
I do agree with John on many of the points in his post, however. I agree that it would be great if Apple opened up the App Store to Mac applications, but also agree that it seems unlikely that Apple will do it because they wouldn't have the same level of control. I also sincerely hope that John and I are both wrong on that. I find it odd that I can go into iTunes and buy movies, music, iPhone apps, and even donate to the Red Cross, but I can't buy Mac apps there. I can't even buy Apple's own Mac apps there like iWork and iLife. Last year, I ordered the latest version of iWork, both a single license for my business and a five-license family pack for home. I was able to just buy a serial number for the individual license, but for the family pack, I had to have a box shipped across the country to me. There's something wrong with that picture. I should have been able to just go into iTMS, specify the licenses I needed, then have the software download to my machine automatically. By now, we should have just as seamless and smooth of a buying experience for Mac applications as we do for movies, music, television shows, and mobile apps.
Even without a Mac App Store, though, opportunity is there in the Mac software world. In some ways, the opportunities are better than they've ever been because the potential audience is larger than ever and many of the people who are qualified to create quality Cocoa apps are myopically focused on the iPhone right now. Yes, there's more work involved with Mac apps. You'll have to find a distribution path. You'll have to advertise. You'll have to arrange a payment mechanism. But there are so many targets begging for a good competitor right now, and so many new as-yet uncreated markets that can now exist because of the amount of processing power we can easily leverage in Cocoa. There are many big, slow, corporate-owned, Carbon-based crappy-ass apps that keep making money because they have tons of cash to advertise and because there isn't a viable alternative or, at least, people aren't aware that there is a viable alternative.
We all started on a level playing field in the iPhone nearly two years ago. In fact, it wasn't even level at the start; smaller companies and individuals had the advantage of agility. Hell, a large corporation like Adobe or EA can't decide to enter a new market in the time that some of the earliest iPhone applications were designed, developed, and shipped. Heck, a large corporation often can't even decide who should decide to enter a new market in the time that many iPhone apps were written. TapTapTap was smart enough and capable enough to take advantage of that opportunity, but people entering the iPhone market today have to compete with the big names and the established small names.
Even though the distribution situation is considerably better on the iPhone than on the Mac, the overall competitive landscape really isn't all that different when you look at the market as a whole. How many of the top-ten grossing games right now are titles from big-name companies? Usually, it seems to run between seven and ten of the top ten are big-name titles. On the other hand, what percentage of successful Mac titles are produced by independents? I have to believe it runs at least 10-30%, and I would guess it runs higher.
I don't see the markets as being nearly as different as John does for somebody starting from ground zero today. There are differences, certainly, but there's plenty of room for success — and failure — in both markets.
1- Actually, I can. A couple of years ago, I abandoned Photoshop for Acorn, which is a native Cocoa image editor that rocks. There are a few features that some design professionals might need that it doesn't have (e.g. CMYK support), but what it does, it does so much faster than Photoshop CS4 that it's not even a close race, and yet it costs a fraction of what Photoshop costs. And think about this: Acorn is mostly written by one person. Compare that with the names in Photoshop's dialog box.
Jumat, 23 Oktober 2009
Marble Madness?
The developer of Stone Loops, a marble game that used to be available in the App Store, has a very discouraging tale to tell in his blog today. Obviously, this is only one side of the story, but it does seem very suspicious to me that MumboJumbo only made these hefty claims of improper and illegal activity to Apple and not in any other forum (like, say, legal proceedings) nor have they leveled the same complaint about the multitude of previously existing platform version of Stone Loops. If Code Minions had really stolen code (among the things alleged from MumboJumbo), it seems like they would be taking more serious action than just complaining to Apple, that is, unless they don't have sufficient evidence to meet the standard of proof anywhere else, but if that's the case, then Apple shouldn't have removed a competitor's application without being shown proof.
I'll refrain from judgment until I hear the other side of the story, but if things are as laid out in Maciej's blog, then Stone Loops should be restored to the App Store immediately. On top of that, Luxor should be pulled from the store just as immediately, as punishment for making unfounded allegations about a competitor. I'd even go so far as to consider pulling MumboJumbo's developer privileges if this is true, and it were my call to make. I have no tolerance for underhanded tactics, especially when resorted to by companies failing to compete on their merits (I'm looking at you, Nokia).
Again, we don't know the whole story now, because neither Luxor nor Apple has addressed Maciej's allegations yet, so let's not pull out the torches and pitch forks just yet. You might want to sharpen the pitch forks, though, just in case. Apple is unlikely to make a public statement about this; it's just not their style, but MumboJumbo, at very least, should respond.
Personally, I think Apple should impose a new policy. When someone makes an allegation of impropriety about a competitor, they should pull both apps until it's resolved. After resolution, the prevailing party's app goes back on the store, the other does not. This may seem harsh, but it would make people think twice about leveling accusations unless they have substantial proof to back up their claims. Of course, this only works if Apple also puts in a mechanism to expedite resolution of conflicts and they may just not want to get into that business. But, as sole gatekeeper of the sole way to sell iPhone applications, they should have expected conflicts of this nature to arise and should be willing to deal with them in a fair and expeditious manner.
I'll refrain from judgment until I hear the other side of the story, but if things are as laid out in Maciej's blog, then Stone Loops should be restored to the App Store immediately. On top of that, Luxor should be pulled from the store just as immediately, as punishment for making unfounded allegations about a competitor. I'd even go so far as to consider pulling MumboJumbo's developer privileges if this is true, and it were my call to make. I have no tolerance for underhanded tactics, especially when resorted to by companies failing to compete on their merits (I'm looking at you, Nokia).
Again, we don't know the whole story now, because neither Luxor nor Apple has addressed Maciej's allegations yet, so let's not pull out the torches and pitch forks just yet. You might want to sharpen the pitch forks, though, just in case. Apple is unlikely to make a public statement about this; it's just not their style, but MumboJumbo, at very least, should respond.
Personally, I think Apple should impose a new policy. When someone makes an allegation of impropriety about a competitor, they should pull both apps until it's resolved. After resolution, the prevailing party's app goes back on the store, the other does not. This may seem harsh, but it would make people think twice about leveling accusations unless they have substantial proof to back up their claims. Of course, this only works if Apple also puts in a mechanism to expedite resolution of conflicts and they may just not want to get into that business. But, as sole gatekeeper of the sole way to sell iPhone applications, they should have expected conflicts of this nature to arise and should be willing to deal with them in a fair and expeditious manner.
Selasa, 20 Oktober 2009
Wil Shipley on Internationalization and Localization
Words of wisdom and free code from the Godfather of Cocoa, Wil Shipley. Go read now. Nuff said.
Senin, 12 Oktober 2009
Why Objective-C Survives
Matt Gallagher, who maintains the excellent Cocoa with Love blog, has an interesting post today on the differences between the Simula and Smalltalk object models including a short discussion of the history of the two models. Objective-C uses the Smalltalk object model, most other compiled OO languages today (C++, Java, C#) follow the Simula model.
Jumat, 09 Oktober 2009
A Neat KVC Trick
Uli Kusterer has a neat little hint today on his blog with a safer way of specifying keys in KVC and KVO.
Selasa, 06 Oktober 2009
What an Apple Offer Looks Like
No, I don't have an offer from Apple, but someone else does, and it's pretty damn cool to see what it looks like.
via CocoaGeek on Twitter
via CocoaGeek on Twitter
Rabu, 30 September 2009
PatrickJ Interviews Loren Brichter
An interesting and apparently amicable end to the Twitter 2 controversy? It sorta looks that way.
Not everyone will agree, but I think now people have a better understanding of the situation Loren was in and the reasons he made the decision he made.
Not everyone will agree, but I think now people have a better understanding of the situation Loren was in and the reasons he made the decision he made.
Critical Thinking from Critical Thought
This is an excellent blog post by David Whatley of Critical Thought Games. I was already bummed about not being at 360 iDev (the first was awesome), but I really would have liked to have been in the audience for David's talk, especially to watch the crowd's reaction.
I've been known to grouse about things from time to time, but I also try to keep a sense of perspective and not lose sight of just how amazing this thing that Apple has enabled with the App Store and iPhone SDK is. David does it better. Well worth a few minutes of your time to read this.
I've been known to grouse about things from time to time, but I also try to keep a sense of perspective and not lose sight of just how amazing this thing that Apple has enabled with the App Store and iPhone SDK is. David does it better. Well worth a few minutes of your time to read this.
13.55
ipod touch review

