Apple brengt iOS 14 uit terwijl ontwikkelaars kritiek uiten op snelle release

Apple heeft woensdagavond iOS 14 uitgebracht, nadat het afgelopen dag veel kritiek kreeg van ontwikkelaars over de snelle release. De Golden Master-release vond dit jaar niet een week voor de uiteindelijke release plaats, maar slechts een dag.

De release van iOS 14 kwam niet om zeven uur Nederlandse tijd, zoals gebruikelijk bij Apple-software, maar enkele uren later. Door de relatief korte tijd tussen GM en de release voor het publiek is er weinig tijd geweest voor ontwikkelaars om updates voor hun apps te compileren met de uiteindelijke versie van Xcode 12, in te dienen bij de App Store en goedgekeurd te krijgen, meldt onder meer Steve Troughton-Smith. Ook Dark Noise-ontwikkelaar Charlie Chapman heeft kritiek op de gang van zaken. Christian Selig van de Apollo Reddit-app zegt dat nachtrust er simpelweg niet in zou zitten door de snelle release.

Bovendien zit er nog een grote wijziging in de GM-release, merkt ontwikkelaar Peter Steinberger op. De api voor OSLogStore in Swift, Apples programmeertaal, zat wel in de bèta's, maar is verdwenen in de GM-release. Apple heeft niet gezegd of de api terug zal komen in een volgende versie of niet. Ook kunnen sommige apps nog niet werken onder iOS 14, zoals Animal Crossing Pocket Camp, meldt The Verge.

Apple kondigde de release van iOS 14 dinsdagavond aan. Apple brengt met iOS 14 diverse wijzigingen aan in de interface van iPhones. Zo kunnen gebruikers widgets gaan plaatsen op homescreens en voegt Apple aan de pagina's vol met apps een alfabetische lijst toe die het meest rechter homescreen zal vormen. Verder kunnen gebruikers een andere browser en mail-app kiezen als default in plaats van Safari en Mail.

Ontwikkelaars kunnen daarnaast hun apps vervangen door 'appclips', kleine delen van apps voor het uitvoeren van specifieke functies. Die appclips zijn te openen met url's, nfc-tags en qr-codes. Ook komt er een 'AppClip-code' met een eigen patroon en nfc. AppClips zijn kleiner dan 10MB. Tweakers publiceerde in juni een preview van iOS 14.

Compatibele apparaten	iOS	iPad OS
2020	SE 2020	iPad Pro (2020), iPad Air (2020), iPad 10.2 (2020)
2019	iPhone 11, 11 Pro, 11 Pro Max iPod touch V7	iPad Air (2019), mini (2019), iPad 10.2 (2019)
2018	iPhone XR, XS, XS Max	iPad Pro 11, Pro 12.9, iPad (2018)
2017	iPhone X, 8, 8 Plus	iPad Pro 10.5, Pro 12.9, iPad (2017)
2016	iPhone 7, 7 Plus, SE	iPad Pro 9.7, Pro 12.9, iPad (2016)
2015	iPhone 6s, 6s Plus	iPad Pro 12.9, mini 4
2014		iPad Air 2

Reacties (145)

[Stein03]

Ik snap dat het niet prettig is dat er zo’n snelle release is. Maar kom op, het is niet de eerste keer. Ik kan me herinneren dat ze de update wel eens hebben uitgebracht op dezelfde avond dat ze het aankondigden.

En daarbij zijn er maanden lang beta’s geweest waarop ontwikkelaars voldoende tijd hebben gehad om hun app gereed te maken.

[dennissimeau]

Je mist het punt een beetje...

Het probleem is dat ook de ontwikkeltools gereed moeten zijn om de App in de App Store te kunnen uploaden. Voor iOS 14 targets was dat alleen mogelijk met de Xcode versie die ook gister pas is uitgekomen (waarvan er ook nog eens twee versies in omloop waren, wat voor extra verwarring zorgde).

Daarnaast is de Golden Master in principe dezelfde versie als de final versie, dus als er nog iets veranderd is in de beta's kun je op de GM aan dat het met de release hetzelfde zal zijn.

Daar bovenop komt dat er dus gister avond pas geüpload kon worden naar App Store Connect, waarbij je dus én Xcode 12 moest hebben gedownload, alles nog een keer getest moet hebben, en alles juist geconfigueerd moet hebben om naar de App Store te kunnen pushen.

Het belangrijkste is nog het beruchte App Store Review proces. Dit neemt tijd in beslag, bovenop het stuk hierboven. Nu zijn een heleboel apps voor zover ik kan zien wel speed-reviewed, maar bij elkaar opgeteld moest alles ineens snel-snel.

Als je voor je brood afhankelijk bent van de Apple en dus de App Store (en dan zijn een heleboel mensen, myself included), dan zijn dit geen leuke grapjes.

[TechSupreme]

Sorry, maar dit komt bij mij een beetje over als van een mug een olifant maken. Het is niet alsof de app die nu in de appstore staat ineens niet meer werkt. Of je je app nu na de release of voor de release gaat updaten maakt niet zoveel uit.

[WhiteDog]

Er zijn wel degelijk bestaande apps die bij anders reageren, bv. doordat iOS komt vragen om toestemming dat de app externe apparaten mag aanspreken.

Heb zo 2 apps die heel raar reageerden de eerste keer, tot ik toestemming gaf en de app herstart had. Die apps zijn duidelijk nooit gebouwd met die extra stap in gedachten. Voor hetzelfde geld starten ze niet meer op.

De ontwikkelaar heeft misschien al maanden een update hiervoor klaarstaan die hij gisteren pas voor het eerst kon insturen.

Kan er wel nog inkomen dat ze weinig keuze hadden, watches met watchOS 7 zijn immers onderweg en daar heb je nu eenmaal iOS 14 voor nodig

[Anoniem: 1322]

Er zijn wel degelijk bestaande apps die bij anders reageren, bv. doordat iOS komt vragen om toestemming dat de app externe apparaten mag aanspreken.

Dat is al maanden in het nieuws geweest en deze functie zat al vroeg in de Beta's (zo niet alle).

Heb zo 2 apps die heel raar reageerden de eerste keer, tot ik toestemming gaf en de app herstart had. Die apps zijn duidelijk nooit gebouwd met die extra stap in gedachten. Voor hetzelfde geld starten ze niet meer op.
Ik heb ook apps gezien die raar reageerden tot ik toestemming gaf. Maar daarvoor hebben we de beta's toch? Zodat ontwikkelaars alvast kunnen voorbereiden? En alle apps werkten trouwens prima...

