Sådan bliver du iOS-udvikler - The Ultimate Guide (2023)

I denne artikel vil vi gennemgå, hvad vi mener, der skal til for at blive iOS-udvikler i løbet af de næste par måneder. 

Vi retter denne vejledning direkte mod to grupper af mennesker, absolut Swift-begyndere (Swift er sproget, der bruges til at kode iOS-apps) – folk der aldrig har bygget noget til iOS før – og såkaldte falske begyndere – folk der har prøvede at lære Swift før, men nåede aldrig rigtigt deres mål om at få et fuldtidsjob.

Regardless af dit nuværende niveau, er målet her det samme. For at sætte dig i stand til at ansøge om en junior iOS -udviklerrolle hos en virksomhed.

Vi vil se på de færdigheder, du bør lære, de kurser, du kan tage, hvordan du får forbindelse til fællesskabet, almindelige fejl, folk begår og meget mere. 

Det bedste af det hele er, at alt, hvad vi diskuterer, er helt gratis, så du behøver ikke betale noget for at følge med.

Alvorligt, alt for mange mennesker tror, ​​at at bruge mange penge vil sætte dem på den hurtige vej til deres drømmejob, når de vigtigste faktorer er beslutsomhed og viljestyrke. 

Denne artikel er opdelt i syv afsnit:

1. Kernefærdigheder, du skal have for at få et job.
2. Forlængelsesfærdigheder, der er gode at have - dem, der vil adskille dig fra mængden, hvis du gør en indsats for at lære dem
3. Almindelige fejl, som folk begår, når de forsøger at lære.
4. De mange gratis ressourcer, der er tilgængelige for at hjælpe dig med at lære Swift.
5. Sådan kommer du i kontakt med iOS -udviklingssamfundet.
6. Et skøn over hvor lang tid det vil tage at nå dit mål.
7. Gør dig klar til at søge dit første job.

Grundlæggende færdigheder, der kræves for at blive iOS-udvikler

Hvad er det absolutte minimum af færdigheder, der kræves for at få et job i iOS -udvikling? 

Der er fem væsentlige færdigheder i alt:

1. Hurtig programmering
2. SwiftUI 
3. netværk
4. Arbejde med data
5. Versionsstyring

Denne liste holdes bevidst kort af forskellige årsager:

Jo mere du lærer, jo mere indser du, at der er at lære, så det er let at bruge så meget tid på at studere og øve, at du mister hovedmålet af syne.

Du vil arbejde som en iOS -udvikler, ikke bare sidde og lære nye ting!

Det er næsten sikkert, at du vil deltage i et team, der allerede har en app, de vil have dig til at hjælpe med at udvikle, så unless hvis du bliver ekstremt heldig, skal de lære dig en hel masse ting omless.

Hvis du prøver at proppe en hel masse ekstra emner på forhånd, spilder du sandsynligvis din tid.

To af disse fem ting er enorme og komplicerede, og du kan bruge måneder på bare at prøve at vikle dit hoved uden om at vove andre steder.

Vigtigst af alt, hvis du får disse fem ting rigtigt, kan du oprette en lang række apps. Sikker på, din kode vil ikke være perfekt, men det er okay, fordi den eneste måde at skrive god kode på er først at skrive en masse dårlig kode.

Lad os opdele de fem elementer i mindre bidder.

1. At lære Swift

Swift er først på listen. Dette er Apple's centrale programmeringssprog. Det har ingen idé om at vise oplysninger på en iPhones skærm eller downloade data fra internettet. 

Det er simpelthen et sprog, der ligner JavaScript eller Python. Det er bare ren kode, som du bruger til at lave variabler, skrive funktioner og så videre.

Swift er kun få år gammel, så den gør brug af næsten alle avancerede sprogfunktioner. 

På den ene side betyder det, at du kan undgå al den gamle adfærd, der er almindelig på ældre sprog som C++ og Java. Det betyder også, at den har en række avancerede funktioner, som du kan drage fordel af.

Og det er fint. Mange dele af Swift er relativt enkle, mens andre vil tage dig længere tid at forstå fuldt ud, erfaring og øvelse gør mester.

2. SwiftUI

Den anden kernefærdighed, der kræves, er SwiftUI, som er en Apple ramme, der giver os mulighed for at bruge Swift til at oprette apps til iOS, macOS, tvOS og endda watchOS. 

Så selvom Swift er programmeringssproget, giver SwiftUI værktøjerne til udviklere til at oprette apps, såsom visning af billeder, tekst, knapper, tekstbokse, datatabeller og mere. 

For at være klar er SwiftUI ikke en erstatning for Swift - det er en ramme bygget oven på Swift, der giver os mulighed for at oprette apps. Du skal kende både Swift og SwiftUI for at lykkes.

Hvis du troede, at Swift var nyt, har du ikke set noget endnu! 

SwiftUI er en ret ung ramme, den dukkede op første gang i 2014, og den blev udviklet til at erstatte det arkaiske mål C.

På trods af sin unge alder har iOS-fællesskabet taget det helhjertet til sig, fordi det er så nemt at bruge.

Apple har også en ældre ramme til at bygge iOS-apps kaldet UIKit. Hvis du spørger en masse mennesker, om du skal lære SwiftUI eller UIKit først, får du en række svar. 

Vi synes, du skal lære SwiftUI, og her er begrundelsen for, hvorfor du bør prioritere SwiftUI som en kernefærdighed.

SwiftUI er væsentligt nemmere end UIKit, og – det kræver måske en fjerdedel af koden at opnå de samme resultater som UIKit, og der er færre ting at lære undervejs. 

Det betyder, at du får en masse momentum, fordi du kan bygge ting hurtigere, se resultater hurtigere og gentage disse resultater med mere smidighed, hvilket er ekstremt motiverende, mens du lærer.

Skabt til Swift

