Tag Archives: iphone

Smartphone religion

Stephen Hackett of 512 Pixels, commenting on a Wired essay by Mat Honan:

“Maybe it’s just the headache I’ve had since the Samsung Galaxy 4 event or the fact that Apple’s turning up the heat, but I find the increasingly defensive views held in the technology community increasingly offensive.”

I got into the Mac in the 1990s during the lead-up to Apple’s certain doom, so I spent quite a lot of time arguing with Windows users. The problem with the new version of that debate, Apple vs. Samsung and the smartphone wars, is that I’m not sure it’s ever going to end. There are good phones on either side, the pundits can’t wait for Apple to fail but Apple is strong, and there’s no hope to escape the noise for those of us who just want to build some apps.

Watermark for iOS

I have a new iPhone app in the store: Watermark Mobile, a lightweight companion app to Watermark, my search and archiving tool for Twitter and ADN. It’s free for existing customers, or $4.99 using in-app purchase to subscribe as a new Watermark customer.

With this app I wanted to solve two problems:

  • Clean, simple search interface on the iPhone.

  • Allow paying for Watermark inside the app with your iTunes account.

While I’d eventually love to have a more full-featured client like Tweet Library available for Watermark, after a quick weekend of hacking I decided that Watermark Mobile was already useful enough that I should release it. So I did.

I hope iAd fails

I feel bad admitting it, because some of my friends are betting on iAd revenue to feed their family, but I’m just not on board with Apple running an advertising network. I don’t want to see ads in my apps, and I don’t want Apple to ever lose even a little of what it means to be a product-driven company.

We talk about this on Core Intuition. Nearly every chance I get I like to point out that all these free Google apps come at a cost. Take this tweet from last year:

“Google Voice is so awesome but I just think it’s dangerous to give Google this much power. Slippery slope, folks. You are not a customer.”

And this comment on MetaFilter:

“If you are not paying for it, you’re not the customer; you’re the product being sold.”

Some apps should absolutely be ad-suported (such as a search engine or social network), and many can be freemium (free versions supported by higher-priced subscriptions), but when given a choice I’d rather pay a fair price for a good service. When your customers are not your users, the product will suffer.

I know the world is full of ads already. We’re used to it — numb to it, maybe. But think about what the App Store has done: millions of people are paying real money for apps that complement ad-supported web sites. These same people would never pay a subscription fee to use the web site, but they’ll pay a few bucks for the same features in an iPhone app and it seems perfectly normal.

Do we really want to give that marketplace up? Because once it’s gone, and iAds are the norm, it will be an uphill battle to get anyone to pay for anything.

iPhone 4

Alright, it’s been 2 weeks. How does the iPhone 4 hold up?

For me, there was less urgency to this launch then for previous iPhone releases. I wanted the 3GS on day one (video recording!) and of course I waited all afternoon for the original iPhone (shiny!). Likewise I couldn’t wait for the iPad. This time I viewed iMovie and FaceTime as the killer apps. Sign me up!

But I wasn’t willing to wait all day. I tried the same approach that had worked great for the iPad: show up late in the day after the madness has settled down. No luck this time. I waited about half an hour, then came back before closing and waited a couple more hours to get a voucher for the next day. Total wait time about 3.5 hours over 2 days and 3 visits.

To get it on day 1, most people waited 6 hours. I’m sure “John Gruber’s story on Flickr”:http://www.flickr.com/photos/gruber/4731689070/in/contacts/ was common too.

This was Apple’s most poorly-managed launch I’ve been to. The 3GS line was pretty fast. For iPad it was extremely quick — in and out in half an hour. I mostly blame the extra step of requiring activation in-store, but there were enough problems that I think this whole thing was mismanaged somewhere.

Some of the inconsistent messages I heard depending on which Apple Store employee I talked to:

  • AT&T activation is not the bottleneck / yes it is.

  • We are selling 30 phones every 10 minutes / no idea how long the wait is.

  • We’ll shut down the line at 7pm and give out vouchers / staying open until 2am.

  • Vouchers will allow you to skip everyone else in line the next day / you’re guaranteed a phone but have to wait in line.

