De laatste tijd horen we vaker, en lezen we ook op ons forum, dat Bring Your Own Device (BYOD) op zijn retour zou zijn en dat Apple devices als de iPhone of iPad daardoor minder marktaandeel in de zakelijke markt zouden krijgen. Maar als we naar de cijfers van het Good Technology Mobility Index Report (PDF, 270 KB) kijken dan zien we dat het aandeel van iOS in de zakelijke markt wereldwijd juist nog steeds aan het groeien is.

Het onderzoek vond plaats door analyse van de data van Good Technology, en dan vooral in het laatste kwartaal van 2013. Daarbij zit data van alle belangrijke platformen (dus iOS, Android en Windows Phone), behalve van BlackBerry, omdat die hun eigen BlackBerry Enterprise Server gebruiken voor zakelijke e-mail. Maar omdat het marktaandeel van die laatste steeds sneller wegzakt lijkt ons dat niet zo'n probleem.

De cijfers zelf spreken in ieder geval boekdelen, in het afgelopen kwartaal waren maar liefst 73 procent van de activaties voor iOS devices.

iOS activations made up 73 percent of total device activations in Q4, up from 72 percent in Q3 and 69 percent in Q2 of 2013. Android activations decreased one percentage point quarter over quarter and came in at 26 percent of total device activations. Windows Phone activations made up one percent of total activations each quarter, holding steady in the total number of activations reported in the previous two quarters.

Hoe groot het verschil in de zakelijke markt is kan je hieronder goed zien.



Daarbij doet de iPhone het trouwens prima, maar is het vooral de iPad die de concurrentie ver achter zich laat.



Opvallend is dat het enorme marktaandeel van Android vaak met de 'overheersing' van Windows in de afgelopen decennia wordt vergeleken, terwijl het juist door onder andere de zakelijke markt kwam dat Windows zo'n grote rol kon opeisen. De meesten op dit forum hebben wel in een bedrijf gewerkt waar de IT-afdeling nu eenmaal besliste dat er alleen maar met Windows gewerkt werd.

Kennelijk is de ontwikkeling op dit moment daarmee niet vergelijkbaar, en is het juist in de zakelijke markt waar Apple's iOS devices de grootste spelers zijn.

Zelf ben ik een ontwikkelaar van databases mbv FileMaker. Op de iPad hebben we dan de beschikking over FileMaker Go waarmee je een FileMaker database kunt openen en muteren.

Daarbij loopt je vrijwel constant tegen de beperkingen van het iOS op. De sandboxing is regelmatig een struikelblok in het realiseren van een transparante procedure om met data op je iPad om te gaan.

Jailbreaking is in veel gevallen een mogelijke oplossing maar dat kun je natuurlijk nimmer aan je zakelijke klanten voorleggen. Een PC blijft dan vaak nodig.

Zakelijke toepassingen hebben vrijwel altijd met opslag en multimediale uitwisseling van gegevens via eigen databases te maken

Daarom verbazen mij de bovenstaande cijfers omdat naar mijn mening de zakelijke kant van het iOS nog heel wat problematiek heeft te overwinnen, waarbij er op dit moment nog geen enkele indicatie is dat dit ook vanuit Apple zal gebeuren.

iOS op met name de iPad is leuk speelgoed, ook bij zakelijke toepassingen, maar kan daar nog lang niet op eigen benen staan.

De cijfers zullen wel betrekking hebben op zakelijke aanschaf van iOS. Hoe iOS gebruikt wordt staat er niet bij. Ik vermoed dat het vooral wordt gebruikt voor functies als mailen, browsen en wat zakelijke apps. Alles wat zwaarder is gaat nog op de ouderwetse PC. Ik zie dat eigenlijk ook niet zo snel veranderen. De PC (of die nou OSX of Windows draait) zal nog lange tijd het werkpaard blijven.

@ devman: een oplossingen met bijvoorbeeld Dropbox waren geen optie..? Vind het verhaal een beetje vreemd, want er zijn erg veel zakelijke ontwikkelaars die het wel lukt, maar dat het anders gaat dan bij een desktop is volgens mij wel bekend...
 

Bij 'zakelijk' kun je ook denken aan andere betekenissen dan waar men tot nu toe het label 'zakelijk' aan opplakt, en waar (dus) altijd een pc mee was gemoeid.
Tegenwoordig zijn er toepassingen voor (specifiek) de iPad waar een paar jaar geleden nog niks voor was dan schrijfblokjes, ordners, klappers e.d. Weet ik uit eigen ervaring.

@Robert, Dropbox, GoogleDrive, FTP app. Daarmee lukt het prima om een database óp de iPad in FMGO te krijgen, Maar vanuit FMGO weer naar elders zetten gaat alleen per email.

Dit is puur vanwege de sanboxing, je kunt DropBox geen toegang verlenen tot de bestanden in FMGO. Met b.v. WeTransfer een bestand uploaden gaat evenmin, want je kunt het bestand niet selecteren vanuit Safari.

Een iPad past prima in een zakelijke omgeving. Mail, agenda, office, dat werkt allemaal prima.

Maar databases op een iPad zetten? Doe normaal! Het single user MS Access tijdperk is voorbij.

Een database draait op een centrale database server. Die database kopieer je niet naar een iPad. Je gaat je iPad ook niet als fat client inrichten. Nee, je gaat je database bijvoorbeeld via Citrix ontsluiten. Het is 2014, de iPad is VS. 2014, MS Access is van 20 jaar geleden...

