Le Lab

Using GitHub Issue

2012-01-27T12:54:00+01:00

I love GitHub. I put all my code there. Github for Mac is a very nice Git GUI. And they even integrated a basic and powerful Issues Tracker. But it’s pretty hard to find the documentation for it.

Issues are attached to a repo. It is a tool to track issues (bugs, features missing, bad text etc) for that repo. It is both a web application, and it has links to your commit messages, and there’s an iOS application. It helps you track, comment and prioritize these issues.

Basically, you log those issues using the web interface or the iOS application. Then, when you solve the issues, you can add commit messages that automatically close your issues. To reference an issue, just add fix #1234 or close #4567 in the commit message where 1234 is the number of the issue. For example git commit -m ‘Corrected the gps. fix #238

You can create Milestones and assign issues to milestones, you can tag issues, assign them to someone etc.

It’s possible to give access to your clients on the repo and the issues tracker. That will help you communicate with the client.

If you want to read the original documentation, there’s apparently only this and that.

Inrocks Objectif 2012

2012-01-20T09:35:00+01:00

Remembering Netscape 2.0

2012-01-13T13:29:00+01:00

This is how and when the interwebs started getting really interesting for me.

In 1995, I was just out of Business School, out of military service (10 months mandatory WTF), and I got my first modem and an Imaginet subscription. Started out with an OEM software, then downloaded Netscape 2.0.

Trying bing for a month

2012-01-13T13:13:00+01:00

After reading this article I decided to test Bing for a month to see what gives. First test was to find out if my store and products are on first page for some keywords and it worked. So far, so good.

Nicest page on the internets

2012-01-12T17:50:00+01:00

How far we’ve come from Netscape 2.0 (via @bmf)

another great article on tech talks

2011-11-14T22:15:00+01:00

Here is another great article by Ole Begemann on the Apple tech talk. Read it in addition to mine to get a bigger picture.

Apple Tech Talk London was cool

2011-11-08T18:53:00+01:00

I was lucky enough to be accepted to Apple’s tech talk in London, last monday. So I spent 3 days in London and had some fun. But mostly I “worked”, attending the Apple mini conference.

The city

London is not my preferred european city, and my experience of London hotels got worse this time. It surely wasn’t expensive, but the room was very very small (I could stand up, but barely). I had a shower/toilets combination: if I wasn’t careful taking my shower, falling in the toilets was next. And the hotel was on a really noisy street with cars and trucks all day and all night.

One of the very first things I bought was a box of earbuds to have less noise during the night. I wasn’t successful. I didn’t leave a good review on FutureTap’s WhereTo? app hoping it will help others make a better decision than me.

By the way: don’t read Booking.com comments and reviews.

The venue

The place looked a bit like Moscone, from the outside,butwith a nice atrium inside. We had three rooms downstairs for sessions. The catering, food and drinks was excellent. Wifi was quite good all day except when it got bad in the middle of the afternoon (and then it was really bad).

This might look like something stupid to talk about. But those who remember the venue for last Tech talk in Paris will understand what I mean when I say it was much better.

The program

I mostly stayed in the main sessions room. Except when I missed a session. So I saw all general sessions.

The kickoff was by John Geleynsie who’s proved over the years how good and inspiring he can be. I remember the first videos I saw with him when the Cocoa Touch SDK was launched. The speech was essentially unchanged from last tech talk, only more historical: figures of sales, of money made by developers on the app store, demo of a range of apps from big -studio to indie-dev, and a lot of motivating sentences to push us to adopt quickly new features from iOS 5.

Mark Kawano was next and you can read all about his presentation on Ole Begemann’s blog. That’s exactly it.

Then Michael Jurewitz had his first session on iCloud. Although the subject was arid, and much more technical than the first two, Michael was quite successful in making it entertaining and motivating, underlining the easiest path to iCloud integration and all the benefit users and developers could get from it.

The first session of the afternoon was also with Michael, and he was once again able to keep many of us interested and awake after a pretty good lunch. I don’t know for others, but he motivated me enough that I am now absolutely sure I will drop support of iOS 3&4 in the next version of 321run and upgrade it to Core Data (at last) to take advantage of iCloud integration.

I missed the session from Stefan Lesser on Xcode 4.2 as it was something I had already seen and seen and seen both at WWDC and in WWDC videos.

