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

dopop version 1

J’en avis déjà parlé ici et , mon application iPhone pour apprendre le solfège est disponible. Le mieux pour voir à quoi ça ressemble est d’aller voir le site officiel:

dopop.net

Pour l’instant, l’application ne comporte qu’un seul jeu, qui s’appelle « Quelle est cette note ? ». Les autres jeux arriveront au fur et à mesure, de même que les améliorations de l’existant. Pour l’instant, je me suis avant-tout attaché à faire un premier jeu jouable, intéressant et pédagogique.

Je vais partager les difficultés que j’ai eu lors du développement de cette première version de dopop.

 Sprite Kit

La première version était jouable en juin. Cependant, elle était basée sur l’animation de UIViews, et même si j’aurais pu en rester à cette solution, je lui trouvais plein de défauts:

  • le code était crade
  • les animations étaient parfois étranges, en particulier à cause des courbes Ease in-out de Core Animation.
  • il était difficile de faire des transitions d’écran, ou même d’ajouter des petits éléments marrants.

Ce que j’aurais pu faire était d’utiliser Cocos2D dès le départ, seulement, je n’aime pas cette bibliothèque dont les API sont mal fichues et l’intégration avec UIKit encore pire. Quand Apple a annoncé Sprite Kit à la WWDC, j’ai tout de suite essayé et j’ai été séduit.

Je ne regrette pas cette décision, même si elle a le défaut de limiter le jeu à iOS 7. Finalement, Sprite Kit a bien eu quelques bugs et quelques incohérences dans sa conception, mais tous mes radars furent corrigés pendant l’été, y compris ceux relatifs à Xcode 5.

Sprites et polices de caractères

Ceci m’a fait perdre beaucoup de temps. Je voulais utiliser un format vectoriel pour les notes et la portée. Mon idée était de créer une police de caractère pour cela. En pratique, dessiner les éléments dans Sketch fut rapide, par contre, il fallait utiliser un logiciel pour créer la fonte, et là c’est la cata. En gratuit, le moins pire est FontForge, mais il faut l’installer avec MacPorts, il fonctionne sous X11, et ça se voit.

Ensuite, je pouvais certes dessiner la portée avec la fonte, mais il y avait toujours des problèmes de taille ou d’alignement, d’un pixel ou un demi-pixel. Un beau jour, je me suis dit: « fini c’est conneries ! ». J’ai exporté mes graphismes en bitmap, je les ai mi dans le projet Xcode et je n’ai plus eu de problème.

La leçon apprise: les sprites, par définition, sont des bitmaps.

Niveaux

Une des difficultés quand on crée un jeu vidéo, est qu’il faut définir les niveaux. Pour ma part, j’ai créé un langage un peu spécial pour cela. Par exemple:

  • Les [ ] délimitent le niveau.
  • T=76 indique le tempo.
  • F3 G3 A3 B3 C4 sont des notes (une lettre qui donne le nom de la note, suivie de l’octave).
  • Enfin, %12 indique qu’il va falloir répéter aléatoirement ces notes 12 fois.

Ce système me permet de décrire précisément le niveau, tout en n’ayant pas à écrire toutes les notes (dans cet exemple il y a 5×12 = 60 notes).

La première difficulté fut de créer un parseur pour ce format. Je n’avais aucune expérience dans ce domaine. Au final, je m’en suis sorti avec des regex et une sorte de machine d’état.

La deuxième difficulté fut de doser la difficulté: les premières versions était quasiment injouables. Il a aussi fallu réduire la durée des niveaux. Vous verrez que le jeu est encore assez difficile, et que vous perdrez souvent: c’est normal. On gagne quand on sait les notes, or cela demande des répétitions pour mémoriser.

Son des notes

Là encore, une grosse perte de temps. Il est important dans le jeu que les notes soit dites. En effet, le but n’est pas que vous deveniez bon à taper sur le clavier à l’écran, mais vous mémorisiez les noms des notes.

Mon idée de départ était de m’enregistrer à chanter toutes les notes: do ré mi fa sol la si, mais aussi A B C D E F G, puisque le logiciel permet de changer de notation. Il fallait le faire pour toutes langues. Le résultat fut décevant. Franchement, c’était horrible, tous les testeurs me l’ont dit.