SwiftUI blev skabt til Swift ved at bruge sprogfunktioner til at hjælpe med at undgå problemer og opnå maksimal ydeevne. 

For eksempel, hvis du ændrer nogle data på én skærm i en app, vil SwiftUI automatisk sikre, at de nye data opdateres et andet sted i din app, der bruger det – du behøver ikke skrive kode for at holde det hele synkroniseret selv, hvilket typisk er ret komplekst. 

UIKit var derimod skrevet til Apple's ældre sprog, Objective-C, og har som et resultat alle mulige særheder, der skyldes dets alder.

SwiftUI er kompatibel med alle Apple's platforme, så du kan bruge det, du lærte på iOS, til at oprette en macOS- eller watchOS -app med næsten identisk kode. 

Selvfølgelig er funktioner såsom Digital Crown eksklusive til en enkelt enhed, den Apple Se, men langt størstedelen af ​​det, du lærer, fungerer på enhver enhed.

Men vigtigst af alt er SwiftUI den retning, som tingene er på vej. 

Hvis du søgte et job for et par år siden, skulle du sikkert kende UIKit, men det faktum, at du læser dette, betyder, at du er meget længere henne i processen. 

Mens UIKit plejede at være mere populært, er SwiftUI nu den dominerende UI-ramme.

Verdens største virksomheder, inkl Apple selv går nu videre med SwiftUI.

Hvornår Apple for nylig lancerede widgets i iOS 14, gjorde de det til et krav, at du bruger SwiftUI.

Netværk og datamanipulation

Den tredje og fjerde færdighed, vi nævnte, var netværk og datamanipulation. Sammenlignet med Swift og SwiftUI er disse ret enkle eller i det mindste simple på det niveau, der kræves for at få et junior iOS-udviklerjob.

Netværk er praksis med at hente data fra internettet eller sende data fra en lokal enhed til en fjernserver. På en mobilapp er dette naturligvis en grundlæggende færdighed.

Der er mange metoder til at opnå dette, men det vigtigste at forstå er, hvordan man henter JSON fra en server.

Og det er her, den anden væsentlige færdighed spiller ind, når man arbejder med data. 

Igen er der adskillige måder at indlæse og gemme data på, men det absolutte minimum, du skal være i stand til at gøre, er at konvertere de data, du har modtaget fra en server ved hjælp af din netværkskode, til information, som din app kan vise.

Så den tredje og fjerde kernefærdighed er uløseligt forbundet. Hent nogle data fra en server, og konverter dem derefter til oplysninger, der kan vises i din app. Nogle udviklere joker med, at det at skrive denne type kode er halvdelen af ​​en iOS -udviklers opgave, og det er bestemt rigtigt, at vi er meget afhængige af det.

Version control

Den sidste færdighed koder slet ikke, dens version control, såsom Git. Igen har du ikke brug for meget her, men det er vigtigt, at du er i stand til at offentliggøre din kode et sted offentligt, f.eks. GitHub, så rekrutterere kan se dit arbejde.

Ingen i verden forstår virkelig, hvordan Git fungerer, men det er okay - du skal bare vide nok om det grundlæggende for at gemme dine data sikkert og samarbejde med andre.

Så når disse fem lægges sammen, er der to massive - Swift og SwiftUI - samt tre mindre, men vigtige. 

Hvis du bare kan fokusere på disse fem ting uden at blive distraheret, er du godt på vej til dit første iOS -udviklerjob.

Det er det: Det er de fem væsentlige færdigheder, jeg mener, du skal være en iOS -udvikler. 

Der er tusinder af mennesker, der kun har disse færdigheder og kan bygge og sende fantastiske apps i App Store.

Hvad kommer efter det grundlæggende?

Når du har mestret de fem kernefærdigheder, kan du sende dine egne apps og arbejde som en indie -udvikler samt ansøge om junior iOS -udviklingsstillinger og arbejde for et firma, hvis det er det, du vil gøre. 

Der er ingen andre særlige kvalifikationer påkrævet - bare søm disse kernefærdigheder, og du får det godt.

Men hvis du har mestret disse færdigheder og ønsker at avancere, er der fem færdigheder mere, vi vil anbefale dig at lære. Det er de færdigheder, der vil drive dig fra en god til en fantastisk stilling – du bliver endnu mere ansættelig, og rækken af ​​apps, du vil være i stand til at bygge, vil udvide sig endnu mere.

Evnerne er som følger:

• UIKit 
• Kernedata 
• Validering
• Test
• Software arkitektur
• multithreading

Som før vil vi gerne gennemgå hver af disse mere detaljeret, så du forstår, hvorfor vi synes, de er vigtige – og hvorfor vi opfatter dem som udvidelsesevner snarere end kernefærdigheder.

UIKit

Først er der UIKit. Dette er Apple's ældre brugergrænsefladeramme, der har været brugt til appudvikling siden 2008 - den er 14 år gammel, da jeg skriver dette, hvilket er gammelt i software -termer. Men det betyder ikke, at UIKit er dårligt. Når du vænner dig til, hvordan det fungerer, bliver du faktisk overrasket over, hvor elegant det kan være.

Der er mange grunde til, at UIKit er værd at lære, herunder:

Hundredtusinder af apps er allerede blevet skrevet i UIKit, så hvis du tilmelder dig et firma, der har en stor, veletableret app, bliver du næsten helt sikkert forpligtet til at skrive UIKit-kode for at vedligeholde den app.

UIKit er langt mere kraftfuld end SwiftUI - der er mange ting, du kan gøre i UIKit, som i øjeblikket ikke er mulige i SwiftUI.

Ved hjælp af Auto Layout -teknologi kan du oprette ekstremt præcise layout.

Hvis du støder på problemer med din kode, har UIKit flere løsninger end SwiftUI simpelthen fordi den har eksisteret i meget længere tid.