De ontwikkelaar heeft misschien al maanden een update hiervoor klaarstaan die hij gisteren pas voor het eerst kon insturen.
Kijk, en dit geloof ik nu echt niet. Je beweert dus dat ontwikkelaars al maanden kunnen voorbereiden maar die updates niet mogen pushen? Ik snap dat dit voor nieuwe features zou gelden maar voorbereidingen om de stabiliteit van je app te garanderen mogen toch echt wel weken of maanden geleden worden ingediend?

Is er een ontwikkelaar hier die het antwoord weet?

[Lord Anubis]

Denk je niet, dat zowel een developer als Apple, het risico willen lopen om een app versie gecompileerd met een beta in de App Store gooien en dan het moet verwijderen?
Je mag updates van de huidige iOS ter aanbieding geven, en deze zullen door het review team getest worden.
Ik heb een SwiftUI app die vorige week werkte, maar met de GM en Final niet meer juist werkt. Als ik deze een week geleden zou aanbieden werd deze sowieso afgewezen; en met het voortschrijdend inzicht, gelukkig. Wat een user experience zou dit zijn zeg.

[TechSupreme]

Externe devices? Welke apps zijn dat dan?

[BaseLine]

Externe devices? Welke apps zijn dat dan?

Ben niet degene waarop je reageert maar heb het zelf gemerkt met bijvoorbeeld Spotify voor het zoeken naar lokale devices om muziek af te spelen met Spotify Connect.

[TechSupreme]

Net geprobeerd maar bij mij werkt spotify connect zoals het hoort. Dus kan gewoon switchen tussen apparten waar Spotify op staat. In het venster van connect staat dat Spotify toestemming nodig heeft om te casten naar het netwerk.

Wat wel raar is dat bij mij de pop-up van iOS dan half Nederlands half Engels is.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 21:45]

[OmgItsKoen]

Alle apps die kunnen casten naar Chromecast hebben dit verschijnsel, maar tot zover ik heb kunnen zien werken alle apps prima hiermee. Wel moet ik daarbij zeggen dat ik de moeilijkste niet ben en dus altijd ‘Ja’ heb gezegd, weet niet wat er gebeurt als je ‘Niet toestaan’ aanklikt.

[TechSupreme]

Heb daar geen last van gehad. Als ik de app open wordt er netjes om toestemming gevraagd om apparaten te zoeken op het netwerk. Als ik die dan geef werkt het netjes.

Wat mij wel is opgevallen, na het geven van toestemming duurt het eventjes voor je het apparaat ziet. Misschien een kwestie van geduld? Opgevallen in Spotify omdat die standaard geen toestemming vraagt bij het openen.

/edit:

Net op de ipad nog een keer geprobeerd en inderdaad, het is een kwestie van even wachten. Als je toestemming geeft, sluit en opnieuw opstart dan verschijnen ze direct.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 21:45]

[Lord Anubis]

Of het een mug is of niet, het steekt deze actie van Apple. Er zullen wel degelijk apps zijn die nu veranderd moeten worden, 50, 100 of meer ik weet het niet.

En het maakt wel degelijk uit, als er een app aanwezig die werkt en jij komt met een uitgebreide versie die niet werkt, kan betekenen dat jij klanten kwijt bent.

[TechSupreme]

Luister eens, heb onderhand genoeg major en minor releases meegemaakt om te weten dat je nooit 100% bent, nooit! Of het duurt te lang, of iemand ergens heeft niet genoeg tijd, of het is niet genoeg getest, noem maar op er is altijd wel iets om over te zeuren. Als het echt in de orde van 100 apps zijn dan valt het allemaal echt mee en dan is het inderdaad een mug.

In de backend is er vrij weinig veranderd als het gaat om iOS, de veranderingen hebben betrekking op widgets, advertenties en ARM mac. Er is verder niet veel wat stuk kan gaan. Dan kan ik best begrijpen dat Apple het gas erop gooit.

[Mayonaise]

Je bent duidelijk geen ontwikkelaar. Een nieuwe OS versie kan breaking changes brengen.

Bijvoorbeeld de update naar Android Oreo vereiste dat men notificatiekanalen aan moest maken, anders werkten de notificaties niet...

[Mayonaise]

Ja.

[TechSupreme]

Heeft iOS 14 dan wel "breaking changes"?

[Mayonaise]

Overzichtje.

[Mayonaise]

Geofences are no longer supported by iOS for users who choose the new approximate location permission.

Use of the “Last Known Location” targeting features will require an upgrade to Braze iOS SDK v3.26.1+ for compatibility with approximate location permission. Note that if you are using XCode 12, you will need to upgrade to at least v3.27.0.

IDFA collection will soon require a permission prompt. Once Apple begins to enforce this change later in 2021, apps must update to use the new AppTrackingTransparency Framework.

If you use the “Ad Tracking Enabled” field for campaign targeting or analytics, you will need to upgrade to Xcode 12 and use the new AppTrackingTransparency framework to report end users’ opt-in status.

Cherrypicking is an art. En dit is maar enkel een voorbeeld van 1 framework.

En ja dat is zeker wel breaking. Staat toch letterlijk in dat de prompt dan niet fatsoenlijk werkt...

[Reactie gewijzigd door Mayonaise op 22 juli 2024 21:45]

[gday]

Dat er slechts een dat zit tussen aankondiging en release is dan ook niet het probleem. Het werkelijke probleem is dat de Golden Masters van iOS en Xcode gisteren pas uit zijn gekomen. Dat is bij mijn weten nog nooit zo kort van tevoren geweest.

Als je het artikel ook nog even volledig gelezen had , had je gelezen dat het voor developers belangrijk is om te weten of er bepaalde API's en features wel of niet in de uiteindelijke release komen. Daar heb je dus normaal een week de tijd voor om op in te springen, maar dat is nu slechts een dag. En dan moet Apple ook nog je app gereviewed hebben tussen het moment dat Xcode 12 GM uit is gekomen, en iOS 14 gereleased is.

[Reactie gewijzigd door gday op 22 juli 2024 21:38]

[ppl]