ARC session was next, also by Stefan and he managed quite well this discussion, but didn’t get as many “oohs” and “aaahs” as I heard in the WWDC sessions. You may need to relax a bit Stefan. I know it’s hard, but you jokes

The last session was by Michael again, and the best one in my opinion, as it was the one in which I wanted the most to take out my Mac and iPhone and do what he was talking about. I had already seen sessions about Instruments, and I use Instruments regularly when needed (don’t fix what’s not broken), mostly for performance and memory issues.

But his session was a real hands on session from someone who has had to do it many times to help other developers. It remembered me my time as a Web Performance specialist, dissecting the issues one page or a particular workflow created for users to improve it, adding caches, minimizing js and so on.

The session

Generally, Michael reminded us of several rules: measure first, analyze, change incrementally and re-test, to measure again if there are improvements (you don’t want to worsen the user experience). Don’t take a global approach to performance, you need quick successes, before you need to re-architect your code for days. Always use a worst case scenario regarding your data: a user who’s got 400 runs with 321run, who’s got 100s of RSS feeds etc, not the simplistic case of a few subscriptions. Then he went in the details about three specific topics: performance, memory and drawing, as these are the most often met.

Performance: das ist wichtig!

Who cares that your app is nice and well designed if the user has to wait 15 Seconds to get to the first screen? Remember your app is jettisoned on launch after 20 seconds. And generally, waiting more than one second is a bad experience.

This waiting could occur both on first “cold” launch or when the app returns from Springboard. Here, dispatch_async is your friend, and generally do whatever you can to return fast and not block the main thread.

He then demonstrated How to use Instruments. Use the Time Profiler to measure what’s happening in your app, and keep the call tree in the right order. Once you are done with the thing that takes time (in his example the launch of the app), you can unfold that tree, starting with main, to find out where you are spending time. You also shoudn’t hide the system libraries calls, to know everything about the performance issues your app might have, where it’s spending time.

The ‘self’ column is very interesting to watch as it gives you a good overview of where time is spent.

If you click the arrow on the right of a call, you’ll recalibrate this column and the time spent (in percent) starting at that call.

In his example he had an easy problem: the app was making a synchronous call to a json iTunes Store URL, and then fetching the images. It was the occasion to remind us that a web connection should never be made on the main thread. Never. Ever. You lose control when you do that, anyway.

Memory

You must be careful about your memory usage, for several reasons. First of all there’s only 512 MB on the device today, less on the older devices, and a lot of that memory is already used by the system. There’s no swap file, so you really only have 512MB.

Apps that use too much memory are killed. Even the frontmost. And when you receive a memory warning in iOS 5 it is really time to do something, because you might be killed by jetsam (I personally had an app which would cause the device to be rebooted because of memory issues after a while, as I was not releasing stuff).

Be also careful about abandoned memory: memory that you’ve stuffed, for example with data or caches, but that you actually don’t use. It increases your memory footprint and that is bad.

Memory spikes are bad. They can cause your app to crash, but also your code to be purged from memory temporarily. The system needs more memory, so it purges your executable, and then needs to reload it, causing a loss of responsiveness.

To be able to analyze memory, Michael has created his own template with: * Allocations * Leaks * VM tracker * Activity monitor

Here’s a version I made of juryAllocations which you can install in ~/Library/Application Support/Instruments/Templates

The last tool is here to show you generally how much memory your app is using compared to other apps on the device.

The VMTracker shows you the real memory usage of your app.

The leaks tool is here to help you detect leaks. As everybody said in the audience, the right amount of leaks to have in an app is 0, so you should watch that tool closely to repair anything you might have forgotten.

And finally the first tool on the top of the list, Allocations, is here to help you find out which objects and which memory is allocated. Not all memory is objects, the system also allocates some for foundation and other libraries.

Michael used the mark heap button to have a measurement of memory usgae in between two points: move the head to a plateau in memory usage, then press the button, go to another plateau and mark again: this way you see only which memory was allocated during an increase in memory usage.

Drawing: you are no designer, so you’d better be fast

Problems are usually of two kinds when drawing. And what you’re wanting to achieve is 60 fps.

bad blending of layers causing a bad performance
misaligned images causing blurry pictures

