›

Aide sur le business model de mon app

RomheinRomhein Membre
dans Commerce, marketing #1

Bonjour à  tous !


 


J'aurais besoin d'aide sur mon business model, j'arrive pas trop à  me décider sur ce qui serait le mieux...


 


La situation :


Mon appli s'appelle Widget Kit.Je propose pour l'instant 16 widgets accessibles dans le centre de contrôle. L'idée c'est d'en ajouter au file des mises à  jour. 


 


Les différentes idées de rémunération :


 


-L'application est gratuite, mais tous les widgets seront bloqués. J'offre 5 étoiles à  la première ouverture, permettant à  l'utilisateur de débloquer les widgets qu'il souhaite. Ceux qui l'intéressent le plus. En général ça lui permettra d'en débloquer 3, le prix en étoile des widget oscillant entre 1 et 3. 


Les achats in-app serait alors :


5 étoiles de plus pour 0.99€/$


15 étoiles de plus pour 1.99€/$


30 étoiles de plus pour 2.99€/$ ( ce dernier donne plus que la somme totale des widgets, mais j'ai 5 autres widgets dans les fourneaux, et encore d'autres en idée)


 


problème de ce mode c'est que j'utilise une monnaie intermédiaire. D'autre part je veux qu'un utilisateur ayant acheté des étoiles en profite sur toutes ses devices. Or mon serveur est assez faiblard, et j'ai peur qu'il tombe en rade quand qqn voudra restaurer ses achats...


 


-Faire un classique : version pro à  2,99€


seulement je compte faire des mises à  jour et ajouter d'autres widgets. Ca serait un peu injuste de mon point de vue de plus me rémunérer de mon travail :/ (après c'est mon point de vue ^^)


 


Voila si vous avez des idées je suis preneur.


 


Mots clés:

Réponses

  • jpimbertjpimbert Membre
    #2

    La monnaie intermédiaire ne me semble pas être un problème. Ce qui serait un problème c'est que les étoiles soit achetables directement ou indirectement depuis l'application sans passer par InApp Purchase et les 30% d'Apple.


  • RomheinRomhein Membre
    #3

    ahhh ok, c'est pour ça que certaine app ont ce système... ok donc ça posera pas de problème alors :)


    Le seul problème c'est la complexité d'implémentation avec un serveur en plus, et surtout la maintenance du service de récupération dans le temps! C'est ce qui me fait le plus peur.


    J'aimerai bien trouver une solution d'in app non consommable, ça me faciliterai tellement la tâche.


  • DrakenDraken Membre
    #4

    CloudKit, peut-être ?


  • RomheinRomhein Membre
    #5

    Et l'utilisateur n'a pas moyen de supprimer les données ? quand par exemple il supprime l'application. J'ai lu un article comme quoi apple avait reset une fois les données présentes avec cloudkit.


    J'ai jamais utilisé cloudkit, en gros je vais y entrer tous mes utilisateurs et ce qu'ils ont acheté ?


    Par exemple la structure serait toute bête du style :


    id utilisateur - nombre de packs 5 étoiles achetés - nombre de packs 15 étoiles achetés - nombre de packs 30 étoiles achetés


  • DrakenDraken Membre
    #6

    Je n'ai jamais regardé CloudKit de prés, mais cela semble être la solution à  ton problème. Et effectivement, Apple a effacé les données quand le nuage a quitté le statut de bêta, pour entrer en service normal, ce qui me semble logique. L'avantage c'est que tu n'as pas à  gérer toi même le serveur.


  • RomheinRomhein Membre
    #7

    Effectivement ça me parait être la solution, je suis entrain de travailler dessus. Merci pour la solution, c'est cool :)


  • RomheinRomhein Membre
    #8

    Dernière question, comment je fais pour garder une référence de mon utilisateur. 


    Par exemple M.Widget achète un de mes pack. L'utilise, puis change de d'iphone. 


    L'idée c'est de lui redonner son (ou ses) pack(s) pour qu'il puisse redébloquer les widgets, mais comment je sais que c'est lui ?


  • DrakenDraken Membre
    #9

    Il garde le même identifiant AppStore, non ? 


  • RomheinRomhein Membre
    #10


    Il garde le même identifiant AppStore, non ? 




     


    en théorie oui mais mais en pratique il peut sans problème changer son id apple (je l'ai fais dernièrement sur le miens).

  • DrakenDraken Membre
    #11

    Les achats sont liés à  un compte iTunes, donc un identifiant Apple. Si tu change son nom, tu gardes tes applications. En créant un nouvel identifiant, tu perds tout ..

  • RomheinRomhein Membre
    #12

    Si je résume :


    Le prob avec ma demande c'est que c'est une solution bâtarde entre un achat in-app consommable et un non consommable.


    -les achats consommables ne sont pas gardés par apple


    -les achats consommables peuvent être achetés plusieurs fois (ce qu'il me faut)


     


    -les non-consommables sont gardés par apple (ce qu'il me faut)


    -ils ne peuvent pas être achetés plusieurs fois


     


    Donc la solution c'est de choisir les achats consommables, et de sauvegarder l'identifiant Apple de l'utilisateur dans cloudKit.


     


    Après quelques recherches, il semble impossible de récupérer l'id apple d'un utilisateur. De plus si j'y parviendrai, si l'utilisateur change son id apple, je ne le retrouverai plus dans ma bdd?


    Dis moi si je me trompe en qq part :)


  • DrakenDraken Membre
    #13

    Pour les détails techniques, tu devrais regarder des tutos sur CloudKit, comme celui-ci : 


    http://www.raywenderlich.com/83116/beginning-cloudkit-tutorial

  • RomheinRomhein Membre
    #14


    Pour les détails techniques, tu devrais regarder des tutos sur CloudKit, comme celui-ci : 


    http://www.raywenderlich.com/83116/beginning-cloudkit-tutorial




     j'étais justement sur celui là . Merci pour l'aide !

  • LeChatNoirLeChatNoir Membre, Modérateur
    #15

    A quoi va servir CloudKit ? A quoi va servir ton serveur ?


     


    Tes widgets sont tes embarquées dans ton app ? Et sur achat, tu débloques certaines.


    Si ton utilisateur change de tel, il peut restaurer ses achats donc ses widgets.


     


    Non ?

  • RomheinRomhein Membre
    mai 2015 modifié #16

    CloudKit me servira pour stocker les achats des utilisateurs (du coup je n'utiliserai pas de serveur perso). Car d'après ce que j'ai lu, on ne peut restaurer uniquement les achats non-consommables. Or les miens seront consommables.


     


    EDIT:


     


    Mais oui ! Quand on est bloqué sur idée c'est difficile de s'en défaire ! En fait je pense avoir mal compris certains postes comme celui-ci :


     


    http://stackoverflow.com/questions/6449312/iphone-in-app-purchase-consumable-correct-approach/9102416#9102416


     


    dans le cas ci dessus, la personne ne veut justement pas rendre tous les consommables, or moi c'est ce que je souhaite.


     


    Donc je n'ai qu'à  restaurer les achats et c'est bon, pas besoin de serveurs etc... 


     


    EDIT 2 : ascenseur émotionnel :


     


    StoreKit only provides recovery functionality for non-consumable items (and to some extend for subscriptions). So for consumable products, recovering using restoreCompletedTransactions will not deliver any transactions in your case. Any handling of restoring information about consumable products must be done within your app and/or server.


  • DrakenDraken Membre
    mai 2015 modifié #17

    Qu'est-ce que tu appelles ascenseur émotionnel ? C'est bien ou mauvais ?


     


    Je ne vois pas en quoi ça change la donne. C'est normal qu'on ne puisse pas restaurer les achats consommables.


     


    Exemple : je me procure le jeu Ninja contre Alien où il est possible d'acquérir des packs de shurikens explosifs en in-app. J'en achète un lot et j'explose quelques niveaux. Puis je sauve le jeu sur le cloud avant de le destinstaller et le réinstaller. Miracle j'ai de nouveaux mes shirikens, pour tuer encore et encore.. C'est pour éviter ça qu'Apple ne restaure pas les contenus consommables. 


     


    Toi, tu as besoin d'une variable "persistante", contenant une réserve de "monnaie virtuelle". Une variable qui résiste à  l'effacement de l'application, et qui puisse être accessible sur plusieurs devices partageant le même compte iTunes. Et c'est exactement ce que permet CloudKit. Quand ton utilisateur achète un pack de x étoiles, c'est un consommable "détruit" sur l'instant. A l'issue de la transaction, tu modifies le compteur de monnaie "persistent" de l'application et c'est tout. Techniquement ta monnaie persistante  n'est pas un consommable in-app, mais une donnée du programme, comme le nombre de point de vie, le score, la position du joueur dans le jeu, etc. Je prend comme exemple un jeu, parce que c'est l'utilisation la plus courante des in-apps consommables.  D'ailleurs Apple n'a aucun moyen de savoir que telle ou telle donnée "persistante" est liée à  un achat in-app.


     


    Ce que permet StoreKit, c'est de récupérer les achats non-consommables, comme le droit d'utilisation des widgets achetés. Mais tu peux aussi utiliser CloudKit pour mémoriser les droits d'utilisation. Ce n'est pas comme une application de lecteur de bandes dessinés où il faut télécharger à  nouveau les fichiers graphiques. 


  • RomheinRomhein Membre
    #18

    ok, c'est clair maintenant, la seule solution c'est donc cloudkit.


    Aller ... je fais mon chiant jusqu'à  la fin : une personne qui n'a pas iCloud d'activer pourra quand même utiliser cette méthode ( en storant dans la partie publique par exemple de cloudkit ) ?


     


    Sinon ce que je pensais faire c'est stocker dans cloudkit le nombre de packs que l'utilisateur a acheté, et du coup lui redonner toutes ses étoiles quand il réinstalle ou utilise sur une autre device. Comme ça je m'ennuie pas a enregistrer quel widget a été débloqué. Ce qui permet également à  l'utilisateur de tester un peu tous les widgets si il est malin. 


  • DrakenDraken Membre
    #19


    Aller ... je fais mon chiant jusqu'à  la fin : une personne qui n'a pas iCloud d'activer pourra quand même utiliser cette méthode ( en storant dans la partie publique par exemple de cloudkit ) ?




     


    Probablement pas. A toi de vérifier ce qui se passe et d'afficher les messages en conséquences.


     




    ok, c'est clair maintenant, la seule solution c'est donc cloudkit.




    Non, tu peux faire la même chose avec un serveur perso, mais c'est plus compliqué à  programmer. Sans parler de la gestion du serveur, et de son abonnement. Sans parler de la sécurité et des sauvegardes. Avec CloudKit c'est gratuit pour toi. Par contre, cela ne fonctionne que dans l'écosystème Apple. Une application Android ou Windows ne pourras pas accéder à  CloudKit. 


     


     




    Sinon ce que je pensais faire c'est stocker dans cloudkit le nombre de packs que l'utilisateur a acheté, et du coup lui redonner toutes ses étoiles quand il réinstalle ou utilise sur une autre device. Comme ça je m'ennuie pas a enregistrer quel widget a été débloqué. Ce qui permet également à  l'utilisateur de tester un peu tous les widgets si il est malin. 




     


    C'est si difficile que ça de sauver un dictionnaire contenant 16 données binaires ?

  • RomheinRomhein Membre
    #20

     


     


    Non, tu peux faire la même chose avec un serveur perso, mais c'est plus compliqué à  programmer. Sans parler de la gestion du serveur, et de son abonnement. Sans parler de la sécurité et des sauvegardes. Avec CloudKit c'est gratuit pour toi. Par contre, cela ne fonctionne que dans l'écosystème Apple. Une application Android ou Windows ne pourras pas accéder à  CloudKit. 

     et comme ces types de widgets sont dispo uniquement sur iPhone, la question se pose plus :)


     



     


     


    C'est si difficile que ça de sauver un dictionnaire contenant 16 données binaires ?

    dis comme ça effectivement, c'est juste qu'il faut que je change la logique de mon appli


     


    Merci pour ton temps et ton aide en tout cas, c'est vraiment sympa ! Normalement j'ai tout ce qu'il me faut ;)


  • GeoffreyGeoffrey Membre
    #21

    Un mode "simple" : 3 widgets gratuits que TOI tu auras décidés - Pro (à  4€) : tous les widgets me parait mieux.


     


    Je viens de tester un mode similaire pour Kwit et c'est vraiment concluant, et surtout beaucoup moins complexe pour toi à  mettre en oeuvre.


  • RomheinRomhein Membre
    #22

    Oui effectivement j'y ai pensé. Finalement j'ai terminé l'implémentation des in-app comme je l'ai décrit dans le premier poste. C'est effectivement plus compliqué, mais ça garde l'avantage de laisser le choix à  l'utilisateur de débloquer les widgets qu'il souhaite avec ses 5 étoiles de départ. L'autre avantage assez important c'est que si je rajoute du contenu, l'utilisateur peut être amené à  acheter d'autres étoiles pour débloquer un nouveau widget qui l'intéresse, c'est principalement pour cette raison que j'ai pas adopté ta solution Geoffrey :)


     


    Finalement j'ai utilisé le Key value storage d'icloud pour stocker les préférences d'achat (un tableau de 16 entrées plus un autre stockant le nombre de packs achetés, après je fais la soustraction pour avoir les étoiles restantes).


    Pensez vous que c'est la bonne solution, surtout niveau synchro entre device et récupération si l'utilisateur change de device ? Ca m'inquiéte un petit peu parce que je trouve ça un peu trop magique, [store synchronise] et c'est bon...bof bof...


    Ah et mon Ubiquitytoken est tout le temps null... donc j'image que ça ne synchronise pas ?


  • DrakenDraken Membre
    #23

    Tu n'as pas 2 devices pour tester ?


  • RomheinRomhein Membre
    #24

    -_-' nan ...


     


    niveau environnement de dev je suis pas dans les meilleurs conditions ^^ heureusement que j'ai pas mal de bétâ testeurs, ça comble certains soucis, mais ils ont pas tous deux devices aussi... donc pour le moment je sais pas trop comment tester cette fonctionnalité, et il est clair que je sortirai pas l'appli tant que je serai pas certain que ça fonctionne parfaitement de ce coté :/


  • DrakenDraken Membre
    #25

    Si tu peux attendre un mois, j'aurais deux devices (un iPhone 4 sous iOS 7.1 et un iPhone 6 sous iOS8).

  • RomheinRomhein Membre
    #26

    oui ça serait super cool ! mais on iphone 4 fonctionnera pas, les widgets sont dispo uniquement sur iOS 8. Dis moi par MP sur quelle adresse j'envoie l'invitation ;)


  • DrakenDraken Membre
    mai 2015 modifié #27

    Je te dirais ça quand j'aurais l'iPhone 6. Pour le moment, je me contente du vénérable iPhone 4.


  • RomheinRomhein Membre
    #28

    Excusez moi mais la je suis en train de craquer... sans raison mes achats in-app ne fonctionnent plus... juste pour moi, mes testeurs n'ont pas de problèmes...


    En gros quand j'appel :



    
[[SKPaymentQueue defaultQueue] addPayment:payment];

    rien ne se passe... J'ai pas d'alertview d'apple... je n'ai rien changer concernant ma classe qui s'occupe des achats, je ne comprends vraiment pas, je cherche depuis hier...


  • GeoffreyGeoffrey Membre
    #29

    Tu fais bien le addTransactionObserver avant ? 



    
        SKProduct *currentProduct = self.delegate.arrayOfProducts[indexPath.row];
    
        SKPayment *payment = [SKPayment paymentWithProduct:currentProduct];
    
        [[SKPaymentQueue defaultQueue] addTransactionObserver:self];
    
        [[SKPaymentQueue defaultQueue] addPayment:payment];
  • RomheinRomhein Membre
    #30

    Oui ! j'ai fini par trouvé, mais j'ai du perdre la moitié de mes cheveux, pour rien d'ailleurs... surtout que j'en ai déjà  plus bcp :/


    Bref j'ai redémarré mon iphone et ça a fonctionné... J'étais sur le problème depuis genre 5 heures, j'arrivais pas à  décrocher. Ma copine prend mon tel, l'éteint pour dire "stop lache l'affaire", le soir je rallume mon tel, et magie magie les achats in-app sont là . D'ailleurs je reçois tous ceux qui étaient en queue... Voilà  voilà  pour la petite histoire, morale de l'histoire, une copine ça sert aussi à  débugguer :D


Connectez-vous ou Inscrivez-vous pour répondre.