Lors des dernières mises à jour que nous avons faites sur des applications iPhone (iPad), nous avons été confrontés à une nouvelle problématique que l’on croyait réservée aux développeurs Android. Depuis la version 4 du SDK de l’iOS, il apparait indispensable de tester les versions sur les versions 3.x de l’iOS pour éviter de se retrouver face à des instabilités qui n’existaient lors des compilations précédentes.

Il est donc indispensable de conserver les anciens périphériques sous des versions anciennes de iOS. En effet, d’après l’article de Casey Tschida, il y aurait encore, une dizaine d’utilisateurs sur cent avec une version 3.x de l’iOS sur iPhone. Beaucoup d’utilisateurs n’ont pas mis à jour leur iPhone en version 4 car les iPhone 3G sont particulièrement lents sur ces nouvelles versions d’iOS. Cette cible n’est donc pas négligeable et ne doit pas être négligée. De plus, ces instabilités peuvent entraîner très rapidement des commentaires néfastes sur l’AppStore.

Chez I See U, comme vous pouvez le voir sur la photo, nous avons mis tout en oeuvre pour assurer une compatibilité maximale en utilisant un maximum de périphériques de test sous différentes versions d’iOS. Notre seul souci reste de les mettre tous à la même heure.

Et vous, avez-vous déjà rencontré des soucis avec des applications sous iOS 3.x?

Les notifications Push sont des petites alertes envoyées par les éditeurs des applications installées sur son iPhone. Ces alertes sont reçues même si l’application n’est pas active. L’utilisateur a la possibilité, à tout moment, de bloquer la réception de toutes les notifications ou uniquement celles de certaines applications.

Au sein de I See U, nous avons mis en place pour nos clients un service de Push. Nous avons souffert de quelques loupés sur la mise en place de ce service jusqu’à ce que nous mettions en place ce que je vais vous présenter ce jour : les « Enhanced Apple Push Notifications« , en d’autres termes, l’envoi avancé de notifications.

En quelques mots, comment se passe l’envoi de notifications sur votre iPhone? Le service Web de l’application envoie des messages avec un formalisme défini et signé numériquement aux serveurs d’Apple. Les messages sont entassés dans une file d’attente chez Apple. Ils seront dépilés par la suite en fonction de la charge des serveurs d’Apple. Le mécanisme d’envoi de notifications n’est donc pas synchrone. Si un deuxième message est envoyé pour le même périphérique alors que le premier n’a pas encore été délivré, seul le deuxième sera envoyé au périphérique. Il peut donc arriver que toutes les notifications ne parviennent pas au destinataire. Pour les informations critiques, Apple conseille d’utiliser un autre canal pour informer l’utilisateur (mail, message interne à l’application, …)

La cinématique d’envoi des notifications classiques aux serveurs d’Apple est la suivante :

• Ouverture d’un canal d’échange crypté avec les serveurs d’Apple. Le cryptage se fait grâce à un certificat généré sur le portail de développement.
• Envoi des messages au formalisme suivant :

• Si une erreur se produit, il faut recréer une connexion avec le serveur et continuer l’envoi.

Sur Internet, on trouve certaines personnes qui conseillent d’envoyer les notifications par lot et de clôturer la connexion pour en recréer une aussitôt. Il faut alors décider du nombre de messages envoyés par lot. La bonne pratique semble être d’un millier environ.

Dans ce mode standard, nous n’avons aucun retour sur l’envoi réel des notifications. Nous savons juste que les messages ont été envoyés à Apple.

Ce mécanisme n’était pas acceptable pour nous qui souhaitions fournir un service d’envoi fiable d’autant plus que nous avions remarqué quelques échecs sur certains périphériques. Nous avons donc étudié la solution avancée qui permet de recevoir quelques retours de la part d’Apple.

La cinématique devient donc la suivante :

• Boucle tant qu’il y a des notifications à envoyer
• Ouverture de la connexion sécurisée avec les serveurs d’Apple
• Envoi de n (1000 dans notre cas) notifications avec le formalisme suivant

• Lecture du canal SSL ouvert avec les serveurs d’Apple pour récupérer les potentielles erreurs
• Interprétation des informations renvoyées par Apple au formalisme suivant