Als je het artikel ook nog even volledig gelezen had , had je gelezen dat het voor ons developers belangrijk is om te weten of er bepaalde API's en features wel of niet in de uiteindelijke release komen. Daar heb je dus normaal een week de tijd voor om op in te springen, maar dat is nu slechts een dag.

Dat is niet waar. De GM is niet per definitie hetzelfde als de release naar de rest van de wereld. We hebben al een aantal maal meegemaakt dat de GM door Apple is teruggetrokken omdat ze problemen in die build hebben ontdekt. Veel ontwikkelaars wachten dan ook niet de beta's of de GM af maar juist de release naar de rest van de wereld. Alleen dan is er de zekerheid of bepaalde API's en features in de uiteindelijke release zitten want ja, dat is de uiteindelijke release

Daarnaast zijn er ook al diverse andere ontwikkelaars geweest die wel in staat zijn geweest om iOS 14 compatible apps uit te brengen. Al tijdens de beta fase nog. Het ligt er in deze dan ook geheel aan of je de app op iOS 14 werkend wil hebben of dat je de app met de specifieke features van iOS 14 werkend wil hebben. Voor dat eerste hoef je echt niet te wachten op de GM of final release, voor dat tweede is het beter om te wachten op de final release (en dus NIET de GM). Hoe dan ook, het is een kwestie van planning en release management: wanneer stop je welke features in je applicatie. Bij de ontwikkelaars die nu klagen is het vooral alle iOS 14 features en API's vanaf dag 1 in de app hebben. Dan maak je het jezelf wel heel erg moeilijk, ook wanneer tussen GM en final release een week zit.

In tegenstelling tot wat de ontwikkelaars hier nu roepen is dit ook helemaal niet nieuw. Dit is een probleem zo oud als software zelf en reden waarom er zo vaak wordt geroepen om nooit direct een nieuwe software versie te installeren. Het is ook de reden waarom we de stap kennen van test naar acceptatie naar productie. We hebben dan ook nog nooit een nieuw OS gehad waarbij vanaf dag 1 alle stukken software het foutloos doen en er volledige compatibiliteit is. Dat duurt altijd een paar maanden. Dit soort zaken zit ook allemaal in release management van beheermethodieken als ITIL en weet ik wat nog meer aan afkortingen. Het is ook terug te zien in de acceptatiecijfers die Apple zelf steeds aanhaalt ("zoveel procent van de gebruikers heeft iOS versie x geïnstalleerd"); dat cijfer is nooit 100% na 6 maanden tijd.

@gday je reactie is exact wat ik zeg. Een app hoeft helemaal niet iOS 14 compatible te zijn om er op te kunnen draaien.

[Reactie gewijzigd door ppl op 22 juli 2024 21:45]

[Lord Anubis]

Wat KingFox schrijft hoef ik hier niet te herhalen. KingFox zit 100% dichter bij de waarheid en realiteit dan jij.

En wat is dat voor onzin over oneerlijke ios Developers?

Er kunnen wel degelijk bestaande app's zijn die opnieuw gecompileerd of aangepast moeten worden, dus 100% no problemo overgang is er niet.

Tevens zijn er developers die zelf wachten, is dus hun keuze, waardoor er of met 'oudere' versie's gewerkt moet worden of er een aantal gewoon stuk gaan of raar verdrag vertonen. Nu zal de 'broken' of niet uitgebrachte apps een stuk groter zijn. Een klant van mij verwacht nu dat zijn app klaar staat, terwijl we nu een stap verder weg zijn. Apple's belofte over zelfs SwiftUI apps uitbrengen is door de haast niet betrouwbaar. Voor een andere app nu volledig in SwiftUI ( converted van Obj-C ) wat ook nu uit kon komen volgens een reactie van Apple 'dien het maar in in de AppStore', is het zelfs zo dat ik nu moet wachten tot iOS15.

[KingFox]

Nadat je op het iOS 14-topic wat hebt lopen leuteren over releasemanagement, kom je dat nu ook even doen op dit nieuwsitem. Je gaat er opnieuw van uit dat het de fout is van developers en dat hun planning beter moet zijn, zonder rekening te houden dat het niet alleen draait om nieuwe features of gaat om een app iOS 14-ready te krijgen op basis van de iOS 13 SDK.

Wat voor jou misschien lijkt op "specifieke features van iOS14 werkend wil hebben" kan voor sommige developers betekenen dat ze de SDK van iOS14 nodig hebben om bijv. bugfixing te doen of iOS 14-compatibel te zijn, zonder app crash bij opstart bijvoorbeeld. Om dat te kunnen gebruiken moeten ze Xcode 12 hebben, en wanneer is Xcode 12 uitgebracht, officieel? Gisteren. Wanneer konden devs hun code builden, testen en insturen met Xcode 12? Gisterenavond. Je kan er niet vanuit gaan dat de Xcode/iOS beta's testen hetzelfde is als de finale release/GM/RC testen. Hoeveel tijd was er dan nog voor Apple om de app te reviewen en tijdig te releasen, zodat mijn gebruiker een werkende app bleef behouden? Minder dan 24u. Rekening houdende dat Apple je app niet reject of het was al dadelijk een onhaalbare piste geworden.

Apple stelt vaak hun gebruikers op de eerste plaats, maar hun gebruikers worden ook enkel tevreden als de kwaliteit van de apps op hoog niveau ligt. Dat ondermijnen ze door deze versnelde release, en da's niet echt oke.

Een GM terugtrekken wil ook zeggen dat Apple trouwens wel een nieuwe build zal voorzien als GM en vervolgens deze releasen. De GM is een soort "finale beta", een RC. In een RC kan je nog steeds bugs en issues ontdekken, net zoals je dat met je productiebuild ook nog kan hebben. Laat ons stellen dat de GM de RC is en in het merendeel van de gevallen ook effectief in productie zal gaan.

In software development maak je namelijk ook een RC dewelke je grondig gaat testen, daarom is het ook een RC. Komen er geen issues meer uit, heb je een grondig geteste package om naar productie te brengen. Heb je issues, ga je terug naar je IDE en fix je de bugs Wat mij betreft kan je een release dan nog best gefaseerd uitrollen, om onvoorziene impact te vermijden, mocht er toch nog iets mis gaan ondanks grondige testing. Apple neemt nu de tijd voor grondige testing af door een overhaaste release, da's iets wat je moeilijk bij developers kan leggen.

