Utvikle iOS-appene dine, ellers vil de dø i naturen

I motsetning til den vanlige troen, er ikke iOS-apputvikling en prosess der en god idé blir destillert til et robust sett med instruksjoner etterfulgt av øyeblikkelig godkjenning som resulterer i langsiktig aksept. Egentlig er den første delen sann. Det er mange nyttige og innovative iOS-apper som er tilgjengelige for brukere å laste ned og glede seg over. IOS-appene med lengst holdbarhet er imidlertid de som utvikler seg til å forbli kompatible med de siste utgivelsene av maskinvare og programvare.

Heldigvis er det ikke nødvendig å endre, redigere, kompilere og sende inn iOS-appen din på nytt hver gang en ny iOS-versjon slippes. Til dags dato har det vært førtini iOS versjonsutgivelser som spenner over den originale iOS 1.0 gjennom den nyeste iOS 6.1. Her er sammenbruddet:

  • iOS 1.0 - Introdusert 29. juli 2007 (9 påfølgende utgivelser på ett år)
  • iOS 2.0 - Introdusert 11. juli 2008 (5 påfølgende utgivelser på seks måneder)
  • iOS 3.0 - Introdusert 17. juni 2009 (7 påfølgende utgivelser på fjorten måneder)
  • iOS 4.0 - Introdusert 21. juni 2010 (18 påfølgende utgivelser på tretten måneder)
  • iOS 5.0 - Introdusert 12. oktober 2011 (3 påfølgende utgivelser på syv måneder)
  • iOS 6.0 - Introdusert 19. september 2012 (1 påfølgende utgivelse på to måneder)

Hver større utgivelse ser ut til å sprenge et spor med nye funksjoner og funksjoner. Utviklere får i oppgave å avgjøre om de skal utnytte disse nye funksjonene eller ikke. Samtidig blir utviklerne imidlertid overfor en beslutning om hvordan de skal håndtere avskrevne metoder og parametere. Det er ikke noe svart-hvitt svar som kan påvirke beslutningen. Apples anbefaling (hentet direkte fra iPhone Development Documentation (PDF)) er "oppdatering så snart du kan, med tanke på iOS-versjonene du vil at appen din skal kjøres på."

Hvis utviklere ble tvunget til å eliminere avskrevet kode fra prosjektene sine, ville det være en konstant rørledning med reviderte apper som går gjennom "app-godkjenningsknappen." Basert på antall iOS-utgivelser de siste fem årene, under scenariet ovenfor, må en app må oppdateres og sendes inn igjen hver sjette uke.

Apper blir ikke avvist så ofte som før for å inkludere avskrevne metoder eller parametere. Apple-kodeanmeldere ser ut til å være mer følsomme for utfordringene knyttet til vedlikehold og oppdatering av apper med hastigheten på iOS-versjonsutgivelser. Utfordringen til enhver utvikler er å finne en balanse mellom å støtte eldre iOS-versjoner og utnytte mulighetene til nye iOS-versjoner.

En god tommelfingerregel

En hovedutvikling for en utvikler bør alltid være å garantere kompatibilitet med de nyeste enhetene. Samtidig er det imidlertid viktig å gi ut en ny versjon av en app med det formål å (1) øke sikkerheten, (2) å fikse større feil og (3) forbedre ytelsen. Jo lenger du venter med å revidere koden din, jo mer tungvint og tidkrevende blir den. Med hver nye kunngjøring om iOS-versjoner, les utviklerdokumentasjonen - spesifikt listen over avskrevne metoder og feilrettinger - for å finne ut om det påvirker din nåværende utgivelse. Utgivelsesnotatene for iOS 6.0 finner du her.

En liste over nye funksjoner og funksjoner sammen med tilhørende utgivelsesnotater og kjente problemer kan være overveldende. Apple Xcode gjør en god jobb med å flagge potensielle problemer - for eksempel avskrevne metoder. Du bør alltid planlegge en ny utgivelse av appen din under følgende omstendigheter:

  • Hver gang det slippes en ny iOS-enhet.
  • Hver gang det slippes en større iOS-versjon.
  • Hver gang en underversjon inneholder kritiske sikkerhetsoppdateringer.
  • Hver gang en underversjon inneholder en funksjon som kan forbedre appen din.

Dette vil redusere den gjennomsnittlige utgivelsessyklusen fra 10 ganger til 2-4 ganger per år. Hvis du er ansvarlig for å administrere og oppdatere flere apper, er arbeidet med å følge med det raske tempoet i teknologien mye mer håndterlig.

Når er en komplett omskrivning en bedre løsning?

Det er en ganske sikker innsats å anta at en hvilken som helst iOS-app utviklet for tidligere iOS-versjoner, og som fremdeles eksisterer, har gjennomgått minst én større omskriving. Innføringen av storyboards, for eksempel, var en god grunn til å gjenoppbygge en app nedenfra og opp. Introduksjonen av iPad skapte en mulighet for utviklere å lage "universelle" apper. En komplett omskrivning av en eksisterende iPhone-app var nødvendig for å lage en app som skulle kjøres på både iPhone og iPad.

En fullstendig omskriving er en domskall. Noen ganger er en omskriving nødvendig for å dra nytte av nye utviklingsmetodologier - som med introduksjon av storyboards. I andre tilfeller er en omskrivning nødvendig for å utnytte en ny design av brukergrensesnittet - for eksempel Master-Detail-designet. Uansett grunn, noen ganger har en app vært gjennom så mange revisjoner og oppdateringer, det er vanskelig å legge til nye funksjoner og funksjoner. Det viktigste å huske er å ikke gå for lenge mellom oppdateringer. Appen din vil stadig utvikle seg.

Les også:

  • Fordelene ved å bruke designmønstre i iOS-utvikling
  • Bygg den selv iOS Twitter-klient Del 1
  • Fem nettressurser for iOS-utviklere

© Copyright 2020 | mobilegn.com