Apps bouwen, welke software?

[SvMp]

Welke software wordt gebruikt om apps te bouwen?

Ik ben al een tijdje bezig met Android apps in Java, met Android Studio. Dit is de standaard ontwikkelomgeving voor Android. Er kunnen echter geen iOS en Windows Mobile apps mee gemaakt worden.

Heeft het - los van hobby - waarde om bekwaam te zijn in het ontwikkelen van apps in Android Studio?

Alle grote apps hebben zowel een iOS als een Android versie. Hoe gaat dat in de praktijk? Bouwen ze twee verschillende apps (met hetzelfde uiterlijk en functionaliteit) voor beide platforms? Dus eentje met XCode en eentje met Android Studio?

Of wordt er gekozen voor een multiplatform-oplossing zoals Corona SDK? Dan kun je met één codebase apps bouwen voor zowel iOS als Android.

[johnkeates]

Allebei. Hangt er van af wat je doet.

Denk aan Apache Cordova (PhoneGap gebruikt dat dacht ik), Xamarin, Titanium etc...

Stel dat je apps maakt die speciale dingen doen of qua performance bepaalde eisen hebben, dan kan het zomaar zijn dat je echt goede native apps moet maken en niet met halfbakken vertaalde apps aan moet komen zetten.

Soms is je app echter niet veel meer dan een viewer met een klein beetje CRUD functionaliteit voor wat lokale data. In zo'n geval maakt het geen zak uit waar je het mee maakt

Los daar van: als je goed kan ontwikkelen maakt het niet uit in welke toolset je het doet of met welke taal, alleen de framework-specifieke zaken zal je echt moeten leren, de rest volgt allemaal dezelfde concepten en patronen. Stel dat je het doet om dat je er lol aan wil hebben en dinge wil leren: ga dan in Xcode aan de slag. Stel dat je gewoon een breed publiek wil bereiken: gebruik een cross-ecosysteem oplossing.

[Amanush]

Kijk eens naar Appcelerator, Xamarin, Meteor en Cordova..
Is dat niet iets voor je?

[SvMp]

Laat ik wat specifieker zijn:
Het gaat mij niet eens zozeer om welk pakket handig is. Dat is een kwestie van uitproberen.

Het gaat mij er meer om door professionals die beroepsmatig apps bouwen het meest wordt gedaan: Een pakket voor meerdere platforms, of voor elk platform afzonderlijk ontwikkelen?

De argumenten voor en tegen, zoals hierboven ook benoemd door johnkeates, zijn mij duidelijk. Ik weet alleen niet waar professionele app developers hjet meest voor kiezen. Ik kan daar nergens wat over vinden en ik ken ook geen mensen die beroepsmatig apps bouwen.

Ik wil mij verder bekwamen in apps bouwen, maar wil in de toekomst ook beroepsmatig wat mee gaan doen. Android Studio vind ik van alle pakketten het beste: Volledig vrij, zelfs registreren hoeft niet, prima gedocumenteerd, en draait op zowel Linux, OS X als Windows. Helemaal perfect. Maar aangezien ook Apple nog steeds een redelijk marktaandeel heeft, en apps van serieuze bedrijven voor beide platforms verschijnen, vraag ik mij af wat handiger is: Verder met Android Studio en XCode er bij leren, of toch over naar een van die pakketten? (die ik eigenlijk niet eens wil gebruiken, en als Linux-gebruiker kan ik er helemaal weinig mee).

[ Voor 10% gewijzigd door SvMp op 23-05-2015 18:26 ]

[Amanush]

Professionele app developers kiezen op basis van de situatie.. Niet op basis van "wat beter is".

[Flapmo]

Amanush schreef op zondag 24 mei 2015 @ 09:16:
Professionele app developers kiezen op basis van de situatie.. Niet op basis van "wat beter is".

Ze kiezen wat het beste is in die situatie , en daarbij houden ze rekening met een hele lijst factoren inderdaad.