Use opaque images as much as you can as it will make the life of the rendering engine easier and much faster.

To learn more about how your app draws to the screen, you should use the Core Animation tool. And once it’s launched, first tick the Color Blended Layers option. Then look at your app: what’s green is fully opaque and only one layer is rendered. What’s red is blended between at least two layers, and the redder the merrier: if it’s more, there is more blending.

Blending is not bad per se, it just depends on where it occurs. A famous example is the fact that often people but a clearColor in the back of a UILabel inside a table cell, thinking that it’s the way to have the selection color shine through, when actually it is useless as the framework records that color for the cell that is selected automagically and makes the label background transparent just when it needs to be.

Don’t forget to switch off that before leaving Instruments though:

Bad alignment of images is another kind of problem which has more to do with the quality of the rendering rather than the speed. Basically, the idea is that you can put images not exactly aligned with pixels, thus creating a bad anti alias where each point of the image has to render over two pixels, instead of one as it should be.

This is generally the consequence of scaling, replacing images by inappropriate retina display images.

You can turn the Color Misaligned Images option on, and it will show you where your images are badly aligned to the pixel, thus in danger of blurring.

Getting together

As usual, an important aspect of these get together events is the occasion to see people you’ve not seen in some time, and to meet new people, and usually from all over Europe, or the world.

I met in person with @cocoanetics Oliver Drobnik, for whom I had bought an iPhone 4s in France in October, and we spent some time trying to figure out if this tech talk would now be regularly scheduled or not, what sessions were most helpful, what kinf of audience was there.

I saw people I know from CocoaHeads Belgium, NSConference or the WWDC, such as Steven Vandeweghe (@bluecrowbar) from Bluecrowbar, Simon Wolf (@sgaw), and people who didn’t attend the tech talk, but were there post tech talk to meet other developers, drink one beer or ten, and know what new or more precise stuff had been discussed in the tech talk, such as Mike Lee’s father who came from Cambridge.

I met quite a few people I didn’t know, both from Apple or not. Sorry I don’t put everybody’s name

I left early (you know, the jetlag and my old age don’t get well together), to go back to my wonderful bedroom. Apparently, beers were drank, tweets were exchanged, but nothing special happened regarding #lickahoktor or bleaching.

Bonus

One thing the evangelism team didn’t talk about a lot before we were there is the fact that there was a Lab. I’m quite disappointed I didn’t know. Only a few of us went to see the people in the Lab, and I didn’t have a list of things to show, ask, review with them as I did during WWWDC.

If you’re lucky to go into another tech talk, think about it, there may be another lab. Be ready! If there’s a lab, you have issues and you don’t go to see them, you’re missing the greatest opportunity to solve your issues.

iPhone 4S and iOS 5: An Opinion

2011-11-03T19:44:00+01:00

I received my iPhone 4S the day it was released. It’s become a policy for me to buy a new unlocked iPhone and a new iPad whenever Apple releases it. Even if I don’t really need it, even if I pay the full price (I hate network operators).

I’ve used all the new features, and had fun on the first day asking funny questions to Siri. These tricks work mostly in english, and in french, I just find that too many things don’t work, such as maps, wolfram alpha, thus reducing the scope of the assistant’s usefulness.

Now I use it everyday, even if my calendar is not so full that I need to move appointments around, mostly for Reminders, Weather and alarms. It is handy. Actually, it makes using reminders a no-brainer: I’ve beenusing iOS 5 since mid-august, and never used Reminders. Since I have my new iPhone, I use it everyday, several times a day.

One of the things I noticed is that the combination of iPhone 4S and iOS 5 seem to give a much better accuracy for location. That’s mostly helpful for me in 321Run, as it provides more info for users, and I’m happy when users don’t complain about Gps in my app.

Even just with iOS 5 and an iPhone 4, the accuracy and behavior problems that have plagued the use of Gps for some people, such as my wife, seem to have disappeared. She would lose he signal, or get a location that was supposed to be accurate when in fact it was a gsm tower: her tracks would suddenly jump 3 km. It seems the transition is over, and I’m quite happy it is, and they stop playing with it.

Network wise, I didn’t notice any improvement. But we have a much better network than At&T, or so it seems (I remember the low quality while in the US last summer).

