App Store: Try Before You Buy

Some time ago, I wrote about "The Cruel Economy of the App Store". This article was echoed in TUAW and Business Week, among other media. Since then, Apple has introduced several important changes that will improve both the developers' and the users' experiences:

- Different sorting options per category.
- Multiple screenshots available in the device when browsing the App Store.
- No voting / comments allowed for people who have not purchased or downloaded the application. This will prevent users from leaving destructive, uninformed comments that do not really help other users make purchasing decisions, nor the developer in crafting a better product.
- No shifting in category sorting when updates are released. This avoids confusion to the final users, as they always look at the latest released applications. In addition, it is no longer possible to trick the system with simple, unimportant updates whose main purpose was just to relocate the apps at the beginning of the list.

These changes are very much welcome, and I do believe they are steps in the right direction.

However, the improvements are not enough. The App Store is populating at a very fast rate. When it launched it had around 550 applications, whereas it hosts more than 10,000 today. That is, in only 4 months the number of applications is 20 times what it was at launch, and it continues to grow on a daily basis: according to AppShopper, around 100 apps are added every day.

This rapid growth is a challenge for all App Store stakeholders. First of all, for Apple: they need to manage, review and approve all the new apps and the corresponding update cycles in an efficient and consistent manner, doing so quickly and applying common criteria to similar cases. What's even more important, Apple is probably extremely interested in promoting high quality apps to keep their lead in the thriving mobile computing platform race and once again, they need to do it consistently and coherently to keep their independence. I would anticipate that one of the top priorities for Apple at this point should be to listen to developers' technical feedback, in order to identify potential extensions to the API, evolutions and other improvements. Keep in mind that one of the most anticipated new features in the API -the ability to receive push notifications- was announced long before it was ready, probably to respond to concerns from the developer community about the implications of not having such mechanism.

Developers also need to deal with such a rapid growth: they are seeing their apps drowned in a sea of apps from others, and it is becoming more and more difficult to differentiate their products in the eyes of the customers. Since users would choose what apps to buy based on just a simple description, a screenshot and a price tag, price soon became the single most important mechanism to market your app inside the App Store. As Craig Hockenberry pointed out, the problem now is that there's a strong tendency to lower prices all the way down to $0.99 - as a consequence, not even price will be enough to differentiate apps any more.

Lastly, users suffer from such a formidable response to the App Store in terms of uncertainty. It's fantastic to have literally dozens of competing apps for any interest area; however, users can only see a uniform, flat offer of similar apps with similar screenshots, similar descriptions and similar prices. It's thus becoming more and more difficult to ensure you buy the app that meets your needs the most, or the one you find easiest to work with, or the one that has those little details you love, or the one that launches faster, or the one you think is simply most beautiful.

Trying

There are many things that Apple can do to adapt to the new situation, helping users and developers at the same time. As they have already demonstrated, I'm sure they will be working on many areas of improvement; however, I would like to stress what we believe is the single most important missing feature in the App Store: a "try before you buy" mechanism.

Such a mechanism should be part, we believe, of the official SDK. It would allow developers to offer trial versions or trial periods for their products in a snap, since the App Store would handle the specifics of downloading, expiration checking and upgrading. Users would be able to list the applications in trial, with details about how many days there are left and what features (if any) would be disabled if the user chooses not to upgrade. The App Store would allow the user to purchase "the license" that would allow the application to be properly registered and keep operating normally thereafter.

This is a model that has been in place for many years in the shareware market, and is perfectly understood by consumers and developers. An additional advantage of implementing it in the App Store would be the coherence and consistency of the user experience - trial policies, once defined, will be shared by all apps.

Our experience - Sketches Trial

Since we are firm believers of this principle, we actually prepared and submitted a special "Sketches Trial" version to the App Store on October 18th. Unfortunately, it was rejected two weeks later, on the grounds that they could not accept our trial because "the application must be a fully functional app and cannot reference features that are not implemented or up-sell to the full version".

From our point of view, our concept was not in conflict with that. Our idea was simply to allow the user to try the application for a few days, without any limitations at all. After the trial period was over, the user could still use some of the features in Sketches, making it act more like a "Sketches Lite" version they would get for free.

What surprised us the most is that the rejection email actually encouraged us to create a free Sketches Lite version, as many others do, but the trial concept was out of the question. What we don't understand is, why is it better to offer a "crippled" lite version, instead of a fully functioning one that some days later transforms into the same lite version? We are proud of the variety of features we've implemented in Sketches while maintaining the ease of use, and we'd like our prospective customers to see and try all of them - that's the only way they can fully evaluate and appreciate the usefulness of the product. In contrast, a "lite" version would necessarily offer a subset of the functionality, and therefore users would get the wrong idea about the capabilities of the product, or they would be constantly nagged about the limitations that do not exist in the full version. We believe those alternatives are clearly inferior.

The Road Ahead

We believe that the addition of a "try before you buy" mechanism would be a terrific improvement to the App Store, since it will encourage customers to try all the apps they want - hence, sales will be informed ones, satisfaction will be much higher and prices will be easier to match to product features. Our idea to offer our own trial mechanism was clearly an interim solution until Apple delivers global trial capabilities. They are in the perfect position to apply all the well-known shareware practices in a consistent, reliable and easy to use way, and we have no doubt they will be considering this improvement.