Anyway, al het bovenstaande is correct. De taal en tooling maakt niet, zorg dat je de software structuren en concepten leert begrijpen die kan je, met enige aanpassing, in elke taal wel gebruiken. Taal is maar een hulpmiddel om je doel te bereiken.

Wat ik persoonlijk zie is dat steeds meer bedrijven native code ontwikkelen voor de mobiele markt. De grote spelers geven aan dat html5 of wrappers nog niet voldoende krachtig zijn voor grootschalige apps. Denk aan Facebook die zijn Android app toch weer native heeft gemaakt. Zelf werk ik bij Philips en daar maken we dezelfde keuzes. Onze desktop apps komen in html5/angularjs/ember/web components/backbone /dojo etc (framework on top of internal libraries voor server en UX) terwijl de mobiele apps weer native gaan per platform. Html werkte gewoon niet goed genoeg.

Leer de concepten van software architectuur te begrijpen en je zal een heel eind komen!

Succes!

[NMe]

SvMp schreef op zaterdag 23 mei 2015 @ 18:24:
De argumenten voor en tegen, zoals hierboven ook benoemd door johnkeates, zijn mij duidelijk. Ik weet alleen niet waar professionele app developers hjet meest voor kiezen. Ik kan daar nergens wat over vinden en ik ken ook geen mensen die beroepsmatig apps bouwen.

Professionele app-developers die "het meest" voor een bepaalde oplossing kiezen zonder naar de situatie te kijken zijn geen professionele app-developers dus dat je daar niets over vindt is niet zo gek...

[Vincentio]

Flapmo schreef op zondag 24 mei 2015 @ 15:19:
[...]

Ze kiezen wat het beste is in die situatie , en daarbij houden ze rekening met een hele lijst factoren inderdaad.

Anyway, al het bovenstaande is correct. De taal en tooling maakt niet, zorg dat je de software structuren en concepten leert begrijpen die kan je, met enige aanpassing, in elke taal wel gebruiken. Taal is maar een hulpmiddel om je doel te bereiken.

Wat ik persoonlijk zie is dat steeds meer bedrijven native code ontwikkelen voor de mobiele markt. De grote spelers geven aan dat html5 of wrappers nog niet voldoende krachtig zijn voor grootschalige apps. Denk aan Facebook die zijn Android app toch weer native heeft gemaakt. Zelf werk ik bij Philips en daar maken we dezelfde keuzes. Onze desktop apps komen in html5/angularjs/ember/web components/backbone /dojo etc (framework on top of internal libraries voor server en UX) terwijl de mobiele apps weer native gaan per platform. Html werkte gewoon niet goed genoeg.

Leer de concepten van software architectuur te begrijpen en je zal een heel eind komen!

Succes!

Sencha heeft dat argument van Facebook toch wel redelijk onderuit gehaald: http://www.sencha.com/blo...book-an-html5-love-story/

En mocht je crossplatform gaan met Cordova en het op oudere versie van Android qua performance niet helemaal lukken, kijk dan ook naar https://crosswalk-project.org/ als plugin.
Dit kan best wel wat schelen, echter zal je binary wel een stuk groter worden.

Uiteindelijk ligt het gewoon aan je set requirements voor je App wat de beste keuze is.

