Saturday, July 04, 2009

From Orange to Apple

Maybe the title should have been “From an Orange Executive to an Apple Indie Developer”, or simply put “Learnings After One Year as Indie”. Basically, I wanted to explain how I came to make one of the biggest changes in my life, what the motivations were, and some of the things I did learn throughout the process.


My background


So, at 39, I was a reasonably successful executive at Orange, the French telecommunications company owned by France Telecom. At that time, France Telecom had more than 200,000 employees, more than 3,000 of them in Spain. I was one of them, one of those called “Top 100”; a director in charge of Web operations, leading a group of nearly 50 people. I had a nice salary and nice benefits too.

I worked for Orange during 8 years. Prior to that, I had been working for other multinational companies, always related to technology, which was, and still is, my passion. That is also the reason why I majored in computer science. However, soon after I started working, it became clear that I could not make a living creating software, at least not the software that I wanted to make. Soon after that, I got a masters degree in business administration, and began a managerial career that some years later took me to Orange.

During my time at Orange, I started Cocoa development, a bit as a hobby. I had been developing applications, mostly games, since I was 14. Being new to the Mac, I wanted to see what Cocoa was about. At the same time, Pedro, who also worked for the same employer, had this idea about making a universal binary stripper. So he went ahead and made the first implementation of his idea as simple shell script. It worked just fine. We had been working together several years, and we knew each other quite well. When he showed it to me, I told him that I wanted to make it more “Mac-like”. I, then, created a user interface that showed the application list and an icon for the architecture. Finally, Pedro integrated the guts of his script into Cocoa. It was the birth of Xslimmer. To our surprise, Xslimmer's popularity began to grow, and with it, so did its sales.

Months later, around August 2007, we created Sketches. Those were the jailbreak days for us, as there was no official support from Apple for third party applications. Interest for it skyrocketed, and for every new update there were hundreds of thousands of downloads. Some months later, Apple announced the SDK and the App Store. It was clear that there was an opportunity.

The change and its motivations


So, my day job, family and other responsibilities were taking most of my time. I felt stressed, and drank a lot of coffee. I had a gut feeling that the time was coming to make a change. As opposed to what was clear to me in the early 90‘s, Xslimmer had taught me that it was possible to make a living on selling software that I had created. And the App Store was coming.

At that same time, Orange was starting to feel the pounding from the world's financial and economical crisis, and had bad forecasts for the future. As it had happened in several occasions before, and in preparation for the crisis, there was a management reshuffle. I was offered the IT Project Management Direction. The job was for sure interesting, but my head was somewhere else. I needed to pursue my dream of creating my own software company, one that would make software I wanted, and I knew that the time was then.

I left Orange, on July 4th, 2008. Exactly one week before the App Store went life.

The learnings


After one year there are a few things I have learned, that might deserve sharing:

App Store success is temporary. I compare it to the music industry. While you are on the top chart, you sell; once you are out, your sales level is much, much lower. In our case, Sketches did great for a couple of weeks, reaching Top 12 in the US for a while.

Apple listens, but it takes them a while to react. During the iPhone SDK beta testing, we wrote several bug reports - it sometimes took several weeks, but they were all answered to, and most fixed. Once the App Store was live, I wrote an article a while back that included several suggestions for improving the App Store. Most of the things that I wanted changed are now changed. For example, allowing only users of the application to voice an opinion and rating about it.

On marketing, experiment and follow your instinct. During this year we tried different things that did not work out. From joining other developers to create an “Apps Gems” site, to purchasing online advertisement. We were new to those types of actions. However, simpler, and cheaper, tactics did work out quite well. Twittering, blogging or simple press releases did much more than any expensive advertisement. I obviously need to learn more on this.

Get help for your paperwork. Administrative stuff and taxes is unavoidable. You just have to do it. We have a small accounting company that takes care of filling up the necessary forms and that keeps the accounting information for us, but most of the work, you still have to do. You have to process those PayPal reports, you have to process those iTunes Connect Financial reports, you have to scan all the invoices you receive, and so on. But having help from a third party places some routine to it, and ensures that you will meet the necessary deadlines.

It is not all fun, but automation helps. You cannot start new products all the time. You have to take care and nurture your existing products, so that your customers realize you actually take them seriously and are committed to making them better and better. Your customer base demands time too. Customer support takes a good chunk of your time. The more products and the more sales, the higher the number of customer support requests. I would say that around 2% of sales translate into customer support requests. Most are very simple, but some are not. The solution is to try to automate things as much as possible. From self service (recover your license) to email templates, all helps.

Working at home is harder than I thought it would be. This is not because of a lack of discipline, but, in my case, the environment is really noisy and busy during the day. I found myself trying to work while being interrupted. Being used to code at night, this was really hard for me. We ended up renting a small office, just a few days ago.

There are more things in life than just work. For a couple of months, I believed Pedro had lost interest in our little software start-up. One day he explained to me that he was ending his 15-year-old marriage. It took a while for him to reorient his life, and, as a result, we deviated from our scheduled workplan, and part of our initial inertia was lost. However, now I try to spend more quality time with my family, while keeping a more flexible philosophy about how to spend my time. For example, last week I took the afternoon off and spent it having fun with my family. What's more, I did not feel guilty or time pressured about it.

You can do all those things that you never could. Now there is no excuse. It is just a question of organizing yourself. In my case, I wanted to lose weight. That is hard to do when you spend a lot of time traveling around, eating sandwiches at meetings or while preparing presentations at 2AM. But once you are the owner of your time, it is. I lost 20Kg (44 pounds) from September to December last year.