Alt dette får UIKit til at lyde fantastisk, så hvorfor gjorde jeg det til en udvidelsesfærdighed frem for en kernefærdighed? 

Fordi UIKit også har problemer:

Næsten alt er sværere at gøre i UIKit end i SwiftUI, med nogle opgaver, der kræver hundrede gange, hvis ikke mere, kode. 

SwiftUI er designet specifikt til moderne iOS-udvikling, så det gør en masse af de tunge løft for dig.

Fordi UIKit ikke blev skrevet i Swift, har det mange funktioner, som SwiftUI ikke har – mange implicit uindpakkede ekstraudstyr, markering af kode med en speciel @objc attribut for at gøre den tilgængelig for UIKit's Objective-C undermave, og behovet for at bruge protokoller og delegerede for at vise simple data.

Intet ved Auto Layout er "automatisk" - faktisk, hvis du nogensinde prøver at bygge et komplekst layout, kan du have mareridt om Auto Layout. Det er ekstremt smart, men det er også ekstremt svært nogle steder.

Og det er derfor, vi anser UIKit for at være en udvidelsesevne: det tager betydeligt mere tid og kræfter at lære end SwiftUI, hvilket betyder, at det kræver meget mere beslutsomhed – du skal virkelig have lyst til at lære det, ellers bliver du forvirret , keder sig, vred eller potentielt alle tre. 

Nok har SwiftUI ikke alle funktionerne i UIKit, men det giver dig mulighed for at gøre hurtige fremskridt og få fart, før du går videre til UIKit.

Håndtering af kernedata

Kernedata, Apple's ramme for at arbejde med applikationsdata, er den anden udvidelsesfærdighed, jeg nævnte. 

Vi nævnte netværk og arbejde med data i afsnittet om kernefærdigheder, og det er rigtigt. Med disse færdigheder på plads kan du hente, hvad du vil, fra en server og vise det i din app. 

Kernedata tager det et skridt videre ved at tillade dig at manipulere disse data, når du har fået dem, f.eks. At søge efter bestemte værdier, sortere resultaterne og mere, alt meget effektivt. 

Det kan også nemt oprette forbindelse til iCloud og sikre, at dine brugeres data er synkroniseret på tværs af alle deres enheder.

Core Data har en lang række ulemper, hvoraf den mest alvorlige er, at det ikke altid er behageligt at arbejde med. Core Data er næsten lige så gammel som UIKit, og selvom det fungerede godt i Objective-C, føles det ikke så naturligt i Swift. 

Det integreres godt med SwiftUI, hvilket får det til at føles less mærkeligt, men det er stadig et overraskende komplekst emne.

Ligesom UIKit er Core Data ekstremt populær - hundredtusindvis af apps er blevet bygget med det, og det bruges i mange store og små virksomheder. 

Kernedata, ligesom UIKit, er ekstremt kraftfuld, og mens du kunne genskabe de vigtigste dele af det i din egen kode, hvorfor skulle du så?

Test din kode

Den tredje færdighed på min liste over udvidelser er test. Skrive speciel kode for at sikre, at din primære app -kode fungerer som forventet. 

Tests giver os mulighed for at sikre, at vores kode fungerer korrekt, og endnu vigtigere, at den fortsætter med at fungere korrekt, selv efter at vi har foretaget væsentlige ændringer af den.

For eksempel, hvis du ændrer 500 linjer kode for at implementere en ny funktion, og alle dine tests består, er du godt i gang.

Som et resultat er test kritisk og vil hjælpe dig med at skrive software af højere kvalitet. 

Så hvorfor betragtes det som en forlængelsesfærdighed frem for en kernefærdighed? 

Det er der tre grunde til:

iOS-fællesskabet som helhed er forfærdeligt til at teste, uanset historiske årsager. Mange store apps har ingen test overhovedet, og tragisk nok er en række senior iOS-udviklere næsten stolte af, at de aldrig skriver tests. 

Når du overvejer alle de fantastiske ting, du kan skabe med Apple's værktøjer og rammer virker skrivningstest ikke meget sjov i sammenligning. 

Når du søger et job, kender du Swift og Apple's store rammer vil altid være mere nyttige end at vide, hvordan man skriver test. 

Virksomheder foretrækker, at du ved, hvordan du bruger SwiftUI, UIKit eller en af ​​de andre store hitters, fordi test er et meget mindre emne - der er ikke nær så mange ting at lære.

Så test er vigtigt, test betyder noget, og hvis du vil være en stor overordnet udvikler, skal du lære at skrive gode tests. Men først efter at du har mestret det grundlæggende i appudvikling – efter at du har haft en vis succes, følt suset med at have din app live i App Store og mestret testning.

Software arkitektur

Den fjerde udvidelsesfærdighed, vi gerne vil diskutere, er softwarearkitektur, som i virkeligheden handler om, hvordan vi skriver kode. 

Du kommer til at skrive en forfærdelig kode, når du først starter. 

Det er okay, for det er sådan, man lærer. Man starter ikke godt – man bliver god ved at være dårlig i lang tid og lære bedre måder at gøre tingene på med erfaring og eksponering.

Pointen er, at du holder fast i din dårlige kode, indtil du finder ud af, hvordan du gør det bedre. Det er her softwarearkitektur kommer ind. Ser man på afprøvede teknikker til at strukturere din kode for at gøre det lettere at læse, bruge, ændre og vedligeholde i det lange løb. 

Disse teknikker er undertiden afhængige af den måde, Swift fungerer på - sproglige funktioner, der kan bruges til at skrive bedre kode. 

Der er dog adskillige andre teknikker, der fungerer i ethvert programmeringssprog og omtales almindeligvis som designmønstre.

Et vigtigt aspekt af denne færdighed, som du bør begynde at lære, er, hvordan du bryder din kode. 

