Nativ iOS-alkalmazás fejlesztése a semmiből Swift nyelven

Natív iOS fejlesztés magánügyfeleknek

A Natív iOS fejlesztés akkor jó választás, ha valaki iPhone készülékre szeretne stabil, gyors és hosszabb távon is kezelhető alkalmazást készíttetni. Itt nem általános sablonról van szó, hanem olyan megoldásról, amely az Apple rendszeréhez igazodik. A magánügyfél számára ez főleg akkor fontos, ha az alkalmazásnak megbízhatóan kell működnie, adatokat kell kezelnie, vagy később bővíthetőnek kell lennie.

Én azt látom, hogy sok ügyfél először csak egy ötlettel érkezik. Van egy elképzelése, de még nincs pontos leírása, nincs képernyőterve, és nem tudja, mennyi munka van a háttérben. Ez nem baj. Egy jó iOS fejlesztő ilyenkor nemcsak kódot ír, hanem segít tisztázni a feladatot. Megkérdezi, kik fogják használni az alkalmazást, milyen funkciók kellenek az első változatba, és mi az, amit későbbre lehet halasztani.

A natív alkalmazás előnye, hogy jól használja az iPhone rendszerének lehetőségeit. Ilyen lehet az értesítés, a kamera, a helyadatok nélküli eszközfunkciók, a fizetés, a belépés, a fájlkezelés vagy a gyors működés gyengébb internetkapcsolat mellett is. De ezeknek ára van. Nem minden ötlethez kell rögtön teljes alkalmazás. Szerintem az első döntés mindig az, hogy valóban szükség van-e natív megoldásra, vagy elég egy egyszerűbb digitális felület.

iOS alkalmazás fejlesztés online munkában

Az iOS alkalmazás fejlesztés távolról is jól szervezhető, ha a feladat leírása elég világos. A megbízó elküldi az ötletet, a meglévő anyagokat, a képernyőterveket, a példákat és az elvárt működést. A szakember ezek alapján felméri a munka nagyságát. Ezután jön a pontosítás, az árajánlat, a határidő és a munkamenet rögzítése.

A távoli munka egyik előnye, hogy a kommunikáció írásban is követhető. Ez csökkenti a félreértéseket. De csak akkor, ha a megbízó nem szórt üzenetekben küldi a kéréseket. Sokan ott hibáznak, hogy egy fontos funkciót csak később említenek meg, amikor a fejlesztés már elindult. Ilyenkor az ár és a határidő is változhat. Ez nem feltétlenül a fejlesztő hibája. Egy alkalmazásnál a kis módosítás is érinthet több képernyőt, adatkezelést és tesztelést.

Volt olyan eset, amikor egy ügyfél egy egyszerű időpontfoglaló alkalmazást szeretett volna. A beszélgetés elején csak naptár és értesítés szerepelt a feladatban. Később kiderült, hogy fizetés, ügyfélprofil, admin felület és több jogosultsági szint is kell. A projekt így már nem kis alkalmazás volt. Tapasztalatom szerint jobb az elején kimondani, hogy mi biztosan kell, mi csak lehetőség, és mi nem része az első változatnak.

Natív iOS fejlesztés árak

A natív fejlesztés ára főleg a funkciók számától, a képernyők összetettségétől, a háttérrendszer szükségességétől, a teszteléstől és az App Store feltöltés előkészítésétől függ. Egy magán fejlesztő általában rugalmasabban áraz, mint egy nagyobb csapat, de a felelősség így is nagy. Egy olcsó ajánlat nem mindig rossz, de a túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent.

Az áraknál fontos, hogy ne csak a fejlesztési időt nézzük. A valódi költségben benne van a tervezés, a tesztelés, a hibák javítása, a kommunikáció és a későbbi módosítás lehetősége is. Szerintem egy korrekt ajánlat nem csak egy számot tartalmaz, hanem azt is, mi van benne az árban, hány javítási kör jár hozzá, és mikor kell külön fizetni.

iOS fejlesztő kiválasztása

Az iOS fejlesztő kiválasztásánál a portfólió fontos, de önmagában nem elég. Érdemes megnézni, hogy a szakember milyen típusú alkalmazásokon dolgozott. Más tudás kell egy egyszerű jegyzetelő alkalmazáshoz, más egy fizetési rendszerhez, és megint más egy olyan apphoz, amely külső szolgáltatásokkal kapcsolódik össze.

A jó jel az, ha a fejlesztő kérdez. Nem baj, ha nem fogad el mindent azonnal. Sőt, ez gyakran előny. Ha valaki már az első üzenet után pontos árat ígér egy összetett alkalmazásra, az kockázatos lehet. A részletek nélkül adott ár vagy túl magas, vagy később változni fog. A Qjob.hu felületén olyan magánszakembert lehet keresni, akinek a válaszaiból látszik, mennyire érti a feladatot, és hogyan gondolkodik a megvalósításról.

Érdemes rövid próbamunkával kezdeni, ha a projekt nagyobb. Ez lehet egy képernyő elkészítése, egy technikai vizsgálat vagy egy kisebb funkció. Így a megbízó látja a munkastílust, a kommunikációt és a pontosságot. A fejlesztő pedig látja, mennyire rendezett a feladat. Ez mindkét oldalnak tisztább helyzetet ad.