Op andere elementen van je post heb ik je ook van antwoord voorzien in de forumpost. Weet dat het allemaal wat verder gaat dan jouw visie over een roadmap of zuiver "van in het begin de meest recente feature aanbieden, omdat het kan".

[Reactie gewijzigd door KingFox op 22 juli 2024 21:45]

[ppl]

Nadat je op het iOS 14-topic wat hebt lopen leuteren over releasemanagement, kom je dat nu ook even doen op dit nieuwsitem. Je gaat er opnieuw van uit dat het de fout is van developers en dat hun planning beter moet zijn, zonder rekening te houden dat het niet alleen draait om nieuwe features of gaat om een app iOS 14-ready te krijgen op basis van de iOS 13 SDK.

Dat is niet alleen iemand persoonlijk aanvallen en woorden in de mond leggen, het is ook niet inzien dat het verhaal van de ontwikkelaars simpelweg niet klopt. Het is dieptriest om te zien hoe oneerlijk iOS developers vandaag de dag zijn geworden. Het hele verhaal wat je opsomt is alleen van toepassing wanneer je een app maakt met de specifieke iOS 14 features. Apps hoeven echt niet opnieuw gecompileerd of gereleased te worden om op iOS 14 te werken. Er zijn legio apps die dat niet zijn, sommigen zelfs zo oud dat ze al heel wat releases achterlopen.

Wat er hier in de discussie doelbewust wordt verzwegen en geridiculiseerd is het feit dat apps niet iOS 14 compatible hoeven te zijn om op iOS 14 te kunnen draaien.

Wat voor jou misschien lijkt op "specifieke features van iOS14 werkend wil hebben" kan voor sommige developers betekenen dat ze de SDK van iOS14 nodig hebben om bijv. bugfixing te doen of iOS 14-compatibel te zijn, zonder app crash bij opstart bijvoorbeeld.

Dat lijkt niet zo, dat IS zo. Als je iOS 14 dingen wil doen dan heb je die SDK en Xcode 12 nodig. Die mensen hebben een probleem maar dat probleem is zeer zeker niet zo groot als ze doen vermoeden. Er worden nu allerlei argumenten aangedragen die onzin zijn. Die GM periode is daar een heel goed voorbeeld van. Als het je echt om kwaliteit te doen is en je echt goed wil testen dan doe je dat niet met de GM maar met de final release. De meer ervaren iOS/macOS ontwikkelaars doen dat dan ook.

Apple stelt vaak hun gebruikers op de eerste plaats, maar hun gebruikers worden ook enkel tevreden als de kwaliteit van de apps op hoog niveau ligt. Dat ondermijnen ze door deze versnelde release, en da's niet echt oke.

En ook dit is weer een strohalm-argument. Dit is niet de eerste nieuw iOS release, het systeem bestaat inmiddels al dik 12 jaar. In die tijd hebben we gezien dat bij iedere grote release een aantal apps blijven werken en een aantal gewoon stuk gaan of raar verdrag vertonen. Dat zien we ook bij andere grote OS updates. Wat je hier dus noemt is iets dat onvermijdelijk is.

De GM is een soort "finale beta", een RC.

Precies een RC en dus niet een final release. Toch is dat hoe de klagers die GM behandelen en dat is dus niet zo erg slim. Weet wat een GM is en ken de beperkingen daarvan.

In software development maak je namelijk ook een RC dewelke je grondig gaat testen, daarom is het ook een RC. Komen er geen issues meer uit, heb je een grondig geteste package om naar productie te brengen.

Nee dus. Wat je hier noemt is de fase vóór de RC. Een RC is een Release Candidate, een versie die in aanmerking komt om vrij te geven voor het grote publiek. Dat grondig testen doe je dan ook vóórdat je iets als RC bestempelt want je wilt er zoveel mogelijk bugs uithalen. Zo'n RC doe je de deur pas uit wanneer je het idee hebt dat je genoeg bugs eruit hebt weten te halen en de boel stabiel genoeg is om het te kunnen releasen.

Weet dat het allemaal wat verder gaat dan jouw visie over een roadmap of zuiver "van in het begin de meest recente feature aanbieden, omdat het kan".

Jammer om te zien dat je mijn post dan totaal niet hebt begrepen. Het gaat namelijk niet om mijn visie of om een roadmap maar om een professionele aanpak van ontwikkeling. Het gaat echter bovenal dat men beter moet vertellen waar de problematiek zit. Dat gebeurd niet, ook niet in je posts hier of op het forum. Is eenvoudig op te lossen: beter uitleggen wat je keuzes zijn en waarom.

[Reactie gewijzigd door ppl op 22 juli 2024 21:45]

[gday]

Apps hoeven echt niet opnieuw gecompileerd of gereleased te worden om op iOS 14 te werken.

Wat er hier in de discussie doelbewust wordt verzwegen en geridiculiseerd is het feit dat apps niet iOS 14 compatible hoeven te zijn om op iOS 14 te kunnen draaien.

Dit is simpelweg niet waar. Ik heb een paar jaar geleden al eens meegemaakt dat een reeds gepublishte app die gebuild was voor voorgaande iOS-versies opeens crashte bij een final build van een nieuwe iOS-versie. Ik heb daarvoor toen een fix moeten uitbrengen, maar enkele honderdduizenden gebruikers zaten toen wel met een app die crashte bij launch nadat ze de iOS-update hadden geïnstalleerd. Daar word je echt niet blij van. Destijds vond ik het echter mijn eigen schuld, omdat ik er vanuit ging dat alles goed zou gaan omdat ik al getest had met de betaversies en daar dus niet scherp op was, maar het was wel een onaangename verrassing. Ik heb daarvoor toen een Expedited App Review in kunnen dienen die Apple gelukkig goedkeurde.

Omdat de GM doorgaans hetzelfde is als de final release (ja, niet altijd, daar zijn we het over eens en dat hoef je niet te blijven herhalen) is dat wel een manier om dit soort last-minute problemen te voorkomen.

[Reactie gewijzigd door gday op 22 juli 2024 21:45]

[TheDutchChief]

Mijn Triodos bank app deed het voor de update nog wel...

[KingFox]