The camera and video are surprisingly good, but still not good enough for low light situations when it comes to the camera. I’m quite happy I took the 32 Gb, but I think that 64 would be nice if you really take a lot of videos. For example I wonder what I will do on my next vacations. Maybe unload all videos and music first?

I don’t know yet if iMessage is “disruptive” but it’s nice, helpful and fast. I’ll take an iPhone with a data card from 3 with me his weekend in London. I think it will be nice to have iMessage. What’s fun and annoying at the same time is when all the devices I use start yelling at me atthe same time because I received a message. I need to clean up some of them in the settings.

I’ll finish with the form factor. I think the iPhone 4 is a great shape, and very nice design, and I’m very happy they kept mostly the same design for the 4S. I wouldn’t mind if they kept the same design for several iterations of the product, and I think they will. I hope they will, even: faster ramp up for the production, less difficulties with accessories (iPhone 1 dock is my reference for that), etc etc.

Apple Tech Talk London

2011-11-03T18:53:00+01:00

I will be in London next week for almost three days to attend the small Apple Conference called Apple Tech Talk. I would have preferred Berlin but the day of the conference was not right for me.

I know already of two or three people I know who will come from all over Europe, and if you’re coming too, please say hello! I don’t see that many devs in my small town so it’s refreshing to be able to speak to people in person.

I should be available on iMessage thanks to a 3 sim card so don’t hesitate to message me. I’m cyril @ this domain name on iMessage.

Keeping my iMac just long enough

2011-11-03T18:30:00+01:00

I bought an iMac in 2007, a 24inches one. With 4 Gb Ram and a 320 Gb disk.

Recently, I really started to get annoyed by how slow it is. I have a 2010 11” Mac Book Air that’s faster for everything thanks to its Ssd. And gong from one to the other was really annoying.

So I started to look at options to speed things up, notably on owc. But they were not nice to me, and told me the truth: my iMac is too old to benefit from an upgrade package.

I just had the hard disk replaced, and it’s already much better. But I’m in for an upgrade soon, at least n 2012 (finances permitting).

How to repair corrupt sqlite databases

2011-09-18T12:53:00+02:00

In 321Run I use sqlite to keep all data. It’s a 2.0 app, and I never migrated to coredata… and probably never will.

From time to time, a user contacts me because their database is empty: no more history, and all former runs (sometimes more than 200) have disappeared.

It’s usually a corrupt database problem.

What I do now is ask for the file itself (it’s available through iTunes file sharing), and then try to repair it. This command has usually given very good result:

echo “.dump” | sqlite3 trainer.sqlite | sqlite3 trainernew.sqlite

Cool, heh? Hope it works for you if you have the same kindof issue.

If you are a user, please contact me so I can try, as it’s not certain it will work and is more for the expert user.

MetaEditor 3.1 borked

2011-07-14T11:56:55+02:00

I noticed that I had two regressions on the 3.1 version. Sorry about that. I should know that I need to test all old features whenever I send a new version. I pulled the app from the store for the moment, until I solve this stupid bug.

MetaEditor 3.1

2011-07-13T21:06:15+02:00

Actualités de Meta Editor

La version 3.1 de MetaEditor vient d’être publiée par Apple dans l’AppStore. Elle contient encore quelques nouveautés pour améliorer votre productivité et rendre l’application plus utile. Une ou deux autres applications de photographie font maintenant aussi l’édition de tags et des infos IPTC. Il était temps de modifier un peu plus encore les fonctionnalités pour faire de Meta Editor une application différente et ne pas être en concurrence sur le prix.

J’ai introduit dans la version 3.0 la sélection multiple de photos (en plus des différents albums etc). Un utilisateur m’a fait remarquer que je n’allais pas assez loin. Aussi j’ai privilégié les fonctionnalités qui permettent de traiter les infos en lots. Il est maintenant possible d’importer tout un album de photos. Bien que l’opération soit encore longue, elle est plus efficace que vous tapant sur chacune des images. Cela vous permet maintenant de traiter un import de photos depuis une carte le plus rapidement possible. Cette opération reste lente. En effet, je suis toujours obligé de copier les fichiers et de générer les prévisualisations à la volée. J’espère pouvoir bientôt faire autrement.