Hvis du f.eks. Opretter en enkelt skærm i din app, kan den indeholde en login -knap, et billedgalleri og en liste med venner. 

Du bør dog ideelt set adskille hver af disse dele - en login-knapkomponent, en billedgallerikomponent og en vennelistekomponent - så du kan genbruge enhver af disse komponenter i andre dele af din app.

Softwarearkitektur er langt mere subjektiv end de andre færdigheder, vi hidtil har diskuteret. For de andre, såsom SwiftUI, kan du ræsonnere, "Nå, jeg ved, hvordan man laver X, Y og Z, så jeg er sikker på, at jeg er en god SwiftUI-udvikler."

 Softwarearkitektur er et meget bredt emne, og der er ofte ingen åbenlys "rigtig" måde at løse et problem på, så det bedste pejlemærke for det er dette: ser du tilbage på din kode fra seks måneder siden, et år siden og så videre .

At skrive dårlig kode er acceptabelt, så længe det kommer dig tættere på at skrive bedre kode. 

Du vil helt sikkert klø dig i hovedet nogle steder, når du ser tilbage på kode, du skrev for fem år siden, for du ved mere nu, end du gjorde dengang – og sådan burde det være.

multithreading

Den sidste udvidelsesevne, vi vil diskutere, er multithreading, som er praksis med at få din kode til at gøre mere end én ting ad gangen. 

Multithreading kan være en rigtig smerte, fordi det er svært for vores hjerner at forstå. Når din kode gør én ting ad gangen, kan vi tænke det lineært igennem, men når to eller tre ting sker på samme tid, potentielt overlappende, kan det virkelig rode med din tankegang.

Så selvom multithreading er en stor færdighed at have som en forlængelsesfærdighed, bør du være forsigtig. Dit mål bør være at forstå lige nok begreberne og koden til at få det til at fungere godt uden at gå for langt. 

For at være ærlig, tror mange udviklere, at multithreading øjeblikkeligt vil få deres kode til at køre tre eller fire gange hurtigere. 

Selvom dette er tilfældet i nogle tilfælde, vil koden i mange andre tilfælde faktisk køre langsommere, og du bliver nu nødt til at håndtere al den ekstra kodekompleksitet.

“Min specifikke anbefaling er, at du undgår at skrive asynkroniseret/samtidig kode så meget som muligt. Dette kan virke mærkeligt i 2018, men omkostningerne i kompleksitet og ydeevne er høje.

Så lær lidt om, hvordan multithreading fungerer i Swift for at demonstrere, at du forstår begreberne og implementeringen, men ikke gå for langt! ”

David Smith - Apple SwiftUI team

Almindelige fejl, nye iOS -udviklere laver

På dette tidspunkt har vi listet alle de kerne- og udvidelsesevner, du skal bruge for at arbejde som fuldtids iOS-udvikler. 

Vi ønsker også at diskutere nogle af de mest almindelige fejl, folk begår, mens de lærer, fordi jeg ser dem hele tiden og ved, hvordan de sætter folk tilbage.

Der er syv store problemer, som folk står over for. 

1. Husker alt
2. skinnende objekt syndrom 
3. Lone ulv læring
4. Brug af beta -software
5. Kommer an på Apple's dokumentation
6. At hænge fast i Objective-C
7. Sigter mod andre sprog

Lad os gå over hver af dem en efter en.

Stop med at prøve at huske alt

Det første og langt det mest almindelige problem, folk støder på, er at forsøge at huske alt udenad - at læse en vejledning igennem og tro, at de skal huske alt i det udenad. 

Ingen husker alt. Ingen kommer i nærheden af ​​at huske alt. Selvom du kun overvejer API'erne udgivet af Apple, som er de stykker kode, vi kan bruge til at bygge vores apps, skal der være godt hundrede tusinde til rådighed. 

Selvom du begrænser det til kernekomponenterne i appudvikling, ser du stadig på flere hundrede - alle arbejder på en meget præcis måde, der kræver meget læring at bruge.

I stedet lærer du, hvordan du gør noget nyt, og derefter glemmer du hurtigt, hvordan du gør det igen. 

Så du slår det op, bruger det igen og glemmer det straks. Så du slår det op en tredje gang og bruger det, og denne gang glemmer du det for det meste - nogle dele bliver hos dig. 

Denne cyklus fortsætter på ubestemt tid, hvor du hver gang skal henvise til en vejledning eller en anden referencevejledning, indtil det grundlæggende er indgroet i dit sind til det punkt, hvor du kan gøre det uden at rådføre dig med andre.

Hvis du ikke allerede vidste det, er glemme en vigtig del af læringen. 

Hver gang du glemmer noget og genlærer det, synker det dybere og mere grundigt ind i din hjerne. Når du genlærer noget, får din hjerne nye forbindelser til andre ting, du har lært, hvilket hjælper dig med at forstå mere om konteksten for, hvad du forsøger at gøre. 

Og hver gang du genlærer, signalerer du til din hjerne, at dette særlige emne er vigtigt nok til at gemme i sin langtidshukommelse.

Men hvis du satte dig for at lære alt udenad, vil du kæmpe. 

I stedet skal du ikke bekymre dig om at glemme ting. At vide, hvor de skal slå dem op, er langt vigtigere end at huske specifik Swift -kode for at opnå noget. 

Når du glemmer noget og skal genlære det, skal du overveje det som en god ting - at informationen vil synke dybere i anden, tredje og tiende gang du lærer det, så du hjælper din hjerne.

Undgå skinnende objektsyndrom

Det næstmest almindelige problem er "shiny object syndrome", hvor de finder en tutorial-serie, der fungerer godt for dem, og begynder at gøre fremskridt, men efter en uge eller to bemærker de en anden tutorial-serie, som de vil følge og hoppe til. det i stedet. 