Wat jij aanhaalt is iets dat iedereen weet en waar ook NIEMAND over in discussie gaat, maar dan ook enkel jij. Elke iOS dev weet dat het niet verplicht is om een nieuwe build in te sturen om compatibel te zijn met iOS14. Mijn hobby-app werkt perfect met een oude versie. Ik ga er niet meer woorden aan spenderen, maar de discussie gaat erover dat als je wel een iOS14 update moet uitsturen omwille van compatibiliteit of omdat je nieuwe features wilt lanceren, je gewoonweg geen tijd kreeg door de 24-urenbeslissing van Apple. Dat wil je precies gewoon niet vatten terwijl dat net de discussie is.

Als jij zegt dat het verhaal van ontwikkelaars niet klopt, wil jij ontkennen wat wij in de praktijk meemaken. Ik snap niet dat je dat niet kan vatten.

Als ik jouw verhaal doortrek (en wat je ook stelselmatig negeert) is dat als mijn app, gebuild met iOS13-SDK, breekt op iOS14 en ik dat pas kan fixen en finaal valideren 1 dag voordat het OS uitkomt, dan heb ik als dev geen reden om te klagen en is volgens jou de schuld van de dev Lekker bezig man...

[gday]

Dat is niet waar. De GM is niet per definitie hetzelfde als de release naar de rest van de wereld. We hebben al een aantal maal meegemaakt dat de GM door Apple is teruggetrokken omdat ze problemen in die build hebben ontdekt. Veel ontwikkelaars wachten dan ook niet de beta's of de GM af maar juist de release naar de rest van de wereld. Alleen dan is er de zekerheid of bepaalde API's en features in de uiteindelijke release zitten want ja, dat is de uiteindelijke release

Natuurlijk is er geen 100% garantie dat de GM hetzelfde is als de final, maar dat is wel waarom Apple de GM van tevoren seed naar developers. Dát is namelijk ook hét moment waarop Apple actief developers vraagt om de updates in te dienen in App Store Connect. Als je als developer gaat wachten tot de final ben je gegarandeerd ‘te laat’ met releasen van een update. Zelf kan ik me trouwens niet herinneren dat er ook daadwerkelijk API’s geschrapt zijn na het terugtrekken van een GM. Wel dat er nog bugs gefixt zijn. Heb je daar wellicht een voorbeeld van? Of wellicht een voorbeeld van een situatie waarin Apple een GM een dag voor de final release uitbracht, die GM vervolgens terugtrok, maar alsnog doorging met de final release? Lijkt me een vreemde manier van werken.

Daarnaast zijn er ook al diverse andere ontwikkelaars geweest die wel in staat zijn geweest om iOS 14 compatible apps uit te brengen. Al tijdens de beta fase nog.

Bedoel je apps die gebuild zijn voor iOS14? Dat kan namelijk niet want die kon je nog niet indienen. Als het gaat om testen of een app wel of niet crasht is dat een ander verhaal natuurlijk, al kun je dat met een beta ook niet altijd betrouwbaar testen. Maar developers die puur hierop willen testen zijn ook minder geschrokken in deze situatie.

Het ligt er in deze dan ook geheel aan of je de app op iOS 14 werkend wil hebben of dat je de app met de specifieke features van iOS 14 werkend wil hebben. Voor dat eerste hoef je echt niet te wachten op de GM of final release, voor dat tweede is het beter om te wachten op de final release (en dus NIET de GM). Hoe dan ook, het is een kwestie van planning en release management: wanneer stop je welke features in je applicatie. Bij de ontwikkelaars die nu klagen is het vooral alle iOS 14 features en API's vanaf dag 1 in de app hebben. Dan maak je het jezelf wel heel erg moeilijk, ook wanneer tussen GM en final release een week zit.

Soms is het belangrijk om een feature eerder te implementeren dan je concurrent. Apple vraagt developers actief om nieuwe features te implementeren en de updates in te dienen. Zoals gezegd is de GM inderdaad niet altijd gelijk aan de final, maar doorgaans wel. Met iOS14 zijn ze ook gelijk, dus als je je concurrent voor wilt zijn ben je nu eenmaal aangewezen op de GM. Het is nu eenmaal je beste referentiepunt als je op moment van final release klaar wilt zijn. Daarnaast is de GM ook de meest betrouwbare release om op het laatste moment nog te testen of je ‘oude’ versie daadwerkelijk 100% functioneert in iOS 14, want dat je app in beta’s niet crasht zegt niet alles. En dan heb ik het dus over de situatie waarin je niet eens nieuwe features implementeert. Blijkt je app opeens te crashen in de GM, dan moet je dus vliegensvlug aan de slag. En daar wil je niet pas achterkomend als de final release al uit is.

Voor mij persoonlijk maakte het overigens in wezen ook niet uit omdat ik nog niet release met Xcode 12 en mijn apps allemaal correct werken met de GM maar ik snap de schrik bij collegadevelopers heel erg goed.

[Reactie gewijzigd door gday op 22 juli 2024 21:45]

[supersnathan94]

En dan kan je zeggen tsja hea. Dan dien je de boel een paar dagen later in, maar het probleem is dus dat je app wel degelijk bugs kan gaan vertonen hierdoor. Ook al heb je de boel netjes bijgehouden.

Het kan dus zijn dat je daardoor een paar dagen een niet werkende app live hebt staan.

Vanuit developer en consument dus niet zo’n goede zet. Jammer, want ze hadden best kunnen zeggen dat de launch ook vrijdag zou zijn net als de nieuwe producten. Had niemand gek van opgekeken.

[SpoekGTi]

Een update uitbrengen kan op dezelfde dag gezien dat vaak minor updates zijn, een hele OS upgrade is ff andere koek.

Daarbij zijn alle iOS versies gelanceerd op de leverdatum of net een dag voor de levering van de nieuwe iPhones, met uitzondering van de iPhone X en de iPhone 12 dus nu

[mjz2cool]

Als het eerder is gebeurd, zal er ook dan over geklaagd zijn. Het is gewoon niet handig als de public release een dag na de GM is, in plaats van normaal een week later.

Ik kan overigens niet vinden wanneer dit eerder is gebeurd bij een os upgrade.

[Reactie gewijzigd door mjz2cool op 22 juli 2024 21:45]

[Luuk2015]

Maar waarom zou Apple er voor kiezen om iOS 14 zo snel uit te brengen?
Stel ze hadden gister nieuwe iPhones aangekondigd dan begrijp ik dat nog wel, maar dat hebben ze niet gedaan. Ze kunnen dan toch makkelijk nog een paar weken wachten?