• Traitement adéquat s’il y a des erreurs
• Si coupure de la connexion, réouverture (comme en mode standard)
• Fermeture et réouverture de la connexion pour boucler

Grâce à ce mode avancé, nous avons donc plus d’informations sur les éventuelles erreurs. Voici les codes erreur renvoyés :

• 0 : Pas d’erreur rencontrée
• 1 : Erreur de traitement
• 2 : Le « token » du périphérique est manquant
• 3 : Le « topic » du périphérique est manquant
• 4 : Le « payload » du périphérique est manquant
• 5 : La taille du « token » est invalide
• 6 : La taille du « topic » est invalide
• 7 : La taille du « payload » est invalide
• 8 : Le « token » est invalide
• 255 : Inconnue

Lors de nos expérimentations, nous avons remarqué que si une erreur se produisait sur un des messages d’un lot de 1000, les notifications devant être envoyées après celles en erreur n’étaient pas reçues. Nous n’avons trouvé aucune information sur ce point dans la documentation et donc cette information est à prendre avec précaution. Dans nos cas, nous renvoyons donc les notifications qui ont lieues après une erreur dans un lot.

Depuis la mise en place de ce mécanisme, nous n’avons plus de souci avec les notifications.

Si vous aussi vous avez rencontré des soucis avec les notifications Push d’Apple, nous serions ravis d’échanger avec vous sur le sujet.

Source : Documentation Apple

Dans une des applications que nous développons pour l’un de nos clients, nous sommes en train de mettre en place une fonction, appelée In App Purchase chez Apple, qui permet d’acheter du contenu numérique ou des fonctions avancées au sein même d’une application iPhone ou iPad avec son compte iTunes. Lors de sa mise en place et de nos premiers tests dans cette application déjà présente sur l’AppStore nous avons été bloqués quelques heures car tous les produits déclarés au sein d’iTunesConnect n’étaient pas reconnus en développement (sandbox).

Voici une liste de points à vérifier pour tester l’InAppPurchase en mode développement si les produits apparaissent dans le tableau invalidProductIdentifiers:

• S’assurer que tous les requis financiers ont été complétés : Contrats, taxes et informations bancaires.
• S’assurer d’utiliser un nom d’application explicite (fr.isee-u.monapplication) et non un nom générique (fr.isee-u.*).
• S’assurer d’utiliser un mobile provision associé à ce nom d’application explicite.
• S’assurer d’interroger les identifiants produits corrects. Attention à la casse.
• S’assurer que les produits ont bien été mis à la vente. Option « Clear for sale » dans iTunesConnect.
• S’assurer que les modifications sur les produits dans iTunesConnect ont été effectués il y a quelques heures. En effet, il faut un certain temps pour que les informations saisies dans iTunesConnect sur les produits soient prises en compte.
• S’assurer que le dernier binaire uploadé dans iTunesConnect n’ait pas été rejeté par vous ou Apple.

Ces points sont ceux fournis dans la documentation officielle d’Apple mais il convient d’en vérifier d’autres (informations trouvées au fil de mes recherches) :

• Le test de l’InAppPurchase ne peut s’effectuer que sur un périphérique physique et non au sein du simulateur.
• Il faut créer un compte de test dans iTunesConnect pour pouvoir acheter des produits sans être facturé à des fin de tests.
• Il faut se déconnecter de l’iTunesStore sur le périphérique mais ne pas se reconnecter avec son utilisateur de test.
• Si votre application est une application déjà sur l’AppStore, veillez à la désinstaller du périphérique pour pouvoir pousser la version de développement de façon propre.

C’est ce dernier point qui était à l’origine de nos soucis. Dans le cas où vous avez laissé l’application originale, l’application va contacter l’AppStore et non la sandbox pour les tests. Vos produits ne seront accessibles, dans un premier temps, que dans la SandBox. Une fois qu’ils auront été testés, ils pourront être soumis à Apple pour publication sur l’AppStore.

Nous espérons que ces quelques rappels serviront au plus grand nombre et qu’ils feront gagner un temps précieux aux personnes rencontrant les mêmes problèmes.