Om meer afbeeldingen op een mobiel apparaat op te kunnen slaan kun je of meer opslagruimte kopen, of de afbeeldingen sterker comprimeren. Apple kiest voor een dubbele strategie. De maximale opslag van een iPhone is vergroot: een iPhone van 256 GB is niet meer extreem duur. Maar dat is nog maar stap één.

In 2017 voegde Apple ondersteuning toe voor opvolgers van het JPEG- (voor afbeeldingen) en H.264-formaat (voor video):

• HEIF (High Efficiency Image File Format) is een zogenaamd container-formaat, waarmee uitgebreide metadata, statische afbeeldingen en sequenties (zoals snel achter elkaar geschoten foto's of Live Photos) samen opgeslagen worden in een enkel bestand.
• HEVC (High Efficiency Video Coding), ook bekend onder de naam H.265, kan video 40–50% effectiever coderen, en levert dus kleinere bestanden op dan H.264 - met dezelfde beeldkwaliteit.

(Voor de technische kleine lettertjes raden we je aan om “HEVC en HEIF maken foto's en video efficiënter,” 30 juni 2017, te lezen.)

Ondanks dat deze bestandsformaten al bijna drie jaar geleden geïntroduceerd zijn waren wij van TidBITS niet goed bekend met de namen HEIF en HEVC. Apple gebruikt deze termen wel, maar de bestanden die deze codering gebruiken worden opgeslagen met de extensies .heic en .mov. (Eén en ander kwam naar voren, doordat de Amerikaanse College Board niet met afbeeldingen van de iPhone overweg bleek te kunnen. Zie “TTake a HEIC: Verzeker je ervan dat AP en andere toetsuploads werken vanaf je iPhone en iPad”, 21 mei 2020.)

De eerste extensie, HEIC, staat kennelijk voor High Efficiency Image Container — daarover zometeen meer. De tweede extensie is zo mogelijk nog verwarrender, omdat MOV-bestanden al tientallen jaren bestaan. MOV is een containerformaat voor video, dat gebruik kan maken van diverse coderingen, waaronder ook HEVC.

Apple noemt HEIF en HEVC op diverse plekken, zoals in "Instellingen > Camera > Structuren". Daar kun je kiezen voor "High Efficiency" (de nieuwere codering) en "Meest compatibel" als je JPEG en H.264 wilt. (Overigens wordt H.264 in een MOV-container opgeslagen). HEIC wordt helemaal niet genoemd, net zomin als het feit dat het MOV-formaat gebruikt wordt voor het opslaan van HEVC, zelfs niet op de ondersteuningspagina waar HEIF en HEVC uitgelegd worden.

Omdat dit allemaal niet eenvoudig boven water te krijgn was, ondanks het feit dat we dagelijks met dit soort dingen bezig zijn, zijn we er eens ingedoken - met dit artikel als resultaat.

HEVC

H.265, wat feitelijk gewoon een andere naam is voor HEVC, biedt substantiële verbeteringen in compressie doordat de afzonderlijke beelden van video slimmer en flexibeler geanalyseerd worden, om vervolgens vooral de verschillen tussen twee beelden op te slaan. HEVC kan zowel stilstaande afbeeldingen als video comprimeren.

HEIF

HEIF is een containerformaat, ontwikkeld door de Moving Picture Experts Group. Een organisatie die inmiddels al een hele serie formaten voor audio en video voortbracht. HEIF wordt gebruikt voor stilstaande afbeeldingen, en biedt ruimte voor het bestand zelf, eventueel aangevuld met extra lagen uit programma's voor het bewerken van afbeeldingen, alfa-maskers en dieptelagen. Meerdere afbeeldingen kunnen er ook opgeslagen worden, als een sequentie (zoals "burst"-foto's die snel achter elkaar geschoten zijn) of als een eenvoudige animatie (zoals met Live Photos).

Een containerformaat is een soort map binnen een bestand. Oudere formaten als GIF, JPEG, PNG en TIFF slaan metadata op in het afbeeldingsbestand, gewoonlijk vanaf het begin. GIF is al lang geleden aangepast om meerdere afbeeldingen in een bestand mogelijk te maken (voor animaties), en TIFF ondersteunt meerdere pagina's in één enkel bestand. Maar elk van deze opties vereist uiteindelijk het uitpakken van het gehele bestand. Omdat HEIF een container is heeft iedere afzonderlijke afbeelding of sequentie een eigen bestand binnen de container, en de metadata worden ook in afzonderlijke bestanden opgeslagen. Dit is robuuster en meer compatibel tussen systemen, en zelfs bruikbaar voor toekomstige systemen.

HEIC

Een HEIC-bestand is een specifieke manier om HEIF te gebruiken, waarbij de HEIF-container alleen HEVC gebruikt om bestanden te coderen. Niet-Apple-besturingssystemen, camerasoftware, en apps voor het bewerken van afbeeldingen gebruiken of ondersteunen vaak variaties van HEIF. Zo heb je AVCI, dat gebruikmaakt van AVC (Advanced Video Coding) om de gegevens in HEIF-formaat op te slaan.

Als je iCloud Foto's aan hebt staan, kun je de extensie .heic zien staan bij bestanden die je vanaf de iPhone synchroniseerde met Foto's voor macOS. iOS is echter voorzichtig bij het exporteren van bestanden, wat kan betekenen dat HEIC-bestanden geconverteerd worden naar JPEG (voor stilstaande afbeeldingen) of JPEG plus een H.264-MOV bestand (voor Live Photos) als iOS denkt dat het ontvangende apparaat geen HEIC weer kan geven.

MOV

HEVC video's worden verpakt in MOV-containers. Je moet echt dieper kijken om te zien of ze H.265-gegevens bevatten — waarvoor je ofwel iOS 11 of nieuwer nodig hebt, dan wel macOS 10.13 High Sierra of nieuwer - of dat ze in H.264 gecodeerde video bevatten, die wel af zal spelen op oudere apparaten. iOS zal, net zoals bij HEIC, een H.264-gecodeerd, MOV-bestand exporteren, tenzij zeker is dat het ontvangend apparaat HEVC/H.265 kan lezen.

Je kunt de interne coderingsformaten van een MOV-bestand in macOS controleren door het bestand in QuickTime Player te openen, en te kiezen voor "Venster > Toon filminfo". Onder "Videostructuur" zie je de codering van de video- en audioformaten, evenals afmetingen en andere informatie.

Ik hoop dat het bovenstaande de dingen opheldert, althans een beetje. Om kort te gaan: HEIC is Apple's eigen HEIF-versie. Een formaat dat alleen met HEVC werkt als compressie-methode voor stilstaande beelden. Voor met HEVC gecomprimeerde videobeelden blijft Apple MOV-containers gebruiken.

Apple liet niet veel los over tvOS 14 en HomeKit tijdens de keynote van de 2020 WWDC-conferentie, maar voor beide systemen staan er later dit jaar wat interessante functies op stapel. We behandelen ze samen, omdat er meer overlap dan ooit is tussen de Apple TV en Apples domotica-platform. Ik heb hierdoor dit jaar aardig wat werk te doen, met het updaten van Take Control of Apple TV en Take Control of Apple Home Automation. En ik weet zeker dat Glenn Fleishman druk zal zijn met het updaten van Take Control of Home Security Cameras.

Wat kunnen we verwachten in tvOS 14?

Zoals al een aantal jaren gebruikelijk, bevat ook tvOS 14 geen revolutionaire nieuwe dingen voor de Apple TV. Toch is de Woning-app nu op Apple TV aanwezig, is er betere integratie met beveiligingscamera's, een picture-in-picture-functie los van de Apple TV app, meer ondersteuning voor 4K, delen van audio met AirPods, en bredere ondersteuning voor game controllers.

De echt interessante vraag is, of Apple nieuwe Aerial-screensavers zal introduceren. Voor veel mensen waren deze video's de zichtbaarste verbeteringen in de recente versies van tvOS.

Woning-App

Het grootste nieuws in tvOS 14 is de toevoeging van de Woning-app. Hoewel we al jaren HomeKit-accessoires konden aansturen via Siri op de Apple TV, was er nog geen ingebouwde Woning-besturingsscherm. tvOS 14 brengt daar verandering in. Ik weet niet hoe zinvol de Woning-app op tvOS in de praktijk zal zijn, maar het is zeker handig om te hebben, vooral als je een huis deelt met iemand die verder geen Apple-producten heeft.

Wat interessant is aan Woning op de Apple TV, is hoe het integreert met de HomeKit-camera's die je wellicht hebt. Net als in iOS kun je favorieten bedienen vanuit het Control Center, en je ziet daar ook het beeld vanaf geïnstalleerde camera's. Als je er één selecteert krijg je het camerabeeld schermvullend te zien.

tvOS 14 maakt aan HomeKit gekoppelde deurbel-video interessanter. Als iemand aanbelt krijg je een voorvertoning (PiP) te zien bovenop iedere willekeurig video die op dat moment aan het afspelen is, en je ziet dan het beeld van de camera.

Betere ondersteuning van 4K

Apple benadrukt graag de superieure beeldkwaliteit van de Apple TV, maar dat neemt niet weg dat hij in een aantal opzichten achterblijft ten opzichte van de concurrentie. Eén van de aspecten die sommige Apple TV-gebruikers in het bijzonder stoort, is het ontbreken van ondersteuning voor 4K video's van YouTube, zo blijkt uit een recent bericht in TidBITS Talk.

De oorzaak was een klassiek geval van de strijd van Apple en Google over beeldformaten. Google ondersteunt YouTube video's in 4K alleen via de open-source VP9-codec; Apple houdt koppig vast aan H.264 en H.265. Er wordt druk gespeculeerd over de aard van het compromis dat nu is gesloten, maar voor ons is het voldoende om te weten, dat ze hun conflict hebben bijgelegd.

Een andere 4K-verbetering is dat je in iOS 14 nu video's nu in volle 4K-glorie via Airplay naar de Apple TV kunt streamen.

Verbeterde picture-in-picture functie

Apple kondigde vorig jaar picture-in-picture (PiP) voor de Apple TV aan, een functie waar ik al lang naar uitkeek. Maar groot was mijn teleurstelling toen Apple ergens in de beta-cyclus PiP beperkte tot uitsluitend binnen de Apple TV app (zie “Picture in Picture van tvOS 13 gebruiken,” 5 oktober 2019). Ik vermoed dat Apple gewoon meer tijd nodig had, om alle problemen op te lossen - de oorspronkelijke functie was in de betreffende bèta's inderdaad nogal buggy.

Het goede nieuws is, dat Apple nu klaarblijkelijk voldoende vertrouwen in de functie heeft om hem systeembreed beschikbaar te maken. Hij is waarschijnlijk ook prominent onderdeel van de nieuwe camera-integratie in HomeKit. Ik ben benieuwd of YouTube ook PiP op de Apple TV gaat toelaten, anders dan op de iPad (zie voor noodoplossingen “TipBITS: YouTube-video's bekijken in "Beeld in beeld",” 19 juli 2019).

Audio delen met je AirPods

Met tvOS 14 kun je twee paar AirPods verbinden met de Apple TV en samen hetzelfde beluisteren. Je kunt dus met z'n tweeën naar een film kijken terwijl de kinderen slapen. Apple vermeldt niet welke versies van de AirPod worden ondersteund, maar wij hopen dat het voor alle modellen geldt.

Gaming verbeteringen

Apple kwam in tvOS 13 al met een beperkte ondersteuning voor meerdere gebruikers, zodat afzonderlijke leden van een huishouden ieder hun eigen profiel konden hebben, althans voor een aantal ingebouwde apps als Apple TV. In tvOS 14 is die ondersteuning uitgebreid met game-voortgang, scorelijsten en game-uitnodigingen voor elke afzonderlijke gebruiker.

In tvOS 14 is ook de ondersteuning van controllers van derden uitgebreid, onder andere voor de Xbox Elite Wireless Control Series 2 en de Xbox Adaptive Controller. Vooral de laatste is interessant voor mensen die bijzondere besturing willen gebruiken. (Ik ging er onterecht vanuit, dat de Xbox Adaptive Controller al ondersteund werd door de vorige versie van tvOS en iOS. Als je er één hebt aangeschaft op basis van mijn eerdere advies, dan bied ik hierbij mijn welgemeende veronstschuldigingen aan. Zie “Xbox en PlayStation game-controllers met Apple Arcade: de FAQ,” 25 oktober 2019).

Apple schrijft, interessant genoeg, dat die twee controllers “inbegrepen” zijn. Welke andere controllers zal tvOS 14 ondersteunen? Iets dat nog niet aangekondigd is?

Dat is het dan zowat, voor wat betreft tvOS 14: niets baanbrekends, maar het zijn interessante verbeteringen voor fans van de Apple TV. En we hopen ook nog op nieuwe schermbeveiligingen — de Aerial-video's zijn dan wel erg mooi, ook mooie dingen worden ouder.

Nieuwe dingen in HomeKit

Net zoals voor tvOS, heeft Apple ook voor de toekomst van HomeKit niets baanbrekends bekendgemaakt, maar maakte wel reclame voor een vorig jaar opgerichte markt-samenwerking. Verder zijn er wel wat handige nieuwe functies, vooral voor HomeKit-beveiligingscamera's.

Project Connected Home Over IP

Het grote nieuws over HomeKit - al is het dan niet echt nieuw - is dat Apple samenwerkt met Amazon, Google en andere domotica-fabrikanten om een gezamenlijke standaard voor domotica te maken. Project "Connected Home over IP" werd vorig jaar al aangekondigd, en hoewel Apple in zijn presentatie geen nieuwe informatie bekendmaakte, was de alliantie belangrijk genoeg om het publiek eraan te herinneren (zie “Apple gaat samenwerken met concurrenten om een standaard voor slimme huizen te maken”, 18 december 2019). Hopelijk werpt deze samenwerking vruchten af, en kunnen we weldra elk slim apparaat vanaf elk toestel bedienen.

Verbeteringen in de Woning-app

Een van de grootste uitdagingen voor de gemiddelde HomeKit-gebruiker is te weten hoe hij alle mogelijkheden van zijn hardware kan benutten. Mensen kunnen misschien wel hun lichten in- en uitschakelen, maar weten vaak niets over scènes en automatiseringen. In iOS 14 stelt de Woning-app nieuwe automatiseringen voor, als je een nieuw accessoire toevoegt.

Dit biedt HomeKit-gebruikers dan wel meer mogelijkheden, maar ik vrees dat nieuwe gebruikers vooral onbewust automatiseringen zullen activeren, deze vervolgens weer vergeten, en dan te maken krijgen met wat ik in Take Control of Apple Home Automation het “spookhuissyndroom” noem. Dat is wanneer losgeslagen huisautomatisering het licht aan en uit doet, terwijl niemand weet waarom.

Een zeer welkome verbetering is de vernieuwde statusweergave van Woning. Het is niet langer alleen een vervelende lijst met de status van jouw accessoires, maar je ziet nu pictogrammen, waarmee je acties van accessoires opstart.

Adaptieve verlichting

Adaptieve verlichting is al langer een standaardfunctie van slimme lampen die van kleur kunnen veranderen, zoals de Philips Hue. Nu ondersteunt de Woning-app deze direct. Adaptieve verlichting verandert gedurende de dag, waardoor licht bijvoorbeeld 's nachts minder blauw wordt, zodat je gemakkelijker in slaap valt. Ik ben benieuwd of je de instelling ervan zelf kunt aanpassen, of dat je moet leven met Apple's ideeën over verlichting (tenzij je de functie helemaal uitschakelt).

Verbeteringen in beveiligingscamera's

De belangrijkste HomeKit-updates zijn gericht op beveiligingscamera's. Allereerst zijn er "Activiteit"-zones die je kunt markeren in het gezichtsveld van de camera, om gebieden aan te duiden waarbinnen bewegingsmeldingen actief moeten worden. Je wilt waarschijnlijk een melding als iemand naar jouw deur loopt, maar niet iedere keer dat er een auto passeert.

Een andere slimme toevoeging aan camera's via HomeKit, is gezichtsherkenning. HomeKit kan mensen op de camera identificeren op basis van gegevens in de app Foto's. Deze functie is voornamelijk bedoeld voor video-deurbellen. Dus wanneer iemand aanbelt, die door iOS wordt herkend, ontvang je een aangepaste melding op je iPhone, iPad, Apple TV en zelfs op je HomePod.

Dat is dus wat er op komst is in tvOS 14 en HomeKit, tenminste voor zover Apple nu deelt. Zijn er functies die je enthousiast genoeg maken om ze te willen implementeren, of toe te voegen aan jouw thuisautomatisering? Laat het ons weten in de reacties.

WWDC is gekomen en gegaan en heeft in zijn kielzog een hele reeks nieuwe bèta's voor het besturingssysteem achtergelaten: macOS 11 Big Sur, iOS 14, iPadOS 14, watchOS 7 en tvOS 14.

Als je je dapper voelt en een deel van je tijd wil besteden om Apple te helpen deze besturingssystemen voor iedereen te verbeteren, kun je de bèta's ervan testen. Per direct als je deelneemt aan het Apple Developer-programma, of iets later wanneer Apple de openbare bèta's vrijgeeft. Als je de bèta installeert (natuurlijk niet op je hoofd-apparaat, want dat zou roekeloos zijn!), zal je onmiddellijk bugs tegenkomen. Het is tenslotte een bètaversie. Als hij klaar was, zou hij wel vrijgegeven worden.

Het is gemakkelijk om te denken dat Apple deze bèta's vooral om pr-redenen vrijgeeft, maar dat is verre van waar. Apple geeft echt om bugmeldingen van zowel ontwikkelaars als gebruikers. Maar zoals je je kan voorstellen, kunnen honderdduizenden ontwikkelaars die bugs melden zelfs de middelen van Apple overbelasten.

Hoe meld je bugs zodat Apple ze daadwerkelijk oplost?

Gebruik Feedback Assistant

Apple vraagt bugmeldingen van gebruikers en externe ontwikkelaars via Feedback Assistant, wat zowel een vooraf geïnstalleerde app is als een website. Ik raad aan om de app te gebruiken om nieuwe bugs te melden. Hij leidt je door specifieke vragen op basis van het type bug dat je meldt, genereert automatisch een sysdiagnosebestand en vraagt je om logboeken en meldingen die relevant zijn voor dat type bug. De iOS-versie van Feedback Assistant kan ook bugs melden op aangesloten Apple TV-, Apple Watch- en HomePod-apparaten.

De app Feedback Assistant is geïnstalleerd in macOS 10.15 Catalina en hoger en in iOS 12.4 en hoger. Op bètabesturingssystemen verschijnt de app Feedback Assistant op het Dock (macOS) of het startscherm (iOS). Wil je het niet in het Dock op de Mac ? Je kunt Feedback Assistant ook in /Systeem/Bibliotheek/CoreServices/Applications/Feedback Assistant vinden. Het is vaak het gemakkelijkst om het programma met Spotlight te starten. Je kan Feedback Assistant ook op elk apparaat vanuit Safari starten door te navigeren naar applefeedback://

Elke bugmelding via Feedback Assistant wordt beoordeeld door iemand van Apple Developer Support. Die persoon kan zelf eenvoudige problemen oplossen of de melding terugsturen als er belangrijke informatie ontbreekt. Als je bugmelding er goed uitziet, kopieert de persoon hem van Feedback Assistant naar Radar, het interne bugvolgsysteem van Apple. Radar stuurt de melding vervolgens naar het juiste technische team, waar hij al dan niet kan worden opgelost of zelfs maar gelezen.

Apple heeft een inleiding tot het melden van bugs gepubliceerd die de moeite waard is, maar lees verder voor de maximale kans om je bug opgelost te krijgen.

Schrijf goede bugmeldingen

Tussen WWDC in juni en de iPhone-introductie in september maken Apple-technici van het besturingssysteem-team dagen van 12 uur en dat zes of zelfs zeven dagen per week. Ze ronden functies af waarvan hun baas aan de hogere baas vertelde dat deze al klaar waren (oeps!) Ze verhelpen bugs die zijn gemeld door Apple Quality Assurance (QA)-collega's. Ze laten alles vallen om de incidentele bug te verhelpen die door een vice president van Apple is gemeld. (Ja, het Apple-management gebruikt pre-releaseproducten en ze melden ook bugs.) Na dat alles moeten ze ook bugs oplossen die zijn gemeld door externe ontwikkelaars en gebruikers van de openbare bèta's.

Toen ik ontwikkelaar bij Apple was, was dit mijn werk. Ik kreeg dagelijks tientallen nieuwe externe bugmeldingen en ik had tijd om er maar een paar te behandelen. Veel ontwikkelaars schreven geweldige bugmeldingen, maar sommige zagen eruit alsof ze waren geschreven door een derdeklasser die hun ADHD-medicatie had overgeslagen. Je kunt raden welke meer aandacht hebben gekregen. Ik zal je vertellen wat je moet doen om een goede bugmelding te schrijven. Sommige van deze punten zijn specifiek voor ontwikkelaars, maar de meeste zijn op iedereen van toepassing:

• Maak een beschrijvende titel. Een goede bugmelding begint met een goede titel. Maak de titel duidelijk en beknopt. Bug-vergaderingen zijn lange, slopende bijeenkomsten waarbij technici en productmanagers prioriteit geven aan honderden nieuwe bugs. Bugs worden op titel vermeld, de titel van jouw bug is er dus maar één in een zeer lange lijst. Een beschrijvende titel maakt het voor de technici gemakkelijker om te weten waar het over gaat zonder de bugmelding te hoeven openen en de beschrijving te lezen. Het is maar al te waarschijnlijk dat bugmeldingen met generieke of te korte titels worden overgeslagen met een vage belofte om er later op terug te komen.
• Beschrijf het probleem. Leg uit wat er werkelijk gebeurt en wat er volgens jou zou moeten gebeuren. Ga er niet van uit dat het duidelijk is wat er mis is. Als Apple-documentatie voor ontwikkelaars beschrijft wat er moet gebeuren, verwijs er dan naar. Ga er niet van uit dat ik alle Apple-documenten uit mijn hoofd ken.
• Voeg duidelijke stappen om de bug te reproduceren toe. Vergeet niet de beginvoorwaarden op te sommen en sla geen stappen over. Als de bug niet elke keer voorkomt, vermeld dan hoe vaak hij voorkomt.
• Wees beknopt. Ik heb na die van jou nog stapels bugs om op te lossen. Gebruik alsjeblieft mijn tijd efficiënt. Hoe gemakkelijker ik je bug kan reproduceren, hoe groter de kans dat ik hem repareer.
• Voeg schermafbeeldingen of video toe. Voeg indien mogelijk een schermafbeelding of schermopname toe die laat zien hoe de bug kan worden gereproduceerd, inclusief de daadwerkelijke bug. Een foto maakt het probleem duidelijk. Het maakt het voor een ontwikkelaar ook moeilijker om het probleem te negeren. Uit het oog, uit het hart.
• Verduidelijk de context. Komt de bug voor op het apparaat, in de simulator of op beide? Komt het voor in zowel de debug-build als de release-build? Heb je verschillende modellen van het apparaat geprobeerd? Voeg al deze informatie toe.
• Neem code op. Als ik code nodig heb om de bug te zien, voeg deze code dan toe. Voeg minimaal een paar regels code toe die de bug demonstreren. Voeg indien mogelijk een voorbeeld van een Xcode-project toe dat de bug demonstreert. Stuur niet je hele app mee, ik wil me er niet doorheen hoeven werken. Maak een nieuwe, lege app in Xcode en voeg precies genoeg code toe om de bug te tonen. Voeg een groot, opvallend commentaar toe: "De bug gebeurt hier!" dan hoef ik niet door alle bronbestanden te bladeren. Een Xcode-project toevoegen heeft nog een voordeel, namelijk dat het al je build-instellingen bevat. Sommige bugs komen alleen voor bij bepaalde build-instellingen.
• Geef buildnummers op. Als je versies van besturingssystemen bespreekt, neem je naast de versie van het besturingssysteem ook het buildnummers op (zoals 17E262). (Om het buildnummers in macOS te vinden, kies je "Over deze Mac" in het Apple-menu en klik je vervolgens op het macOS-versienummer. Ga in iOS naar "Instellingen > Algemeen > Over" en tik op het versienummer.) Intern bij Apple wordt het besturingssysteem altijd geïdentificeerd door een buildnummer. Apple-technici weten niet altijd zonder meer welk buildnummer overeenkomt met een bepaalde externe bèta of release. Ze kunnen het natuurlijk opzoeken, maar alles wat hen tijd bespaart, maakt het waarschijnlijker dat je bug wordt verholpen.
• Voeg sysdiagnose en logs toe als dat relevant is. Als je de app Feedback Assistant gebruikt, zal deze automatisch een sysdiagnose bevatten en je vragen naar logs die relevant zijn voor het soort bug. Een sysdiagnose is een rapport met stapels informatie wat er in je systeem wordt uitgevoerd. Hij is erg handig voor wie weet hoe je ze moet lezen. Als je de Feedback Assistant-website gebruikt, moet je handmatig een sysdiagnose genereren, wat niet moeilijk is. Voeg alle relevante console-logboeken of andere logboeken bij die mogelijk relevante informatie bevatten. Apple biedt instructies voor het genereren van een sysdiagnose, samen met allerlei gespecialiseerde logboeken voor specifieke soorten bugs.

• Geef de Xcode-versie op. Elke bètaversie van het besturingssysteem bevat doorgaans een bijbehorende bètaversie van Xcode, dus zorg ervoor dat je de nieuwste Xcode gebruikt. De bug kan zich in een van de frameworks in Xcode bevinden, niet in het besturingssysteem zelf. Je wilt geen bug melden die al is verholpen omdat je deze hebt getest met een oude versie van Xcode.

Meld bugs onmiddellijk

Apple maakt elke avond een nieuw intern besturingssysteem, de zogeheten dagelijkse build. Apple-technici installeren deze dagelijkse build elke ochtend. Sommige dagelijkse builds zijn redelijk stabiel, anderen zijn dat niet. Om de paar weken tussen WWDC en verzending wordt een stabiele build een bètakandidaat. Die wordt extra getest om zeker te zijn dat alle aspecten stabiel lijken. Indien goedgekeurd, krijgt hij een bètanummer en wordt hij vrijgegeven aan ontwikkelaars en gebruikers die deelnemen aan de openbare bèta.

Tegen de tijd dat de bèta wordt gepubliceerd, beschouwen Apple-technici deze al als oud omdat ze ondertussen weken van dagelijkse builds hebben geïnstalleerd. Tegen de tijd dat je hem downloadt, hem test, een bugmelding indient, je melding wordt gekopieerd van Feedback Assistant naar Radar en een Apple-medewerker ernaar kijkt, beschouwt die de bèta zeker als prehistorisch. Hoe langer het duurt om een bug te melden, hoe moeilijker het voor programmeurs is om de situatie die jij ziet te reproduceren.

Dus als er een nieuwe bèta uitkomt, begin dan direct met testen en bugs melden. Laat je bugmelding zo actueel mogelijk zijn wanneer een Apple-technicus hem ziet.

Controleer elke volgende uitgave van het besturingssysteem

Het zou fijn zijn als Apple je zou laten weten of je bug is verholpen. Het zou ook fijn zijn als de tandenfee bestond. Apple ontvangt over elk probleem tientallen, zo niet honderden, bugmeldingen van buiten het bedrijf. Intern binnen Apple is de bug mogelijk ook al gemeld. Eén bugmelding, meestal de melding met de meest duidelijke uitleg van het probleem, wordt het origineel genoemd. De andere zijn gemarkeerd als duplicaten of 'dups' en in theorie worden alle bugmelders op de hoogte gebracht wanneer de bug is opgelost. Als je beschrijving niet goed overeenkomt met de beschrijving in het origineel, wordt deze mogelijk niet herkend als een 'dup' en word je misschien dus niet op de hoogte gesteld wanneer de bug is verholpen.

Daarom moet je voor elke nieuw uitgebrachte bèta testen of je bug is verholpen. Zo niet, overweeg dan om bij de nieuwste versie een nieuwe bugmelding te schrijven. Dat brengt de bug weer onder de aandacht van Apple en laat de technici weten dat deze niet is opgelost in de recentste update.

Zelfs als je denkt dat je bugmelding als 'dup' gemarkeerd zal worden, rapporteer hem toch. Beschouw je melding als een stem om die bug op te lossen. Wanneer technici in bug-vergaderingen zitten en moeten beslissen welke bugs prioriteit krijgen, krijgt een bug met 100 dups meer aandacht dan een bug met 3 dups, omdat hij duidelijk veel meer mensen treft.

Als je bug is verholpen, wordt deze pas in Feedback Assistant gemarkeerd als opgelost wanneer de versie van het besturingssysteem met de reparatie wordt verzonden, of dat nu een bèta is of de definitieve versie. Apple houdt er niet van oplossingen aan te kondigen voordat deze vrijgegeven worden.

Voor ontwikkelaars: als een bug een belangrijke functie van je product blokkeert en deze niet lijkt te worden opgelost, stuur dan een e-mail naar Developer Support en vraag of er een statusupdate is of dat ze suggesties hebben voor een tijdelijke oplossing. Wielen moeten soms piepen om gesmeerd te worden.

Als een kennis van je bij Apple als programmeur werkt, kan je die misschien vragen om de bug op te zoeken in Radar, om na te kijken of die zal worden verholpen. Er zijn een aantal redenen waarom dit niet zou gebeuren. Jouw bug is misschien nog niet van Feedback Assistant gekopieerd naar Radar. Niet alle programmeurs kunnen, om veiligheidsredenen, alle Radar-bugs zien. En misschien voelt je kennis zich niet helemaal vrij om dit voor jou te doen. Doet je kennis dit wel, dan krijg je waarschijnlijk algemene informatie te horen, zoals “het staat op de rol om verbeterd te worden in de volgende versie”. Alleen al dit weten kan handig zijn. Vraag je kennis niet om bij Apple aan te dringen deze bug te verbeteren. Er is een redelijke kans dat jouw kennis niet werkt op de afdeling waar de bug zit en de programmeur die deze heeft toegewezen gekregen niet persoonlijk kent. Apple heeft duizenden programmeurs. Zij mogen de status van bugs niet met niet-werknemers bespreken dus zorg ervoor dat je je kennis niet in een lastig parket brengt.

Een laatste opmerking. Feedback Assistant en Radar gebruiken verschillende bug-nummersystemen. Apple-programmeurs kunnen de die naar elkaar vertalen. Radar is geen acroniem. Het is al 30 jaar Apples bug-reportsysteem. Ontwikkelaars hadden vroeger een Web-portaal met directe toegang tot de Radar-database, RadarWeb, al waren ze beperkt tot de bugs die ze aangaven. Feedback Assistant heeft RadarWeb vervangen en werkt met een aparte database om bugs bij te houden die door externe ontwikkelaars en gebruikers worden gemeld.

Reageer snel op Apple

Soms vraagt een Apple-programmeur om meer details of logs. Probeer dit voor te zijn, door relevante logs al in het eerste bugreport bij te voegen. Soms vraagt Apple om specifieke verdere gegevens of stuurt het bedrijf je een profiel dat een speciaal logbestand aanmaakt. Antwoord hier snel op. Hoe langer de bug blijft zitten, hoe meer kans er is dat de programmeur verdergaat met een andere taak. Controleer je openstaande bugs regelmatig.

Soms lijkt het erop dat een Apple-programmeur je aan het lijntje houdt door meer informatie te vragen. Toen ik daar werkte, zag ik dit gebeuren bij bugs die waren veroorzaakt door andere Apple-programmeurs en door externe ontwikkelaars. Een programmeur vraagt om aannemelijke extra informatie en het verzamelen daarvan kost tijd. De helft van de programmeurs reageert hier nooit op en de programmeur kan die bug dan negeren terwijl ze “wachten op meer informatie”.

Andere bronnen van bugreports

Apples Crash Reporter registreert en meldt vastloop-bugs automatisch. Teams worden gerangschikt op basis van hoeveel actieve vastlopers hun code veroorzaakt. Apple heeft een goed systeem, zowel technisch als procedureel, voor het oplossen van vastloop-bugs. Dat betekent niet dat je vastloop-bugs niet moet melden. Bugreports kunnen nog steeds de urgentie van een bepaalde reparatie verhogen.

Als je vastloop-bugs of kernel panics, hardware-bugs of printproblemen op de Mac meldt, moet je Systeem-informatie bijvoegen. Gebruik de app Systeeminformatie in de map Hulpprogramma's om dit rapport te genereren. (Je kiest hiervoor Archief > Bewaar.)

Apple-programmeurs kijken wel op bepaalde ontwikkelaars-forums, blogs en podcasts. Klachten die herhaaldelijk verschijnen, kunnen als bugs worden opgetekend in Radar. Ik heb gezien dat tekst uit een ontwikkelaars-bericht gekopiëerd werd in een Radar-bugreport. Maar Apple-programmeurs schrijven zelden in ontwikkelaars-forums, omdat het bedrijf dit ontmoedigt. Dit was in ieder geval in het verleden zo: Apples herontworpen ontwikkelaars-forums moedigen ontwikkelaars aan deel te nemen. (Zie “Apple maakt schema van WWDC 2020 bekend”, 11 juni 2020.) Hoewel het zelden wordt toegegeven, kijken Apple-programmeurs wel naar de meningen van ontwikkelaars.

Bug prioriteit

Apple geeft iedere bug een bepaalde prioriteit, van P1 tot P5. P1 is een vastloop- of gegevensverlies-bug, en dit soort bugs moeten doorgaans worden verholpen. P2 is een functie die niet werkt en Apple verhelpt deze problemen bijna altijd. P3 is een functie die niet correct wekt. Apple wil P3-bugs graag verhelpen maar dit wordt soms uitgesteld. P4 is een gebruikersinterface-probleem of een andere minder belangrijke bug en die blijft vaak liggen. P5 is een verzoek om verbetering of uitbreiding. Dit soort verzoeken worden doorgaans genegeerd.

Sommige Apple-programmeurs verhelpen alleen de bugs die hen worden toegewezen en werken dan van hoge prioriteit naar lage. Vaak komen ze niet aan de bugs met lage prioriteit toe. Apple-programmeurs met meer ervaring kiezen vaak enkele bugs met lage prioriteit waarvan ze weten dat gebruikers zich eraan ergeren en zorgen ervoor dat die verholpen worden. Apple-programmeurs gebruiken ook Apple-producten en willen dat die goed werken. Sommige afdelingen loven prijzen uit aan de programmeur die de meeste bugs oplost.

Als de uitgiftedatum nog ver weg is, mogen Apple-programmeurs kijken in zo'n beetje alle code die ze willen. Naarmate we dichter op de alpha, bèta en uiteindelijk golden master komen, zijn er meer beperkingen. Ten eerste kunnen dan alleen P1- of P2-bugs worden verholpen. En dan alleen P1-bugs van de goedgekeurde lijst. Iedere bug en reparatie krijgt een waardering voor de ernst van de bug en het risico van de reparatie. Niemand wil een risicovolle reparatie van een minder ernstige bug. Als het moment van uitgifte nadert, worden zelfs serieuze bugs uitgesteld. Een slechte maar zeldzame bug waarvan de gevolgen goed in kaart zijn gebracht, is beter dan een slecht in kaart gebrachte reparatie met te weinig tijd om die te testen. De reparatie wordt dan toegevoegd aan de eerstvolgende update, nadat er meer is getest.

Apples ontwikkelcyclus

Om de kans dat jouw bugs worden gerepareerd zo groot mogelijk te maken, is het handig als je weet hoe Apples ontwikkelcyclus werkt. Nadat de grote X.0-versies van iOS en macOS zijn uitgegeven, doorgaans in september, begint het ontwikkelwerk voor de X+1-versies van beide voor het jaar daarop. Er wordt ontwikkeld tot en met het eind van het jaar, en tegen februari of maart begint QA met het uitgebreid testen van 'builds' en het melden van bugs. Na verloop van tijd wordt de ontwikkelversie stabieler van amper bruikbaar tot niet slecht. Tegen mei begint de dagelijkse build er fatsoenlijk uit te zien. En dan komt de sprint om de WWDC-bèta te bouwen. Al die onvoltooide functies en genegeerde bugs krijgen plotseling meer aandacht.

Bèta 1 op de WWDC ziet er na installatie (op een test-apparaat!) misschien grof uit, maar is toch het resultaat van een enorme hoeveelheid werk. Dat is het moment waarop je bugs wilt melden! Apple-programmeurs worden opgedragen om bugreports te lezen en problemen te verhelpen. Maak gebruik van deze aandacht en meld de bugs die je aantreft.

Er komen meer bèta-uitgaven in juli en augustus. Test ze allemaal om te zien of je bugs zijn verholpen, en let ook op regressies (functies die eerst werkten maar nu niet meer). En als een bug die je gemeld hebt in een voorgaande bèta niet is verholpen, schroom dan niet deze nogmaals te melden.

Als september in zicht komt, worden de bèta's stabieler maar wijzigt Apple ook minder dingen. Als je een kleine bug hebt gevonden die tegen augustus niet is opgelost, zal zal die waarschijnlijk nog wel in de golden master zitten. Meldt hem toch, dan zal Apple hem hopelijk in een van de updates alsnog repareren.

Het nieuwe besturingssysteem komt doorgaans in september uit, als versie X.0.0. De updates komen daar meteen achteraan. X.0.1 en soms X.0.2 zijn al gepland voordat X.0.0 wordt uitgebracht. In X.0.1 zitten een paar belangrijke reparaties die het niet gehaald hebben in X.0.0. X.0.2 bevat minder vitale reparaties die te laat kwamen voor X.0.0. In een slecht jaar komt er soms een update X.0.3.

Als die eerste oplap-updates eenmaal uitgebracht zijn, beginnen Apple-programmeurs aan de nieuwe grote versie X+1. Ze hebben weinig ruimte om bugs te repareren in het besturingssysteem dat op dat moment al is uitgebracht. Blijf bugs melden, maar de kans dat ze worden verholpen wordt flink minder.

(Terzijde: Apple-teams zijn doorgaans verdeeld naar terrein of functie, niet op basis van hoofd- en oplap-versie. Bijvoorbeeld: als bijvoorbeeld een energie-beheerprogrammeur bent, dan werk je aan die functie in zowel de aanvankelijke X.0-versie als in alle oplap-versies. Het werkt niet goed om de ene programmeur de aanvankelijke code te laten schijven en een andere programmeur de bugs te laten verhelpen, omdat die andere programmeur niet zo diepgaand bekend is met de code, waarom iets op een bepaalde manier is ontworpen, welke ideeën zijn geprobeerd enzovoorts. Het is beter om een programmeur eigenaar te maken van een bepaald stuk code, in alle versies.)

Er komt waarschijnlijk een X.1- en een X.2-versie, maar die bevatten doorgaans nieuwe functies zoals iCloud-bestandsdeling en batterijconditiebeheer in Catalina. In deze versies zijn een aantal bugs verholpen, maar dat is niet hun belangrijkste doel. Het kan nooit kwaad om in deze periode bugs te melden, maar als ze niet echt ernstig zijn kan je ervan uitgaan dat ze op zijn vroegst pas in de volgende grote versie worden aangepakt.

Waar het op neerkomt, is dat als je wilt dat Apple de bugs verhelpt die jij vindt (en wie wil dit nou niet?) je deze eenvoudige stappen moet volgen. Schrijf duidelijke, complete bugreports. Sluit schermafbeeldingen, video en voorbeelden van code bij, indien mogelijk. Meldt bugs zo vroeg mogelijk. Werk binnen Apples ontwikkelcyclus.

En het allerbelangrijkste: blijf je meldingen insturen. Bugs die niet gemeld worden, worden niet verholpen.

Van de twee zekerheden van het leven, de dood en belastingen, heeft de dood de krantenkoppen dit jaar beheerst. Hoewel belastingheffing in sommige delen van de wereld werd uitgesteld, zijn 500.000 mensen wereldwijd tot dusver aan Covid-19 overleden, waarvan meer dan 125.000 in de Verenigde Staten woonden en daarvan kwamen er meer dan 22.000 om in New York City, slechts 4 uur rijden van waar ik woon. En dan zijn er nog de veelbesproken moorden op George Floyd, Breonna Taylor, Ahmaud Arbery en veel te veel andere mensen van kleur.

Dus, zonder verder commentaar op de sociologische en epidemiologische crises waar we nu allemaal in zitten, ja, de dood is de laatste tijd in mijn gedachten geweest.

Toen zag ik een bericht op een privé-berichtenlijst waar ik op geabonneerd ben, waarin hulp gevraagd werd na de onverwachte dood in een bootongeluk van een familielid van een kennis. De man die stierf was de enige beheerder van zijn "Delen met gezin"-account en had geen gedeelde wachtwoorden of beveiligingsvragen achtergelaten, zodat de leden van zijn gezin niet bij de administratieve kant van het account konden, zoals de betalingsgegevens, die aangepast moesten worden zodat het account niet zou worden gedeactiveerd door een betalingsachterstand.

Het verontrustende was dat, toen ze met Apple-support spraken, de medewerkers niet kon helpen en zeiden dat tenzij ze het wachtwoord konden achterhalen of anderszins zelf toegang konden vinden, het account op nonactief zou komen te staan. Ze waren bezorgd dat ze alle gedeelde gezinsgegevens zouden verliezen mocht dat gebeuren. Ik vermoed dat dit niet zo vaak voorkomt, anders hadden de helpdeskmedewerkers wel geweten dat het bedrijf een richtlijn heeft voor dergelijke situaties. Omdat ik nog nooit eerder van deze richtlijn gehoord had, bedacht ik dat het wel nuttig zou zijn om deze te delen voor het vervelende geval dat iemand deze informatie nodig heeft.

Het Apple-supportdocument “Toegang aanvragen tot Apple accounts van een overleden familielid” legt uit wat de procedure is en welke papieren nodig zijn. De sleutel is een gerechtelijk bevel dat de volgende informatie moet bevatten:

• De naam en Apple ID van de overleden persoon
• De naam van de nabestaande die toegang aanvraagt tot het account van de overledene
• Dat de overledene de gebruiker was van alle accounts die zijn gekoppeld aan de Apple ID
• Dat de aanvrager de wettelijk persoonlijke vertegenwoordiger, agent of erfgenaam is van de overledene, wiens autorisatie 'rechtmatige instemming' behelst
• Dat Apple door de rechtbank wordt opgedragen te assisteren in het verlenen van toegang tot de gegevens van de overledene in de accounts van de overleden persoon

Ik vermoed dat het verkrijgen van een dergelijk gerechtelijk bevel veel tijd kost en gemakkelijkst gedaan kan worden in samenwerking met een advocaat. Als je het eenmaal hebt, neem dan contact op met Apple-support en wees duidelijk over wat je nodig hebt, het feit dat je een gerechtelijk bevel hebt en dat je de instructies van dit hulpdocument volgt.

In het specifieke voorbeeld dat ik hierboven aanhaalde, wacht de familie twee weken na indiening nog steeds op de staat om hun aanvraag voor een gerechtelijk bevel in te willigen, onder andere omdat het lang duurde om de officiële akte van overlijden te krijgen. Gelukkig ontdekten ze dat ze dit probleem konden omzeilen door elk gezinslid zich uit het gezinsabonnement te laten uitschrijven vanaf hun eigen apparaten. Daarna konden ze een nieuw gezinsabonnement afsluiten en iedereen weer inschrijven.

Nog twee opmerkingen. Ten eerste, net zoals wanneer de FBI hulp vraagt bij het kraken van de iPhone van een crimineel, is Apple zeer duidelijk over dat het geen toegangsversleuteling kan breken:

Houd er rekening mee dat apparaten die zijn vergrendeld met een toegangscode, zijn beschermd door toegangsversleuteling en dat, tenzij de nabestaande de toegangscode van het apparaat weet, Apple de toegangscodevergrendeling niet kan verwijderen van het apparaat zonder het te wissen.

Dus Apple zou je genoeg kunnen helpen om de apparaten van een overleden familielid te wissen, maar er is geen enkele manier waarop je bij de informatie op dat apparaat kunt komen. Je zou wellicht een iCloud-reservekopie kunnen terugzetten op een nieuw of gewist apparaat als je eenmaal toegang hebt tot het Apple ID van de overledene, maar ik weet niet zeker of dat mogelijk is.

Ten tweede, hoewel bootongelukken een bijzonder onverwachte manier zijn om heen te gaan (ze zijn verantwoordelijk voor slechts 0,02% van de overlijdens in de Verenigde Staten), is het verstandig om je voor een dergelijk geval voor te bereiden. Een aantal jaren geleden schreef Joe Kissell een enorm nuttig boek over het onderwerp, Take Control of Your Digital Legacy, en kondigde het aan in TidBITS in met het artikel “Tante Agatha peinst over haar digitale erfenis” (30 januari 2017). In het boek leidt Joe de lezer door de gedachtengang die nodig is om een digitale inventaris te maken van je online accounts, aangeschafte media, software, persoonlijke gegevens en cryptomunten. Als je een dergelijke inventaris maakt, kun je er gerust op zijn dat je familie geen extra werk krijgt mocht je onverwachts komen te overlijden.