I also “collected a few tweets about the launch”:http://tweetlib.com/manton/iphone4.

Anyway, the phone. It’s the best phone I’ve ever seen. No question.

Now that some time has passed, I think I can comment on the reception issue. It’s real. Outside my house, I don’t notice it. But my street is a notoriously bad dead zone, and while I don’t get any more dropped calls than I used to, I can no longer hold the phone in the palm of my left hand when using mobile Safari. It’s pretty frustrating because I’ve been holding the phone this way for 3 years. It’s awkward to break the habit.

Having said that, I’ll close with the same thing I told strangers who came up asking about the phone. It’s easy to overlook the reception issue because of how great the rest of the phone is, and all existing iPhone users will love the iPhone 4. Eventually I’ll just cave in and buy a bumper.

New iPad hackers

My first reaction when I started reading “The Kids Are All Right”:http://daringfireball.net/2010/04/kids_are_all_right on Daring Fireball was: Well, I had to disagree with a John Gruber essay eventually, might as well be this one. There was no developer program fee when I started building Mac apps! You could write whatever you wanted and share it with friends.

But then I thought more about the $99 hurdle. What was I doing as a teenager and would the procedures Apple has in place now have stopped me? (For context, I’m 34.)

I started programming for the Mac with THINK Pascal, a beautiful little development environment. Then I moved to C with Dave Mark’s book, which came with a C compiler on a floppy inside the back cover. Eventually I saved up and bought Symantec C++. Even at an educational discount these were expensive compared to the free Xcode of today.

At that point I’m pretty heavily invested in the Mac, but the killer was the documentation. I’m sure I spent hundreds of dollars on “Inside Macintosh”:http://en.wikipedia.org/wiki/Inside_Macintosh books. Our senior year in high school, my friends and I would meet at a restaurant before class for coffee and breakfast. I remember I’d get there early and sit in the booth with one of my oversized volumes of Inside Mac, taking in too much caffeine for my own good while I devoured every page, even the advanced topics that were still over my head.

I lived and breathed this stuff pretty heavily for a few years. To imagine letting a $99 iPhone dev fee and some locked-down APIs prevent me from building apps is laughable. Great computers inspire people to build new software. That’s how it was when I got my first Mac, and I’m sure it’s that way for the new generation of young iPhone and iPad tinkerers.

One day I hope the App Store will be more open. But it is what it is. I’ll point out where I think Apple can improve, and then I’ll build and ship anyway. It makes no sense to sit around and complain on my blog about the good old days while some kid half my age is taking his or her idea all the way to the top of the App Store and owning the platform of the future.

Quiet rejections, no big news

It appears I was too optimistic “in my last post”:http://www.manton.org/2010/03/24hour_review_times.html about the App Store getting better.

The iPhone version of Snowtape, in development for months, “was rejected”:http://www.vemedio.com/blog/posts/134 because it could let users record and share audio from the internet:

“His sole words were, that there are lots of things missing in the SDK agreement and that they can not foresee any circumstance that leads to a denial of an app. That’s right! We did not violate any paragraph of the SDK, yet they forbid us distributing our app.”

The developer removed the ability to transfer audio files off the phone and then Apple let the app through.

Then there’s this post “on the developer forums”:https://devforums.apple.com/message/190892 about an iPad app rejection because they recreated a UI innovation from the new Photos app. Apple said:

“The application uses a tap and a pinch to expand feature that is present in Apple iPad Applications. This action is associated solely with Apple applications, and we kindly ask that you update your app appropriately.”

I’ve been doing a bunch of iPhone and iPad development this week. The more I work with it, the more I love the platform. But it just takes a couple rejections to sour the whole experience.

And yes, I realize I’m posting this on one of the most exciting days in the history of the App Store. The first round of iPad apps hitting the store today look fantastic.

Fast customer support

Three years ago “I wrote the following”:http://www.manton.org/2007/02/customer.html about customer support:

“Most people who buy Mac software from independent developers know that it’s only 1-5 people behind the company. We can’t compete with the Microsofts and Adobes of the world on application size, but we can compete on quality customer service. _Being small is a competitive advantage_.”