Problemet her er, at mange aspekter af at lære noget er uinteressante. Det er ikke nødvendigvis lærerens skyld. 

Det er bare en kendsgerning at lære at kode – nogle ting giver dig fantastiske resultater med en lille indsats, mens andre tager meget mere tid at forstå, ikke producerer smarte resultater eller kun er en del af et større koncept.

Når du rammer disse stejle indlæringskurver, kommer det skinnende objektsyndrom ind - med så mange gratis tutorials til rådighed, kan du hoppe til enhver af dem og genstarte, og du vil være tilbage i den lave ende af poolen og dække lettere dele du har allerede lært. 

Men, unless det originale kursus valgte et usædvanligt emne at dække, du bliver sandsynligvis nødt til at lære det til sidst, og du udsætter bare det uundgåelige.

Vær opmærksom på skinnende objekt-syndrom - når du støder på et problem, så prøv at bede en anden om hjælp og holde ud i stedet for at skifte.

Gå ikke alene

Når vi taler om at spørge en anden, så er det tredje problem, vi ser folk støde på, når de går ensom ulve med deres læring – de tror, ​​de er fuldt ud i stand til at lære at bygge iOS-apps ved hjælp af Swift helt alene og ikke kræver hjælp fra andre .

Denne metode fungerer for et meget lille antal mennesker, typisk dem med stor erfaring med andre programmeringssprog eller platforme. 

Men for langt de fleste mennesker er læring på denne måde en frygtelig oplevelse - hver fejl eller misforståelse tager fem gange så lang tid at løse, det er ekstremt let at miste motivationen, og du går glip af en masse inspiration fra at se andre lykkes.

Hvis du er en naturlig "ensom ulv"-lærer, opfordrer vi dig til at ændre dine måder. 

Del, hvad du lærer, få kontakt med andre, der lærer, og udvikl vanen med at stille spørgsmål. 

Ikke alene vil du opdage et fantastisk fællesskab af elever, der vil støtte og opmuntre dig, men du vil også blive inspireret af deres arbejde og til gengæld inspirere dem med dit. Det er fuldstændig transformerende.

Brug ikke betaversioner

Det fjerde store problem er, når folk insisterer på at bruge betaversioner af Appleudviklingsværktøjer. 

Hvert år, Apple frigiver en ny iOS, en ny macOS og andre produkter, der altid leverer spændende nye ting, vi kan prøve. Det er naturligt, at folk vil lære det nyeste og bedste, især hvis de ved, at Swift har en lang forandringshistorie.

Men når folk forsøger at lære med betasoftware, støder de ind i en række problemer:

Fordi tutorials ikke er blevet opdateret til betaversionen, er det ikke altid muligt at følge deres instruktioner eller mislykkes.

Bugs er almindelige i betas, især dem, der frigives til større iOS -opdateringer.

Apples beta-frameworks tager tid at stabilisere sig, hvilket betyder, at kode, der fungerede i beta 1, muligvis ikke virker i beta 3.

Så selvom det er spændende at lære nye ting, og du måske tror, ​​at du kommer foran spillet med nye funktioner, så tro mig: det er ikke det værd. 

Brug altid de seneste offentlige udgivelser af Apple's udviklerværktøjer, indtil du er fortrolig med dem.

Stol på officiel dokumentation

Det femte store problem, som folk står over for, når de forsøger at lære, er at stole på Apple's dokumentation. 

Apple's udviklerpublikationsteam arbejder hårdt på at dokumentere så meget som muligt ud fra virksomhedens store udvalg af rammer, men deres hovedopgave er at skrive referencemateriale - ting, du læser, når du forsøger at bruge et bestemt stykke af deres værktøjer - frem for oprette et struktureret kursus for at hjælpe dig med at lære at bygge iOS-apps.

Vi har mistet tallet på antallet af gange, folk har spurgt mig: "Hvordan kan jeg lære Swift?" kun for at få at vide, "Læs Appleer en hurtig referencevejledning. " 

Denne tilgang virker for nogle mennesker. 

Men for de fleste mennesker ligner det at forsøge at lære et menneskeligt sprog ved at læse en ordbog. Det er beregnet til at dække alt på sproget i stedet for at lære dig de vigtigste dele og hvordan du anvender dem.

Så hvis du har stor erfaring med andre sprog, læsning Apple's reference guider kan være nyttige, men hvis du lige er startet, vil du måske besøge dem igen efter et par måneder.

At hænge fast i Objective-C

Det sjette store problem, som folk står over for, er at forsøge at lære Objective-C. Dette var Apple's primære udviklingssprog inden introduktionen af ​​Swift, og selvom der er rester i nogle gamle kodebaser, er langt størstedelen af ​​eksisterende kode nu Swift, og næsten alle nye kode er også Swift.

Nogle mennesker bruger år på at skrive Objective-C før Swift og bliver virkelig glade for det, men det har en ekstremt stejl indlæringskurve og mangler de fleste af Swifts vigtige funktioner. 

Hvornår Apple først annoncerede iPhone SDK, mange mennesker var forfærdede over Objective-C, fordi det var ulig noget andet, der havde set hidtil.

Objective-C og Swift har næsten intet til fælles for en begynder. 

Ja, de deler det samme Apple rammer, men unless du planlægger at arbejde på Apple -det eneste selskab i verden, der stadig producerer store mængder Objective-C-du bør lade Objective-C være i fred og helt koncentrere dig om Swift.

Ignorerer andre sprog

Den sidste store fejl, folk begår, når de lærer Swift, er at afvise andre sprog som ringere end Swift. 

Det mest almindelige mål er JavaScript, men du vil også se, at folk tager sigte på Python, Java, Ruby, Go og andre sprog, og til hvad? Det er ikke et løb, folkens – de sprog behøver ikke at tabe, for at Swift kan vinde.