Second changement pour être plus rapide: il est maintenant possible de sélectionner toutes les images d’un album d’une seule pression sur un bouton. Là aussi, c’est tout simple, il fallait y penser et cela doit vous permettre d’être plus rapide pour éditer vos données. J’ai corrigé quelques bugs aussi, par exemple dans la gestion des mots clés. L’autre grande nouveauté est l’utilisation de Dropbox pour exporter vos images une fois l’édition finie. Personnellement, j’adore Dropbox et je l’utilise plusieurs fois par jour. C’est notamment très pratique pour partager du contenu avec des collaborateurs, ou à plusieurs sur un projet. Petit bonus, il est maintenant possible d’importer un nombre conséquent de mots-clés depuis le presse papiers. Par exemple, copiez vos mots clés habituels dans un email, séparés par des lignes (un mot par ligne), et envoyez ce mail sur votre iPad. Vous pouvez ensuite copier cette liste, aller dans meta editor et taper dans “importer” dans la gestion des mots clés. C’est une fonctionnalité avancée et pour le moment mal documentée.

Qu’y a-t-il dans le futur?

Tout d’abord, j’ai prévu de passer MetaEditor en application universelle (iPad + iPhone). C’est long à faire car il faut remettre à plat l’interface, simplifier certaines choses, etc. Mais cela me permettra de toucher plus rapidement un grand nombre d’utilisateurs. Et il parait qu’il y a aussi des lecteurs de cartes pour l’iPhone. Il y a aussi iOS 5 et iCloud. J’ai l’intention de supporter les nouveautés que ces deux apportent très rapidement. Elles sont en effet très pertinentes pour les photos. Ne serait ce que les photos streams qui se mettent à jour en permanence. Mais plein d’autres petites choses qui vont vous rendre l’application plus pratique, mais dont je n’ainpas le droit de vous parler. Tous les commentaires sont bienvenus et vos remarques et demandes me permettent d’orienter mes efforts sur des fonctionnalités vraiment pratiques. Par exemple, je ne sais pas aujourd’hui si une intégration avec 500px serait utile, j’ai du mal à apprécier quels sont les réglages qui vous manquent sur l’export vers flickr. Alors envoyez moi un email ou laissez un commentaire. Je ne fais pas tout ce qu’on me demande, mais j’écoute toujours attentivement.

Update MetaEditor

2011-05-24T07:29:42+02:00

J’ai mis à jour Meta Editor en corrigeant les crashs rencontrés par plusieurs personnes, et que ces utilisateurs m’ont remontés par le crash reporter. Merci. I updated Meta Editor to 3.0.1 after correcting some of the crashes that most people came accross. Thanks to those who reported the crashes with the crash reporter.

Meta Editor for iPad 3.0

2011-05-07T17:48:13+02:00

Meta Editor for iPad has reached version 3.0. It will be released very soon, hopefully next week. This new version adds a lot of features, of course. The goal is to make the tool more useful and more solid for users. So I first took into account the comments received: - “I want to edit multiple pictures at once” - “this application crashes too often”

More is better, multiple is best

The newest version is now able to select and make editable several pictures at once. This means that you can add several images from the photo library at once: tap the plus sign, and select as many pictures as you’d like, one by one but without having to tap again the plus sign. Much faster process. You can also change mode and go into multiple edit mode. This mode allows you to select more than one picture at once from your list to edit the IPTC fields. You can then upload (except for mail) that list of pictures. A new feature that I hope you’ll like is the addition of albums. This is becoming more than necessary when you have more than a bunch of pictures. There is still a “all pictures” choice of course.

Bugs

To make sure that the app worked better, with less crashes and less bugs, I spent quite some time making some beta versions, reaching out for people to provide their feedback and correcting quickly the issues that were found to keep the discussion going on. I also added a developer feature that allows me (with your permission) to receive the crash reports that are automatically produced by the system to find where and how the crashes are happening. As one of my fellow developers said: you should solve bugs from Crash reports before the user tells you about it. But of course you need crash reports. So next time you crash on Meta Editor, please send the crash, it will help me make a better app.

New way to export

I’ve added the Flickr upload to the different ways of saving your edited and tagged pictures. If you have a Flickr account, please try it and comment on it, preferably by direct email.