[Keypunchie]

Nodig voor WatchOS dat op de nieuwe horloges draait?

Dus weken wachten, nee. Maar ze hadden wel langer dan een dag kunnen wachten. Of eerder iOS 14 release kunnen aankondigen

Aan het einde van de rit is het storm in glas water, de verschillen tussen iOS 13 en 14 zijn niet immens. In ieder geval had ik in de Beta (vanaf public 6) geen enkele app die problemen gaf/niet wilde starten.

Ze zullen er wel zijn, maar niet veel.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 21:45]

[Luuk2015]

Ah thanks, dat was ik even vergeten.

[SpoekGTi]

Nee want a die nieuwe horloges heb je dan ook pas over een week. En B dan zou ik dat ook al moeten hebben voor de oude die naar watchOS 7 gaan

[Caayn]

Het was toch juist het hele doel van de oefening om het allemaal minder afhankelijk van elkaar te maken en apart te kunnen releasen en optimizen? Dat was toch zo'n beetje de hele reden dat bijvoorbeeld iPadOS in het leven geroepen was vorig jaar.

[X-GeaR]

Nieuwe widgets worden automatisch boven de oude widgets geplaatst (in het linkerscherm). Rare keuze dat het niet langer mogelijk is om zelf de volgorde te bepalen. Ik wil de Apple-widgets bijv onder Google News.

[WhatsappHack]

Dat lijkt er vanaf te hangen dat de widgets compatible met iOS 14 als “widgets” worden gezien en de rest als legacy. Dus als Google News de app update mét iOS 14 widgets: dan kan je de volgorde weer indelen. Alle widgets die niet compatible zijn komen in die donkere box onder de andere widgets; je kan van die legacy widgets onderling wel de volgorde indelen.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 21:45]

[mjz2cool]

Het is maar tijdelijk, de oude widgets moeten ergens een plek hebben, en dan is het een logischere keuze om deze onderop te plaatsen, zodat de nieuwe widgets meer aandacht krijgen. Het is niet logisch om extra functionaliteit toe te voegen om de volgorde van de nieuwe en oude widgets onderling te verwisselen, als die oude widgets vervangen gaan worden.
Wat ik wel een nadeel vind, is dat ik die oude widgets voornamelijk gebruikte vanuit long-press op een app icoontje, dit is nu ook verdwenen.

[Mr. Bourbon BBQ]

Long-press werkt goed hier. Ik kijg gewoon netjes een menu-popup, of doelde je daar niet op?

[mjz2cool]

Long-press werkt wel, maar in iOS 13 kreeg je bij de telefoon app bijvoorbeeld 4 favoriete contactpersonen te zien, bij Whatsapp je recente chats, en zo kreeg je bij de meeste apps de bijbehorende widget te zien.

[Mr. Bourbon BBQ]

Oh ja, nu zie ik het.

Dat voelt inderdaad als een stap terug.

Wellicht een bug.

[mjz2cool]

Ik denk dat het te maken heeft met de nieuwe widgets. Die in de long-press popup waren de oude widgets. De nieuwe widgets passen naar mijn idee ook niet mooi bij qua design.

[Mr. Bourbon BBQ]

Dat viel mij ook op. Het is volgens mij het verschil tussen widgets die wel en niet compatible zijn met iOS 14. Het wordt dus even wachten op updates van developers.

[funrider]

Inmiddels zijn er al aardig wat apps (hier mijn lijstje van 80+ apps) voorzien van een update met iOS14 homescreen widgets.

[Mr. Bourbon BBQ]

Cool.

[Enchantress]

Top, ga ik gelijk downloaden. Alle tracking en reclame blokkeren.

[gise]

Volgens mij komt die functionaliteit pas later dit jaar

[Stinky9]

Dat zat er al in.... Ook in iOS <14. Staat alleen standaard uit. Moet je dus zelf aanzetten:

Instellingen - Privacy - Reclame - Beperk Reclame Tracking aanzetten.

Klaar!

In hetzelfde menu kun je ook je Reclame ID opnieuw instellen, oftewel elke dag, week of hoe vaak je maar wilt. Reclame tracking wordt dan een héél stuk lastiger.

[Reactie gewijzigd door Stinky9 op 22 juli 2024 21:45]

[gise]

Moest even zoeken, maar: nieuws: Apps op iOS 14 moeten vanaf begin volgend jaar toestemming voor track...


Ook dat Facebook stelt dat ze een daling in inkomsten verwachten door iOS14.
Mij lijkt het dus niet een systeem instellingen, maar een opt-in, per app, om te mogen tracken?

[WhatsappHack]

Het zat er al jaren in, maar idd als opt-out en dan alles of niets. Wat iOS 14 gaat doen is standaard opt-in, waarbij apps toestemming moeten vragen aan je. Als je dit echter uitzet, globale opt-out, of in een eerdere iOS versie al had uitgezet: dan kunnen apps geen toestemming (meer) vragen en is het simpel “deny all”. Mensen die dit dus al op opt-out hebben staan nu in iOS 13 merken geen enkel verschil.

[Stinky9]

Zou kunnen. Ik weet het niet. Ik ben er vanuit gegaan dat deze optie in de instellingen straks standaard aan staat in iOS14 ipv uit.

Maar eh... We gaan het straks meemaken!

[Sjeefr]

Dat is uitgesteld, toch?

[B38A12A]

Maar...
Doen, of beter wachten?

Edit: hebben de ontwikkelaars van authenticator apps alsmede de banken hun zaken reeds op orde voor iOS 14?

[Reactie gewijzigd door B38A12A op 22 juli 2024 21:45]

[vinsterdamus]

Waarom zou je wachten? Als je het niet fijn vind dat het een en ander misschien niet werkt of dat ergens misschien een bug in kan zitten dan zou ik wachten. Voor mij is het belangrijk dat m'n mail werkt en al het andere mag er even uit liggen geen probleem zolang het m'n telefoon niet bricked is het geen probleem dat er een paar schoonheidsfoutjes zijn.

Je kan vast terug als het on dragelijk is

[supersnathan94]

Nee je kan niet zomaar terug. Sws kun je nooit een backup terugzetten naar een oudere versie plus een restore kan altijd alleen naar de nieuwste versie.