Faktisk er Swift og SwiftUI ofte inspireret af andre sprog og rammer - hver gang nye sprogfunktioner overvejes, ser samfundet på lignende implementeringer i Rust, Python, Haskell og andre sprog, og SwiftUI er stærkt påvirket af JavaScript React rammer. 

Så folk i samfundet hævder, at SwiftUI er JavaScript-fri eller noget lignende - intet kan være længere fra sandheden.

iOS udviklingsressourcer og kurser

Nu til den del, som de fleste mennesker er interesserede i: Hvad er de faktiske ressourcer, du skal bruge til at lære Swift, SwiftUI og mere – for at nå dit mål om at blive iOS-udvikler?

Der er mange derude, og Swift-fællesskabet har en så forskelligartet gruppe mennesker, der deler deres viden. 

Men i denne artikel vil vi fokusere på gratis ressourcer – steder, hvor du kan lære at bygge fantastiske apps uden at bruge en krone.

Dette skyldes to faktorer:

1. Nogle mennesker tror, ​​at jo højere prisen på et Swift -kursus er, jo bedre skal det være, så de ender med at betale ublu priser uden at få tilstrækkelig fordel.
2. Mange websteder, f.eks. Udemy, er afhængige af at sælge et stort antal billige kurser i tillid til, at hvis du ikke kan lide et, vil du bare købe et andet. De har også en forretningsmodel, der ligner Steams, idet der er konstant salg, hvilket tilskynder folk til at samle et stort antal kurser for at studere "en dag."

Så her lister vi kun gratis ressourcer, så du ikke bruger hundrede dollars eller mere på dit første kursus, og ikke køber et dusin billige kurser, fordi du tænker, at det vil gøre dig til en udvikler.

Vejledninger

At begynde, Apple har to store ressourcer, der kan hjælpe dig. Den første er dens Teaching Code -websted, der indeholder elev- og lærerressourcer til at lære Swift fra bunden, helt op til professionelle certificeringer. 

Deres pensum er omfattende, så det kan tage noget tid at finde det bedste indgangspunkt for dig, men når du er der, finder du masser at udforske.

Sekund, Apple har en række SwiftUI-tutorials, der leder dig gennem processen med at oprette apps i den virkelige verden. Disse lærer dog ikke Swift, så du skal først fuldføre deres Swift-fokuserede pensum.

Apple udgiver også en vejledning specielt til programmeringssproget Swift, men der er en god chance for, at det ikke fungerer for dig - det er tænkt som en reference frem for en struktureret tutorial, så det er ret tæt læsning.

Hvad Apple's tutorials ikke gør, er at forsøge at tilvejebringe en struktureret metode til læring. 

YouTube og andre websteder

Der er nogle fremragende YouTube -videoer, der leder dig gennem det grundlæggende i SwiftUI, såsom:

Der er andre websteder med Swift- og SwiftUI-vejledninger af høj kvalitet, inklusive BLCKBIRDS, Ray Wenderlich, Donny Wals, Antoine van der Lee og flere – vi opfordrer virkelig folk til at besøge en række forskellige ressourcer og finde, hvad der virker for dem.

App-baseret uddannelse

Hvis du foretrækker at lære gennem apps, anbefaler jeg to, der begge er helt gratis. Det første er Apple's Swift Playgrounds app, som giver dig mulighed for at lære Swift direkte fra din iPad eller Mac. 

Der er mange interaktive lessrettet mod børn, men der er også nogle mere avancerede lessder hjælper dig med at fremme dine færdigheder.

Den anden app hedder Unwrap, og den blev oprettet af mig. Unwrap er kompatibel med alle iPhones og iPads og giver dig mulighed for at lære, gennemgå og øve grundlæggende Swift -principper gennem videoer, test og andre værktøjer. Det dækker alle de grundlæggende elementer i Swift og supplerer 100 -dages SwiftUI -pensum perfekt.

Indhentning af løsninger

Endelig skal du lære at finde svar online. Dette kunne betyde, at du går til Stack Overflow, men jeg håber ikke, fordi det ikke er et særligt behageligt sted.

Stil i stedet spørgsmål om Hacking with Swift -fora, din foretrukne Slack -gruppe, iOS Dev Happy Hour -sessionerne, Twitter og andre steder - vi er et virkelig varmt, imødekommende fællesskab med mange mennesker, der er ivrige efter at hjælpe dig med at nå dine mål.

At involvere sig i fællesskabet

Når vi taler om vores samfund, vil jeg gerne diskutere et virkelig vigtigt emne, der vil hjælpe dig med at møde mennesker i lignende stillinger som dig, lære mere effektivt og finde jobåbninger-det er en win-win-situation rundt omkring.

Emnet forbinder med iOS-udviklingsfællesskabet. Dette inkluderer at vide, hvor man skal lede efter nyheder og interessante ideer, hvor man skal henvende sig for at møde folk og dele tips, og hvor man skal henvende sig for at stille spørgsmål.

Hvem skal jeg følge på Twitter?

Lad os starte med det enkleste, nemlig at bruge Twitter. Twitter er en fantastisk måde at følge ting, der interesserer dig, og der er et par personer, jeg vil varmt anbefale i tilfælde af iOS -udvikling.

Ja, disse mennesker tweeter om deres eget arbejde, men jeg synes, de er gode at følge, fordi de også tweeter meget om andres arbejde - de hjælper dig med at se forskellige perspektiver på et bestemt emne, og de deler alle slags interessante ideer og ting at prøve.

Her er 9 personer, vi anbefaler, at du følger på Twitter:

Sean Allen bruger meget tid på YouTube på at lave Swift- og iOS-udviklingsvideoer, men han arbejder også rigtig hårdt på at sprede budskabet om andres arbejde – han gør virkelig et godt stykke arbejde med at hjælpe alle med at opdage noget nyt hver uge.