Meta = Exif + GPS + IPTC

One of the meta information sets I totally overlooked in the 2.0 version was Exif. This big error has been corrected. I hope Meta Editor in its third version becomes more useful for you and helps you be more productive with your iPad quickly. Please help me making it better by spreading the word so that I can spend more time on it.

NSConference 2011

2011-03-26T18:42:02+01:00

Here’s my comment on NSConference 2011.

Giving back, one app at a time

2011-03-12T19:04:30+01:00

Of course, there is the iPad 2. I live in France, so I can only wait for it to arrive here (if it does in time). There’s also this message from Twitter that they are looking at third party developers with a bad feeling, and that developing clients is no more acceptable. That’s rocking my world and my relations on Twitter these days. How futile… In the meantime, hundreds, probably thousands of people in Japan have died in a terrible earthquake, and others are facing a delicate nuclear situation, in a country where the only atomic bombs have detonated to kill people. You can pray for Japan and for people you know there.

But helping them requires money. Even in one of the richest nations of the world.

So I decided that I’d give all the money I make from my app 321run for this week end to a fund that would help save lives (and by all, I mean all).

That’s not a lot, but you can make it more. And that’s what I can do. I don’t know yet which fund will get that money, probably MSF, or the red cross.

But it will be to help save lives. If you already have 321Run, or else, don’t hesitate to give to your local organization. Money will be more helpful than prayers.

Becoming a Mac OS X developer, the easy way

2011-02-21T13:15:49+01:00

(Cet article est aussi disponible en français)

Ever since I own a computer, I want to become a firefighter… errh , no, I want to become a Mac OS X developer. To me it means creating apps, coding them, selling them and making enough money out of it that I can make other apps , even better ones. And on, and on. That wish is about to come true. But first, why didn’t I start before? I did actually. When Mac OS X 10.0 was released, I was not totally stranger to the platform, having developed in WebObjects for several years. I mostly created small utilities for friends or for myself, getting to know the tools and the platform. I hope nobody finds these apps on the internet, it would be embarrassing.

When iOS 2.0 was released (at that time, it was the iPhone SDK), the virus bit me again, on the iPhone this time. So I developed several apps since june 2008, both for me (321Run, GPSRecorder, MetaEditor) or for clients.

Thanks to Apple and to the AppStore, my bad marketing skills were taken care of, and I was able to make enough money to one day consider becoming a full time indie. Since I did code for the iPhone,the itch to code for the Mac grew stronger. But making an app for the Mac is much harder. I was joking about it saying to Daniel Jalkut”When I grow up, I’ll become a Mac developer, like you” (tweet unreachable, thanks Twitter!).

Except it is much more complex and you need to make a bigger effort to release an app that compares in features and design with the other apps on the market. First of all, the UI is bigger, AppKit is at the same time bigger and older and also more complete (too complete?). The Mac software history is also something to take into account: users have expectations. The grand debut of Mac OS X was a time to restart all clocks, but since then there’s been new apps, new APIs, new uses. If you want an app that compares, you have to be on the same level of features, and thus the first attempt is harder to make.

So I took a shortcut: I bought an app, to code it some more and publish it, make it mine.

Deck

I asked Kristof Van Landschoot to sell me his app he launched one year ago Deck, and he accepted. Why this one, and not another one? Simply because I like it and I like what it does: playing music. Finding an app that belonged to my centers of interest was key. I have to like it, and use it, even if I’m the only one who ever uses it. Deck is leveraging your iTunes library to allow you to play your music as albums, one by one, as if you were playing them on a deck. Deck is a new way to appreciate and rediscover your music, without launching iTunes and all its features (iTunes Store, AppStore, Video rentals…). An app that does one thing, but does it well: play your music.

Buying an application

Buying an application isn’t easy, nor is it so difficult. It’s just risky, and a jump into the unknown. Luckily, I didn’t do it without advices several stories of apps that have been sold/bought have arisen since 2006, and the app market exists. Daniel Jalkut was one of the first one to tell he was about to do it, and he did it (twice) with success (I’m using MarsEdit to write this post btw). I contacted him while I was watching his C4 presentation. He gave me sound advice and comforted me in my opinions regarding the valuation of the app. Justin Williams also told his stories, but him as a seller. I tried to get into his mind while reading his slides from 360iDev. Ortwin Gentz also bought his first iPhone app, leveraging the boost it gave him to become a successful publisher/developer. His story too was interesting, and he wrote the numbers in plain sight (as did Daniel).