Je kunt via een omweg ws nog 1 of 2 weken codesigning krijgen voor een vorige versie (losse ipsw terigzetten via custom update), maar dan moet je die wel zien te vinden en actief kunnen (laten) signen én je moet een backup hebben van voor die versie. Dus je bent hoe dan ook wel wat data kwijt. Daarom heb ik voor veel belangrijke apps afzonderlijke ocloud backups draaien (zoals whatsapp met 2gb aan data).

[WhatsappHack]

Backup terugzetten naar oude versie is super simpel als je maar backupt met een tool als iTunes of iMazing Gewoon de iOS versie in de .plist aanpassen en hij herstelt hem zonder gezeik.

[supersnathan94]

Oh lol. Goeie tip. Die kende ik nog niet.

Dergelijke dingen vereisen echter wel wat kennis. Dus voor de gemiddelde Johny Appleseed misschien niet de meest handige oplossing .

[mjz2cool]

Je kan sowieso eenvoudig terug zolang de vorige versie nog ondertekend blijft (inderdaad met zo'n ipsw file), en backups terug zetten kan met een beetje moeite ook. Toch zou ik gewoon een schone installatie doen in zo'n geval. Los daarvan, er zijn eigenlijk weinig redenen om niet te upgraden.

[supersnathan94]

Je kan sowieso eenvoudig terug zolang de vorige versie nog ondertekend blijft

Ja en dat is hoogstens een paar weken.

inderdaad met zo'n ipsw file

heb jij die zo 1,2,3 liggen? ik niet namelijk. dus die zou ik dan ergens vandaan moeten trekken.

en backups terug zetten kan met een beetje moeite ook.

Ja WhatsappHack gaf het hierboven aan.

Dit zijn echter geen dingen die je als John Appleseed even uitvoert, dus voor een gemiddelde consument is dat dus al niet "zomaar terug".

[mjz2cool]

Klopt, maar dat is toch genoeg als je die updates gelijk installeert? En dan kost het misschien een paar minuutjes online zoeken, maar het is vrij eenvoudig te vinden, en er zijn voldoende tutorials die je stap voor stap helpen.
Bovendien is het niet persé nodig om te downgraden, met een paar klikken kun je je iPhone herstellen vanuit iTunes, zonder dat je wat kwijt raakt.

[supersnathan94]

Bovendien is het niet persé nodig om te downgraden

het punt om terug te willen is juist dat bepaalde dingen echt systematisch kapot zijn, Apps die niet geupdate zijn en dus niet werken, maar die je wel nodig hebt.

Klopt, maar dat is toch genoeg als je die updates gelijk installeert?

hoogstens een paar weken he. het kan ook drie dagen zijn. En dan kan het dus net vervelend uitkomen.

[B38A12A]

Nou, als mijn internetbankieren en authenticator apps niet goed werken dan wordt het toch wel zeuren hoor.
Dan wacht ik liever, vandaar de vraag.
Ik update graag, maar het moet op de essentiele onderdelen wel betrouwbaar blijven.

[mjz2cool]

Ik heb persoonlijk nog nooit gehad dat internetbankieren en authenticators niet werken, zelfs niet in de beta's. Welke apps gebruik je daarvoor?

[Tokkes]

zolang het m'n telefoon niet bricked is het geen probleem dat er een paar schoonheidsfoutjes zijn.

Dat zou nochtans ook niet de eerste keer zijn dat zoiets gebeurd.

Gewoon lekker afwachten in plaats van als een gek die update binnen te halen van het moment dat die uitkomt. Als je 15 bent en je hebt tijd over om ermee aan de slag te gaan als het eventueel fout loopt, geen probleem, deed ik ook. Maar tegenwoordig wil ik die uren er echt niet meer insteken, het moet werken en blijven werken.

[mjz2cool]

Gewoon upgraden wanneer je de telefoon even kwijt kunt, dan is er niets aan de hand. In het enkele geval dat het wel fout gaat kost het je misschien een half uurtje om via iTunes (of Finder in Mac OS Catalina en hoger) een herstel te doen zonder je data kwijt te raken.
Als je bang bent dat het fout gaat kun je geen enkele update meer installeren.

[ikweethetbeter]

Mijn advies: wacht ten minste op iOS 14.0.1.

[supersnathan94]

Kan je lang wachten als ze direct met 14.1 uitkomen ;P

Nah kijk het een weekje aan. Check je favoriete apps op release notes en houd even in de gaten of er nog bugs in het nieuws verschijnen. Ik kijk volgende week of ik over ga op 14 voor iPhone. IPad gaat vannacht al over. Die kan ik missen dus is het niet erg als ie ff niet werkt.

[ikweethetbeter]

Vandaar dat ik ten minste zei...

[supersnathan94]

Dan nog is dat wel een heel generiek timeframe. Stel dat dat nog een maand gaat duren en het dan nog niet gelukt is met die ene app die jij wel nodig hebt?

Zit je nog steeds met een niet werkende app.

Of ze brengen het eind van de week uit en de ontwikkelaars van die app hebben er nog steeds niet voldoende tijd voor gehad wegens een bepaalde bug?

Zit je nog steeds met een niet werkende app.

Conclusie. Doe onderzoek of je over kan. Er is geen holy grail mbt versienummers die je kunt gebruiken.

[supersnathan94]

Misschien moet je even opzoeken hoe semantic versioning werkt. Het nummer zegt niets over het aantal ertussen. 14.0.45 is namelijk prima mogelijk. Net als 14.0.4320. Zeer onwaarschijnlijk, maar wel mogelijk.

Semantic versioning werkt met drie nummers: major.minor.patch. Aan de positie van een nummer kun je dus zien wat voor update het is. Een x.x.1 versie is dus altijd een bugfix of security fix.
Een x.1.x is altijd een feature addition die backwards compatible is dus waar je als software dev niets voor hoeft te doen om het werkend te houden.
1.x.x is een major upgrade. Dit kan alles zijn tussen een volledige rewrite met andere API’s tot een boolean waarde die nu default false teruggeeft ipv true. Niet backwards compatible dus succes ermee.

[ikweethetbeter]

Ik heb al enige tijd Apple spullen. De eerste fix komt binnen een week, en dat is altijd de versie die je wil hebben, met uitzondering van iOS 13, de versie die vorig jaar net iets te vroeg werd uitgebracht (maar dat was algemeen bekend).

[klakkie.57th]

ik draai nu toch al een tijdje alle beta's van ios 14 en mijn bankapp blijft netjes werken.
Eigenlijk geen enkel probleem gehad . Ook mijn microsoft authenticator werkt zonder probleem.

[Reactie gewijzigd door klakkie.57th op 22 juli 2024 21:45]

[tomic]

Als je de komende dagen afhankelijk bent van 3rd party apps op je iPad/iPhone is het aan te raden de update nog even uit te stellen. De ontwikkelaars kunnen dan een update uitbrengen voor IOS 14 compatibiliteit.

[mjz2cool]

In principe moet elke app gewoon compatible zijn. Misschien wat verouderde apps die problemen krijgen, maar het meeste moet gewoon werken. Ontwikkelaars hebben al een aantal maanden gehad om hun apps te testen en updaten voor iOS 14, alleen hebben ze nu wat weinig tijd gehad om te testen of aan te passen op basis van de GM versie.

[m00d]

Ik draai iOS 14 sinds development beta 1 en heb geen enkel probleem gehad.

Bunq en ING werken perfect, alle andere apps ook.

[tiies]

iOS had altijd mijn voorkeur boven Android vanwege de simpelheid en eenvoud, zonder eindeloze mogelijkheden om dingen in te stellen zoals widgets, emoji en weet ik het allemaal meer. Naar mijn mening wordt het steeds rommeliger, tevens lijkt het aantal bugs met elke versie toe te nemen.

[mjz2cool]

Daar verandert niet zoveel aan als je de nieuwe features niet gebruikt. De meeste drastische vernieuwingen moet je al zelf in gebruik nemen, zoals die widgets. Wel kan het zijn dat bepaalde widgets die eerder alleen in het meest linker scherm geplaatst kunnen worden, na een app update vervangen zijn met die nieuwe widgets, maar deze kun je nog steeds in datzelfde linker scherm plaatsen.
Je hebt nu wel de app library waar je niet echt onderuit kunt, maar als je geen instellingen verandert, blijven nieuwe apps gewoon op je beginscherm geplaatst worden, en kun je die library gewoon negeren.

[tiies]

Ik begrijp uiteraard dat je al die functies niet hoeft te gebruiken, maar met elke update wordt het OS weer groter, en al die extra functies komen de stabiliteit en snelheid niet ten goede.

[mjz2cool]

Ik heb zelf nog nooit echt problemen met snelheid en stabiliteit gevonden. Het maakt natuurlijk de kans op bugs wel groter, maar ze kunnen moeilijk een custom iOS aanbieden voor iedere gebruiker.

[PakoeDIEP]

Je vergeet dat je het niet hoeft te gebruiken. De update geeft gebruikers meer opties, wat ik een plus vind.
Als je geen fan bent van widgets, gebruik het niet.

[cranebird]

Als je de widgets niet gebruikt, dan verandert er eigenlijk niks in je interface. Apple lijkt er bewust voor gekozen hebben om bestaande gebruikers niet af te schrikken. Als je iOS14 installeert en je doet zelf niks, dan lijkt er maar weinig gewijzigd te zijn. Een heleboel subtiele tweaks die je niet snel zult opmerken.

iOS 14 beta's waren stabieler dan ooit, dus met de bugs valt het mee.

[Anoniem: 767041]

ik ontvang hem nog steeds niet ios14

[WhatsappHack]

iPhone herstarten wil nog weleens wonderen doen.

[Anoniem: 767041]

al gedaan,.. zelfs net een volledige reset(moes toch nog is,.. cleanup)

[WhatsappHack]

Heb je wel een compatible iPhone? Hier op alle devices ergens rond 22:00 beschikbaar gekomen.

[Anoniem: 767041]

jazeker, iphone xr, maar waarschijnlijk apple netwerk overbelast.. ik zag hem net even ios14 update op mobiel en daarna schoot hij weer weg

[WhatsappHack]

Leip. Oh well, je kan hem eventueel ook altijd aan iTunes/Finder hangen en dan updaten. Succes!

[Anoniem: 767041]

Dat heb ik ookal geprobeerd en ging ook niet x) error code 4000