We'd like this blog post to be seen as a small contribution towards the improvement of an already awesome platform. If you, as a developer or a customer, agree with us, don't hesitate to express your comments or digg the story :)

License delivery delays

EDIT: Everything seems to have gone back to normality now, and we are receiving PayPal events in a timely manner again. All licenses should be out now, please write to us if you haven't received yours yet.

----

PayPal is undergoing a systems maintenance period today, and we are experiencing delays in receiving transaction data for Xslimmer and Snapshot. We will be processing licenses manually during this period, so they might take a little longer to reach you than usual. Thanks for your patience and understanding.

We'll post an update as soon as the service is fully restored, or follow us in Twitter for the latest news.

iPhone Programming Tips: building Unix software

The NDA that was part of the agreement between Apple and registered iPhone developers was lifted yesterday. Not an hour had gone by before other developers started to share tips, code or even full frameworks. Like them, we'd also like to contribute some of the learnings we've found during our work with Apple's SDK.

We've decided, therefore, to write a second piece in our internationally acclaimed iPhone Programming Tips series. Our first article, devoted to image orientation techniques, was written during our jailbreak apprenticeship, before the NDA even existed - how's that for anticipation?

This time we'll explore a very different area: how to build a Unix source package in such a way it can be used as part of your iPhone project.

The Problem

So you've found this wonderful open source Unix package that perfectly handles one of the areas you need in your application. Being a publicly scrutinized, well-maintained library, you decide you would waste your time if you tried to do something similar, so you try to use it in your project and concentrate on your own features. Or maybe you simply want to test how this thing would work in the iPhone. Whatever your reasons are, you download the distribution and read the INSTALL file. This package is so well designed it compiles under a zillion Unix variants, including many evolutionary dead ends. It includes a fancy "configure" script that guesses everything it needs to know to configure itself properly. Apple's Developer Tools include a full gcc/make toolchain, so you perform the sacred ritual "./configure; make" and presto, you obtain an Intel dynamic library ready for use!

Wait a minute, that's not what you need. You want to cross-compile for ARM so that it runs on the device, of course. And you need it to run in the simulator, too.

Being a resourceful, tough programmer, you drop the source code on your Xcode project, alongside the rest of your code. You build your project and get like 148 errors and 57 warnings. Naturally, there are lots of definitions that ./configure should have defined, and the source defaults must be those of a PDP-11, or something. You try to tweak the settings manually for 10 minutes before you give up.

Your next step is to tell the configure script to cross-compile for a different platform. But you don't know exactly how to tell it your platform is like Mac OS X, only running on an arm chipset, what's the problem about that. After reading the scripts and template files and googling your way around, you use something like ./configure --host=arm-apple-darwin. This doesn't work, either, because configure insists on using your standard Mac OS X system libraries and headers instead of the ARM ones for the iPhone. You then try to tell configure to use the gcc compiler in your /Developer distribution, and this still doesn't work. Oh, well. You know what you need to do - investigate compilation options and library locations - but it's painful.

Wouldn't it be nice to have some notes on how to set up your environment to compile an Unix package from the command-line, but using Xcode's development libraries for the iPhone?

The Solution

If you have read the introduction above, you will have noticed that it is just a feeble attempt to disguise the fact that this article is only going to tell you how to configure your environment variables to compile a Unix library using Xcode's toolchain from the command line. That's it. It is admittedly not a very glamourous or innovative task; however, we still had to devote a few lenghty hours to set everything up properly, following the embarrassing steps outlined above, one after the other.

So, without further circumlocutions, let us show the damned variables. I'll dissect one of the build scripts I have actually used, accompanying the definitions with some comments or caveats.

The following two definitions point to the root of the command line developer tools and iPhone SDK. You may need to modify them to update the location in your own system, or if you are using a newer version of the SDK:

export DEVROOT=/Developer/Platforms/iPhoneOS.platform/Developer
export SDKROOT=$DEVROOT/SDKs/iPhoneOS2.0.sdk

Next, let's save the current build environment - we'll use it later to build the i386 version of the library which will run in the simulator.

# Save relevant environment
U_CC=$CC
U_CFLAGS=$CFLAGS
U_LD=$LD
U_LDFLAGS=$LDFLAGS
U_CPP=$CPP
U_CPPFLAGS=$CPPFLAGS

We'll now define the values we need to use to target the ARM architecture. Compilation flags in my case look something like this:

export CPPFLAGS="-I$SDKROOT/usr/lib/gcc/arm-apple-darwin9/4.0.1/include/ -I$SDKROOT/usr/include/"
export CFLAGS="$CPPFLAGS -arch armv6 -pipe -no-cpp-precomp -isysroot $SDKROOT"
export CPP="/usr/bin/cpp $CPPFLAGS"

Linking flags are a bit more tricky. You need to ensure the output of the compilation process is a static library, and not a dynamic library or an executable file. Dynamic libraries can in fact be produced, but the iPhone sandbox will sadly refuse to load them at runtime - only dynamic libraries and frameworks in predefined system locations can be used. There's a mention about this limitation somewhere in the Development Agreement.

Even though you won't be using dynamic libraries in your project, some packages are configured in such a way that it is easier to let them compile the dylib then ignore it, rather than trying to convince them not to create the dynamic code. If you encounter such a case, you should configure your linker in a way similar to this:

# dynamic library location generated by the Unix package
LIBPATH=src/.libs/<libname>.dylib
LIBNAME=`basename $LIBPATH`

