Discussion :

[youtpout978]

Ce genre de réflexion, ne te sens pas obligé de les mettre par écrit...

Explique-moi l’intérêt pour une petite structure de vendre de l’application native Windows 10 si le simple portage d’une appli Android fait l’affaire (déjà que cette même structure avait du mal à le faire hier sans cette compatibilité...). Donne-moi un cas de figure où les applis Windows universelles ont encore un intérêt aujourd’hui avec cette annonce (mis à part le fait qu’elles soient compatibles Xbox et Holo). Bref, coté mobilité, tout le monde sur Java et on n’en parle plus....

Je suis dans le même cas j'ai commencé à faire des applis sur WP, en me disant que j'ai pas de concurrence et ça prendra peut être avec Windows 10, mais là ça risque d'être le contraire, les applis que je peux sortir il y aura déjà 100 clones provenant d'iOs ou Android et quel intérêt de faire de l'universal apps alors qu'en travaillant directement sur les produits concurrent on pourra aussi cibler Windows 10.

[Hinault Romaric]

Windows 10 : les applications iOS développées avec Swift pourront aussi fonctionner sur l’OS
Microsoft travaille sur les outils pour le langage

Pour enrichir sa galerie d’applications en prélude à la sortie de Windows 10, Microsoft avait annoncé lors de la conférence Build la semaine dernière qu’il aillait permettre la publication d’applications d’Andoid et iOS sur son store.

Pour les développeurs Android, la firme a intégré à la version pour mobile de Windows 10 une couche d’exécution qui permettra de faire tourner, sans aucune modification, les apk existants. Toutefois, pour les applications utilisant des API Google, il faudra de petites modifications pour utiliser à la place des API Microsoft.

Pour les développeurs iOS, le processus n’est pas pareil. Ils seront obligés de recompiler leurs applications en utilisant les outils mis à disposition par Microsoft. Les outils fonctionnent pour le langage Objective-C.

Pourtant, Apple dispose d’un nouveau langage de programmation baptisé Swift, qui est désormais le langage de référence pour la création d’applications iOS. Qu’en est-il du support de ce langage par Microsoft ? De nombreuses personnes se sont certainement posé cette question.

En effet, la prise en charge de Swift est encore en élaboration. Raison pour laquelle Microsoft n’a pas communiqué sur le sujet lors de la Build 2015.

En effet, lors d’une séance de questions/réponses, un ingénieur de Microsoft a fait savoir que la firme publiera plus tard les outils de compilation pour porter les applications développées avec Swift sur Windows 10.

Source

[psychadelic]

A un moment ou un autre il faudra bien que les différents App-stores deviennent inter compatibles.

Ca s'appelle la libre concurrence !

[qtwallaert]

Les applications Android sur Windows 10 ne me semblent pas tellement des Universal Apps :

Pour les développeurs Android, Microsoft offre le projet Astoria. Ce dernier permettra aux applications Android de fonctionner sur Windows 10. Contrairement au projet Islandwood, qui permet en quelque sorte de traduire une application iOS en application Windows, Astoria est une couche d’exécution qui sera intégrée à Windows mobile (la version de Windows 10 pour terminaux disposant d’un écran de moins de 8 pouces) pour les applications Android.

Il semblerait donc que porter ses apps Android ne permette pas de toucher Windows 10 sur PC + nombreux autres supports, seulement Windows 10 sur smartphones. Si c'est effectivement le cas, ça fait une grosse différence avec les Universal Apps.

[anonymous69]

Bonjour,

Je suis développeur .Net depuis plus de 7 ans (ASP.Net/VB.Net/C# et framework .net jusqu'a 4.5.1), sur Windows Phone (Silverlight et WinRT) depuis plus d'un an, et oui la première impression à "chaud" est que c'est bel et bien un coup de couteau dans le dos de la part Microsoft.
Ensuite connaissant extrêmement bien la plateforme Windows Phone 8.1 et l'ensemble des API disponibles, et comparant avec les applications iOS et Android de mes collègues, je demande à voir le niveau de compatibilité.
Quid des autorisations, quid du mode background, encore une fois je pense (et ce n'est que mon avis de développeur d'application) que Microsoft se trompe purement et simplement de cible et ce depuis des années, ils misent sur les développeurs indépendants or Microsoft à toujours réussi grâce aux partenaires, SSII etc ...
Ils cherchent à attirer "ceux" qui ont développer sur Android et iOS au lieu de capitaliser sur des développeurs .net (Winform/WPF/ASP) qui ne demandaient que des APIs digne de ce nom pour porter leur applications déjà existantes.
Je ne vois pas un développeur indépendant avoir assez de temps pour gérer trois plateformes, quand aux entreprises, elles se heurtent à un problème de taille, le store n'est pas prévu pour les tiers, c'est à dire un éditeur ou un partenaire.
Attention le "company account3 est en fait prévu pour distribuer en interne des applications.
Pour moi le fond du problème est toujours les APIs et certaines lacunes au niveau fonctionnel qui empêchent de bâtir des applications "sérieuses", l'exemple le plus flagrant est le mode background un véritable retour en arrière au temps des mainframes, on a le droit y compris sur un PC branché sur secteur à 2 secondes toutes les 15 minutes, comment générer ou traiter des données en arrière plan ? On ne peut pas demander à l'utilisateur de rester sur une seule application c'est un non sens !
Maintenant je me souviens aussi de "python et ruby for .net" et je me dis que peut-être ce n'est qu'une opération pour augmenter l'attractivité de Windows.

[Aiekick]

c'est triste, on va encore ce coltiner des appli en java pour un bout de temps. A bas java, vive c++

[defZero]

Donc si j'ai bien comprit, non seulement ils ont recodé un compilo objective-c fonctionnel avec tous les frameworks dispos sous IOS, mais en plus ils pensent à faire de même pour swift ?

Si oui, c'est que du bonheur .

[I_Pnose]

Donc si j'ai bien comprit, non seulement ils ont recodé un compilo objective-c fonctionnel avec tous les frameworks dispos sous IOS, mais en plus ils pensent à faire de même pour swift ?

Si oui, c'est que du bonheur .

Oui enfin, il faut noter qu’à l’heure actuelle le converter iOS se base sur le code source pour produire un package compatible WinRT, ce qui signifie que l’application à convertir doit elle-même utiliser des libs open-sources, sans quoi le converter ne pourra pas bosser. Bref, en l’état ça limite un tout petit peu quand même (pour peu que dans la chaîne des dépendances on se retrouve avec des bibliothèques un tant soit peu fermées, le portage n'est pas possible).