Seems reasonable, but the fact is that many small companies are struggling to keep up with the support load. “Jesse Grosjean recently downgraded”:http://blog.hogbaysoftware.com/post/468160055/support-expectations his support expectations for customers. From the official site:

“I’ll answer basic questions and license key/order issues as fast as I can. I also appreciate larger questions and feature suggestions, but I’m finding that I no longer have time to answer them all as I used to (mostly). I promise to read and consider everything, but you may not get an individual response.”

I’m a huge fan of Jesse’s TaskPaper and his minimalist approach to Mac development. He is very honest with customers and encourages participation starting with early beta versions.

But it can be damaging to set support expectations too low. Here’s what a support page says about support in “Pastebot”:http://tapbots.com/software/pastebot/, another one of my favorite iPhone apps:

“We try our best to answer every support question. But please make sure your question hasn’t already been answered in our FAQ. If you email us with an issue that has already been explained in the FAQs, we may skip the email.”

This seems slightly backwards to me. The questions in the FAQ are the easiest to answer! I respond to those immediately. It’s the hard questions for which I don’t have a good answer yet that usually take the longest time or are more likely to fall through the cracks.

Is the weight of support for iPhone developers just too much? TaskPaper and Pastebot are both very popular. I guess we can all hope to be successful enough that we find out.

Meanwhile, I had a question for “Beanstalk”:http://beanstalkapp.com/ yesterday and received a response in just 19 minutes and an additional follow-up response in under 10 minutes. I like to show off impressive companies, so I tweeted how fast their response was. “Their answer”:http://twitter.com/Beanstalkapp/status/11270045214 to my tweet? “We’re usually faster.”

Yep, that’s the right attitude. Set your standards high.

24-hour review times

I noticed a couple tweets last month about fast, less than 24-hour review times for iPhone app submissions. After I tweeted it, a whole bunch of other people came forward with similar stories. Apps going from submission to ready-for-sale in 12 to 24 hours.

The App Store is still fundamentally broken in many ways, possibly beyond repair depending on who you talk to, but there’s no question that fast review times are great for developers. Even if the progress stops with this, it’s a significant improvement to the App Store process.

Is it just for established devs? Just for minor bug fixes? It’s not the latter, since some of these were brand new apps. The question is whether this was a change for a certain class of developers and apps or whether it represents an overall speed-up to the review process, and maybe even a hint at prepping for the iPad launch.

Review times are a big deal and they’ve gone mainstream. Opera Mini has a very public “count up”:http://my.opera.com/community/countup/ widget as part of their extensive pre-approval hype. You can tell from the demos that Opera put a huge amount of work into polishing Mini before submitting it, to remove as many potential objections as possible, and to get users excited before it ships. A high-profile rejection now would erase any goodwill that Apple has built up recently.

I know some developers are nervous with openly discussing or blogging about their relationship with Apple, but I think more people should follow Opera’s lead. By being vocal on the App Store’s strengths and shortcomings, we force Apple to be more transparent. Bad press has a proven history of leading to overturned rejections. The narrative of the last few months, to me, is that the App Store is getting better, and I don’t think it would be happening without the critics.

iPhone patents

“Wil Shipley on Apple’s decision”:http://wilshipley.com/blog/2010/03/open-letter-to-steve-jobs-concerning.html to be aggressive on their iPhone patents:

“But when you sue someone for doing something you do yourself, you become one of the bad guys. Can you name a company _you_ admire that spends its time enforcing patents, instead of innovating? Remember the pirate flag you flew over Apple’s headquarters when you were building the Mac?”

And “my tweet on this”:http://twitter.com/manton/status/9886138112 from yesterday:

“This iPhone preemptive patent war is going to backfire. You’re losing the battle for our hearts and minds, Apple.”

Whether Apple wins this patent lawsuit or not doesn’t even matter; the old Apple many of us fell in love with is dead and maybe never coming back. I still want to think of Apple as the company that fights the good fight, innovating and putting user experience first. But you have the App Store exclusivity and rejections, and now you have the patents.

It’s a shame they’ve gone so far off course. Regardless of market share and billions in revenue, I’ll always hold Apple to a higher standard than every other mega corp, and hope not just for better products but also for leadership and doing what’s right.