The dream


So, now what? Well, when I think of what I want to accomplish in the future, I do not think of creating a huge company with many employees, controlling the world’s software market. My objective at this point in time is to create a company similar to Panic or the Omnigroup. These companies keep the indie spirit, while having some specialization and some size, so they produce quality products while providing a quality service, as their employees can dedicate most of the time to what they do best.

So, for LateNiteSoft 2.0, and if our numbers allow for it, my intention is to hire an enthusiast support/webmaster/marketing person, as the first non-founder employee. Then, where we go from there remains to be seen, but I am sure it is going to be both interesting and fun.

Monday, June 29, 2009

Apple iPhone: Light-Years Ahead

As shown in one of the banners at the Moscone West during WWDC 09: one year later, light-years ahead:

WWDC09.JPG


It could not be more true. Many things have changed during the last two years, and in the last year in particular.

I truly believe there is still no competitor for the iPhone. I have tested many different phones. I have owned, both Blackberry and Palm branded phones, and I have had several Nokia phones in the past. Being a mobile device fan, I have the tendency to ask people to show me their phones. I have seen many, and there is still no competition, not even in those new touch screen phones that keep popping up.

It is also my believe that the key to is not in the hardware, which is definitely good, but not unique. The key difference is in the software. Apple created a software base that is extremely responsive to user input, and that made it easy and intuitive. Then, with the SDK and the App Store, opened the door to rest of us.

P1000157.JPG


Many things have changed. From the initial 550 applications that were available on July 11th, 2008, the App Store has now surpassed the 50,000 mark. That is almost 100 times more applications, and still growing fast. Another change is the introduction of firmware 3.0. Technologies like MapKit or Core Data, are amazing. Finally, new hardware. Faster, with more memory and more powerful.

In my opinion, 2 years after the introduction of the iPhone, Apple clearly dominates the smartphone market and it is clear that its intention is to keep doing it. But what it is most impressive is, that Apple is listening to both customers and developers. Took a while, and there are still things Apple do not want to change, but they are doing it. Almost all my requests for new iPhone SDK APIs have been made available in firmware 3.0, and almost most of the common requested features are now there (like copy & paste). Even most of the changes I wanted on the App Store are there.

So, I want to take this opportunity to say: thanks, Apple! Thanks for the iPhone, for the SDK, for the App Store, for your updates, and most of all, for listening. Keep doing it, and you shall keep light-years ahead of the competition.

Tuesday, February 17, 2009

Reject-me-not!

While it's been a while since our last post, we have not been resting on our laurels. During this time, we have released new versions of both Xslimmer and Snapshot. We have also released Sketches 1.5, and prepared and uploaded Sketches 1.6 to the iTunes Connect portal. Version 1.6 of Sketches, however, has already been rejected twice. As it happened with the undo icon back in October-November 2008, reviewers have found previously undetected issues in our product.

The first of these rejections was due to the fact the reviewer was confused about two distinct features: image hosting, and Web sharing. We had updated our application description to reflect the fact that sharing your images via twitter or email causes them to be uploaded to a new web hosting service we have developed anew for Sketches, instead of the former third party service we had been using. It was also explained that the reason for this change was to ensure an excellent quality at all times: we are not interested in placing ads on Sketches' image hosting services; we can act promptly on the event of unexpected downtime; and we can grow the service in the future with new features - none of which was possible with the previous offering.

The Web Sharing feature, on the other hand, allows customers to start a tiny Web server running inside Sketches in your iPhone, then download your pictures in PNG, JPG or PDF from your computer.

After activating the Web Server screen (see screenshot below), the reviewer somehow kept waiting for the drawing to be uploaded to our server. This, of course, never happened, and thus our app was rejected.

Picture 1562.png



When the rejection mail came in, I uploaded the same binary again and wrote back to the reviewer:

"Thanks for your feedback. Uploading to our server is only done when exporting to email or twitter.

What you attached as screenshot, is the integrated web server. That is, Sketches has a Web server that allows you to access your drawings from a Mac or PC using a Web browser, in order to export them. To do so, you simply have to connect to the URL address shown in that screen. In your case, if you open Safari, enter "http://10.0.0.3:8080" [IP address changed from original value] in the URL field. You should get something similar to the screenshot I have attached. Then you can press on the file type you want to export, jpeg, png or pdf, under any of the drawings to obtain a local copy.

I hope this clarifies it. Let me know if you need any further explanation."


A week later, the second rejection email was received. This time, the reviewer had found a true issue, totally unrelated to the previous discussion. Sketches Web capture mechanism used two icons that did not adhere to the iPhone Human Interface Guidelines "as outlined in iPhone SDK Agreement section 3.3.5".

IMG_0001.1.PNG


The funny thing is that those two icons have been there since the App Store launch back in July 2008.

What's interesting is that Sketches 1.6 is just a small, bugfix release that was submitted shortly after Sketches 1.5 was approved. Sketches 1.5 added some notable new features (such as our own image hosting service, as described above), and it was approved in just 40 hours. Somehow, improving over the existing feature set has triggered more alarms to fire off than creating new functions in the first place.

Anyhow, we talked to Adam Betts and he sent us a new pair of icons in no time. We created a new build and upload it again. 5 days later, we are still waiting for a response.

Tuesday, December 16, 2008

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.

Picture 1383.jpgPicture 1385.jpg


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 :)

Thursday, November 06, 2008

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.

Thursday, October 02, 2008

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!

Thursday, September 25, 2008

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.