Het ligt ook maar aan wie je het vraagt. SAP heeft bijvoorbeeld op dit moment 555 HTML5 apps liggen. ( https://fioriappslibrary....ternalViewer/#/detailInfo )

[Flapmo]

Vincentio schreef op zondag 24 mei 2015 @ 15:53:
[...]


Sencha heeft dat argument van Facebook toch wel redelijk onderuit gehaald: http://www.sencha.com/blo...book-an-html5-love-story/

En mocht je crossplatform gaan met Cordova en het op oudere versie van Android qua performance niet helemaal lukken, kijk dan ook naar https://crosswalk-project.org/ als plugin.
Dit kan best wel wat schelen, echter zal je binary wel een stuk groter worden.

Uiteindelijk ligt het gewoon aan je set requirements voor je App wat de beste keuze is.

Het ligt ook maar aan wie je het vraagt. SAP heeft bijvoorbeeld op dit moment 555 HTML5 apps liggen. ( https://fioriappslibrary....ternalViewer/#/detailInfo )

offtopic:
Mwah, ik neem zulke "kijk het kan wel" examples toch vaak met een korreltje zout. FB, LinkedIn, ze switchen met een reden. Misschien kan het wel maar kost het gewoon teveel moeite, of misschien doen ze in de achtergrond veel meer dan sencha in hun prototype heeft zitten. Om nog maar niet te spreken over de enorme verscheidenheid in devices die FB moet Supporten, dat kunnen ze bij sencha onmogelijk getest hebben. Prototypes kan je niet vegelijken met echte apps, Prototypes werken altijd maar vaak loop je pas tegen de complexe problemen aan zodra je naar productie gaat.

[ Voor 5% gewijzigd door Flapmo op 24-05-2015 22:21 ]

[Anoniem: 374991]

Over hybrid development:
Met 'frameworks' als ionic, begint het toch echt serieuze vormen aan te nemen.

Zeker omdat het voor hybrid developers nu mogelijk is om apps te updaten zonder een nieuwe binary te uploaden in de App store met phonegap/cordova sync

Checken vanaf de pull slides
http://simonmacdonald.blo...-eu-2015-push-n-pull.html

[Amanush]

Anoniem: 374991 schreef op dinsdag 26 mei 2015 @ 17:00:
[...]

Zeker omdat het voor hybrid developers nu mogelijk is om apps te updaten zonder een nieuwe binary te uploaden in de App store met phonegap/cordova sync

[...]

Wat is er mis met een nieuwe binary te uploaden? Dat je nu ongecontroleerd mallware kan inladen op mobile devices?

[NMe]

Amanush schreef op dinsdag 26 mei 2015 @ 17:30:
[...]

Wat is er mis met een nieuwe binary te uploaden?

Om te beginnen dat dat proces bij Apple al snel meer dan een week duurt. Dat is al snel onacceptabel als je een bug in je applicatie hebt gefixt die op Android wel meteen wordt doorgevoerd maar op iOS op zich laat wachten buiten jouw eigen invloed om.

Dat je nu ongecontroleerd mallware kan inladen op mobile devices?

Dat kun je vast onderbouwen...

[ Voor 12% gewijzigd door NMe op 26-05-2015 17:35 ]

[Amanush]

NMe schreef op dinsdag 26 mei 2015 @ 17:34:

[...]

Dat kun je vast onderbouwen...

Ik onderbouw geen wilde gokken .

[Ryur]

NMe schreef op dinsdag 26 mei 2015 @ 17:34:
[...]

Om te beginnen dat dat proces bij Apple al snel meer dan een week duurt. Dat is al snel onacceptabel als je een bug in je applicatie hebt gefixt die op Android wel meteen wordt doorgevoerd maar op iOS op zich laat wachten buiten jouw eigen invloed om.

Mijn ervaring met Apple is:
Zodra de App voor de eerste keer gecontroleerd is, zijn de bugfixes bijna direct (met 1 dag speling) wel geüpdatet.
Als er weer een grote nieuwe feature erin komt, ja dan duurt het wat langer. Maar meer dan een week heb ik niet meegemaakt?

[NMe]

Ik wel. Ik heb vanuit mijn werk een app in de App Store en elke keer als ik die aanbied ben ik wel weer een week of langer aan het wachten, terwijl het toch echt stuk voor stuk simpele bugfixes zijn (want featurestop). Besides, hoe gaan ze zien of er veel wijzigingen zijn gedaan of een bugfix? Dat zou betekenen dat ze elke app die ze testen moeten onthouden en zelfs dan nog komen ze er pas tijdens het testen achter of er veel veranderd is of niet. Tenzij ze uitgaan van de release-description en die zal lang niet altijd compleet zijn.

[Anoniem: 374991]

NMe schreef op woensdag 27 mei 2015 @ 11:47:
Ik wel. Ik heb vanuit mijn werk een app in de App Store en elke keer als ik die aanbied ben ik wel weer een week of langer aan het wachten, terwijl het toch echt stuk voor stuk simpele bugfixes zijn (want featurestop). Besides, hoe gaan ze zien of er veel wijzigingen zijn gedaan of een bugfix? Dat zou betekenen dat ze elke app die ze testen moeten onthouden en zelfs dan nog komen ze er pas tijdens het testen achter of er veel veranderd is of niet. Tenzij ze uitgaan van de release-description en die zal lang niet altijd compleet zijn.

Precies dezelfde ervaring (met meerdere apps) en we hebben het nu vooral over bugfixes. Maar als je een security fix hebt wil je die asap door kunnen voeren en niet een week hoeven te wachten, terwijl het in de playstore dezelfde dag nog wordt geupdate. Nu maak ik geen 'Enterprise' achtige apps, maar dit soort ondersteuning is wel een hele grote pré voor de Enterprise jongens (facebook).

Een van de doelen van cordova/phonegap is ook dat ze hopen dat ze in de toekomst niet meer nodig zijn.
http://phonegap.com/2012/...efs-goals-and-philosophy/
The ultimate purpose of PhoneGap is to cease to exist.
Is al een wat ouder artikel, maar op PhoneGapDayEU 2015 werd dit nog een keer herhaald.

Persoonlijk denk ik ook dat de webstack de toekomst is voor apps. Het is nogal raar dat je voor elk platform een aparte app moet maken, de kosten worden gewoon te groot met de winst die je eruit haalt.

Waarom raar? Apps op OS niveau zijn toch heel normaal? Dat is ook zo, maar dan bouw je geen app meer maar een website in plaats van een app. En blijf je uiteindelijk ook bij de webstack technologie.

Mijn algemene keuze zou dan ook zijn voor Cordova/Phonegap. Maar zoals hierboven meerdere malen gezegt word: 'The right tool for the job.'

[NMe]

Anoniem: 374991 schreef op donderdag 28 mei 2015 @ 14:42:
Persoonlijk denk ik ook dat de webstack de toekomst is voor apps. Het is nogal raar dat je voor elk platform een aparte app moet maken, de kosten worden gewoon te groot met de winst die je eruit haalt.

Ik weet het niet. Het zou kunnen dat Google en Apple op een gegeven moment het voorbeeld van Microsoft gaan volgen.

[Anoniem: 374991]

NMe schreef op donderdag 28 mei 2015 @ 14:46:
[...]

Ik weet het niet. Het zou kunnen dat Google en Apple op een gegeven moment het voorbeeld van Microsoft gaan volgen.

Microsoft moet wel willen ze ooit marktaandeel gaan winnen en succesvol worden op mobiel, dat is bij Google en Apple wel anders. Hiermee wil ik niet zeggen dat dit niet de toekomst is, het is zeker een mooie ontwikkeling.

Wat ook een andere kijk geeft is een mix van native controls en de content in de webview.
Native hybrid mobile apps. Ik heb hier zelf geen ervaring mee, maar een 'best of both worlds' principe.

[Down]

Anoniem: 374991 schreef op donderdag 28 mei 2015 @ 15:13:
[...]


Microsoft moet wel willen ze ooit marktaandeel gaan winnen en succesvol worden op mobiel, dat is bij Google en Apple wel anders. Hiermee wil ik niet zeggen dat dit niet de toekomst is, het is zeker een mooie ontwikkeling.

Wat ook een andere kijk geeft is een mix van native controls en de content in de webview.
Native hybrid mobile apps. Ik heb hier zelf geen ervaring mee, maar een 'best of both worlds' principe.

Dat principe is leuk en heb ik (in beperkte mate) toegepast, maar vooral de traagheid van de webviews op Android zijn een doorn in het oog, vooral als sprake is van aardig wat javascript.

Ik heb nu meerdere gepubliceerde apps gemaakt voor zowel Android als iOS. Jaren geleden las ik overal al dat hybrid of volledig web de weg was om in te slaan voor mobiele apps, maar ik zou op dit moment nog steeds voor native kiezen. Zelfs recente high end smartphones hebben nog performance problemen in web based apps.

[ZpAz]

NMe schreef op donderdag 28 mei 2015 @ 14:46:
[...]

Ik weet het niet. Het zou kunnen dat Google en Apple op een gegeven moment het voorbeeld van Microsoft gaan volgen.

Nee. Dat gaat Apple niet doen. En de enige reden dat Microsoft het doet is omdat ze het kleinste marktaandeel hebben. Dezelfde strategie die BB ook heeft toegepast. Want daarop kan je ook (sommige?) Android Apps draaien. Het nadeel is dat dan vrijwel niemand een oplossing maakt die echt toegespitst is op het platform zelf. Maar een generieke "het draait overal, maar het voelt zich nergens thuis" oplossing aanbied.

[NMe]

Net zoals webapps bedoel je?

[farlane]

Down schreef op donderdag 28 mei 2015 @ 16:19:
[...]
Ik heb nu meerdere gepubliceerde apps gemaakt voor zowel Android als iOS. Jaren geleden las ik overal al dat hybrid of volledig web de weg was om in te slaan voor mobiele apps, maar ik zou op dit moment nog steeds voor native kiezen. Zelfs recente high end smartphones hebben nog performance problemen in web based apps.

Met 'Native' bedoel je VM based op Android en niet mbv de native SDK neem ik aan?

[Down]

farlane schreef op donderdag 28 mei 2015 @ 22:05:
[...]

Met 'Native' bedoel je VM based op Android en niet mbv de native SDK neem ik aan?

Dat bedoel ik inderdaad, 'native' t.o.v. web based .

Als je gebruik wilt maken van zaken zoals b.v. google maps op Android moet je haast wel aan de slag met de maps sdk voor Android i.p.v. de javascript variant. Zo heb ik een app met een kaart waar potentieel honderden items op kunnen staan die ook regelmatig refreshed worden. Web based performed dit absoluut niet goed. Dat betekent dat je dus al richting hybrid moet. Android sdk voor bepaalde zaken en web based voor simpele schermen met weinig eisen.

Daarmee vervalt meteen het grote voordeel van slechts één techniek hoeven beheersen/toepassen/onderhouden. Bijkomend probleem is dat interactie tussen de native delen en de web based delen niet bijzonder prettig loopt, waarbij je callbacks doet vanuit de javascript naar je native stuk. Problemen met focus van controls en responsive styles ben ik ook al tegengekomen.

Ik werk bij een .NET-club en heb gekozen voor Xamarin. Een common lib voor alle niet-platform specifieke zaken (business logic voor zover aanwezig, data access) met een abstractielaag voor platformspecifieke zaken. Deze worden in de platformspecifieke projecten voor iOS en Android geïmplementeerd.

Zoals hier al eerder aangegeven is het controleproces voor updates nogal vervelend bij iOS. Niet alleen de initiële publish maar zelfs simpele updates kunnen zo 8-10 dagen duren voordat ze er door zijn. Bij Android staat die vaak wel met 2-3 uur online.

Voor nieuwe projecten zal ik wederom native gebruiken.

[pasz]

Xamarin is leuk, maar alleen als je erg veel business logic hebt. Het meeste tijd gaat toch echt zitten in het bouwen van je UI. En die is compleet anders in Android, iOS en Windows Phone.

Stel dat je business logic ergens in de cloud of op een servertje draait, dan is de snelheid van je UI bepalend. Heb je echt iets heel snels nodig, dan zal je per platform een native front-end moeten bouwen. Meestal is dit niet het geval en kan je met frameworks als Ionic (angular based) en cordova snel meters maken.

Corona SDK is overigens voor simpele spelletjes een zeer goede keuze. Niet te gebruiken voor "business"-applicaties, maar wel heel erg goed inzetbaar voor meerdere platformen. Zeker nu in combinatie met Corona Cards wat gratis is voor Windows Phone.