My quote from “Cult of Mac”:http://www.cultofmac.com/i-have-been-hit-by-a-love-taser-devs-speak-out-on-ipad/28435 sums up my feelings about the iPad from a business perspective:

“I was so annoyed with the closed nature of the App Store that I stopped developing for the iPhone. The iPad will still have those frustrations, but the large screen opens up a whole new class of applications. It’s impossible to resist.”

Will there be a “Clipstart”:http://www.riverfold.com/software/clipstart/ for iPad? I hope so. This platform will be the future for plenty of customers. Apple lived up to the hype not because of the hardware or distribution or anything entirely revolutionary, but because of the software. Splitviews and popovers. Keynote and Pages. These apps are just as competent as their desktop versions.

Daniel and I talked about the iPad for most of “Core Intuition 26”:http://www.coreint.org/2010/02/episode-26-theres-a-pad-for-that/.

Bodega bootstrap

I wrote the following before the iPad was announced. The world may have changed since then, but I’m posting it anyway. Enjoy.

I like the content but not the title in “John Casasanta’s blog post about the so-called death of Mac software”:http://www.taptaptap.com/blog/iphone-software-sustainability-and-the-death-of-mac-software/. He shares some great stats and lays out the case for why iPhone development is more appealing and successful for him, but that doesn’t make the Mac dead. What he really meant and says later is that it’s dead to him.

For those of us who love writing Mac software and who don’t feel the pull of get-rich-quick blockbuster apps, the Mac is alive and remains just as healthy as it was before the iPhone was announced.

That’s not what I want to write about, though. The real question is how do we learn from the App Store and expand the market for Mac software. Compared to the iPhone, the Mac has a fragmented application discovery and an inconsistent purchasing experience.

When Keith Alperin and Rick Fillion “talked on the MDN Show”:http://www.mac-developer-network.com/shows/podcasts/mdnshow/mdn017/ about a possible Mac app store, Rick revealed some interesting numbers from “Bodega’s”:http://appbodega.com/ installed base: 80,000 downloads and 10,000 active users. They’re not 1.0, and I don’t see anything wrong with these numbers, but it’s not big enough yet to make an iPhone-like impact on how we buy Mac software.

What Bodega does have is a technology head start. “My products”:http://www.riverfold.com/ have been listed there since launch, and they have a polished application and feature-rich backend for tracking releases and collecting usage metrics. The key is solving the chicken-and-egg problem of getting the Bodega app in everyone’s hands.

There are two approaches: either get people excited about installing Bodega because it’s useful for updating existing apps (which it is), or sneak a copy of Bodega on to many more Macs (which is what this post is about). This solution isn’t perfect, but short of Apple building a real Mac App Store or a marketing giant like MacHeist getting involved, it’s the only idea I can see working.

First, start with “PotionStorefront”:http://github.com/potionfactory/potionstorefront. There are a few of these in-app purchase frameworks out there, but I like the “Potion Factory’s aesthetic”:http://www.potionfactory.com/thehitlist/ and Potion Store is popular. The web service used to submit orders could be supported by other custom store backends, including Bodega’s own purchasing system when they have it.

On top of this in-app purchase foundation, you bundle a subset of the Bodega application discovery UI directly into the framework. Users can download and install demo versions of new apps without leaving the catalog. Think of it as a “lite” version of Bodega, streamlined to fit inside everyone’s app. You also include the full Bodega application so that it can be launched and optionally installed in the user’s applications folder.

What you’ve effectively done here is give everyone who buys a third-party app access to a new store where they can discover other apps. It’s compelling for developers because the more companies that participate, the wider their reach becomes. And it’s great for users because over time it starts to create a consistent user experience, and familiarity reduces the effort in buying Mac software.

Some tricky issues remain, though. You don’t want to distract users from buying their first application, or muddle that app’s branding, and you want to later encourage users to find or be notified about new applications without it looking like an advertisement. The challenge is in finding a balance that most developers would want to use.

Back to the iPhone’s success, from a post by “Guy English”:http://kickingbear.com/blog/archives/67:

“People, lots and lots of people, people who have no idea what software even is, will download Apps like they’re snacking on potatoe chips. What’s my proof? Well, two million downloads of an App in a week supports that and I’d argue that a total of three billion Apps downloaded backs up my argument too.”

We’ve never seen anything like it, and I’m really happy for my friends who have had success on the iPhone. Luckily, the iPhone and Mac don’t actually compete. The App Store can sell ten thousand times the amount of software as the Mac does and it doesn’t change the fact that Mac users need software too. It’s our job as developers to continue to provide solutions for users and help those users find us.

iPhone giveaway wrap-up

I was reminded by “Nick Bonatsakis on Twitter”:http://twitter.com/nickbonas that I never wrote about how giving away the iPhone worked out. The short answer is: pretty well! The longer answer follows.

I’ve conducted 3 giveaways for Riverfold Software now:

  • Nintendo Wii, back when they were in short supply. You could enter by sending a message to “@wii”:http://twitter.com/wii or by entering your email address and sharing the link with a friend.

  • iPhone 3GS, plus year of Vimeo Plus and Flickr Pro. That’s what I’ll talk about below.

  • New Super Mario Bros Wii game. Probably the simplest giveaway, all I asked is that you give me your email address and optionally sign up for my newsletter.

In all cases I had two goals: do something fun for potential customers, and give the press an excuse to write about my products. By that metric all the giveaways were successful.

I noticed when originally giving away the Wii that most of the entries were Windows users — people who couldn’t even use my application! So for the iPhone giveaway I made a change: you could only enter by downloading the app and choosing a special menu item, which loaded a simple webview with the entry form. Pretty straightforward, and no complaints. The total number of entries was lower, but they were targeted to existing or potential customers.

In additional to sending news about the giveaway to a few contacts who I hoped would pick up the story, I also wrote a formal press release for it, which “went out through prMac”:http://prmac.com/release-id-6861.htm. This is so inexpensive that it’s hard to find fault with it, but I think the main outcome was getting contacted for advertising on sites that I had never heard of before.

Another thing to remember is to set up a “system to track referrers”:http://www.manton.org/2008/09/tracking_sales_referrers.html through to sales, so that you can judge the effectiveness of these giveaway-style marketing efforts. I could tell right away that it paid for itself, but it wasn’t a significant bump in overall weekly stats. I do believe it helps long-term though.

The final part I took pride in was shipping quickly. Growing up we all had the wind knocked out of our sails by the “allow 6-8 weeks for delivery” fine print on cereal box prizes or other mail-in gimmicks. If nothing else, I made an effort to ship the next day if possible, and I paid for express shipping.

Giving away stuff is fun. Until I get sued for not following some obscure rule on contests because I didn’t hire a lawyer, I’ll plan for more giveaways in 2010.

Worthless apps

I like “this article on Mobile Orchard about the relationship between price and ratings”:http://www.mobileorchard.com/app-store-heresies-higher-price-better-ratings-dont-discount-your-app-at-launch/:

“Customers with some skin in the game carry a psychological pressure to feel that they’ve been wise in their purchases; they’ll tend to over emphasize their positive feelings.”

This makes sense to me, and the other side of pricing that’s so important is the message you send. The perceived value of a product is connected to the published price. This is especially true in the App Store, where there’s no way to try the software before purchasing it. The price sets expectations.

So to take the Mobile Orchard analysis a little further: no one feels guilty judging a free app harshly with a 1-star rating because even the developer thinks the app is literally worthless.

Sure, there are good reasons to have a free app. To complement another paid service or desktop app, as a demo for a game or full version, or to “make $125,000/month in ad revenue”:http://fingergaming.com/2009/12/02/paper-toss-developer-earns-125000-in-monthly-ad-revenue/. In fact half the ideas I had for iPhone apps would have been free. But I don’t think any of that changes the truth of what Mobile Orchard said, that free stuff isn’t respected as much as something the customer is personally invested in.

The only 2 fixes for the iPhone platform

I let my iPhone developer account expire last week. Even though I had already stopped development on my iPhone projects, officially letting go of even the temptation to build for the iPhone platform has really helped me focus.