export LDFLAGS="-L$SDKROOT/usr/lib/ -Wl,-dylib_install_name,@executable_path/$LIBNAME"

This will create a valid dylib file that you will be able to use within Xcode; however, it won't run in the iPhone as described above.

Therefore, you will actually be interested in using the static library version, so we'll store its location:

# static library that will be generated
LIBPATH_static=src/.libs/<libname>.a
LIBNAME_static=`basename $LIBPATH_static`

Now we are ready to run the configure script and build the libraries.

./configure CC=$DEVROOT/usr/bin/arm-apple-darwin9-gcc-4.0.1 LD=$DEVROOT/usr/bin/ld --host=arm-apple-darwin
make

Depending on the package you are trying to compile, you might need to supply additional arguments to the configure script. Some packages, for example, will accept arguments indicating whether a static library or a dynamic one should be built. It is also frequent to disable features or modules you know you won't use in your project. You need to refer to your package documentation for fine tuning details.

After make finishes (hopefully without errors), we'll move away the generated libraries to a safe location:

mkdir -p lnsout
cp $LIBPATH_static lnsout/$LIBNAME_static.arm

We repeat now the same steps, but targetting the i386 architecture. This will allow us to build libraries compatible with our iPhone simulator environment.

make distclean

# Use default environment
export CC=$U_CC
export CFLAGS=$U_CFLAGS
export LD=$U_LD
export LDFLAGS=$U_LDFLAGS
export CPP=$U_CPP
export CPPFLAGS=$U_CPPFLAGS

# Overwrite LDFLAGS
# Dynamic linking, relative to executable_path
# Use otool -D to check the install name
export LDFLAGS="-Wl,-dylib_install_name,@executable_path/$LIBNAME"

# ToDo - error checking
./configure
make

# Save generated binaries
cp $LIBPATH_static lnsout/$LIBNAME_static.i386

After we have produced the i386 and arm versions of our library, we will create a fat Universal Binary enclosure containing both of them:

# Create fat lib
$DEVROOT/usr/bin/lipo -arch arm lnsout/$LIBNAME_static.arm -arch i386 lnsout/$LIBNAME_static.i386 -create -output lnsout/$LIBNAME_static

Finally, you can add the generated library and any necessary development header files to your project and build it. If everything went well, your application will be linked with the library and will run correctly in both the simulator and the device.

As explained above, this is mostly basic Unix tinkering, but it took us a while to get the right configuration. Maybe we were just rusty, so if you know a better way to achieve this, please do let us know!

Sketches 1.3 is out!

After a long 5-week wait that felt like an eternity, we are glad to announce that Sketches 1.3 is finally available in the App Store.

The reason for the delay was that we were requested to modify some details in the User Interface. We immediately complied; however communication during this process was slow.

To celebrate the release and compensate our patient customers, we will be starting a one-week promotion next Saturday. From September 27th through October 4th, Sketches will be $1.99 instead of the usual $5.99. So, if you were in the brink of purchasing a license, please wait until next Saturday and you'll get Sketches almost for free.

Yoyu can check Sketches 1.3 new features and improvements in this previous post. In addition to that, we have fixed image uploads to Twitter: while Sketches was in review, our image hosting provider discontinued its service, and we had to urgently integrate a new one. Our appologies for the inconvenience.

If there's a good thing about the delay, it is that Sketches 1.4 is ready. We are testing it throughly and will submit it very soon. We hope it won't take so long this time.

The Cruel Economy of the App Store

A recent article in Wired suggests that Trism’s creator could become a millionaire soon, from Trism sales alone. I doubt it, let me explain why.

Wired's article explains that Steve Demeter, the sole author of Trism, made more than $250,000 in the first two months after the the launch of the App Store in July 11th. That is, without a doubt, a nice sum. They conclude: “If the game keeps selling at this rate for a year, he will have made $1.5 million. Not bad for a lone coder.”

However, what the article fails to analyze are the dynamics of sales in the App Store, probably assuming that they will work out in a similar fashion as desktop online sales. The Mac shareware market is a healthy business with an ever-expanding user base, and products have considerable longevity after being introduced; thus, it is reasonable to approximate sales linearly as a rough figure of yearly revenues. In our experience, however, the App Store is currently operating in a way that resembles the media business more than the shareware market. Like in sales for a movie or a music CD, if you are able to produce a hit like Trism the App Store will give you 30-45 days of glory. Those are the days when your application will be listed as one of the top sold apps, as very well explained by John Casasanta. Being featured in the App Store will have an echo effect in other media and your app will be reviewed, analyzed and blogged about.

The App Store, being a tremendous sales channel, is obviously acting as the most influential source for iPhone software. Think of it as if there was a single Top 40 music radio station everybody listened to: moving up or down in the list has a huge impact on sales, and dropping from the list means your sales will be easily reduced by one or two orders of magnitude.

Let's look at this further.

App Store Sales

There are basically 5 parameters that affect your sales on the App Store:

+Product
+Price
+Apple’s product placement
+Position in the charts
+Star rating

Your product is described and shown as a series of screenshots in iTunes. The better the description and appeal of the images, the better for your sales.

