Commentaires : Cet ancien ingénieur d'Apple révèle pourquoi il était impossible de copier/coller du texte sur le premier iPhone

En 2007, Steve Jobs levait le voile sur un appareil qui allait à jamais changer nos habitudes : l’iPhone. Mais cet appareil, aussi révolutionnaire fût-il à son époque, ne permettait étrangement pas de copier/coller du texte. Un mystère qui vient enfin d’être élucidé, près d’une décennie et demie plus tard.

2 « J'aime »

De mémoire il a fallu attendre iPhone OS 3 pour avoir le copier coller, ce fut long.
Par contre, on parle du premier iPhone, mais c’est le deuxième (iPhone 3G) qui illustre l’article.

5 « J'aime »

Malgré leurs milliards et leurs ingénieurs , ils n’avaient pas le temps de mettre la fonction simple copié/coller .
C’est une blague?

11 « J'aime »

Il me semble que l’on ne pouvait pas enregistrer de vidéos non plus. Mais vu les tailles de mémoire des iPhones de l’époque…

Tu es du genre a penser qu’en mettant deux fois plus d’argents et d’ingénieurs, un projet va avancer deux fois plus vite ? Si c’était aussi simple…

5 « J'aime »

Ben oui, le temps ne s’achète pas, et en 2007 il n’avait pas autant de milliards qu’aujourd’hui ! même pas sûr qu’Apple valait 1 milliards à cette époque…

3 « J'aime »

+1. Comme on dit souvent, si c’était aussi simple, 9 femmes arriveraient à faire un bébé en 1 mois :rofl:

11 « J'aime »

Comme souvent le « premier » n’est pas vraiment le premier au sens chronologique mais le premier à avoir démocratisé le concept. Il y a aussi la question de la définition exacte de ce qu’est un smartphone, qui est encore assez floue. Est ce que les windows phones de l’époque remplissaient vraiment tous les critères pour mériter cette appellation ?
Ce qui compte c’est que l’histoire actera que l’iPhone était le premier smartphone alors que tout le monde aura bientôt oublié les windows phones.

1 « J'aime »

Perso je dirais même qu’ils les remplissent PLUS que les premiers iPhone… L’un des critères fondamentaux qui distinguent un « smartphone » d’un « feature phone », pour moi c’est le fait que les fonctionnalités du smartphone ne sont pas figées en usine par le constructeur, elles s’adaptent aux besoins de l’utilisateur par l’installation d’applications répondant à ces besoins.

Or alors que les Windows Mobile (puis Windows Phone) ou Symbian dès le début des années 2000 offraient cette possibilité, ce n’était pas le cas du premier iPhone, et Steve Jobs insistait même sur son opposition à ce principe (avant de faire volte face sous la pression du jailbreak).

Le terme « smartphone » a d’ailleurs bien été inventé bien avant l’iPhone, et popularisé à l’époque de ces Windows Mobile et Symbian. Dès 2003, Windows mobile a été décliné en deux éditions, « Windows Mobile 2003 for Pocket PC », destiné aux PDA, et « Windows Mobile 2003 for Smartphone », destinés aux smartphones.

Ce qui a changé avec l’iPhone, c’est que les smartphones se sont mis à viser le grand public, alors qu’avant ils visaient surtout les professionnels. Et c’est pour ça que le grand public voit l’iPhone comme le premier smartphone. Parce que avant, ils ne connaissaient pas les smartphones.

1 « J'aime »

Moi j’oublie pas le N900 ^^

Les premiers smartphone Qtek sur Windows CE le Qtek s9090 et perso le s100 que j’avais on faisait déjà du couper copier coller :joy: et les GPS Mio on pouvait les modifiés ct Windows ce aussi… L’ingénieur apple avait voulu dire qu’il n’a pas réussit à convertir c++ en java :joy: mais peut être qu’il connaissait pas le raccourci clavier tout simplement

Oui, j’aurai du dire tout le monde sauf ceux qui en ont possédé un.

Votre réponse au sujet des 9 femmes enceintes pour comparer le travail de 2 fois plus d’ingénieurs, est vraiment… idiote.
Bien sûr qu’en doublant le personnel de développeurs, on gagne du temps. Il suffit qu’un développeur s’occupe de la routine du copier-coller, pendant que les autres peaufinent les autres fonctions.
Un OS est un ensemble de pièces détachées qu’on peut modifier individuellement à souhait sans aucun risque pour le noyau de l’OS.