[WhatsappHack]

Dat is raar! Error 4000 komt meestal uitsluitend voor als ofwel a.) je reeds de nieuwste versie draait (dus de iOS 14 GM van gisteravond bijvoorbeeld?) of b.) je iPhone gelockt was toen je PC/Mac de update probeerde te starten. o0

[Anoniem: 767041]

nope er staat nog steeds ios13.7.... uw software is up-to-date

[Anoniem: 767041]

oke nu nog is geprobeerd... vanochtend nog steeds geen ios14 op mn telefoon,.. en ge checked weer via itunes,..op laptop daar was ik blijkbaar nog vergetene aan te melden op itunes... en voor de zekerheid de toegangscode van mn iphone afgehaald... nu lijkt het wel te werken via itunes

[basst85]

Ik heb zelf de GM-release van gisteren en ervaar en issue met het refreshen van widgets.
Bijvoorbeeld de klok widget, deze loopt soms een uur achter.

Dit issue was er ook bij de eerste bèta's, en later opgelost. Maar blijkbaar weer terug?

[gise]

Probleem zat in alle bèta’s, ook in Beta8 en dus de GM, hij loopt alleen niet altijd verkeerd waardoor het niet altijd opgemerkt kan worden.

[basst85]

Dacht dat het was opgelost vanaf beta 4 of 5, toen is het mij tot de GM niet meer opgevallen.

[mivadi574]

Instal is bezig op de iPad, AppleTV. Watch moet eerst de iPhone klaar zijn.
Op de iPhone nog aan het downloaden. Lijkt erop dat het drukker is op de download voor de iPhones. An sich logisch wel ergens...
Ben benieuwd hoe lang de instal gaat duren.

[Reactie gewijzigd door mivadi574 op 22 juli 2024 21:45]

[supersnathan94]

De dag na launch is het altijd druk omdat iedereen en z’n moeder direct de update gaat downloaden. Met enkele miljarden actieve apparaten heeft dat zelfs zichtbaar impact op het internet qua verstookte bandbreedte.

[derikkert]

Toch leuk dat Apple nogsteeds updates geeft aan een 6 jaar oude iPad Air 2. Dat zie je bijna nooit in de mobiele wereld, meestal gaat het na een paar jaartjes met updates en dan stopt het ermee bij de meeste merken.