Prices on the App Store are quite low. Ever since Super Monkey Ball was announced at $9.99 a few weeks before its launch, the psychological barrier for all games, and most other applications, was set at that price point, and lots of users will not buy anything above $4.99. This was a big surprise for us, as we thought that a game that normally sells for $40 in other platforms would sell for $20-$25 on the App Store. Anyhow, the lower the price, the higher the probability that your application will sell more.

Apple has a lot of prescription power. Whatever they promote on “What’s new”, “What’s hot” on the iPhone, or the iTunes App Store home page, will sell. At this point this is completely managed by Apple.

Being on the Top 25 generates sales per se. Users trust other users, and if your application is on top, many others will buy. In addition, being among the first applications in a category, like Entertainment, will also facilitate people finding you application and buying it.

The star rating also has some influence. It is another mechanism from users to tell other users if they like the application or not. In the App Store, anyone can rate an application, irrespective of they having purchased it or not. This helps applications get votes and comments. Most users use the overall star rating as a guidance: if the application has 3 stars or more, it must be OK; otherwise, it must be no good.

What marketing tools do developers have?

Product

A quality product with certain appeal, will be more likely to sell well, than poor quality products. But having a good product is not enough. More and more apps arrive at the app store each day. Unless the application comes from a big game studio, or a known developer, it is easy that good new apps get their sales diluted among the list of thousands of applications in the App Store. As there is no “try before you buy” mechanism, visual appeal is very important. The screenshots and the description of its functionality of your product will be key.

Price

This one is really tricky. Depending on how you price your application, you will get better or worse reviews, even from people that may not be that interested in your app. As of today, 3 of the top 5 applications are priced at $0.99, the other 2 are $1.99 and $2.99. Thus, the influence of price is huge. Having seen this, there are many developers that are following the "first free, then charge strategy". It is the case of Air Sharing, currently free, but that will most probably be at the top of the sales chart, once they change the price to their announced amount of $6.99.

Today, Pangea’s games are on sale. Cro-Mag Rally is being sold for $1.99 when it was $9.99 a few days back. It has climbed to the Top 3 paid apps ranking. Prior to lowering the price you could see this kind of reviews:

That is people, even liking the game, lower the rating due to price. After lowering the price, however, you can see this:

The text of the review reads as follows: "A lot of early adopters paid $10 for an app that is now 80% less... a lame attempt by devs to drive up their sales rank. REALLY terrible way to treat customers. As for the game, it's not for me. But I wouldn't be complaining if they hadn't decided to treat early supporters like garbage. Thanks a lot, guys. You've cost yourself at least one future customer."

The dilemma is served. If you lower the price for your application, you will hopefully attract more people, but users who have purchased your application at the previous price will post negative comments about it, lowering your star rating.

The issue derived out of this is that many developers are opting for creating simple, nice looking, low-price apps. This lowers the risk of developers and provides higher probability of success. But, how many of these apps will get maintained once the initial 30-45 days are over and sales have gone down dramatically?

So, right price handling is very complex. It will influence your sales, charts, ratings and comments, and, the product itself, in the medium term.

Apple’s product placement

Most developers have no control over this factor. Big corporations, like EA, will obviously get some attention. But Apple will also promote products from other developers. We were lucky enough to be among this group for the App Store launch. Sketches was highlighted in several countries. And today you can go into Apple’s physical stores in the US and see the Sketches icon (Top line, 3rd from the right):



It was Apple, though, who decided to promote Sketches. We, of course, provided all the material and information they required. But it was Apple contacting us, not the other way around. Thus, there is little a developer can do, apart from creating a great product and get some visibility, then hope for Apple to like the product.

Product Position

The position your app has in the charts can only be managed by 2 factors: price, as discussed before, and updates. Price will influence the sales chart. Updates will allow for your application to be shown sooner in the category it belongs to.

Ideally, updating often would allow for your application to be listed before other apps in the category, making you sell more. Unfortunately, updating in the App Store is not fast. What's more important, the developer has no way to know how much time it will take for an update to be approved, possibly affecting your options to create marketing and advertising campaigns. Sketches 1.3 has been in review for more than a month now. In terms of positioning, we are totally lost towards the end of the Entertainment category. In addition, Apple discourages frequent updates, unless they fix severe bugs.

Star Rating

The App Store has no barriers for comments. As anyone can post an opinion on your application, developers are out of control on this. The good thing is that nice apps, will attract nice users, who will post nice reviews. On the other side, depending on different factors, mostly unrelated to the product itself, your app will also attract some unhappy users that will punish your every move.

Currently the global rating is built as the arithmetic mean of all votes. A destructive, even unreasonable rating will count as much as a well thought out review of your application. It would be nice if individual ratings were weighed by the "helpfulness" factor, indicating how many other people thought the review was relevant for them.

Marketing outside the App Store

There is some marketing that can be done outside the App Store. Blogging, news and press releases do help. We have even joined other developers in creating AppStoreGems. However, given the margin per sale, it is hard to buy advertising and get a profit out of it. Given that developers get 70% of each sale, acquisition costs for a $4.99 app have to be below $3.5. That quantity of money will buy you a few guaranteed clicks, but I am not sure if the sales will cover the cost.



Other popular marketing tools that are well proven in the Mac shareware business are also not possible in the App Store. Daily offers like MacZot or MacUpdate promo, hugely successful bundles such as MacHeist, discounts or even cross-product sales (buy AppZapper and get a discount on Disco, iClip or Picturesque) cannot be achieved today.

Trends

