Solicitation pour un développement sous iOS

Je reçois régulièrement des solicitations pour développer des applications iOS, en échange de parts sur des gains éventuels. La dernière demande était bien plus sérieuse que d’habitude, j’ai donc décidé de répondre de façon détaillée.

J’y explique pourquoi j’ai refusé toutes les demandes qui m’ont été faites jusqu’ici.

Bonjour,

Je suis actuellement pris dans une mission de longue durée; je ne peux donc pas répondre favorablement à votre demande.

Pour être tout à fait honnête, j’aurais probablement refusé. Laissez-moi vous expliquer pourquoi:
Depuis quatre ans, j’ai déjà été sollicité de nombreuses fois pour réaliser des développements, avec des projets plus ou moins sérieux.

L’une de ces solicitations venait d’un ami d’un ami que j’avais déjà eu l’occasion de rencontrer. À cette époque, je débutais comme indépendant, et je n’avais pas de missions, aussi j’avais du temps, et le besoin de faire mes premières réalisations. La première discussion s’est très bien passée: le projet semblait un peu trop ambitieux, mais a priori rentable. Un truc dans l’hôtellerie. Il s’agissait d’une sorte d’appli iPhone en marque blanche que nous allions personnaliser pour chaque hôtel.

Evidemment, ils n’avaient pas d’argent, donc je devais travailler en échange d’une part sur les gains de la vente de l’appli. Tout le monde avait l’air heureux, aussi je me suis mis au travail; nous allions régler les questions contractuelles dans la semaine.

La première douche froide fut quand je reçus les premières conditions contractuelles: non seulement on me proposait peu (parce qu’ils avaient beaucoup de frais de déplacement pour acquérir les clients), mais ils voulaient même que je leur cède la propriété intellectuelle de mon travail.

La deuxième douche froide fut qu’au fil de la semaine, ils ont commencé à réclamer fonctionnalité sur fonctionnalité, ce qui signifiait concrètement pour moi, que je devais travailler plus longtemps. En d’autres termes, j’investissais également les gains financiers que j’aurais eu en travaillant pour d’autres clients.

Finalement, j’ai mi le hola: j’acceptais le partage des gains proposé, mais je délimitais clairement ce que ferait l’appli iPhone. Les discussions se sont arrêtées là. Je ne l’ai jamais regretté.

Ce jour-là, j’ai compris une chose: c’est une relation commerciale qui n’est pas saine. Quand je fais de la prestation, le client et moi délimitons un périmètre, et un prix. Si c’est trop cher, nous pouvons réduire le périmètre.
Mais dans la situation évoquée avant, le client et moi avons des intérêts divergents: moi de travailler le moins longtemps possible pour investir le moins possible, et lui d’avoir le maximum de fonctionnalités pour que son offre soit la plus sexy possible.

Par ailleurs, je ne suis pas un investisseur. Je ne dispose pas d’une réserve pécuniaire suffisante pour travailler des mois pour un gain potentiel. D’autant plus qu’avant d’investir, on se doit d’évaluer le potentiel du projet, et surtout l’équipe.
Parce qu’en pratique, ce que j’ai pu souvent observé, c’est que le porteur de projet n’y apporte rien qu’une idée, une vague expérience et un vague réseau professionnel. À me demander quel serait mon intérêt de m’associer avec un tel partenaire: c’est moi qui travaille et nous devons nous partager les gains.

(Je précise que la phrase précédente ne s’applique pas forcément à vous. En fait, je ne sais rien de votre situation, vous avez sans doute plus qu’une idée, d’autant plus que votre projet a l’air déjà assez avancé).

Bref, j’espère que vous ne m’en tiendrez pas rigueur, et j’ai pris le temps de vous écrire en toute honnêteté le fond de ma pensée; j’espère que cette honnêteté vous aidera à comprendre pourquoi il vous sera difficile de trouver un développeur iOS qualifié pour votre projet. Mais pourquoi pas aussi éventuellement à convaincre un éventuel développeur qui serait éventuellement prêt à se lancer dans l’aventure.

Amicalement,
Renaud