The Rogue Amoeba rejection for Airfoil Speakers Touch has been covered on Twitter and at Daring Fireball, but I think it’s easy to get distracted by legal technicalities and not the heart of the matter: as long as Apple is the gatekeeper, there will be bad decisions and apps that deserve to be approved will be rejected instead. For this reason the App Store cannot be fixed with incremental improvements.

There are only two possible solutions:

  • Accept all applications. Joe Hewitt, the developer of the Facebook application who this week also quit the App Store, has written well on this solution.
  • Allow applications to be installed on the phone without being listed in the App Store. Both Android and the Palm Pre support this model.

There is no third or fourth solution. There is no compromise or small improvement to the review process. Better transparency or tiered support options won’t help either. Without either of the above two changes, rejections will continue because in a subjective review process there will always be bad judgement calls. Some percentage of indie developers will abandon the iPhone either because the risk is too great or based on principle alone.

Let me take the second one (allow applications to be installed without being listed) because it plays directly to this Rogue Amoeba rejection. Rogue Amoeba is one of my favorite Mac companies, and Daniel Jalkut and I record Core Intuition using their Audio Hijack Pro app. It’s universally regarded as great software.

It might surprise you to find out that Audio Hijack Pro is not listed in the Apple Downloads site, though other Rogue Amoeba products such as Fission, Nicecast, and Airfoil are. I’m not sure Rogue Amoeba has ever spoken on the record about this, but Apple apparently doesn’t like the app and won’t list it. Maybe because you can use it to record copyrighted music? Who knows.

But it doesn’t matter because being rejected from Apple Downloads doesn’t mean you can’t make Mac software! It just means you have to market the software yourself. Rogue Amoeba has to work extra hard to get the word out about the app, but their business won’t fail just because Apple doesn’t give it their blessing.

This is so important for a small company. I want my software to fail because it sucks, or is buggy, or doesn’t have the right features, not because Apple can shut me down over a minor difference of opinion.

There are a lot of well-intentioned suggestions for improving the App Store, but the result will always be the same until we acknowledge the root problem. The only fix is for Apple to remove itself as gatekeeper, or let us route around them.

It’s okay to ignore the iPhone

I talked in “Core Intuition episode 22”:http://www.coreint.org/2009/08/episode-22-not-just-a-hobby/ about how I’ve stopped working on my indie iPhone apps. Mike Ash is also done with it. “He writes”:http://www.mikeash.com/?page=pyblog/the-iphone-development-story-one-year-later.html:

“I have abandoned the platform. Apple’s nonsense is just too much for me. There’s no joy in iPhone development, and an enormous amount of frustration.”

Reading through the comments got me thinking. I’m not abandoning the iPhone just because the App Store is such a frustrating environment to run a business in, or that I have a bunch of real work I could be doing instead of playing games with Apple. It’s also because most of the apps I would write have already been done, and in some cases done very well.

I love having a small computer in my pocket and mine is full of third-party apps. I’m thankful for the developers who are coming from other platforms and focusing all of their attention on the phone. And they are thrilled to be an a platform that is such a step up from traditional mobile development. The financial success stories of developers hitting on a great idea and it just taking off in the App Store are real and inspiring.

But the iPhone doesn’t need me.

As a user there’s no way I’ll give up the phone, but as a developer I can focus my time on “things that I have control over”:http://www.riverfold.com/, and add value to places where no one else has a good solution. Perceived gold rush or not, stretching myself too thin with both iPhone and Mac development is a great way to fail at both.

Imagine for a moment that “Yellow Box for Windows”:http://www.cocoadev.com/index.pl?YellowBox wasn’t killed off — that we could build Windows apps using Cocoa. Should I make my apps cross-platform just because it’s Objective-C? No. Writing software for a platform I don’t use would be like still supporting Mac OS X 10.2; there’s no way I’m going to boot into that thing to test and fix my app.

If you’re a Mac developer, my message to you is the same: just because the iPhone is awesome and runs on Objective-C does not mean you are required to build software for it. Maybe your time would be better spent refining old apps or building new ones on the Mac. Maybe… the iPhone doesn’t need you, either.

Image Capture API

In “episode 21 of Core Intuition”:http://www.coreint.org/2009/07/episode-21-the-tyranny-of-commit-access/, I called the Image Capture API “quirky”. What did I mean by that? A few things.