Even though the App Store is only two months old, the way it has been working so far seems to signal towards two very different app trends, if the mechanisms keep being the same.

+ On one hand, blockbuster productions from established companies will be hits in the App Store. Given the enormous value of the precious few "Top App" spaces, competition will become more and more fierce (more so as the number of iPhones sold increases), and I expect big companies investing considerable amounts of money to release new titles and get one of the spots. This is basically games from big studios we are talking about.

+ In the short term, we will be seeing more "disposable" apps: short-lived apps that can be crafted in a short time and that explore a good, original or fun idea. These apps will be offered at $0.99 with the expectation to hit the list and make a profit for a few days. After the app is out of the list, it will be basically forgotten since the operation costs (support, improvements) will not be justified by the very low vegetative revenue. The trick to succeed in this space is to launch many apps and expect that one out of 10 will make it. The success ratio will lower as time goes by and game studios take the top places.

This prospect basically leaves out the space for small but carefully crafted apps with a long time-span, such as those from indie shops we are so familiar about in the Mac shareware market. Creating a good app is hard, even for the iPhone, and sustaining it takes a lot of work. In the case we know best, we started working in Sketches in August 2007. Of course it was not a full time job then, but it was a necessary training that allowed us to create the app we wanted to, and to do it in such a nice way that Apple decided to feature it at App Store launch. Today we keep working on it, adding improvements, answering to emails from our existing customers and planning the next major release.

There is a catch in our previous statement: those are the trends _if_ the status quo is not changed and things keep being the same. Our bet is that the App Store will evolve, simply because customers will demand apps other than big games or little smart toys. When we decided to put effort in Sketches, it was a bet that someday we could even sell it, and now we have something as revolutionary as the App Store. Likewise, we still believe that there will be a place for companies like ours in the future.

Reality

Today, Trism is ranked as the application number 499 in popularity, 63 in the paid apps rankings, as per the information medialets provides. I am betting though, that it has gone up during the last few days after the article was published and made popular in digg. Thus, as anticipated in the introduction, it is becoming subject to the App Store "Top Apps" dynamics and it will be hard for its author to keep the past sales level.

So, if anyone wants to become a millionaire on the App Store, think again. I am not saying it is impossible, but it is not as easy as some people have put it.

Sketches Update and AppStoreGems.com

This week is looking great. We uploaded Sketches 1.3 to the App Store last Tuesday, so, we are hoping to see it in the App Store very soon. This new version includes:

+ Text input using the virtual on-screen keyboard, for those situations when that option is more adequate than entering hand-drawn text. This is possibly the most frequently requested feature from our current customers.

+ Web Sharing via a built-in web server. A very tiny and efficient HTTP server has been integrated to facilitate exporting the drawings in PDF, PNG or JPEG format. Users simply use their browser to connect and download their drawings, and they don't need to install desktop synchronization software or use other intricate solutions.

+ Improved shape placement algorithm. The shape placement algorithm is now tolerant to the user accidentally taking one of his fingers out of the tactile area during a multitouch gesture. This was a frequent issue when trying to locate a shape near the edges of the screen. In this new version, users can even purposely lift one of their fingers to easily move the shape to a corner or even halfway out of the screen.

+ Tip system. Small "hints" are displayed the first time the user selects a new feature or tool. This will solve the problem of some users that found themselves in full-screen mode and did not know how they got into it or how to bring the toolbars back! These help topics are presented as nice subtle overlays that dismisses after a certain amount of time to not interfere with your work.

+ Additional shapes, featuring a brand new "Office" category with pushpins, sticky notes, tape paper and the like. Fun and Callout categories have been improved as well.



In addition, several bugs have been corrected and several optimizations have been made.

But this week, we are also starting with a new idea: App Store Gems. We are joining forces with other developers that have created quality applications, in an effort to stand out from the already pretty crowded App Store. Promoted by John Casasanta and Austin Sarner, it includes 5 other applications apart from Sketches: File Magnet, Where To?, Pennies, Kineo and Groceries.

Today, in its first day, we are all donating our application revenues to a charity. In our case, Prevent Cancer Foundation.

To promote this new effort, we are making cooperative advertising, as explained in this post. It would be great if you help us digg it. Many thanks!

Text, Sketches, Soon!

We have received a good number of requests about adding text to Sketches. We are working on it, here is a sample:



It will take a some more days to get all the details finished and done correctly, but we are getting there!

Sketches Available on the App Store!

We are extremely excited to announce that Sketches is now available on the App Store, and is highlighted in several countries:


We want to thank everyone who has supported us in this process: Apple, our users, our friends, and particularly, our families.

Sketches Web site is now back. Any comments or suggestions can be posted through the contact form.

LateNiteSoft Acquires Snapshot

As a consequence of our last visit to San Francisco for WWDC, we are happy to announce that we have acquired Snapshot from Stunt Software. We sat down with Dan Messing and reached an agreement that we have now made operational.



We are excited about this opportunity. We believe Snapshot is a nice product that makes a great addition to our portfolio, and that will become a nice complement for Sketches in the future.

To all current Snapshot customers, welcome! We'll try to live up to your expectations.

WWDC 2008

If I had to summarize this year's WWDC in one word, it would be "Awesome". A year ago, we went to WWDC with no clear goals. We attended a lot of sessions, and met a few people. Overall, it was a good experience, in which we gained a lot of technical knowledge.