Ik zie dat je in deze materie niet zo ingewerkt bent. Er zijn situaties denkbaar waarbij je niet afhankelijk wilt/kunt zijn van de beschikbaarheid van een server. Denk b.v. aan een monteur onderweg.

Die monteur heeft dan een lokale kopie van zijn onderdelen database op zijn iPad. Dat werkt: database overzetten van Mac naar iPad. Zo gaan monteurs 1, 2, 3, 4 en 5 op pad met een gevulde iPad.

Monteur 1 monteert, en werkt de database bij. Monteurs 2, 3, 4 en 5 doen dat ook.

Monteur 2 is het eerst terug op de zaak, en zet de database terug naar de server. Vervolgens komen monteurs 1, 5, 4 en 3 terug, en zetten hun database over. Daarbij overschrijven ze de databases van monteur 2, 1, 5 en 4. Dus uiteindelijk staat alleen de database van monteur 3 op de centrale server.

Beste devman, dit zijn MS Access methodes, die werkten destijds al niet, en die werken anno 2014 helemaal niet meer!

Een catalogus (statisch, of dynamisch met een lage mutatiegraad) op je iPad meenemen kan prima. Dat werkt volgens jouw bericht van gisteren 20:39 ook. Dat is eenrichtingsverkeer, en dat moet ook zo blijven.

Transacties (uitgevoerde werkzaamheden) moeten terug naar het centrale systeem. Dat kan prima via een netwerk, zodra je weer verbinding hebt. Dat kan niet door simpelweg de hele database terug te kopiëren, je moet daar een speciale transactie voor ontwerpen.

Fijn, het is je al duidelijk dat het eerste punt, het bij je hebben van een offline database voor een monteur belangrijk is. Het tweede deel zoals jij dat schetst is niet aan de orde. Er worden geen databases overschreven. Ook komt een monteur niet terug op de zaak.


Maar eerlijk gezegd denk ik dat dit nu buiten deze discussie valt. Mocht je in de details geïnteresseerd zijn dan wil ik daar best over doorgaan via PB.

@devman: ben vroeger ook helemaal into Filemaker geweest, maar liep constant tegen de beperkingen aan, oa diegene jij nu schetst. De problemen waar je mee te maken hebt mag je niet op iOS afschuiven, ze zijn gewoon het gevolg van FileMaker.
Op dit moment ontwikkelen wij webapplicaties (waar relevant en altijd internet access, meestal voor gebruik op desktop en notebook computers) en native iOS applicaties. Deze laatste communiceren meestal met onze webapplicaties.

We gaan hier meestal als volgt te werk: bij eerste opstart van de iOS app worden credentials gevraagd en worden de relevante gegevens van de webapplicatie (die meestal een MySQL db als backend heeft) gedownload naar een locale SQLite db. Voordeel is dat voor consulteren de data onmiddellijk beschikbaar is en men niet afhankelijk is van het wel of niet beschikbaar zijn van een netwerk (soms komt de iOS app ook prefilled met data). De data wordt op regelmatige tijdstippen ververst op basis van wijzigingen op de server.
Als een user lokaal nieuwe zaken aanmaakt of dingen wijzigt, worden die niet alleen lokaal opgeslagen maar ook naar de server gepusht. Ofwel op het moment zelf als er netwerk beschikbaar is, ofwel van zodra het netwerk beschikbaar komt.
Doordat heel veel zaken (import van gewijzigde records van de server, het pushen van nieuwe en/of gewijzigde data) steeds in een background thread lopen krijgt de user een supersnelle gebruikservaring, immers zijn gegevens worden eerst opgevraagd/weggeschreven in een lokale database.
Dit is een pak meer werk dan een FMPro db-tje opzetten en vraagt ook heel wat meer technische kennis (Cocoa, de ontwikkelomgeving van iOS en OS X is een pak complexer dan FMPro), maar zorgt wel voor een naadloze gebruikerservaring

devman om 16:47, 20-02-2014
Fijn, het is je al duidelijk dat het eerste punt, het bij je hebben van een offline database voor een monteur belangrijk is.

Daar ben ik het helemaal met je eens. Catalogi, naslagwerken, montagehandleidingen, ..., die moet je offline bij je hebben, zodat je onafhankelijk bent van netwerken.

devman om 16:47, 20-02-2014
Het tweede deel zoals jij dat schetst is niet aan de orde. Er worden geen databases overschreven. Ook komt een monteur niet terug op de zaak.

Waarom wil je dan de database vanaf een iPad weer terugkrijgen op een centrale server?!?! Wat is dan je probleem?

Een catalogus op je iPad zetten is van een andere categorie dan het bijhouden van transacties. Een goede (database)tool zorgt ervoor dat je beide kunt doen, en dat je transacties niet verloren gaan als je (even) geen netwerk hebt.

@MacSea, leuk om te lezen hoe jullie dit hebben getackled. Voor onze toepassingen is dit op dit moment iets te zwaar maar op termijn zou dit ook voor ons een mogelijk pad kunnen zijn.

Ik ben het met je eens dat het eerder een probleem van FileMaker is dan van iOS al kan ik mij de problematiek van de developers bij FileMaker levendig voorstellen. Die sandboxing is een grote blokkade welke de ict kosten behoorlijk kan opjagen. Leuk voor de consument maar vervelend voor bepaalde toepassingen.

Men zou bij Filemaker samen met de iOS mensen (twee deuren verder?) eens moeten komen tot een plug-in structuur in iOS zoals die op de PC al bijna decennia in gebruik is.