Passé un certain seuil, non. Parce qu’au bout d’un moment, ajouter des développeurs supplémentaires fait perdre plus de temps aux autres développeurs (parce qu’il faut consacrer du temps à la « synchronisation » entre les différentes sous-tâches) que le temps qu’apporte ce développeur supplémentaire.

Et c’est en raisonnant comme ça qu’on se retrouve avec un ensemble sans aucune cohérence et avec des bugs de partout parce que ça explose à chaque interface…

4 « J'aime »

Je ne pense pas que la routine du copier-coller ralentisse la vitesse du compilateur de l’OS. Donc perte de temps dérisoire.

Tu n’as visiblement jamais travaillé sur du développement en équipe…

Quand je parle de perte de temps pour les autres, je ne parle pas de l’augmentation du temps de compilation parce qu’il y a un peu de code supplémentaire. Mais du temps que les autres doivent consacrer pour accueillir ces développeurs supplémentaires (un développeur, c’est pas un truc magique que tu met sur un projet et qui est directement productif, il faut que l’équipe en place consacre du temps à le former aux procédures internes de l’équipe, aux outils utilisés, à la base de code, etc… tiens dans mon équipe actuellement il y en a un qui est en arrêt pour 6 mois, on a jugé que ça ne valait pas le coup de prendre un prestataire pour le remplacer, parce que sur quelques mois on n’arrivera pas à « amortir » le coût initial, on en fera moins en intégrant un prestataire qu’en continuant avec un effectif réduit jusqu’au retour du collègue), et du temps qu’il faut consacrer aussi pour interfacer ces développements supplémentaires avec le reste. Parce que s’il s’agit juste de pondre une routine de copier-coller dans son coin, oui, ça peut se faire. Mais ça servira à rien. Parce que cette routine de copier-coller, il faut l’intégrer dans l’UI et dans l’UX pour qu’elle serve à quelque chose. Ce qui éventuellement peut du coup impacter d’autres fonctionnalités qu’il faut déplacer, etc, etc…

Donc non, ajouter le copier-coller en recrutant un développeur supplémentaire pour le faire sans délai supplémentaire sur le reste, ça ne marche pas.

Accessoirement, il se pose aussi un autre problème en ajoutant des ressources supplémentaires : on en fait quoi quand il n’y en a plus besoin ? En termes de gestion des ressources humaines, sur un projet qui va vivre pendant des années, il est bien plus intelligent de lisser un peu la charge sur la durée, pour limiter les variations d’effectif, plutôt que de concentrer 95% de l’effort la première années puis de ne garder que 5% de l’équipe les années suivantes…

Et c’est aussi plus intelligent en terme de « protection industrielle ». Parce que les 95% que tu vires, ils ont une certaine connaissance de tes produits, qu’ils vont aller vendre à prix d’or à la concurrence, qui sera ravie d’embaucher ce personnel, formé à tes frais et connaissant tes secrets industriels.

2 « J'aime »

Ils n’avaient apparemment pas eu le temps d’implémenter les MMS ni un vrai GPS fonctionnant hors ligne, alors que d’autres téléphones bien plus anciens (chez Nokia notamment) faisaient tout ça.

1 « J'aime »

Oui mais développer, corriger, redeveloped, recorriger, reredeveloper… ah non pardon ça c’est la méthode agile et scrum.

Le when it’s done c’est bien mieux pour l’utilisateur et la boîte à moyen et long terme. Sauf que l’actionnaire ça le fait chier d’attendre.

1 « J'aime »

C’est l’iPhone 4 qui avait mis les bonnes bases. Mais faire une UX tactile au doigt est bien plus compliqué à implémenter qu’une application de cartographie que l’on détient. (Here pour Nokia)

1 « J'aime »

On parle quand même de la société Apple… Soit-dit en passant. Trouver des développeurs déjà opérationnels (c’est quand même un noyau de base unix, assez courant) pour le salaire proposé qui doit être loin de notre SMIC, ne devrait pas être un gros problème pour Apple. Je pense même que ça doit se bousculer.
Donc ne prenez pas votre société pour un modèle, surtout si c’est une société française où tout le monde sait ça, il vaut mieux être en maladie que bosser pour un salaire quasi identique.