This year, it was different. Our primary goal was not to spend all of our time in sessions. We wanted to make our visit business oriented, meeting people, and getting feedback about different aspects of our applications.


After 2 years of working with him, we finally met Louie Mantia, our graphic designer. Currently, he works mostly for our friends at Tapulous, but, fortunately, he still does some work for LateNiteSoft.

We also met Chuck Soper, Cabel Sasser, Daniel Jalkut, Mike Lee, Kenichi Yoshida, Steve Scott, Tristan O'Tierney, Colin Wheeler, Kevin Hoctor, and some others in the SF Mac Indie Soiree.

During the week, we met with many Apple employees, as well as other entrepreneurs, developers, designers and journalists. We participated in a few labs and different consultancy sessions. We were present at the parties and events, but overall we probably did not make it to more than 5-6 sessions each.

The overall result has been very good, and we are very satisfied. Within the next few weeks we hope to start showing you the outcome of our visit.

Server Up :)

We are glad to inform you that the issues with our Web server have been fixed, and it is back online. We are sorry for any inconveniences caused.

Server down :(

I regret to inform you that our web server is currently down. It started responding very slowly a few hours ago, and not at all some time after that. We've asked our service provider to reboot our server (it's a dedicated one), but they have just found a hardware fault in one of the hard drives and are working on a fix or replacement.

This affects the Xslimmer and Sketches web sites, as well as the remote Xslimmer license retrieval feature we released yesterday. We beg your patience and understanding while the problem lasts.

Our services had been 100% available for the past 250 days, even through a change of IP addresses. Jorge and myself had been planning to set up a second server in a different service provider as an emergency backup solution. Unfortunately, we didn't do it in time.

We'll keep you posted. Thanks again for your patience.

Dark Xslimmer's Toolbar

A few days back, I watched Cabel Sasser's C4 presentation. I thought it was a very nice presentation, with some insightful bits that can only be produced out of experience. I particularly enjoyed the part where he explains why they had to create their own toolbar. We had to do the same.

During the summer of 2007, Louie Mantia challenged us to produce a black themed version of Xslimmer. As Leopard approached, we were thinking that providing Xslimmer with face lift was a good idea. So, making Xslimmer black would made it look nicely different. At that time, it did sound as something simple: just make the grey areas of the window become black, and the black ink become white. Easy.

I started developing the window part. Fortunately, some people had walked that path before me. Making the window black was relatively easy. Using a background image for the window title + toolbar area was the only tricky part, as, in the beginning, it was not correctly rendered. The top half of the image was drawn in the bottom half of the toolbar, and viceversa. Fortunately, I discovered that setting something called "the pattern phase", within the graphics context, cured the wound. The black window was done.

Next step was to make the toolbar font white. I checked the documentation. Nothing. Checked Cocoa development sites. Nothing. Checked everywhere I could think off. Nothing. Asked other developers. Nada. How could it be? Similarly to the guys in Panic, who were fighting to get access the 3 bottom pixels of NSToolbar, we just wanted to draw white text with a bit of grey shadow, and make the black dotted lines, white dotted lines. That was all. I tried every hack possible, subclasses, all sort of undocumented stuff to try to get access to the text rendering part, so I could invert the colors. Nothing.

My first thought was: "I will just build the toolbar using Interface Builder". Then, I started to design how it would work and operate. I soon realized that it was not going to be an easy task. Not only would I had all sort of issues placing the different pieces of the toolbars, but also controlling them during run time. In addition, Xslimmer already used toolbars in 4 different places, so the code to manage them was already there and would need major rework.

I decided it was time to create our own toolbar management system, a system that would operate in the same fashion as Apple's, but that would provide the needed flexibility. This would allow us to not change the existing toolbar management code, and, at the same time, make the text color any color we wanted. It took a while, but it was fun, and the results paid up:

It was time to get other people's opinion. So, during our beta testing phase, we had a poll. Most of our users did not fully like the dark theme. We held several internal discussions and finally went back to a more "Leopard-like" look, the one that Xslimmer uses today. Given the fact that code for toolbar management was unchanged, rolling back was trivial.

So, at the end, we never used the newly developed toolbar system. At that time, Chris Messina suggested that there might be some interest out there in continuing its development, that we should open source it. To make the toolbar system open source would imply some work: I would have to extract the toolbar and window code, produce a sample application, etc. So, prior to making the effort, I was wondering: Would anyone be really interested?

Leopard & Time Machine Experiences

Ever since Time Machine was announced, I had been awaiting for it. I am one of those people that do backup from time to time, but with no regular schedule or automated system. Clearly, Time Machine seemed simple enough and could very well prevent any undesired hiccups.

Once I had Leopard installed on my iMac, I was excited to give Time Machine a try. I decided to buy a Lacie external HD to make the backups. After connecting it, I immediately got a message asking if I wanted to use the disk as a Time Machine disk. I answered positively.

The disk was connected through firewire 800. I left it backing up all night. I took several hours to get all the used space on my iMac HD, a total of 250 Gb, onto the disk. Next day, I launched Time Machine's animated interface. Wonderful. Everything seemed to work fine.

After a some minutes, Time Machine began backing up automatically. This time just a few megabytes. Unfortunately, it took around 15 minutes for something like 3 Mb. In the following days, this became a constant, and I was not happy about it. Backups took way too long. I thought that I had not chosen a good external drive, or that it was faulty.