Still it didn’t make finding a price so easy, as each case is different. The usual model to value an app is how much it made during two years. And in that case it was not working: Kristof seems to be as good a marketer as me and the sales of Deck have not been what he expected. At the same time, he spent a lot of time creating an app which worked, so he couldn’t sell it for nothing. So I decided to buy a forecast, my own forecast of what the app should become to be profitable, and pay him some royalties on that fair scenario, and if I over-succeed, I pay him too a fair share. He is therefore interested in my success: the faster I reach my sales, the more he makes. If I don’t reach my own goals, it is 7 000 euros that I have to give him over the course of several years, and I already gave him a part of that money. I don’t have all that money yet, so I need to make a successful launch.

Future plans

It’s been almost three weeks that I received the keys to the app. I had little issues to solve, things that were not working as I wanted (for example, the app included podcasts as albums). In that time I corrected those little things, and got to now the app better, which is vital too for support. I localized in french too, and prepared it for the Mac App Store, as I don’t intend to sell it directly. All this makes a 1.1 which I sent to Apple for review to the AppStore (or not). Immediate future plans are to be ready for that launch (my first launch). I quickly want to extend to other languages the localization efforts. It is key for us European developers I think, as we need to be close to our local markets. The UI is next on the upgrade path. As soon as I have money to pay a gaphic designer. Of course, I need to add some expenses in PR and advertising to make sure the app has coverage and sales.

I’ll continue to keep you updated on my efforts, strategies etc. If you have questions, don’t hesitate to comment.

Devenir un développeur Mac OS X

2011-02-21T12:45:59+01:00

(This post is also available in English)

Depuis que je suis tout petit, je veux devenir pompier… euh non, développeur Mac OS X. Pour moi, cela veut surtout dire développer des applications, les vendre, en vivre pour faire d’autres applications encore mieux. Et recommencer, et continuer. Ce souhait est en passe de se concrétiser. Développer des applications pour Mac OS X, je l’ai déjà fait au début du siècle, quand Mac OS X est sorti. J’avais un passé de développement avec WebObjects, donc je n’étais pas totalement étranger à la chose. J’ai surtout fait de tous petits utilitaires pour des copains, pour m’occuper. J’espère qu’il n’en reste plus de trace sur Internet, ce serait embarrassant.

En 2008, avec le SDK Cocoa Touch, le virus a fait un retour, d’abord sur l’iPhone. J’ai développé depuis plusieurs applications, à la fois pour moi (321Run, GPSRecorder, MetaEditor) ou pour des clients.

Grâce à Apple et à l’AppStore, j’ai pu compenser mes maigres talents de marketeur et gagner un peu d’argent pour payer quelques frais, pas encore de quoi en vivre. Depuis que j’ai recommencé à développer pour l’iPhone, mon envie de développer pour le mac s’est aussi réveillée. Mais développer pour le Mac c’est juste beaucoup plus dur. J’en rigolais avec Daniel Jalkut à l’époque en disant que quand je serais grand je deviendrais moi aussi développeur Mac (tweet introuvable, merci Twitter). Sauf que devenir grand s’avère plus complexe. D’abord, l’interface du Mac est beaucoup plus dure à maîtriser, avec cette surface non finie et de taille différente qu’est l’écran. AppKit est beaucoup plus complet, mais parfois aussi beaucoup plus “daté” que UIKit. L’historique sur le mac est beaucoup plus important. Mac OS X a été l’occasion de remettre un certain nombre de compteurs à zéro et de recommencer. Mais 10 ans ont passé, et les couches des différentes applications se sont accumulées, nouveaux usages, nouvelles API. Pour avoir une application qui ne dépare pas, il faut composer avec tout ce qui existe en termes de fonctionnalités, et la première marche est beaucoup plus haute. Alors j’ai pris un raccourci: J’ai acheté une application pour la développer et l’éditer sous mon nom, en faire la mienne.

Deck