Une deuxième piste était de créer un synthétiseur vocal chantant. J’ai fait un peu de recherche, et même si ce que je voulais restait simple, j’ai vite compris que c’était un travail bien trop gros. Au final, la version actuelle est un compromis: j’ai utilisé le synthétiseur vocal introduit par Apple dans iOS 7, et je joue la note en même temps.

D’ailleurs, jouer la note n’a rien de simple. Je ne suis pas certain que ce soit la technique la plus facile, mais j’ai carrément créé un synthétiseur basé sur une AudioQueue. Le synthé sonne vraiment bien, c’est une grande fierté.

Organisation

C’est la première fois que j’écris un jeu vidéo. J’avais bien quelques idées sur la manière de faire, mais pas vraiment d’expérience. La difficulté fut donc de savoir comment organiser l’appli. Déjà, j’ai respecté le principe du MVC, avec succès. Ensuite, la conception a émergé progressivement, au fil des remaniements. Au final, ce n’est pas parfait, mais c’est assez modulaire, assez gérable.

Achats in-app

Étant dans le cas le plus simples (achats non-renouvelables), je pensais que ce serait vite réglé, en fait, ça m’a pris une semaine. Pour ceux qui n’en n’ont jamais faits, disons qu’il faut gérer la transaction, et surtout, présenter tout ça dans une interface utilisateur perso, Apple ne fournissant rien de standard.

Au final, le code n’est pas très lourd, mais il y a un tas de petits détails à régler. La doc d’Apple est répétitive et manque d’exemples (comment savoir si un achat a déjà été effectué ?).

Voilà, si vous avez des questions ou des commentaires, ils sont les bienvenus.

Une fenêtre qui change de view controller

Ce billet intéressera les programmeurs débutants sur le Mac. Je vais ici vous montrer comment passer d’un panneau à un autre, chacun défini dans son propre xib et géré par une sous-classe de NSViewController.

Capture d’écran 2013-09-16 à 10.09.24

Création du projet et mise en place de la toolbar

J’utilise Xcode 5. Commencez par créer un projet d’application pour Mac.

J’ajoute deux images de 32 x 32 pixels, qui serviront d’icônes pour la toolbar:

Square Circle

 

 

Xcode a créé un premier MainMenu.xib pour votre appli, comprenant une barre des menus et surtout une fenêtre.

Nous allons ajouter une NSToolbar à cette fenêtre. Pour cela, il suffit de glisser une toolbar depuis la rubrique Object Library (dans le coin inférieur droit de la fenêtre de Xcode) vers la fenêtre. La toolbar comporte déjà des icônes. Configurez-la pour qu’elle présente deux icônes en son centre:

Capture d’écran 2013-09-16 à 09.33.27

Pour cela, supprimez tous les NSToolbarItems présents,  glissez de nouveaux items, puis configurez-les.

Maintenant, tirez des actions allant de chaque icône vers l’AppDelegate.

 Création des panneaux

Chaque panneau sera géré par un view controller et sera contenu dans un xib.

Commencez par créer une sous-classe de NSViewController (que j’appelle CECustom0ViewController):

Capture d’écran 2013-09-16 à 09.42.16

Éditez CECustom0ViewController.xib. Ajoutez simplement une NSBox et fixez son titre pour savoir de quel xib il s’agit:

Capture d’écran 2013-09-16 à 09.43.50

Créez une deuxième sous-classe de NSViewController sur le même principe (CECustom1ViewController).

Passage d’un view controller à l’autre

Pour gérer le changement de view controller, je créé une classe CEViewControllerSwitcher, qui hérite de NSObject:

CEViewControllerSwitcher.h

CEViewControllerSwitcher.m

Liaison avec l’AppDelegate

CEAppDelegate.m

C’est terminé !

Voilà, ça fonctionne, on passe bien d’un View Controller à l’autre. Il s’agissait de la technique de base, je vous laisse régler l’autolayout des vues pour qu’elles remplissent bien la contentView de la fenêtre comme on le souhaite.

Le projet Xcode complet: ChangeVues

 

(Encore un article sur) le retrait de l’application Appgratis

Comme vous avez sans doute pu le lire à divers endroits, l’application Appgratis a été supprimée la semaine dernière par Apple.