In addition, my Leopard was not too stable, nor did it operate as fluidly as I was hopping it would. I carefully considered reformatting the iMac with Leopard, and restoring all the user files from Time Machine. I was worried, thought, that the restore process would not work as smoothly as I would want, given the slow backup times and my doubt about the external HD condition.

After some investigation, I found an article that explained how issues might arise for using an APM partitioned drive on an Intel Mac. This could be the cause of my Time Machine troubles. Time for a repartition, reformat, re-first-time-backup.

As my final goal was to get my iMac into better condition, than what the upgrade from Tiger had left it into, I decided that after repartitioning, I would make the external hard drive bootable. I took the Leopard DVD, and using Disk Utility, I "restored" it onto the external hard drive.

Now I had an external hard drive, that used GPT (GUID) instead of the the original APM partitioning, and that was not only bootable, but it had the capacity to install Leopard. Time to try to get all 250 Gb on that disk again. This time it was much faster. It took around 3 hours.

Then, I booted from the external drive. Made a Leopard clean install in around 20 minutes. When the option for transferring files from another Mac was up, I chose to restore from Time Machine. It did it.

Once the restore process finished, most things were fine. As usual, Spotlight started indexing and made the Mac a little bit slow for a while.

After careful examination, I realized that some folders at root level were duplicated. I had "/Applications" and "Applications (from old Mac)". This was true for several others. I deleted all those folders. After all, if I was to need any of those files, they would be present on the Time Machine backup.

Now both Leopard and Time Machine seem to behave reasonable well. I am, though, ready to reproduce this process if I ever need to do so again.

There is Xslimmer in the Air (in the Macbook Air)

Since the Macbook Air was first presented at Macworld '08, we have had several people telling us that we should write about it. In particular, how Xslimmer is an ideal tool for it due to the small hard drive sizes. Faced with this kind of proposal, the question becomes what to exactly point out that it is not totally obvious. Xslimmer is a product to recover disk space from applications. The Macbook Air has a small hard drive. What else? As I do not know, I leave it there and point to you to some other people's articles:

* http://www.isights.org/2008/02/free-disk-space.html

* http://www.macrumors.com/2008/01/31/unboxing-video-of-macbook-air-more-notes/

Enjoy!

Colors in Sketches

We knew it had to come. With only 6 colors in Sketches 0.5 and older, we had several requests to add more. Some were really specific, "please add brown", some were more generic, "a few more colors would be nice". With our passion to do things as simple as possible for our users, this was no easy task. The current color picker was easy to understand and nice:

We looked at a good number of existing color pickers in different systems. From Hue, Saturation and Lighting circles to the Mac crayons, all had advantages and disadvantages. The HSL circles provide a great range of colors, but it is hard to select the same color twice, plus, not all people understand it well. Other pickers were not too suited for the iPhone/iPod touch interface.

We finally decided to evolve our current color picker, adding more colors, for a total of 24, getting rid of the text and giving it a different aspect:

After several tries, this was the final result:

We hope you like it!

iPhone programming tips: image orientation

One of our main focus when we started to write Sketches was to leverage as much as possible the existing technologies already available in the iPhone. This is not a new idea: just as all Mac OS X apps cooperate with each other, we thought that integrating Sketches with the rest of apps in the system would make it a far more fun and pleasing app.

Given the complete lack of documentation or experience, trying to figure out how the APIs work and fit together with each other was no easy endeavor. However, we bravely set out to study the Cocoa iPhone APIs, armed with our previous knowledge of desktop Cocoa, and a lot of patience. Sometimes we thought the effort might be overkill, but being perfectionists at heart, we were uneasy to deliver something that we ourselves considered suboptimal. We are satisfied with many of the results we got, and people seem to appreciate them too. In fact, we've had several fellow coders ask us about details in our image handling code, or how we manage to send emails from Sketches without actually launching MobileMail.

One of the areas we are frequently asked about is the way we handle images shot from the camera or picked from the photo album, and how we detect their orientation. Instead of answering the questions privately, we thought it could be interesting for others to post them here. Maybe our explanations will become outdated next week after The Event - if so, that'd be great news for all :)

In the following paragraphs I'll try to describe some of the interesting "features" I found when guessing how to use the Camera and Photo Album APIs, with a special focus on detecting orientation. I may be utterly wrong in my interpretations, but so far they have been working reasonably well for Sketches :)

* Warning: technical burble ahead *

The first idea that comes to mind if you want to have the camera shoot pictures and use them in your app, is to use the cameraController:tookPicture:withPreview:jpegData:imageProperties callback invoked by the CameraController class. It looks promising, but after some experimentation, we found this approach was not as flexible as we required. Instead, we are using a different mechanism in Sketches. We subscribe to the CameraImageFullSizeImageReadyNotification event, which is sent just after a new photo has been taken. Early in our development we decided to subscribe to all notifications and log them in a file, a simple technique that was instrumental to learn about the existence of this particular notification. In our code, the method that receives the notification is similar to the following:

- (void) cameraImageFullSizeImageReadyNotificationObserver: (NSNotification *) notification
{
    NSLog( @"cameraImageFullSizeImageReadyNotificationObserver" );
    [cc stopPreview];
    CameraImage * cameraImage = (CameraImage *) [notification object];
    if ( cameraObserver && [cameraObserver respondsToSelector: @selector(imageWasSelected:)] )
    {
        [cameraObserver performSelector: @selector(imageWasSelected:) withObject: cameraImage];
    }
}