Antoine van der Lee driver et iOS -udviklingswebsted på https://www.avanderlee.com, men han deler også nogle gode links til nyttige ressourcer, han finder på GitHub, nyhedsbreve og mere.

Novall Khan arbejder for Apple, men det forhindrer hende ikke i at poste videoer med jævne mellemrum om, hvad hun arbejder med, hvad hun lærer, hvad hun har problemer med og meget mere – hun er virkelig inspirerende.

Steve Troughton-Smith er kendt for sit tidligere arbejde med at arbejde med iOS, men du bør virkelig følge ham for det fantastiske udvalg af links, han deler til imponerende arbejde. Jeg kan godt lide, hvordan han deler udviklingen af ​​sine egne apps, så du kan se dem vokse fra start til slut.

Kaja Thomas er en af ​​vores fællesskabs mest kendte indie-udviklere, og hun er blevet fremhævet af Apple flere gange end jeg kan tælle. Hun tweeter ofte om sit eget arbejde og præsentationer, men hun deler også links til bøger, hun læser, artikler hun har læst og andre ressourcer.

Majid Jabrayilov ikke bare skriver en fantastisk Swift og SwiftUI blog, men han er også et dækless promotor for andre - hvis du følger ham på Twitter, får du idé efter idé sendt din vej fra en lang række forskellige kilder.

Donny Wals skriver en Swift -blog og for nylig bøger om Kombiner og kernedata, men han opfordrer også folk til at dele, hvad de arbejder med på Twitter. Selv bare at læse den tråd en gang om ugen vil inspirere dig til at prøve nye ting, så du bør helt sikkert følge Donny.

Sommer Panage virker på Apple's tilgængelighedsteam, så selvom hun er lidt begrænset i, hvad hun kan sige, tweeter hun en masse førsteklasses tips fra sig selv og andre, som alle kan bruge til at bygge bedre apps.

Natascha Fadeeva skriver en blog om Swift- og iOS -udvikling, herunder artikler om Core Data, interviewspørgsmål og andre emner, men hun tweeter også om ting, hun finder andre steder.

Nyhedsbreve og mere

Selvfølgelig er Twitter ikke det eneste sted at holde kontakten med samfundet; der er også nyhedsbreve, Slack -grupper, Zoom -møder, fora, konferencer og andre spillesteder. Jeg vil ikke kede dig for meget, så jeg vil bare liste en af ​​hver her:

Du kan ikke gå galt med iOS Dev Ugentlig til nyhedsbreve. Mens jeg skriver dette, har det lige passeret 500 numre, et hver uge, som jeg mener fortæller dig alt, hvad du har brug for at vide om, hvor vigtigt det er.

Hvis du vil skrive på et webforum, https://www.hackingwithswift.com/forums er ret godt. Der er mange kategorier at vælge imellem, og enhver, hensynless af erfaringsniveau, er velkommen til at deltage. Du er mere end velkommen til at sende dine nybegynder -spørgsmål her, tro mig!

Hver måned, iOS Dev Happy Hour afholdes på et Zoom-gruppeopkald med over 300 personer, men det virkelig sjove er i breakout-rummene, hvor du kan chatte med grupper på 6 til 8 personer ad gangen. Det er meget sjovt, og du vil møde nye mennesker.

Det har været svært at deltage i konferencer på grund af coronavirus-pandemien, men Apple's WWDC var en kæmpe succes sidste år, og det blev ledsaget af en lang række fællesskabsarrangementer. En gruppe venner og jeg skabte en GitHub repository for at hjælpe med at holde styr på alle de andre begivenheder, artikler og andre ting, der er sket - tag et kig!

Endelig, hvis du foretrækker at chatte på Slack, hvor du hurtigere kan få svar, kan du deltage i gratis Hacking med Swift Slack -gruppen og slut dig til en af ​​Swift, SwiftUI og andre kanaler.

Hvor lang tid tager det at lære iOS?

Dette er et af mine ofte stillede spørgsmål: hvor lang tid tager det at gå fra at vide noget om Swift til at kunne få en iOS-udviklerposition på entry-level?

Det oplagte svar er "det afhænger", men det ville være en politimand i denne sag, så lad mig behandle det på et par forskellige måder.

Den gyldne regel er ikke at skynde sig

Først og fremmest kan du ikke tage flere kurser på samme tid. Kan du huske, hvad jeg sagde om "skinnende objektsyndrom"? Ja, mange mennesker tror på, at de kan tage to kurser på samme tid og derefter proppe i fire, fem eller endnu flere timer hver dag og stadig have en høj kvalitetsforståelse af de emner, de dækkede.

For at være klar har jeg set folk prøve dette så mange gange, og det fejler altid. Hver gang - det virker aldrig, og jeg hører folk sige, at det er fordi tutorials var dårlige, eller fordi Swift var for svært, eller af bogstaveligt talt en anden grund end at forsøge at skynde sig gennem noget komplekst.

At lære Swift kan til tider være svært, og at lære at bygge apps kræver en masse forsøg og fejl, lave fejl og tage forkerte sving. Og det er fint - det er bedre end fint, det er fantastisk! 

Fordi hver gang du prøver noget, laver en fejl eller tager en forkert drejning, lærer du noget undervejs, og når du endelig når frem til løsningen, forstår du det meget bedre.

Så TL; DR her er ikke skynd dig - tag din tid, vær ikke bange for at udforske tangenter, der opstår, vær ikke bange for at eksperimentere med dine projekter, og vær ikke bange for at gå tilbage til noget du har tidligere lært og genlæret det efter behov.

Hvad er din uddannelsesmæssige baggrund?

For det andet bør du overveje din baggrund, før du kommer til Swift. Du ser, at lære at bygge apps kræver en bred vifte af færdigheder, og hvis du kommer til bordet med et væld af forudgående viden som f.eks. version control, datastrukturer, algoritmer og mere, har du en betydelig fordel i forhold til dem, der er nye inden for datalogi generelt, såvel som Swift og andre Apple rammer.