Si, comme moi, vous ne connaissez ni l’application ni son site web, rappelons qu’il s’agit d’une application qui répertorie tous les jours des applications gratuites «sélectionnées». Comme l’application disposait d’une audience significative, elle avait la faculté d’influencer — de façon artificielle — sur le nombre de téléchargements d’une application et par conséquent sur son classement sur l’App Store. D’où son retrait.

Ce sont les événements qui ont suivi qui m’ont intéressés: une plainte publique de la part du dirigeant d’Appgratis, suivie de l’intervention de Fleur Pelerin, la ministre de l’Économie numérique.

L’affaire Coyotte

Cette affaire a éveillé en moi un parallèle avec une autre affaire: celle des avertisseurs de radars. Quand les radars automatiques ont été mis en place, le législateur a laissé la liberté de rendre publics leurs emplacements. L’idée dominante de la loi est qu’un radar a pour vocation de sécuriser une zone; ainsi, que les usagers de la route soient avertis de sa présence les incite à ralentir, et la sécurisation de la zone est assurée.

Peu après est apparu le célèbre Coyotte, un avertisseur de radars français qui embarquait une liste des radars. Je voudrais  faire une mise au point: quand on est chef d’entreprise, on rencontre des opportunités et on décide s’il est judicieux de les saisir ou non. Dans le cas de Coyotte, les dirigeants ont vu l’opportunité de créer un avertisseur de radars et savaient que le marché était juteux. D’un autre côté, ils savaient que la législation risquait de changer, mais ils ont quand même tenté leur chance, parce qu’ils espéraient profiter de la manne au moins quelques années.

Ce qui devait arriver, arriva. Sous la pression du ministère des finances des associations contre la violence routière, le gouvernement semblait enclin à interdire les avertisseurs de radars. Or, ce changement de position était prévu dès le départ par Coyotte, aussi avaient-ils déjà préparé leur défense, avec un argument simple: modifier la loi mettrait fin aux activités de Coyotte, aux emplois de ses salariés, des ses sous-traitants, et à l’activité indirecte générée.

Si un ministre avait vocation à se positionner sur des questions de société, un choix aurait été fait: soit interdire les avertisseurs de radars, pour renforcer la sécurité routière quitte à perdre quelques emplois, soit continuer à les autoriser, ne remettant pas en cause l’esprit initial de la loi et préférant la liberté individuelle. Mais un ministre a plutôt vocation à trouver un consensus mou.

Au final, il fut décidé de ne pas décider: les « avertisseurs de radars » sont devenus des « avertisseurs de zones de danger », zones qui incluraient les zones où se trouvent les radars, et une liste d’autres zones qui serait publiée, eh bien… un jour peut-être.

L’affaire Appgratis

Ce détour par l’affaire Coyotte m’amène à faire un parallèle avec Appgratis. Au départ, Appgratuites est un simple blog qui parle des nouvelles applications iPhones gratuites. L’audience devenant croissante, les éditeurs d’application sont devenus prêts à payer pour apparaître sur le blog. Voilà pour l’opportunité, que le dirigeant d’Appgratis a fort bien exploitée.

Mais, il savait forcément qu’il y avait un risque: comme cette forte audience modifie artificiellement les classements de l’App Store, Apple pouvait prendre la décision de retirer leur application pour rééquilibrer la situation.

Le jour où l’application est finalement retirée, Appgratis exécute son plan, forcément préparé depuis longtemps: faire le maximum de bruit. Soyons clairs, il est improbable qu’Apple revienne sur sa décision, et cette plainte publique ne la fera pas changer d’avis. Contrairement à un ministre, Apple se moque pas mal que quelques français perdent leur emploi, n’a pas à trouver de consensus, ni entreprendre des pourparlers. Par contre cette affaire permet de faire causer la presse et les blogs (comme le mien!) et faire découvrir Appgratis, qui va finalement proposer une autre solution technique pour présenter les  applications.

La question subsidiaire est: Que vient faire Fleur Pelerin dans cette histoire ? Eh bien, son boulot de ministre. Elle sait elle aussi qu’Apple ne va pas plier devant des menaces de porter plainte devant le commission européenne, mais elle ne veut pas être taxée d’inaction. Aussi lui faut-il défendre le gentil Appgratis de la méchante Apple. Au moins, si Appgratis venait à fermer boutique, elle aura fait ce qui était en son pouvoir.