Reading Barcodes on iOS 7

iOS 7 introduced APIs to read bar codes using the camera. I could have easily overlooked it without this excellent post from doubleencore.

NSHipster provided sample code, but it missed some details to work. Here is a sample which does.

Sample code

Pitfalls

The issue I had with NSHipster’s sample code is the delegate method was not called at all. I quickly understood this was because the AVCaptureMetadataOutput must be configured to tell which metadata to recognise.

But, and this was not obvious to me, -[AVCaptureMetadataOuput setMetadataObjectTypes:] must be called after -[AVCaptureSession addOutput:]. Otherwise, the following message shows in the console:

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[AVCaptureMetadataOutput setMetadataObjectTypes:] - unsupported type found.  Use -availableMetadataObjectTypes.'

I did try to look at the output of -availableMetadataObjectTypes, and it returns an empty array.

Therefore, -addOuput: must be called before setMetadataObjectTypes. In retrospect, it makes sense: the output object must know it is linked to a video session to know which metadata it may provide.

iOS et les comptes utilisateurs

Un élément de iOS qui semble faire bondir nombre de développeurs est l’absence de comptes utilisateurs. Évidemment, iOS est un Unix BSD comme l’est Mac OS X, les comptes au sens Unix y existent donc bien, simplement l’utilisateur n’y a pas accès: il n’existe qu’un seul compte, lancé au démarrage. Tout le propos de mes homologues est que si un téléphone mobile est un objet personnel, il n’en n’est pas de même pour l’iPad, qui peut être partagé par toute la famille (cette affirmation est déjà à prouver). Chaque utilisateur devrait donc disposer de son propre espace personnel, privé et ajusté à son goût. Ils pensent donc qu’à terme les comptes utilisateurs seront intégrés à iOS. Je n’y crois pas un instant.

Je comprends tout à fait l’intérêt des comptes utilisateurs; sur mon Mac se trouvent trois comptes. Je travaille au quotidien sur un compte non-administrateur, pour deux raisons:

  • pour des questions de sécurité
  • parce que les utilisateurs de mes logiciels ne sont pas forcément administrateurs de leur machine. Je dois m’assurer du bon fonctionnement de mes logiciels dans cette circonstance.
  • Par ailleurs, ma compagne dispose de son propre compte, ce qui m’évite qu’elle m’impose son fond d’écran avec des poneys !

Si je n’y crois pas, c’est parce que je constate que le grand public n’à que faire de plusieurs comptes. Cette affirmation est étayée par mon expérience personnelle, en rendant visite à mes amis non-spécialistes de l’informatique, dont la machine se ”logge” automatiquement sur le compte par défaut. Une autre preuve est que j’ai inclus dans PortraiMatic la possibilité de déplacer la galerie des portraits. Mon intention était de permettre le partage de la galerie entre plusieurs comptes utilisateurs. Or, je n’ai jamais reçu de plaintes de clients à son propos. Vous pouvez penser que l’utilisation de cette fonction est limpide et qu’elle marche impeccablement… Je reste persuadé qu’elle n’est quasiment pas utilisée, les utilisateurs n’ayant qu’un seul compte.

Mais si je ne crois vraiment pas que les comptes utilisateurs arriveront sous iOS, c’est à cause de la philosophie d’Apple: ils ont déjà décidé que les utilisateurs n’avaient pas accès au système de fichier pour des questions de simplicité. Avoir plusieurs comptes utilisateurs crée des problèmes au quotidien. Par exemple, chez moi, les bibliothèques iPhoto et iTunes sont placées dans le compte Partagé pour que ma compagne puisse y accéder. Il faut donc régler les autorisations Unix. C’est déjà rébarbatif pour un programmeur qui sait jouer du ”chmod”, mais pour un utilisateur moyen, c’est un obstacle. Malgré tous les avantages des comptes utilisateurs, ils créent des difficultés dans l’utilisation.

Ne projetons pas nos désirs d’informaticiens sur l’utilisateur moyen: il ne veut pas savoir comment marche la machine. Même s’il devra changer régulièrement la photo de fond d’écran.