The important piece of information here is that the "object" property of the notification contains an instance of the CameraImage class, which belongs to the PhotoLibrary API framework. In a moment we'll show how to deal with CameraImage instances.

For photos picked with the photo album browser, we use the PLUIController class. A line like

[[PLUIController sharedInstance] setDisplayingPhotoPicker: YES];

will trigger selection of a photo from the photo album. If you set a delegate object, the photo album will invoke your delegate's imageWasSelected method, indicating as a parameter the CameraImage instance that corresponds to the image selected. Note we are using the shared PLUIController instance and do not instantiate a copy ourselves - results are more difficult to achieve the other way around, because the constructor of the shared object actually knows how the instance has to be instantiated, while we have no idea about the properties we should set to make it work.

Therefore, for both types of photo selection (shooting with the camera or selecting a photo from the photo album), we end up with a CameraImage instance to deal with. A CGImage can be created from the CameraImage, using the following API call:

int orientation;
struct CGImage * cgimage = [image createFullScreenCGImageRef: &orientation];

Now we have a Core Graphics image, which is a good thing because there's actually a whole lot of documentation about that.

However, this is where things get a bit hairy regarding how to determine image orientation.

First of all, there are three different sets of values that refer to orientation characteristics:

- If you copy photos from your iPhone to your computer and look at them in an EXIF browser, you'll see that they contain one of the following values: "1" for "normal" images; "3" for images that are rotated 180 degrees; "6" for images that are rotated 90 degrees; and "8" for images that are rotated 90 degrees counter-clockwise.
- The orientation value returned in the integer above does not correspond to the EXIF values just mentioned. The values returned by createFullScreenCGImageRef are, respectively: "1", "2", "3", "4". To make things amusing, images shot with your phone in the vertical upright position will typically be stored to disk with a 90 degrees CCW rotation; therefore, the orientation value you'll receive if you pick such a photo from the photo album will be "4".
- Third, the device orientation, as reported by UIHardware, uses a different set of values. They are the following: "1" (phone vertical, upright position); "2" (phone upside down); "3" (phone rotated 90 degrees CCW with respect to the vertical position); "4" (phone rotated 90 degrees CW).

Therefore, after you select a photo from the photo library, you should check the orientation value you get when creating the CGImage reference, and then you have to correct the rotation using the rotation and translation transformations provided by the CoreGraphics API.

For photos shot with the camera, however, the orientation value returned by createFullScreenCGImageRef at that particular callback is always "4", no matter what the device orientation is, or the way the photo is stored in the disk. This probably happens because my initialization of the camera related APIs is possibly incomplete, but I haven't figured out how to achieve a better result. For shots, therefore, what we do is use the device orientation value, then rotate the photos according to the description above.

Another option I tried was to open the physical files that refer to the CameraImage and read their properties. I was hoping to get the EXIF orientation value, but it seems that at this stage not many properties are available. In fact, code like the following yields a dictionary with just a "FileSize" property:

NSString * imgPath = [[image fileGroup] pathForFullSizeImage];
CGImageSourceRef imageSource = CGImageSourceCreateWithURL( (CFURLRef) [NSURL fileURLWithPath: imgPath], NULL );
NSDictionary * imageProps = (NSDictionary *) CGImageSourceCopyProperties( imageSource, NULL );

We are using these techniques in the current version of Sketches, and will also be the basis for some new features we are still cooking up. We hope they are useful to other iPhone programmers too!

More iPhone Drawing Fun: Sketches 0.5 beta released

Sketches 0.5 beta has just been released, it should be available soon via Installer.app.

The biggest feature is support for multitouch drawing, making it possible to easily draw shapes such as ovals, rectangles, lines or arrows. Multitouch has been integrated with the "single-touch" mechanism in previous versions: you can use two fingers to create a shape, or just one to continue drawing free style, just like you were used to.



Sketches 0.5 is compatible with iPhone and iPod Touch devices running firmware versions 1.1.1 through 1.1.3, adapting to platform specificities automatically. The bug that caused only one photo to be exported to your photo album has been fixed, and sending sketches via email has been made a bit more user-friendly by providing visual progress indications.

More details about these new features and other improvements are available in these iPhone-ready release notes.

We hope you like this release!

Xslimmer 1.5 is Out!

It has taken us more than expected, but Xslimmer 1.5 is finally out.

Initially we intended to release this version along with Leopard, but we changed our strategy along the way. Feedback received from our testers and some difficulties in getting localizations recommended to dedicate some more time to this version. At the same time, we did not want to delay full Leopard compatibility, so we decided to add Leopard functionalities (code signing support, time machine exclusion, and others) to the 1.2 development line, while continuing to work on 1.5 at the same time.

Shortly after our initial Leopard-compatibility release we started to work on the preparation of the Christmas promotions we chose to take part in: MacUpdate bundle, and MacHeist II (as a loot for Mission 4). They both have been a success, and we have managed to get Xslimmer into the hands of many more customers.

The wait is now over. Thanks very much to all testers and to all our customers for your patience. We hope you enjoy this release, and that you see a lot of your suggestions covered by it.

Happy New Year!

From the Xslimmer Team, our best wishes for the new year that commences today.