Natív alkalmazás készítés menete

A natív alkalmazás készítés első lépése a cél tisztázása. Nem az a kérdés, hogy hány funkció fér bele, hanem az, hogy melyik funkció ad valódi értéket az első változatban. Egy túl nagy induló lista lassítja a munkát, növeli a költséget, és könnyen elviszi a figyelmet a fő feladatról.

A következő lépés a rövid leírás. Ebben szerepelhet a célközönség, a fő képernyők listája, a felhasználó lépései, a szükséges adatok, a belépés módja, a külső kapcsolatok és az elvárt határidő. Nem kell tökéletes dokumentum. De legyen annyira érthető, hogy a szakember ne találgasson.

Ezután jön a becslés és az ütemezés. Egy kisebb munka néhány nap alatt elkészülhet, de egy komolyabb alkalmazás több hét vagy több hónap is lehet. A fejlesztés közben általában részátadások vannak. A megbízó megnézi az elkészült részeket, visszajelzést ad, majd a fejlesztő javít vagy folytatja a következő szakaszt.

A végén következik a tesztelés, a javítás és az átadás. Az átadás nem csak annyit jelent, hogy működik az app. Ide tartozhat a forráskód, a belépési adatok, a dokumentáció, a képernyőképek, az App Store anyagok és a további karbantartás feltételei is. Ha ezek nincsenek előre tisztázva, később vita lehet belőlük.

Online iOS fejlesztés kommunikációja

Az online iOS fejlesztés akkor halad jól, ha a kommunikáció egyszerű és rendszeres. Nem kell minden nap hosszú beszélgetés. Sokszor elég egy rövid státusz, hogy mi készült el, mi hiányzik, és mihez kell döntés a megbízótól. A fejlesztőnek is könnyebb dolgozni, ha nem kell napokig várnia egy válaszra.

A feladatokat érdemes írásban rögzíteni. Különösen a módosításokat. Egy mondatban megfogalmazott kérés sokszor többféleképpen értelmezhető. Például az, hogy legyen egyszerűbb a képernyő, nem fejlesztési utasítás. Jobb azt leírni, melyik mező maradjon, melyik kerüljön ki, és mi legyen a gomb szövege.

Tapasztalatom szerint a legjobb munkák nem azért sikerülnek, mert minden tökéletesen indul. Hanem azért, mert a megbízó és a szakember időben jelzi, ha valami nem világos. A jó fejlesztő nem csak elkészíti a kért részeket, hanem figyel arra is, hogy az alkalmazás használható maradjon. Ez különösen fontos akkor, ha a megbízó nem technikai ember.

Gyakori hibák iOS applikáció rendelésénél

Az egyik gyakori hiba, hogy a megbízó túl sok funkciót kér az első változatba. Ez érthető, mert az ötlet ilyenkor még friss, és minden fontosnak tűnik. De egy alkalmazásnál a kevesebb sokszor jobb indulás. Először azt kell megcsinálni, ami nélkül az app nem értelmezhető. A többi később is jöhet.

A másik hiba a pontatlan brief. Ha nincs leírva, milyen adatokat kell menteni, milyen képernyők kellenek, és mit lát a felhasználó egy adott lépés után, akkor a fejlesztő saját feltételezések alapján dolgozik. Ez ritkán jó. Nem azért, mert rosszul dolgozik, hanem mert nem ugyanazt látja maga előtt, mint az ügyfél.

Gondot okozhat az is, ha a megbízó csak az árat nézi. A legolcsóbb ajánlat vonzó lehet, főleg kisebb magánprojektnél. De ha később újra kell írni a kódot, javítani kell a hibákat, vagy másik szakembernek kell átvennie a munkát, a végösszeg magasabb lesz. Én inkább azt nézném, mennyire érthető az ajánlat, van-e benne tesztelés, és mit vállal a fejlesztő az átadás után.

iOS fejlesztési eredmény átvétele

Az iOS fejlesztési munka végén nem elég annyit ellenőrizni, hogy az alkalmazás elindul. Meg kell nézni a fő folyamatokat, a hibás adatok kezelését, a lassabb kapcsolatot, az értesítéseket, a belépést és a különböző képernyőméreteket. A magánügyfélnek nem kell fejlesztőként tesztelnie, de érdemes végigmenni a saját használati esetein.

Az átadásnál legyen világos, mit kap meg a megbízó. A forráskód, a hozzáférések, a képernyőtervek, a feltöltéshez használt anyagok és a dokumentáció mind fontosak lehetnek. Ha az alkalmazás később bővül, ezek nélkül nehezebb lesz folytatni. Egy korrekt szakember ezt előre elmondja, és nem az utolsó napon derül ki, hogy mi nincs benne a megállapodásban.

A végeredmény akkor jó, ha az alkalmazás nemcsak elkészült, hanem érthetően használható is. Lehet egyszerű, lehet kicsi, de legyen stabil. Szerintem egy első iOS appnál ez fontosabb, mint a sok látványos részlet. A jó alap később bővíthető. A rossz alap viszont minden további fejlesztést drágábbá tesz.