J’ai proposé à Kristof Van Landschoot de racheter l’application qu’il a sortie l’année dernière, Deck. Pourquoi celle ci et pas une autre? Parce que je l’aime, parce que j’aime ce qu’elle fait: jouer de la musique. Trouver une application qui soit dans un de mes centres d’intérêts est essentiel. Il faut que je l’utilise, quitte à être le seul utilisateur. Deck s’appuie sur votre librairie iTunes et vous permet de jouer vos albums de musique, un par un, comme si vous aviez encore une platine (Deck) platine disque ou platine CD. Deck se présente comme une nouvelle façon de consulter et d’apprécier votre bibliothèque de musique, sans lancer iTunes et toutes ses fonctions supplémentaires (Store, vidéo, appstore…). Une application qui fait une seule chose et le fait bien: vous faire redécouvrir votre musique.

Acheter une application

Acheter une application n’est pas facile. Ce n’est pas difficile non plus. C’est juste un saut dans l’inconnu, un de plus. Heureusement, il y a déjà eu plusieurs expériences qui ont été racontées. Daniel Jalkut notamment a été un des premiers à dire qu’il allait le faire, et à le faire avec succès (j’écris ces mots dans MarsEdit, d’ailleurs). Je l’ai contacté en même temps que je regardais sa présentation à C4.

Ses quelques conseils m’ont conforté dans l’opinion que j’avais déjà. Justin Williams a aussi raconté publiquement ses expériences en tant que vendeur. J’ai lu et relu ce qu’il en disait, notamment lors d’une présentation récente à 360iDev.

Enfin, Ortwin Gentz a acheté sa première application iPhone lui aussi, bénéficiant lui aussi de l’effet d’accélération que cela représente.

Reste que trouver un prix n’a pas été très facile. Surtout que les modèles habituels d’évaluation ne s’appliquent pas. Car Kristof l’admet lui aussi: la vente d’applications n’est pas son fort. Et en conséquence, les ventes réelles de Deck étaient faibles. Ce qui n’empêche qu’il a passé beaucoup de temps à faire une application, et que celle ci fonctionne bien. Donc il ne pouvait pas non plus la vendre pour zéro. J’ai donc acheté un potentiel. J’ai évalué combien je pouvais en vendre et combien je devais en vendre pour que l’application soit un relatif succès et s’autosuffise: coûts de développement, hébergement, support, etc. Et j’ai déterminé avec Kristof le prix sur la base d’un pourcentage des ventes sur les prochaines années. Il a ainsi particulièrement intérêt à ce que je réussisse à vendre l’application.

Mais même sans cela, c’est près de 7 000 euros que je dois lui verser sur plusieurs années pour dire que l’application est à moi. Une somme que je n’ai pas aujourd’hui devant moi, il faut donc que ce lancement se passe bien.

Futurs plans

Cela fait bientôt 3 semaines que j’ai l’application et son code source. J’avais de petits griefs quant à la façon dont elle fonctionnait, et j’ai corrigé ceux ci. J’ai appris à connaître un peu mieux l’application, découvrir ses arcanes et son fonctionnement pour toutes les parties, ce qui est aussi important pour le support. J’ai localisé en français aussi, parce que je ne pouvais pas laisser l’application en anglais seulement. Et je l’ai préparée pour l’AppStore Mac. Tout ça fait une version 1.1 qui a été envoyée à Apple pour validation (ou pas) et publication sur l’AppStore.

Le futur immédiat, c’est donc le lancement de l’application sur cet AppStore. A moyen terme, la localisation dans d’autres langues est importante: néerlandais, allemand et espagnol font partie des langues que je veux rapidement ajouter. L’interface utilisateur est amenée à évoluer, dès que j’aurais de quoi payer un graphiste. Par ailleurs, j’ai prévu d’accompagner le lancement de l’application avec pas mal de dépenses de marketing pour qu’elle soit plus connue et acquière plus de visibilité. C’est là aussi un gros poste de dépenses pour les mois à venir.

Je continuerai à vous tenir au courant de l’évolution de cet achat et de ce lancement.

Couvertures Inrocks

2011-02-14T00:08:05+01:00

Le retour de la revanche… Je dois mettre à jour les anciennes version, mais j’ai remis en ligne quelques pochettes des inrocks, notamment Objectif 2011

Best of 2010

Une rentrée 2010