Så her er et par muligheder for, hvor du måske er lige nu:

Hvis du har en datalogi, vil du allerede være bekendt med mange af de CS -grundlæggende elementer, der er nødvendige for at komme i gang med Swift. Variabler, arrays, loops, arrays, sæt, funktioner, OOP og andre koncepter vil være nyttige i Swift, ligesom alt dit arbejde med datastrukturer og algoritmer vil være nyttige. Dette kan spare dig for 4-6 måneders studietid afhængigt af de emner, du har studeret, og det vil også give dig en fordel, når du søger job hos mange virksomheder.

Hvis du ikke har en CS -grad, men har deltaget i en kodende bootcamp, har du mange af de grundlæggende ting, du skal bruge for at komme i gang med Swift. Dette vil ikke give dig den samme fordel, når du søger job hos disse virksomheder, fordi de ofte forventer en grad bare for at markere et felt på deres liste over vilkårlige krav, men det vil stadig spare dig tre eller fire måneder.

Hvis du ikke har en CS-uddannelse og ikke har deltaget i en bootcamp, men du har kodet i din fritid, sparer du noget tid – sandsynligvis to måneder eller deromkring, afhængigt af sproget eller rammerne du brugte .

Hvad hvis du ikke har en CS -grad, ikke har deltaget i en bootcamp og ikke har tidligere erfaring med kodning? Så ville jeg anslå 9 til 12 måneder at gå fra ingenting til et job på startniveau. Ja, det kan være et helt års arbejde oven i hvad dit nuværende fuldtidsjob er, og det er bare for at få dit første job som iOS-udvikler.

Er det altid det samme år? Nej. Hvis du har tidligere erfaring, kan du skære den tid ned til 1 til 6 måneder, som jeg tidligere har nævnt. Hvis du tager de bedste tal på begge sider-9 måneder fra ingenting til et job på startniveau, plus 6 måneder for at have en CS-grad-betyder det, at du kan blive ansat på bare 3 måneder, hvilket er utroligt.

Du tror måske, at det er umuligt at finde dit første job om tre måneder, men det er det ikke. Pokker, jeg mødte en, der tog mit 100 Days of Swift kursus og fik et job inden dag 50 - de havde allerede lært nok om appudvikling i less end to måneder, fordi de bestræbte sig på at få hver dag til at tælle.

Så du behøver ikke en CS -grad eller en bootcamp, men du skal være villig til at arbejde hårdt.

Giv dig selv et spillerum

Det tredje punkt, jeg gerne vil komme med, før vi går videre, er, at "det tager så lang tid, som det tager." Jeg elsker en tekst af John Lennon, der lyder: "Livet er, hvad der sker, når du har travlt med at lave andre planer."

Det er fantastisk, hvis du har store læringsplaner og store drømme om det job, du vil have, men nogle gange er du træt, nogle gange er du stresset, nogle gange lækker dit tag, eller din hund skal til dyrlægen, eller dine børn har brug for ekstra hjælpe med deres lektier eller hvad det nu er, og det er bare livet. 

Så vær ikke for hård ved dig selv, hvis du går bagud med din indlæringsplan, eller hvis du mangler nogle få dage eller endda et par uger og så videre - så længe du er modstandsdygtig, får du der.

Det er fantastisk, hvis du arbejder virkelig hårdt og får et job efter 50 dage - godt gået! Hvis det tager dig 500 dage, er det også fantastisk, og du skal være lige så stolt af dig selv. Pokker, hvis det tager dig fem år, er jeg sikker på, at det ikke var det, du ville have, men slutresultatet er det samme, og det er alt, hvad der betyder noget.

Gør dig klar til at ansøge

Sidst men ikke mindst, hvis du er lidt længere fremme i din iOS-læringsrejse og overvejer at lande dit første job på startniveau, vil jeg gerne pege dig på en massiv samling af ressourcer, jeg har sammensat for at hjælpe dig.

Jeg vil anbefale Sean Allens Swift interview tips videoer - han har en hel afspilningsliste til dem, hvor du kan arbejde igennem individuelle diskussioner såsom klasser vs strukturer, funktionel programmering, fejlhåndtering og mere. Ingen af ​​videoerne er specielt lange, men de er alle designet til at give dig de færdigheder, du skal bruge for at klare dig godt i en interviewsituation.

Hvor nu?

Okay, så jeg har gået over de kerne- og udvidelsesfærdigheder, du skal bruge, almindelige læringsfejl, kurser, du kan tage, hvordan du opretter forbindelse til iOS -fællesskabet, og hvordan du forbereder dig til dit jobsamtale - det er meget at dække, og jeg håber det har været nyttigt.

Desuden håber jeg, at jeg har demonstreret, hvor meget information der er tilgængelig gratis. 

Ja, fristelsen til at bruge hundrede dollars eller mere på et kursus er stærk, men slap af – kom i gang først, find noget momentum, og find også en, der underviser Swift på en måde, der fungerer for dig. Når du er et godt sted og føler dig klar, kan du bruge nogle penge, hvis du vil.

De bedste ønsker på din rejse!

Om forfatteren

Forfatter: David AttardInternet side: https://www.linkedin.com/in/dattard/E-mail: Denne e-mailadresse bliver beskyttet mod programmer som samler emailadresser. Du skal aktivere javascript for at kunne se.

David har arbejdet i eller omkring online / digital industri i de sidste 18 år. Han har stor erfaring inden for software- og webdesignindustrien ved hjælp af WordPress, Joomla og nicher, der omgiver dem. Som digital konsulent er hans fokus på at hjælpe virksomheder med at få en konkurrencemæssig fordel ved hjælp af en kombination af deres hjemmeside og digitale platforme, der er tilgængelige i dag.