Refcon. This should be familiar to anyone who has built Mac OS 9 or Carbon apps. I’ve certainly written plenty of code that stuffed a pointer to an object in the refcon field of a structure or passed to a callback method. It’s an essential pattern for being able to integrate C++ or Objective-C objects with a C-based API.

For Image Capture, the code might look like this:

  ICAGetDeviceListPB pb = {};

pb.header.refcon = (unsigned long)self;

OSErr err = ICAGetDeviceList (&pb, YourDeviceListCallbackHere);

Then in the callback you cast the refcon back to your controller object and go about calling methods and accessing member variables.

  void YourDeviceListCallbackHere (ICAHeader* pbHeader)


YourController* ic = (YourController *)pbHeader->refcon;

[ic doSomethingUseful:pbHeader];


Works fine, but what about 64-bit? The reason I noted this part of the API to blog about was because the first version of my code accidentally cast my pointer to a UInt32. Luckily for us, the refcon is actually declared as an unsigned long instead, so it should share the same pointer size in 64-bit land, where long and void* are both 8 bytes. Other data types in Image Capture, such as ICAObject, are declared to be UInt32.

(What would we do if the refcon was UInt32? The solution is not terribly difficult: use a simple lookup table that maps a random ID or incrementing number stored in the refcon to your 64-bit compatible pointer. But this just doesn’t seem to be necessary very often.)

No delete function. I found this one strange, and had to dig in example code to find the solution. There is no first-class function in Image Capture for deleting objects off of a camera. Apparently this isn’t a feature that is supported by all devices, but nevertheless it seems common enough that it deserves something more than an enum constant hidden in a secondary header file.

Here’s how you go about deleting a video off of the iPhone:

  ICAObjectSendMessagePB pb = {};

pb.header.refcon = 0;

pb.object = (ICAObject)your_movie_id_here;

pb.message.messageType = kICAMessageCameraDeleteOne;

OSErr err = ICAObjectSendMessage (&pb, NULL);

Bad delete on success design. Related to the above, Image Capture has this trick that seems clever at first but which I don’t think could be used for most applications. You can set a flag to tell Image Capture to delete a video after it imports. Maybe this also explains why there’s no standalone delete function, but the design feels dangerous to me; if an import fails halfway through importing 10 videos, the first 5 will still be deleted. I much prefer to examine the imported files to make sure they were saved correctly, and then after everything was successful go back and delete the imported objects.

It’s been a couple months since we recorded Core Intuition 21, but there are some other segments worth noting. Daniel and I talked about the WWDC 2009 session videos, a plug for “rooSwitch”:http://www.roobasoft.com/rooswitch/, beta testing MarsEdit 3, and a listener question about working for non-developer managers. Listen at coreint.org or “subscribe in iTunes”:http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=281777685.

Crippled iPhone LGPL

I mentioned on the “latest Core Intuition”:http://www.coreint.org/2009/08/episode-22-not-just-a-hobby/ that I no longer have any plans to release my own iPhone software. While that decision is mostly based on my unwillingness to give Apple so much control over my business, and frustrations with the App Store process in particular, there are a handful of technical reasons why iPhone development is not a good fit for me. Here’s one: open source.

“Daniel Jalkut’s essay on the GPL”:http://www.red-sweater.com/blog/825/getting-pretty-lonely hits all the points about how the GPL can hurt developers by discouraging commercial participation. I’ve used LGPL projects in both “Clipstart”:http://www.riverfold.com/software/clipstart/ and “Wii Transfer”:http://www.riverfold.com/software/wiitransfer/, and I am careful to use them correctly. But iPhone development presents an interesting problem.

Can’t run command line tools. Separating the GPL code into a command line tool that is inside your application bundle is a common way to get around licensing issues. This is not allowed in the iPhone SDK.

Can’t replace dynamic libraries. The LGPL says that you can also link to libraries at runtime, but the catch is that the user must be able to replace an LGPL library with a newer version of their choosing. There is no way for normal users to do this on the iPhone.

Can’t use private frameworks. Oh, that point above about dynamic libraries? Actually it’s a moot point because Apple requires everything to be statically linked anyway. So you are blocked at every pass; you can’t ship an app that loads code dynamically even if the user could touch it.

The only solution I’ve seen so far is to release a special version of your Xcode project, with most of your application split into compiled libraries instead of source code, and allow developers with the iPhone SDK to relink your application with a different copy of whatever LGPL code you used. I stopped researching this when I put my own iPhone projects on hold, though. It’s just another example of how the closed nature of the platform creates an unnecessary burden in the software development process.

Clipstart for iPhone?

You know it has been a good conference when you come back inspired, with ideas and tools to build new things. No surprise that WWDC was like that for me, as it is pretty much every year.

Even before the keynote was over I was getting questions — which continued all week — about whether I had iPhone plans. At the very least, Clipstart 1.1 needs to be able to import videos off of the 3GS. “That’s in beta now”:http://www.riverfold.com/forums/topic.php?id=26. But what about a native phone app?

I’ve convinced myself over the last couple weeks, after listening to what people are doing with their phones and evaluating the existing applications in the App Store, that Clipstart for iPhone would be a very useful app. Video on the 3GS is a big deal. Eventually I can see a new top-level Video category in the App Store, and whoever is in that list is going to do very well.

“Neven Mrgan”:http://mrgan.tumblr.com/post/124025728/wwdc-2009 sums up the urgency:

“I’m sure Phil Schiller’s prediction of iPhone 3GS quickly becoming the most popular video-capable phone — if not the most popular consumer video device period — is right on the money. A message for those working on apps that help us shoot, edit, organize, and share quick, casual video clips: get ready to get busy.”

I’ll admit that after WWDC I panicked, thinking for a moment that I had to deliver Clipstart for iPhone immediately, and drop everything I’m doing to make that happen. I no longer believe that. The Mac version of Clipstart has a lot of potential and I can’t get too distracted from following up on that. But at the same time I will be expanding what I do on the phone, so we’ll see where that goes.

Apple competition in iPhone 3.0

There’s always the risk when developing for Mac OS X that Apple will compete directly with your product. iTunes, Mail, and Safari are high-profile examples, as well as the “lightning strikes twice” hit of Watson/Sherlock and Sandvox/iWeb. That history is “well documented”:http://www.karelia.com/news/small_and_nimble_the_long_s.html so I won’t repeat it here.

But when listening to the “Macworld podcast”:http://www.macworld.com/weblogs/mwpodcast.html a week ago (the episode with Dan Moren and Jason Snell back from the iPhone 3.0 announcement) it struck me that iPhone software is a little unique. They made the point, which I think is true for most software, that Apple’s offering is usually simple, full of holes that could be filled with new features from third-party developers. There is usually room for a developer with a unique twist on an idea to market and sell his solution to like-minded users, even if Apple ships a default good-enough app for most people.

Except there’s one pretty significant problem, especially on the iPhone. Apple cheats.

Third-party apps cannot run in the background. So it doesn’t matter how many features a recording app has that Apple won’t bother to implement, background recording is the killer feature that will always remain out of reach for developers.

Put another way, if the Apple app didn’t record in the background and a third-party app could, that third-party app would likely be worth $5-10 to many people for that one feature alone. But give Apple background recording and it doesn’t matter how many features another app adds — syncing music, FTPing to a server, multiple tracks, sound effects, more file formats — it’s going to be a challenge to convince users they need two recording apps. I expect some audio developers to overcompensate by adding every feature listed above and more to make up for the one feature they can’t have.

App Store new version UI

Centralized app update notifications on the iPhone were a great idea, right? Turns out, maybe not. My App Store icon has a “26” badge on it. I have no idea which apps have a new version available until I click and scroll through the list, or use iTunes. The reality is that at least 3/4 of them are for apps I downloaded but don’t use very often. I now have to set aside some time to weed through this list of apps.

I’d much rather get a friendly reminder of a new version when I launch the app itself — maybe even outside the app’s control, near the top of the screen just like when a phone call is in the background. There are a few apps I use every day that were updated weeks ago, but I continued to use an old version because the notification was lost in the noise of dozens of other junk apps.