Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 247 reacties

De ontwikkelaars van f.lux vragen aan Apple toestemming om hun software uit te mogen brengen op iOS. Nu Apple met Night Shift zelf vergelijkbare functionaliteit heeft ge´ntroduceerd, willen de f.lux-makers dat de bijbehorende api wordt opengesteld.

f.lux fpaApple brengt binnenkort met iOS 9.3 de functie Night Shift naar zijn mobiele apparaten. Met de functionaliteit wordt de hoeveelheid blauw licht dat het scherm uitstraalt in de avonduren verminderd. Het is voor het eerst dat dergelijke functionaliteit officieel mogelijk is op iOS-apparaten.

De makers van f.lux, dat vergelijkbare functionaliteit biedt, reageren in een blogpost op de Night Shift-functie. Zij stellen de originele bedenkers en leidinggevend te zijn op gebied van dergelijke software. Al jarenlang proberen zij hun f.lux-app in de iTunes App Store te krijgen, maar Apple staat deze niet toe omdat f.lux gebruikmaakt van api's waar ontwikkelaars officieel geen toegang tot hebben. Zodoende werkt de app enkel op iPhones en iPads die gejailbreakt zijn.

Nu Apple zelf met een vergelijkbare functie komt, beredeneren de ontwikkelaars dat de benodigde api opengesteld zou moeten worden, zodat ook derden vergelijkbare apps uit kunnen brengen. Ook hinten de makers in de blog op een 'volgende fase', van de techniek. Hun missie is om met f.lux nieuwe wetenschappelijke inzichten te bieden. Ook stellen de ontwikkelaars dat hun software in de toekomst beter afgestemd moet kunnen worden op individuele gebruikers.

Tweakers schreef vorig jaar een achtergrondartikel over de gevolgen van blauw licht en de diverse oplossingen die er zijn om de weergave van beeldschermen aan te passen, afhankelijk van het tijdstip op de dag.

Apple Night ShiftApple brengt de functie Night Shift met iOS-versie 9.3 naar iPads en iPhones

Moderatie-faq Wijzig weergave

Reacties (247)

Dus wacht even: ontwikkelaars introduceren een nieuwe superhandige feature voor Apple devices. Apple blokkeert hun toegang tot de App Store een jaar lang en nu heeft Apple de feature ingebouwd...
Dat is toch haast crimineel?
1. Ontwikkelaars gebruiken private API's om een app te ontwikkelen. Deze app wordt logischerwijs niet goedgekeurd voor de App Store.

2. Ontwikkelaars delen de app buiten de app store om, zodat gebruikers hem zelf kunnen installeren. Apple geeft aan dat dit de voorwaarden van het Developer-lidmaatschap overtreed.

3. Apple bouwt de functionaliteit van de app in in iOS

4. Ontwikkelaar wil dat de API's die Apple gebruikt voor deze functionaliteit opengesteld worden.

Deel ÚÚn en twee zijn logisch. Deel drie was Apple waarschijnlijk al mee bezig voordat f.lux de sideloading methode introduceerde. Deel vier vind ik ook een volkomen terecht verzoek, al weet ik niet wat f.lux kan toevoegen. Het probleem is dat de functionaliteit van f.lux tegelijkertijd kleiner en groter is dan een app. In principe zou zo'n app geen invloed op de 'core' gebruikservaring hebben, maar als de app het scherm van de iPhone 24 uur per dag wit of zwart maakt is de iPhone totaal gebrickt.
Om even op punt 2 aan te vullen;

Het feit dat F.lux zijn app buiten de store om beschikbaar stelde voor side loading is geen overtreding van de voorwaarden, de manier waarop zij dit deden was een overtreding. F.lux had, omdat zij hun eigen bron code niet openbaar willen maken, hun app gecompileerd tot een pakketje en daar omheen een app gebouwd die dit pakketje opent op je telefoon waardoor je de app kunt gebruiken. Om dit pakketje te kunnen maken heeft F.lux wat shady dingen gedaan met certificaten, en dat is wat Apple niet zo tof vond. Daarnaast bied die manier de mogelijkheid om dat pakketje zo maar te vervangen zonder dat de gebruiker het door heeft, wat verschillende veiligheidsrisico mee brengt.
Hoewel ik zeker de voordelen van open source zie, kan ik me best voorstellen dat er partijen zijn die hun source (en daarmee, hun algorithmen *)) liever niet delen met de hele wereld. EÚn van die partijen is overigens Apple zelf, dus het is op zijn minst opmerkelijk (alternatieve bewoordingen: "met twee maten meten", "hypocriet") dat ze geen methode aanbieden om apps puur in gecompileerde vorm te verspreiden (dan nog kunnen ze voor de app store vereisen dat je de source instuurt, zolang ze een optie geven om naar gebruikers toe alleen de, door Apple gecompileerde, binary beschikbaar te stellen).
Als een derde partij een volkomen begrijpelijke en acceptabele wens heeft, wie is dan de "schuldige" voor de lelijke hack: Apple die bewust probeert die wens onmogelijk te maken (en daarmee de lelijke hack nodig maakt), of Flux die "een minder ideale oplossing" kiest om Apple's beperkingen te omzeilen en toch hun zin te krijgen?

*) Voor zover ik in kan schatten is er slechts ÚÚn niet-triviaal punt aan Flux: de formule die geografische locatie en tijd omrekent naar een kleurtemperatuur. Als je die code uit hun app trekt dan kun je (zonder tijd en geld te steken in het doen van onderzoek) een app maken die precies net zo goed is als die van hen. Dat is een duidelijk gevalletje oneerlijke concurrentie, maar formules komen niet in aanmerking voor bescherming als intellectueel eigendom, dus het ding closed source houden is de enige manier waarop ze zichzelf (en hun investering in dat onderzoek) kunnen beschermen.

@quantumleapje:
Ik zie je punt, ik ben het er (tot op zekere hoogte) zelfs mee eens..., maar wat heeft het te maken met mijn post!? Zowel in mijn post als in die van t1mmy waar ik op reageerden, gaat het nergens over de gebruikservaring.

[Reactie gewijzigd door robvanwijk op 15 januari 2016 13:59]

Dit heeft niets met open of closed source te maken, maar met het feit dat Apple de controle wil houden over wat je al of niet kan doen op het niveau van het OS, en dus wil Apple controle houden over de gebruikservaring. Een App die het ganse systeem/de ganse systeemervaring kan be´nvloeden, dat past gewoon niet in de filosofie van iOS (zie ook 'sandboxing') en ik vind dit een duidelijke en wat mij betreft, voor een telefoon een heel terechte filosofie. EÚn van de redenen waarom ik iOS zo goed vind is net de consistentie en de strenge lijn die uitgezet en aangehouden wordt.
Nou, je kan ook gewoon third-party toetsenborden gebruiken, iets wat ook heel erg ingrijpend is imho, dus dat geld niet altijd wat je daar zegt
Een third-party keyboard activeren gebeurt daarom ook via de "settings" (settings/general/keyboard).
Een third party keyboard is gelimiteerd in wat het kan doen. Ook voor een toetsenbord een netwerkverbinding op kan zetten moet je dit expliciet goedkeuren.
De kleurtemperatuur van het scherm veranderen be´nvloedt de hele systeemervaring?
Stel dat er een bug in zit en de kleurtemperatuur wordt per ongeluk op 0 Kelvin gezet (elke kleur wordt "vertaald" naar #000000, ofwel puur zwart), dan wordt je hele scherm zwart en je apparaat feitelijk onbruikbaar. Dat heeft nogal een impact op de gebruikservaring ja!

Ik neem aan dat de gebruikte API wel een "beveiliging" zal hebben in de vorm van een toegestane range van kleurtemperaturen, zodat er altijd voldoende contrast overblijft om je apparaat in elk geval te kunnen gebruiken, maar het punt blijft. Denk ook aan een "grappige" app die continue de kleurtemperatuur aanpast, elke tien seconden door de hele range heen lopen bijvoorbeeld; dat heeft (een uiterst irritante) impact op het complete systeem.
Stel dat er een bug in zit en de kleurtemperatuur wordt per ongeluk op 0 Kelvin gezet (elke kleur wordt "vertaald" naar #000000, ofwel puur zwart), dan wordt je hele scherm zwart en je apparaat feitelijk onbruikbaar. Dat heeft nogal een impact op de gebruikservaring ja!
Net zoals het scherm niet knalrood zondermeer zal worden indien je de temperatuur op 1500K zet, zal het scherm niet volledig zwart worden indien dat op 0K komt te staan om welke reden dan ook. Het gaat hier over een semi-transparante filter.
Sterker nog, wanneer je F.lux met bijvoorbeeld de Rabo Reader gebruikt zul je F.lux in bepaalde gevallen even uit moeten zetten. Dat gaat voor problemen zorgen. Je geeft zelf een voorbeeld van een bug, maar mijn voorbeeld komt voor in de praktijk. Best lachen wanneer je vriendin je op je werk belt dat haar bankpas niet meer werkt. Gelukkig had ik het vrij snel in de smiezen maar dit gaat gegarandeerd telefoontjes naar de banken opleveren.

Het probleem wat je stelt is vrij simpel op te lossen. Android M en iOS werken met capabilities. Je geeft applicaties gewoonweg geen toegang tot die API tenzij de gebruiker uitdrukkelijk toestemming geeft. En dat zullen maar bar weinig applicaties nodig hebben. Je wilt ook zeker niet twee applicaties die allebei gaan vechten voor een 'goede' kleurtemperatuur.

De bug die je als voorbeeld geeft kan enerzijds opgelost worden dmv een restart, anderzijds inderdaad door bepaalde waardes te blokkeren.
Wat een onzin. Apple bepaalt toch zelf welke apps tot de store worden toegelaten...
Een API die een kleurtemperatuur van 0K toelaat zou ook wel erg stompzinnig zijn en dat zie je daarom ook in geen enkel stuk software terug.
Ik reageerde op jouw post "De kleurtemperatuur van het scherm veranderen be´nvloedt de hele systeemervaring?" met de uitleg waarom de kleurtemperatuur wel degelijk een significante invloed heeft op de gehele gebruikservaring. Het voorbeeld van 0K was puur om even heel kort en bondig duidelijk te maken waarom dat zo is.

Hoewel een API dat specifieke probleem kan (en waarschijnlijk, zal) afvangen, zijn er ook situaties denkbaar (mijn voorbeeld van een "joke program", Jerie's voorbeeld van twee applicaties die allebei de kleurtemperatuur proberen in te stellen) die een API niet af kan vangen en die net zo goed een flinke impact op de gebruikservaring hebben.

Deze tweede reactie van je "Wat een onzin. Apple bepaalt toch zelf welke apps tot de store worden toegelaten... " lijkt overigens compleet in tegenspraak met je eerdere opmerking: de reden dat ze zelf willen bepalen wat ze wel en niet toelaten is nou immers juist het beschermen van de gebruikservaring.
Ik bedoelde dat apps die mensen op de store willen aanbieden toch gescreend worden door Apple.
Ik zie het probleem gewoon niet. Bescherming tegen 'joke apps' vind ik een heel zwakke reden om de creatieve mogelijkheden in het maken van apps te beperken.

[Reactie gewijzigd door Aham brahmasmi op 15 januari 2016 20:02]

Een joke program met die functionaliteit zal Apple niet eens goedkeuren voor de App Store. Doen ze dat wel, dan krijgen ze er van langs achteraf. En als je dat programma gaat sideloaden is het je eigen verantwoordelijkheid.
Je wilt gewoon geen apps hebben die je kleuren instellingen gaan aanpassen, of 1 of geen.
Als Apple de API ervan beschikbaar gaat stellen (zal denk ik niet gebeuren) moeten ze weer een setting maken en een toestemmingsventer tonen aan de gebruiker). Maar ja wat gaat er dan gebeuren als je een 2e app installeert bovenop flux. Die gaan elkaar tegenwerken met alle gevolgen van dien voor de casual gebruiker.
Uiteraard, dat lijkt me duidelijk: het impacteert elke andere app.
Deel drie was Apple waarschijnlijk al mee bezig voordat f.lux de sideloading methode introduceerde.
Waar baseer je dat op als ik vragen mag? Err is voor zover ik kan zien geen enkel bewijs dat Apple hier al mee bezig was en de implementatie is het werk ook niet, het is het idee van f.lux dat redelijk uniek was. Het kost Apple relatief weinig tijd om zoiets in te bouwen in een volgende update, dus tsja... Het feit dat het snel volgde wil niet zeggen dat ze er "al lang" mee bezig waren :)

@TMC:
Tot slot stelt f.lux inhoudelijk niks voor en is het ook niks nieuws. Zeer nuttig, zeer handig, maar niet dusdanig uniek dat je het niet gewoon eenvoudig zelf kan inbouwen.
Dat zou geen argument mogen zijn. Op dezelfde manier kun je veel van de "handigheidjes" van Apple bagatelliseren, maar het gaat hier toch vooral om het idee. Zoals ik hierboven ook al zeg: natuurlijk stelt het technisch gezien niks voor. Apple programmeert zoiets in een weekje in een nieuwe update, maar of iets nu veel of weinig werk is, het gaat erom dat functionaliteit die een ontwikkelaar via een app toevoegt en waaraan ze willen verdienen gewoon uit de store geweerd wordt (op zich nog terecht gezien de voorwaarden) en vervolgens toegevoegd wordt aan iOS :)
Omdat er volgens mij nooit een feature voor iOS in twee maanden van idee naar roadmap naar alpha naar beta gaat.

Kan jij andere functionaliteit noemen die Apple binnen een half jaar kopieerde?
Fl.ux bestaat al vele jaren, sinds 2009.. En Redshift (vergelijk programma) idem. Dan moet Apple wel heeeeel lang geprogrammeerd hebben als zij werkelijk de eerste waren.

[Reactie gewijzigd door Vistaus op 16 januari 2016 11:14]

Dat zeg ik ook niet. Ik zeg dat Apple waarschijnlijk al aan de functionaliteit werkte voor het akkefietje in november.

"Deel drie was Apple waarschijnlijk al mee bezig voordat f.lux de sideloading methode introduceerde."
je gaat hier wel voorbij aan de claim dat f.lux de eerste zou zijn met deze functionaliteit, in dat geval zou er spraken kunnen zijn van marktvervalsing als aple hen die het idee introduceerde hun verdienmodel ontzegt, om dan zelf een vergelijkbare app / functie te ontwikkelen.

toen ms dat met Internet Explorer deed zijn daar uiteindelijk miljardenboetes uit voort gevloeid, waar ik in dit geval ook vanuit ga (met wat lagere vergoedingen uiteraard). maar concurentie-vervalsing lijkt me bewezen zodra de 'wij waren eerst'-claim van f.lux gegrond blijkt.
Wat is het verdienmodel? F.lux is al jaren gratis.... Daarnaast heb ik nergens in mijn post gezegd dat wat Apple doet goed of slecht is, alleen dat ik kan begrijpen waarom dit niet als 'app-functionaliteit' wordt gezien.
Het verdienmodel is dat Fl.ux donaties krijgt.
Het nadeel van afhankelijk zijn van het platform van een derde partij. Zij zijn de baas van het platform en bepalen de spelregels.

De feature op zich is leuk, maar niet bijzonder uniek en makkelijk na te maken.

Op het Apple platform is er een term voor: "Getting Sherlocked", naar de 3rd-party Watson software, die door 1st-party Sherlock vervangen werd.

Natuurlijk niks nieuws onder de zon, Microsoft deed het met Internet Explorer, Twitter met de 3rd-party clients, Google met navigatie.

Alleen Microsoft is daarvoor in de problemen gekomen en dit draaide vooral om de dominante marktpositie van Microsoft, maar ook omdat ze leveranciers (ISP's, hardwareleveranciers) onder druk zetten om de concurrentie van Netscape te onderdrukken.

In de mobiele markt is er nu redelijke keuzemogelijkheden en Apple gebruikt (voor zover bekend) geen buitensporige tactieken.

Kortom: jammer voor F.lux, maar het is bekend risico voor partijen die zelf afhankelijk zijn van iemand anders platform.
Nee, niet crimineel in strafrechtelijke zin.

In niet-strafrechtelijke heb ik er ook geen moeite mee. Het is bekend dat apps alleen gebruik mogen maken van publieke API's. Dat wisten de makers van f.lux al voordat ze ooit waren begonnen aan hun app. Daarnaast is het een begrijpelijke keuze van Apple, ze willen stabiliteit en een gegarandeerde gebruikservaring, die kunnen ze alleen garanderen door strict om te gaan met de API's die 3rd party apps mogen gebruiken.

Tot slot stelt f.lux inhoudelijk niks voor en is het ook niks nieuws. Zeer nuttig, zeer handig, maar niet dusdanig uniek dat je het niet gewoon eenvoudig zelf kan inbouwen.
Tot slot stelt f.lux inhoudelijk niks voor en is het ook niks nieuws.
Zelfs al zou dat zo zijn, dan nog is dat natuurlijk compleet geen argument voor de stelling "het is acceptabel dat Apple dit idee jat en oneerlijke concurrentie pleegt door het origineel buiten te sluiten". Ik vind dat afgeronden hoeken en rubber-bounce-scrollen inhoudelijk ook bar weinig voorstellen, maar naar Apple's eigen mening zijn dat toch cruciale zaken. Dan moeten ze de functionaliteit van Flux ook als game-changing meerwaarde beschouwen.

Ik betwijfel of Flux gek genoeg is om Apple voor de rechter te slepen (iets met absurde kosten als de diepe zakken van Apple het oneindig rekken...), dus hun gelijk krijgen bij de rechter zit er niet in, maar ik ben zeer benieuwd of ze (in elk geval in theorie) strafrechtelijk misschien wel gelijk hebben (denk aan koppelverkoop IE meeleveren bij Windows vs. "Flux" meeleveren bij iOS of oneerlijke concurrentie).
Maar op welke basis dan? Qua intellectuele eigendom hebben ze een zwakke positie totdat hun octrooi wordt bevestigd (als dat Řberhaupt gebeurt). Qua mededinging wordt het al lastig omdat Apple in tegenstelling tot Microsoft of Google waarschijnlijk geen toereikende marktmacht in de relevante markten heeft waardoor een overheidsingrijpen gerechtvaardigd zou zijn. Misleidende reclame is vermoedelijk ook niet aan de orde.

Ook niet over het hoofd zien: f.lux is niet uniek. Vergelijkbare functionaliteit is elders ook al te vinden, bijvoorbeeld in de vorm van soortgelijke programma’s. Google bracht eind vorig jaar een update voor de Google Books-app uit waarin hetzelfde principe wordt toegepast en Apple zelf heeft in iBooks ook al een tijdje met kleurwijzigingen gespeeld (weliswaar niet met de kleurtemperatuur, maar een vergelijkbaar principe). Het wordt dus al verdomd lastig om te zeggen dat Apple hier oneerlijk handelt specifiek tegenover f.lux.

Het is in dit geval misschien wel sneu, maar eigenlijk vind ik wat Apple doet wel prima, hoewel niet netjes. Aan softwareoctrooien worden bewust strenge eisen gesteld. Het gevolg daarvan is dat triviale uitvindingen dus gewoon naar hartenlust kunnen worden gekopieerd, omdat niemand eigendom daarin kan opeisen.
Maar op welke basis dan? Qua intellectuele eigendom hebben ze een zwakke positie totdat hun octrooi wordt bevestigd (als dat Řberhaupt gebeurt).
Er is een verschil tussen het idee "laten we iets doen met de kleurtemperatuur" en de implementatie "[specifieke formule om de 'beste' kleurtemperatuur te berekenen".
Of Flux met dat idee de eerste was (en, indien dat zo is, er patent op heeft aangevraagd) weet ik niet. De implementatie is echter sowieso van Flux (tenzij iemand hard kan maken dat ze die ergens gevonden / gestolen hebben; ik heb nog nooit claims in die richting gehoord, dus ga er voorlopig even van uit dat het hun eigen algorithme is), maar als ze ooit een versie naar Apple hebben gestuurd ter goedkeuring, dan is het wat mij betreft aan Apple om te bewijzen dat de ontwikkelaars van hun eigen versie op geen enkele manier bij Flux "gespiekt" hebben; dat zou hoe dan ook strafbaar zijn (al weet ik niet precies onder welke noemer; valt dat misschien onder industriŰle spionage?).
Qua mededinging wordt het al lastig omdat Apple in tegenstelling tot Microsoft of Google waarschijnlijk geen toereikende marktmacht in de relevante markten heeft waardoor een overheidsingrijpen gerechtvaardigd zou zijn.
Tja, percentages hangen compleet af van hoe je de "markt" definieert; ze hebben 100% macht binnen het iOS platform... Geen idee hoe dat hier uit zou pakken.
Ik weet dat in het verleden Apple wel hun eigen browser mee mocht leveren (zonder browser-keuzescherm), omdat ze een klein marktaandeel hadden op de markt voor computers, maar die situatie is niet echt vergelijkbaar, omdat ze toen weliswaar Safari meeleverden, maar Firefox niet daadwerkelijk blokkeerden, wat ze in dit geval wel doen.
Ook niet over het hoofd zien: f.lux is niet uniek. Vergelijkbare functionaliteit is elders ook al te vinden, bijvoorbeeld in de vorm van soortgelijke programma’s. Google bracht eind vorig jaar een update voor de Google Books-app uit waarin hetzelfde principe wordt toegepast en Apple zelf heeft in iBooks ook al een tijdje met kleurwijzigingen gespeeld (weliswaar niet met de kleurtemperatuur, maar een vergelijkbaar principe). Het wordt dus al verdomd lastig om te zeggen dat Apple hier oneerlijk handelt specifiek tegenover f.lux.
Maar... op welke manier is dat relevant? Als Apple niet oneerlijk mag handelen tegenover Flux, waarom zouden ze dat dan wel mogen tegenover een grotere groep concurrenten...!? Ook van de beschikbaarheid op Android zie ik de relevantie niet; dat heeft niks te maken met Apple's handelen binnen het iDevice-gebeuren.
Het is in dit geval misschien wel sneu, maar eigenlijk vind ik wat Apple doet wel prima, hoewel niet netjes. Aan softwareoctrooien worden bewust strenge eisen gesteld. Het gevolg daarvan is dat triviale uitvindingen dus gewoon naar hartenlust kunnen worden gekopieerd, omdat niemand eigendom daarin kan opeisen.
Ik zou er ook faliekant tegen zijn als Flux een octrooi zou kunnen krijgen op het idee van kleurtemperatuur aanpassen met het oog op nachtrust, dat is wel heel erg breed. Maar dat is ook niet waar (wat mij betreft) het probleem zit: het gaat er mij niet om dat Apple ˇˇk een blauwfilter uitbrengt, waar ik bezwaar tegen heb is dat ze Flux blokkeren (en op die manier hun eigen versie pushen).
Er is een verschil tussen het idee "laten we iets doen met de kleurtemperatuur" en de implementatie "[specifieke formule om de 'beste' kleurtemperatuur te berekenen".
Of Flux met dat idee de eerste was (en, indien dat zo is, er patent op heeft aangevraagd) weet ik niet. De implementatie is echter sowieso van Flux (tenzij iemand hard kan maken dat ze die ergens gevonden / gestolen hebben; ik heb nog nooit claims in die richting gehoord, dus ga er voorlopig even van uit dat het hun eigen algorithme is), maar als ze ooit een versie naar Apple hebben gestuurd ter goedkeuring, dan is het wat mij betreft aan Apple om te bewijzen dat de ontwikkelaars van hun eigen versie op geen enkele manier bij Flux "gespiekt" hebben; dat zou hoe dan ook strafbaar zijn (al weet ik niet precies onder welke noemer; valt dat misschien onder industriŰle spionage?).
Ten eerste is dit natuurlijk volledig uit de duim gezogen. Desalniettemin: het blijkt nogal uiterst lastig te zijn om een ‘implementatie’ te beschermen. Er is op dit moment geen octrooi en daarmee is eigenlijk alles al gezegd. Het auteursrecht leent zich er amper voor om computerprogramma’s te beschermen. Zelfs al zou Apple de broncode hebben kunnen inzien, wat niet onderdeel van het reviewproces is, dan belet het auteursrecht hen niet om delen van de implementatie over te nemen, zolang ze de broncode niet zelf kopiŰren. Het lijkt mij volstrekt bizar dat Apple dat zou doen. Verder is er weinig aan de implementatie van f.lux, aangezien zij hun cijfers vermoedelijk zelf uit het relevante onderzoek hebben gehaald, waar zij zo graag naar verwijzen. Probeer dan maar eens te bewijzen dat van f.lux is gekopieerd en niet van dat onderzoek. Nogmaals, het zijn aannames, maar ik zie prima facie al geen goede grondslag.
Tja, percentages hangen compleet af van hoe je de "markt" definieert; ze hebben 100% macht binnen het iOS platform... Geen idee hoe dat hier uit zou pakken.
Ik weet dat in het verleden Apple wel hun eigen browser mee mocht leveren (zonder browser-keuzescherm), omdat ze een klein marktaandeel hadden op de markt voor computers, maar die situatie is niet echt vergelijkbaar, omdat ze toen weliswaar Safari meeleverden, maar Firefox niet daadwerkelijk blokkeerden, wat ze in dit geval wel doen.
iOS als een eigen markt gaan definiŰren schiet natuurlijk ook niet op en ik kan mij niet voorstellen dat een mededingingsautoriteit daarin meegaat. Apple mocht overigens altijd al een eigen browser meeleveren. Sterker nog, ik kan mij geen enkel geval herinneren waarin Apple door mededinging aan extra eisen moest voldoen, puur omdat zij zelden een zodanige marktmacht hebben dat een ingrijpen nodig is. Apple heeft overal wel een concurrent. Omgekeerd weten wij ook van de Microsoft-zaken hoe lastig het is om dit soort claims door te zetten. In het geval van Microsoft hebben alleen Windows Media Player en Internet Explorer succesvolle zaken opgeleverd, waarbij de enorme marktmacht van Windows in desktopbesturingsystemen (90%+) Ún het misbruiken daarvan leidende rollen hebben gespeeld. Daar komt Apple nog steeds niet in de buurt. Bovendien waren dit Europese zaken, in de VS gaat men daar nog veel terughoudender mee om. F.lux is een Amerikaans bedrijf en ik zie hen niet in Europa gaan procederen.
Maar... op welke manier is dat relevant? Als Apple niet oneerlijk mag handelen tegenover Flux, waarom zouden ze dat dan wel mogen tegenover een grotere groep concurrenten...!? Ook van de beschikbaarheid op Android zie ik de relevantie niet; dat heeft niks te maken met Apple's handelen binnen het iDevice-gebeuren.
Het is relevant voor een eventuele zaak van f.lux tegen Apple. F.lux zou moeten stellen en bewijzen dat Apple van hen heeft gekopieerd en niet van iemand anders. Als Apple bijvoorbeeld zegt: wij hebben de temperatuurwaarden uit het relevante onderzoek gehaald, wat wil F.lux daar nog tegen inbrengen?
Ik zou er ook faliekant tegen zijn als Flux een octrooi zou kunnen krijgen op het idee van kleurtemperatuur aanpassen met het oog op nachtrust, dat is wel heel erg breed. Maar dat is ook niet waar (wat mij betreft) het probleem zit: het gaat er mij niet om dat Apple ˇˇk een blauwfilter uitbrengt, waar ik bezwaar tegen heb is dat ze Flux blokkeren (en op die manier hun eigen versie pushen).
Maar ze blokkeren F.lux niet. Ze stellen alleen geen API’s ter beschikking die dit soort functionaliteit zou kunnen omzetten en ze bieden geen programma’s in hun App Store aan die private API’s gebruiken. Het gaat dus vooral om een doen en geen nalaten. Vind jij het wenselijk dat een rechtbank zich met de ontwikkeling van een besturingssysteem gaat bemoeien?
Ik denk dat dit het hele punt precies is:

"niet daadwerkelijk blokkeerden, wat ze in dit geval wel doen."

Ze blokkeren het niet, je kunt het op je iPhone installeren via een omweg. Ze ondersteunen het echter ook niet, en dat lijkt me het goed recht van Apple, simpelweg omdat de app niet aan de voorwaarden (van de App Store) voldoet.

Dat Apple vervolgens iets maakt dat erop lijkt of precies hetzelfde werkt is een andere zaak. Als de heren van f.lux er patenten of octrooien op hebben zullen ze Apple aan moeten klagen of een schikking moeten treffen. Daarin geef ik ze weinig kans.

[Reactie gewijzigd door Thomas18GT op 16 januari 2016 05:41]

Zoals ik dit verhaal lees heeft f.lux een werkende app die door apple geblokkeerd wordt. Apple kopieert de bestaande functionaliteit van f.lux en brengt dan zelf een app uit.

Als Apple technische redenen wil aanhalen om f.lux te blokkeren prima, maar dan had men nightshift api onmiddellijk moeten openstellen voor zij zelf hun app uitbrachten.

Nu lijkt het mij een overduidelijk geval van monopoliemisbruik.
Als Apple technische redenen wil aanhalen om f.lux te blokkeren prima, maar dan had men nightshift api onmiddellijk moeten openstellen voor zij zelf hun app uitbrachten.
Waarom moeten ze dat?
Nu lijkt het mij een overduidelijk geval van monopoliemisbruik.
Apple heeft geen monopolie.
Apple heeft geen monopolie.
monopolie: een situatie waarin een product of dienst slechts door ÚÚn partij wordt aangeboden

Aangezien binnen het iOS-ecosysteem van Apple een derde partij kennelijk niet de mogelijkheid krijgt hetzelfde aan te bieden (want APIs niet beschikbaar), kun je m.i. dus wel degelijk van een monopolie spreken!

[Reactie gewijzigd door LaMaZitten op 15 januari 2016 19:55]

Gelukkig ben jij geen jurist. Waarom zou alles ook door een derde partij aangeboden worden? Dat is onzin. Er is ook geen derde partij die een telefoonapp kan uitbrengen.

[Reactie gewijzigd door TMC op 15 januari 2016 20:30]

Ik weet niet wat je hiermee wilt zeggen. Jij stelt dat Apple geen monopolie heeft. Ik ben van mening dat dat voor iOS in dit geval (niet beschikbare APIs) niet waar is.

Ik heb niet beweerd dat ik vind dat alles door een derde partij aangeboden moet worden. Maar als dat niet mogelijk is, kun je m.i. dus wel degelijk over een monopolie spreken (het is letterlijk de definitie daarvan). :)
Volkswagen heeft ook een monopolie op het verkopen van Volkswagens, moeten zij dan ook maar alle api's openstellen?

Als Apple nou de enige smartphonemaker zou zijn.. Oke. Maar je hebt genoeg keuze nu.

[Reactie gewijzigd door Thomas18GT op 16 januari 2016 06:01]

Vergelijking met auto's is een beetje lastig in dit geval.

Apple stelt een deel van haar product (het OS in dit geval) open voor andere ontwikkelaars. Zij zijn zelf dus niet de enige app-ontwikkelaar voor hun eigen platform. Echter, een deel van dat platform stellen zij niet open (in dit geval onder andere de APIs om schermkleur mee te regelen). Op dat punt, zijn zij daarmee monopolist.

Dat ze in de smartphone-wereld zelf geen monopolist zijn, lijkt me helder. Mijn oorspronkelijke reactie was echter op TMC, die reageerde op denBoom door te stellen dat Apple geen monopolie heeft. Echter, binnen haar ecosysteem en ten aanzien van het gebruik van deze APIs, heeft ze dat wel degelijk.
Juist, dat deel wat ze niet open stellen weten consumenten wanneer ze een iOS telefoon kopen en dat weten developers wanneer ze beginnen aan een app. Daarom vind ik dit geen misbruik maken van een monopolie (ik vind het ook geen monopolie gezien er genoeg andere keuze in smartphones is).

Dan moet je achteraf niet zeuren dat ze die API vrij moeten geven.
Apple heeft een natuurlijk monopolie op iOS en iPhones. Daar is niks op tegen.

Als jij morgen besluit om LaMaZittenPhones te maken is er geen andere fabrikant die dat ook doet en heb jij ook een natuurlijk monopolie.

De vraag is of er andere fabrikanten zijn van mobiele telefoons en godzijdank ja dat is zo.
Apple heeft een natuurlijk monopolie op iOS en iPhones. Daar is niks op tegen.
Dit is het monopolie wat denBoom bedoelde toen hij zei dat Apple misbruik maakt van haar monopoliepositie. Kennelijk vindt hij het niet eerlijk dat deze functies worden afgeschermd van andere ontwikkelaars.
Een 'nieuwe' feature, die al jaren bestaat. F.Lux doen alsof ze het hebben uitgevonden, het enige wat zij gedaan hebben is een iOS versie gemaakt. Een app als F.Lux bouw je in een uurtje, zie niet wat er de meerwaarde van is als we straks 10.000 apps in de store krijgen die niets anders doen dan 1 API aanroepen.
Wie was er eerder dan F.Lux dan?

F.lux is al bijna 10 jaar oud :)
F.lux komt uit 2009. ;-) Het principe was technisch niet nieuw. Er waren ook al lampen die dat konden (met een klok). De vernieuwing is hier dat ze het als software implementeren, maar het idee is vrijwel hetzelfde. Zelfs al zou Apple de tijdfunctie niet aanbieden, dan blijft er eigenlijk alleen nog maar een paneel over om de kleurtemperatuur van het scherm te veranderen en dßt heeft F.lux zeker niet als eerste aangeboden. Het illustreert overigens ook hoe triviaal het principe van F.lux is.
Ik kon 20 jaar geleden al de kleurtemperatuur van m'n monitor instellen.
Wat totaal niet hetzelfde is.

Heb jij ooit de combinatie van locatie, tijd, en schermfilter bedacht? F.lux namelijk wel. Je kunt het niet bijzonder vinden, maar zoals met alle uitvindingen: je moet er maar net op komen.
Bij flux gebeurt het automatisch afhankelijk van de tijd...
Als ik de night shift promotie hierboven zie dan zijn zij zeker niet de enige die doen alsof ze het warm water hebben uitgevonden.
f.lux claimt baanbrekend te zijn, en jij weerlegt dit niet met feiten, hun claim kan dus nog steeds staan. ik heb geen zin om uit te zoeken wie deze 'savonds minder blauw' optie voor hete eerst heeft ontwikkeld, maar in de flux vs apple waren ze in ieder geval wel eerder en dat geeft al dat apple waarschijnlijk schuldig is aan marktvervalsing.
Het kunnen aanpassen van je whitebalance kan al decennia, dit automatisch doen op basis van het tijdstip kan je moeilijk 'baanbrekend' noemen. Da's echt een totaal triviale toevoeging.
Ach, het aanpassen van kleurtemperatuur kon al sinds de allereerste LCD schermen op de markt kwamen. We kunnen heel speciaal gaan doen over F.lux maar het is niet alsof ze het wiel hebben uitgevonden of met wat dan ook 'iets als eerste deden'. Voorheen deed je dit namelijk gewoon met een button op je paneel. En eigenlijk doe ik dat nog steeds, want F.lux werkt niet heel lekker samen met bepaalde applicaties.

Heel kort door de bocht, leuke applicatie voor de mensen zonder PC kennis verder totaal overbodig.

[Reactie gewijzigd door Vayra op 15 januari 2016 12:05]

Onzin.

Kleurtemperatuur aanpassen kan inderdaad al jaren.

Maar ook automatisch, op basis van tijd, locatie en de daaraan gekoppelde zonsondergang/opgang?

Schermen, SoC's en metaal bestonden ook voor de iPhone. Heeft Apple dan ook niks als eerste gedaan?
Schermen, SoC's en metaal bestonden ook voor de iPhone. Heeft Apple dan ook niks als eerste gedaan?
Dat klopt inderdaad :)
Dat klopt, Apple was nergens het eerste mee.

Wel het beste in het integreren van allerlei functionaliteit.

@Jeroenneman: Vwb het aanpassen van kleurtemp op basis van een tijdsklok heb je inderdaad gelijk, alleen het is jammer dat F.lux niet heel lekker is geintegreerd, ik denk dat dat ook de reden is dat Apple het zelf doet (OS restricties, die er niet zonder reden zijn). Ik heb F.lux ook gebruikt, maar het kan niet altijd aan blijven staan, bijvoorbeeld tijdens installs, maar ook bij bepaalde beeldscherm instellingen gaat het flippen. Dan is de meerwaarde van een ingebouwde timer wat mij betreft al snel verdampt.

Nog altijd vind ik het persoonlijk handiger om gewoon een paar display settings te gebruiken omdat dat hardwarematig is. Met G-Ignition kan ik deze settings zelfs koppelen aan een keyboard toets. Numpad Plus is nu voor mij een switch voor helderheid, strobe en kleurtemps :)

[Reactie gewijzigd door Vayra op 15 januari 2016 13:46]

Aangezien je het zelf nalaat om deze informatie te geven, zal ik je deze nog cadeau geven ondanks de vervelende toonzetting van je reactie. Maar daarna is het puur en alleen integratie van bestaande functionaliteit geweest, en eigenlijk is dit voorbeeld er ook eentje van een integratie/combinatie van software en hardware, waarop Apple zich eigenlijk altijd al heeft geprofileerd:

"De Apple I was een vroege personal computer en de eerste die een toetsenbord combineerde met een microprocessor en een verbinding naar een monitor."

Het was dus niet de eerste PC. Wel de eerste die GUI, besturing en hardware als ÚÚn geheel aanbood. Je kan hetzelfde zeggen van vrijwel elk product dat Apple ook daarna heeft aangeboden; altijd was het een stap vooruit op gebied van integratie hardware/software, en altijd op basis van 'tried and tested' technologie.

[Reactie gewijzigd door Vayra op 15 januari 2016 13:44]

"Het was dus niet de eerste PC"
Dat heeft Apple ook nog nooit beweerd.

"Wel de eerste die GUI, besturing en hardware als ÚÚn geheel aanbood"
Ook die stelling is niet waar het was vrij gebruikelijk in die tijd dat men zowel het OS als het computer systeem ontwikkelde (bijv. Atari deed dat ook al).

Maar Apple heeft wel een zeer lange geschiedenis en hebben zeker een grote bijdrage geleverd en om te concluderen ze nooit ergens mee de eerste waren is gewoon onzin.

[Reactie gewijzigd door BoringDay op 15 januari 2016 13:55]

Nou benoem eens wat dan? Dan gaat het nog een keer ergens over...
Hey, inderdaad! Helemaal vergeten dat dat van Apple af kwam
Hypercard, waarmee de inspiratie is opgedaan om het WWW uit te vinden.
PowerBooks Waarna de gehele industrie het naar achteren geplaatst toetsenbord heeft ge´mplementeerd.
Design, want personal computers en smaakvol design waren zeker geen vanzelfsprekendheid (en nog niet bij veel merken).
En voor wat betreft de eeuwige discussie over de GUI en nu de touch interface op iOS, Apple en met name Bill Atkinson (jazeker, van HyperCard) heeft zo ongelooflijk veel ge´nnoveerd. Xerox had niet eens overlappende vensters, of een bureaublad metafoor. Dat zijn toch echt allemaal Apple uitvindingen.
Oh ja, de gebruiker centraal stellen, dat was pas echt innovatief. En kijkend naar de concurrentie, is nog steeds innovatief.

[Reactie gewijzigd door tonnert op 15 januari 2016 14:53]

Knopje is handig voor een PC waarbij je geen transitie wilt. F.lux doet het automatisch op basis van lokatie, tijd, en dag (ivm zonsopgang en -onderdang) plus nog eens jouw preferenties. Het heeft ook een aantal handige opties. Enkele voorbeelden:
  • By default zul je van de overgang weinig werken tenzij je "fast transitions" optie aan hebt.
  • Het heeft een movie mode.
  • Je kunt bepaalde applicaties bijvoorbeeld foto editing software (tijdelijk) een uitzondering geven.
  • Je hebt opties om het aan je slaap aan te passen. NB: je kunt het niet aan je bioritme tracker koppelen.
Ik draai het op meerdere computers. Het enige probleem? Fullscreen mode in applicaties (zeg maar gerust: games). Die draai je dan in fullscreen/desktop mode hetgeen je een paar FPS kost maar waardoor je ze ook nog eens kunt streamen en je Windows theme hetzelfde blijft. Kortom, er zijn meer applicaties die problemen hebben met volledig fullscreen.
F.lux bouw je echt niet in een uurtje. Enig idee hoe groot de kleur verschillen van alle schermen zijn? Als je die allemaal op de kelvin precies gekalibreerd wilt krijgen zodat je geen telefoons krijgt met belachelijk afwijkende kleuren heb je toch iets meer tijd nodig. En een hele hoop telefoons.
Die schermen zijn al gekalibreerd, enige wat deze software doet is het whitebalance punt aanpassen. Zit in OS X gewoon een slidertje voor.
Apple levert geen telefoons, tablets of conputers met OLED scherm dus waar je dat vandaan haalt...
Ah ik haal twee reacties door elkaar, mijn excuses. Meende dat bovenstaande over de verschillende f.lux uitgaven ging (o.a. Android).
Mijn vergissing.

Bij Apple is het inderdaad allemaal gekalibreerd.
volledig met je eens, waarom een app van een derde partij gebruiken als ios het ook native kan.

(de apps zullen weinig meerwaarde kunnen bieden, wat ik uit de beta heb gezien werken de instellingen behoorlijk goed. je kan per uur instellen wat de warmte moet zijn en of je dit geleidelijk aan wilt laten overlopen.)

ik zie apps van derden hierin dus niet noodzakelijk, het is tenslotte iets geheel anders dan een addbloker waar veel voorkeuren in aan te geven zijn.
Apple heeft in al haar wijsheid wel besloten dat de optie alleen werkt vanaf de iPhone 5s.

Op mijn 5c voegt zo'n app dus daadwerkelijk iets toe.
Apple moet gebruikers wel een reden geven om te vernieuwen, dus opzicht is dat niet zo gek. Nu zal deze functie op zichzelf geen reden zijn om te vernieuwen, maar als dat samenvalt met meerdere handigheidjes misschien wel.

Bovendien als er constant nieuwe features worden toegevoegd, die voor extra achtergrond processen zorgen, wordt een oudere iPhone misschien wel onwerkbaar traag?
> Apple moet gebruikers wel een reden geven om te vernieuwen

Ben je nu de planned obsolescence aan het verdedigen? Ik had F.lux al op mijn iPhone 4 jaren terug (jailbreak weliswaar). Waarom zou het voor Apple dan te moeilijk zijn om dit ook in te voeren voor de oudere modellen die nog gesupport worden? Functionaliteit als f.lux kost echt amper rekenkracht, dus dat kan de reden ook niet zijn.
Het is niet te moeilijk, de reden staat bovenin je reactie.
Apple is een commercieel bedrijf dat winst wilt maken, die wilt niet dat jij 5 jaar met een telefoon blijft doen. Door je gewoon uit te sluiten van nieuwe functies, die je toch eigenlijk wel graag wilt koop je misschien wel een nieuwe. En misschien koop je wel nooit meer een product van ze omdat je je belazerd voelt, dan kom je bij andere merken weer hetzelfde tegen.

Welkom op de aarde :+
Argh! Dit meen je niet?!? Ik vond het ook al zo suf dat ik geen adblocker kan installeren op mijn 5. Teleurstellend... net zoals de adblocker had ik ook graag gebruik gemaakt van deze nieuwe feature. Mijn toestel werkt nog prima, batterij is nog goed, dus heb geen zin om een nieuw toestel te kopen.
Zoals de beta nu is zie ik zeker nog ruimte voor vebetering. Ik draai op mijn iPad inmiddels 9.3 public beta 1 en zie enkel een turn on/turn off optie. Je kan instellen hoe ver het blauw gereduceerd moet worden op welk moment het aan moet en welk moment het uit moet (tijd of zonsopkomst/zonsondergang). Instellingen per uur heb ik niet gevonden.
Ik heb de indruk dat de overgang geleidelijk gaat, maar dat weet ik nog niet zeker. En ook dit zie ik niet als instelbaar (daar moet ik bij zeggen dat ik het geleidelijke erg prettig vind).
Ik heb ook enkele weken f.lux gebruikt op zowel mijn iPhone (6) als iPad (air 2) en hierbij merkte ik helaas dat elke paar dagen het blauw 's ochtends niet meer goed terug kwam en dit enkel op te lossen bleek met een herstart. Op mijn computer gebruik ik al jaren f.lux tot volle tevredenheid. Enkel mijn pc op kantoor heeft het niet aangezien ik nooit 's avonds of 's nachts op kantoor ben.
Met de nuance dat f.lux vooraf wist dat ze de API die hun software op iOS gebruikt, niet mochten aanroepen. Apple weigert dus niet vanwege de functionaliteit en om het snel zelf te maken, maar omdat de software interactie met het OS heeft die Apple verbiedt. Of je daar voor of tegen bent, is een tweede maar Apple zorgt door die regels voor stabiliteit en veiligheid van het OS.
en f.lux leverde ook daadwerkelijk problemen is mijn ervaring. Ik heb het op zowel mijn iPad als mijn iPhone gedraaid en bij beiden moest ik elke paar dagen een herstart doen omdat het blauw 's ochtends niet meer terug kwam. Ik kon dan met de settings in de app spelen wat ik wilde, maar een herstart bleek echt de enige oplossing. Dus dat argument van stabiliteit snap ik wel.
Dat is juist een argument om de API waar f.lux om vraagt wel open te stellen zodat ze een stabiele app kunnen maken.
Als dat de reden is had Apple ook hun eigen app moeten verbieden
of voorzieningen moeten treffen dat 3rd party developers ook van deze mogelijkheden gebruik kunnen maken. bv dezelfde test en review procedure als voor hun eigen software.
Haha geweldig, lees eens wat je typt.
Dus als Apple een app maakt voor haar eigen toestel, moeten ze andere bedrijven de kans geven om eenzelfde soort app te maken?

Volgens mij wil je dit juist voorkomen, tientallen dezelfde apps in je App Store..
Het is inderdaad wel op zijn zachts gezegd een smerig zaakje.
Dit is overigens imo wel de ultieme bevestiging dat Apple van een innovator naar volger/opkoper is veranderd.
Dan ben je lekker bij de tijd..
Apple maakt al jaren apps na die via cydia (of andere omwegen zoals in het artikel beschreven) wel te verkrijgen zijn, en daar ben ik als iOS gebruiker heel erg blij mee.
Komt wel meer voor bij Apple. Zo werd bijvoorbeeld 'Week Cal' niet toegelaten. Later bracht Apple een verbeterde versie uit van hun eigen agenda en die kon nog steeds niet tippen aan Week Cal. Uiteindelijk mocht die app dan toch worden aangeboden. Maar ja dan wordt je als bedrijf al jaren tegengewerkt door Apple.
Je bent van Apple afhankelijk omdat het de enige weg is om je apps op dat OS aan de man te brengen terwijl Apple zelf je tegenwerkt uit eigenbelang. Op zijn minst twijfelachtig te noemen.
Tja, je kunt niet verkondigen dat de functie essentieel is voor de gezondheid van alle iOS gebruikers en tegelijkertijd verwachten dat Apple de werking hiervan overlaat aan een appje van een derde.

Ik denk ook niet dat de f.lux developers anders verwacht hadden dan dat Apple het eerst zelf zou implementeren en vervolgens pas gaat overwegen de API openbaar te maken.

Dit overigens vrij standaard bij Apple. Eerst doen ze iets zelf zodat ze nog aan de API kunnen sleutelen en een paar versies later maken ze de API dan openbaar.
Als Apple het in iOS "openbaar" zou maken zou dat als volgt moeten gaan: je installeert een "Screen temperature controller". Je gaat vervolgens naar instellingen/beeldscherm en helderheid/Screen temperature/Controllers en je activeert de app. Gewoon de API openbaar maken zonder meer, zou erg inconsistent zijn met hoe iOS werkt, en kan dus niet (zie ook 3rd party keyboards).
In het artikel staat dat je alleen f.lux kan installeren als je een jailbreak hebt, dat is onjuist. Je kan de app zelf compileren en sideloaden. Er zijn handleidingen te vinden die het uitleggen. Dit kan trouwens ook met Kodi en andere open source apps/tweaks.

Edit: links toegevoegd.

[Reactie gewijzigd door ruimtekoek op 15 januari 2016 11:58]

Klopt, momenteel kan dit ook op Android. Ik draai momenteel een alpha/beta van f.lux op mijn Android telefoon die via adb gesideload is.
Ze zoeken momenteel zoveel mogelijk testers ivm de diverse chipsets en schermen. Voor wie interesse heeft kijk even op het forum, je kunt je aanmelden waarna je toegang krijgt tot het verborgen test gedeelte.
https://justgetflux.com/f...droid-you-have-internally
Als je geen zin hebt in gedoe, kun je op Android ook gewoon Twilight gebruiken.
Twilight zorgt wel voor oranje screenshots, waar f.lux dat niet doet.
f.lux zie je ook terug in je screenshots hoor. Verschil is de manier waarop f.lux een lagere kleurentemperatuur weet te bereiken.
Niet op Android. Al mijn screenshots zien er normaal uit, ook die ik snachts gemaakt heb. Ik heb van een van de twee ontwikkelaars van f.lux begrepen dat de Windows versie nog wat brak ge´mplementeerd is en idd een rood oranje gloed laat zien. Verbetering komt nog.
De Linux-versie werkt prima (en de OS X-versie idem), geen oranje gloed, dus ze weten wel wat ze doen voor de desktop en de Windows-versie zal dus ook wel een zelfde implementatie gaan krijgen :)

[Reactie gewijzigd door Vistaus op 16 januari 2016 11:03]

Twilight werkt niet het zelfde als f.lux. Die maakt je scherm alleen maar rood/oranje.
Is dat niet ook wat f.lux doet? Ik dacht dat ze (qua effect) vrij gelijkwaardig waren? (Twilight gebruiker hier :) )
Nee, flux past de kleur waarden aan van het scherm waar andere apps meestal eigenlijk alleen maar een oranje overlay over je scherm leggen.
met als gevolg dat zwart oranje wordt, waar bij f.lux zwart gewoon zwart blijft.
Nu we toch in de me too stand staan, in cyanogenmod(open source versie android) lijkt het ook standaard al in te zitten.
Klopt, in CM12.1 zat het op een gegeven moment al en het is nu standaard inbegrepen in CM13.
Klopt dat is LiveDisplay in de instellingen. Ik heb zelf de ervaring dat f.lux veel beter werkt. LiveDisplay is mij te geel en heeft niet het volledige resultaat.
Twilight legt gewoon een rode laag over jouw scherm heen, verder doet het weinig met de hoeveelheid blauw die het scherm uitstraald.

Ander dan f.lux en LiveDisplay, die verminderen de hoeveelheid blauw licht echt.
Jammer dat je zoveel moeite moet insteken voor een simpel .apk linkje.

Dan blijf ik maar bij Twilight
Oh dat kost mijn geen moeite hoor. Ik heb alleen de afspraak met beide ontwikkelaars om nieuwe testers via het forum aan te melden. Het is ons nadrukkelijk verboden om de directe link naar de apk te delen. Een van de redenen is dat ze feedback willen op deze alpha/beta versies.
In het artikel staat dat je alleen f.lux kan installeren als je een jailbreak hebt, dat is onjuist.
Klopt, momenteel kan dit ook op Android.
Nee, hier is vooralsnog root voor nodig. Voor de uiteindelijke versie van Android is geen root nodig, en F.lux team zegt zelfs dat mensen niet hun device moeten rooten alleen maar om F.lux te testen.

[Reactie gewijzigd door Jerie op 15 januari 2016 15:00]

Sorry, momenteel is er inderdaad root nodig. Er wordt inmiddels wel gewerkt aan een geheel nieuwe versie. Ik weet niet of die al zonder root werkt, dat is uiteindelijk wel de bedoeling maar momenteel nog niet mogelijk. Daarnaast is het wel handig om logcat te gebruiken.
Interessant dat dat kan.

Anderzijds wordt dit voor een groot deel van de gebruikers waarschijnlijk te ingewikkeld, eng, onbegrijpelijk.
Hangt ervanaf. Op Windows, Mac OS X en Linux is het heel makkelijk te installeren, als ieder ander programma. In de toekomst op Android idem en op iOS ook als Apple gehoor geeft aan het openstellen van hun API.
Ik gebruik het al op desktop. Ik reageerde op ruimtekoek's "Je kan de app zelf compileren en sideloaden." wat slaat op iOS. Sideloaden in iOS kende ik nog niet en blijkbaar is Apple er niet blij mee.
Dankje f.lux is een van de beste programma,s voor op mijn p.c .
Nu ik weet dat het er is voor android zal ik zekers ff verder neuzen :)
Ik ben erg geinteresseerd in de Kodi implementatie, heb je daar meer informatie over?
Kan nog steeds. Wel even de SHA1 controleren van dit bestandje :9
Waarom zegt het artikel iets anders dan? Het is geen oud artikel.
Het kan nog steeds met het bestandje dat f.lux niet meer "mag" verspreiden. Kwestie van Xcode installeren, zelf f.lux signen en dan sideloaden. Staat ook gewoon in het artikel, f.lux heeft het bestand dat ik linkte van hun eigen website afgehaald, verder kan Apple geen actie ondernemen om jou te stoppen het bestand ergens anders te downloaden en te sideloaden.
Ik raad f.lux aan iedereen aan! Ik gebruik het op mijn laptop als ik savonds nog vlug een serie o.d. kijk. Veel aangenamer voor de ogen. Als je het uitschakelt op dat moment is het alsof je naar de zon kijkt.
F.lux voor films en/of series is geen fijne kijk ervaring. Je hebt dan een gele filter en dat is geen fijne kijk ervaring. F.lux aanbevolen voor normaal gebruik.
Ik vind wel dat het went. Ik neem F.lux helemaal niet meer waar, ongeacht wat ik doe. Ik heb het zelfs bij games aanstaan en het stoort mij niet.
Moet je eens foto's bewerken, en dan de volgende dag kijken wat je ervan hebt gemaakt :+
Ik moet het voor bankzaken ook altijd uitzetten :) Die raboscanner vind de kleurafwijkingen niet tof :+
Klopt. De Raboscanner kan er niet mee omgaan maar dan gewoon ff 'Disable for 1 hour' aanvinken, scannen en weer uitvinken. Op mijn Android telefoon met CF Lumen pikt de Raboscanner dat gelige licht wel.
Voor films kijken, ik zie geen verschil. Wel met sommige foto's bewerken dan moet ik ook even f.lux uitzetten als het kritisch is.
Maar verder werkt het geweldig op de Mac. Op Android heb ik dus CF.Lumen, die werkt net zo goed.
Nu nog op iOS. Ik ben het geheel eens met de makers van f.lux, Apple moet niet zo moeilijk doen.
Eens, ik heb het ook aan staan (zelfs echt de hoge stand) 's avonds en met series kijken heb ik er totaal geen last van, die warme kleuren. Misschien is het onnatuurlijk, maar op de een of andere manier hebben ze het zo gedaan dat het toch lekker wegkijkt. Als ik het dan uit zet voor een uurtje, dan vind ik het ineens weer erg fel en "koud". Ik heb hem wel op "slow" staan en niet op "fast 20seconden", dus ik wen er echt langzaam aan op de avond. Top programma!
Zeker maar dat is een persoonlijjke mening en is voor iedereen anders. Je kan zelf de sterkte instellen. Voor een serie als House of cards is het nu niet erg. Als je een serie kijkt met veel kleuren/effecten dan kan ik me inbeelden dat je geen filter wilt.
Als je het uitschakelt op dat moment is het alsof je naar de zon kijkt.
Ik ken f.lux niet en ik heb ook echt geen idee wat je met die uitspraak bedoelt. :) Naar de zon kijken is toch bijzonder onprettig of zie ik dat verkeerd (no pun intended)?
's Avonds wordt je scherm geler door f.lux (de kleurtemperatuur wordt lager)
Als je het uitzet dan zet f.lux het scherm (snel) weer terug in de normale stand.
Meestal hebben mensen hun scherm erg blauw staan. Het verschil tussen 2900K en 6500K is nogal heftig, en zeker onprettig.
Het is maar net wat je 'erg blauw' vindt; 6500 Kelvin is 'neutraal wit' voor een monitor en het kan nog veel 'blauwer'. Het probleem van de vraag wat neutraal is, is natuurlijk: wat neem je als uitgangspunt voor wit? Zonlicht op het midden van de dag leek me eerst logischerwijze het meest wit, maar bij bewolkt weer is licht nog veel koeler van kleur. En in Nederland is het daglicht vaker bewolkt dan onbewolkt/midden op de dag.
Naar mijn weten is 5500 Kelvin 'neutraal wit', en zit 6500 Kelvin dus in het blauwe spectrum.

Maar goed, voor F.lux draai ik 6500K overdag, en geleidelijk terug naar 2900K 's nachts.
Monitoren staan fabriek-af altijd op 6500 Kelvin of nog veel kouder van kleur. 9300 K is de laatste jaren ook een populaire temperatuur maar dat is een stuk blauwer. Ik krijg de indruk dat dat komt doordat handig is bij goedkope LEDs. 6500 werd gebruikt bij het kalibreren van monitoren in een keten voor het produceren van drukwerk, toen ik me daar nog veel mee bezig hield.
Ohhh... Ik begreep de zin van Wux helemaal verkeerd.

Ik dacht dat hij bedoelde: "Met f.lux is in het donker naar Netflix kijken op mijn laptop veel prettiger. Als ik hem uitzet dan lijkt het alsof ik naar de zon kijk."

Met uitzetten dacht ik dat hij de laptop bedoelde. Dus: "Als ik de laptop uitzet, dan lijkt het alsof ik naar de zon kijk." Daar begreep ik dus helemaal niks van.

Maar hij bedoelt: "Als ik f.lux uitzet, dan lijkt het alsof ik naar de zon kijk."

Ik snap 'm nu!

Dat moet ik ook eens uitproberen dan!
F.lux is echt ideaal... Ik heb nog wel eens standby dienst, waar ik dus midden in de nacht wakker gebeld kan worden en achter de computer moet kruipen.

Met f.lux heb je geen zonnebril nodig op zo'n moment :-)
Jep heb ik ook voor die standby dienst. F.lux is een verademing voor de ogen!
Ik gebruik het zelf ook naar volle tevredenheid, echt een geweldige app. Op Android gebruik ik Livedisplay wat hetzelfde doet, als je het eenmaal gewend bent kun je echt niet meer zonder.

Wat wel het nadeel is, de Rabo scanner werkt niet wanneer Flux is geactiveerd en ook het scannen van bioscoopkaartjes met m'n telefoon werkt niet met Livedisplay enabled vanwege de screen overlay, ook sommige andere applicaties kunnen er af en toe vreemd door reageren laatst had ik er bijv eentje met missende knoppen en toen ik overschakelde naar normale modus waren die ineens wel weer zichtbaar.
Apple lost het met Night Shift toch anders op f.lux.

Met f.lux aan doet de Rabo scanner het inderdaad niet. Niet alleen de kleurtemperatuur wordt aangepast, maar de kleuren ook.

Met Night Shift werkt de Rabo scanner wel.
Dit suggereert dat een screenshot gemaakt tijdens f.lux gebruik er ook anders uitziet? (Een screenshot met NightShift ziet er gewoon normaal uit, zonder NightShift effect.)
Dat klopt. Een screenshot met Flux levert je een aangepast beeld op (dus inclusief overlay). Dat heb ik al wel vaker ondervonden helaas.
Buiten dat kun je Flux gemakkelijk pauzeren (voor kleur intensief werk) dus dat is eigenlijk geen probleem.

@La1974: Hoe weet je dat de Raboscanner met NightShift wel werkt? Die functie is nog niet uit toch?
F.lux gebruikt geen overlay. Screenshots op de Mac met f.lux aan zijn niet gelig. Bij CF.Lumen is dat wel het geval, maar die gebruikt ook geen overlay, ik het de root versie. Soortgelijke apps zonder root leggen er een soort bruine laag over zodat alle zwart bruin wordt, heel lelijk. CF.Lumen (root) en f.lux hebben daar geen last van.
Op de iPad heb ik nu Gamma Thingy en die doet het ook goed, ook zonder bruine overlay, maar deze mag niet in de Play store vanwege eerder genoemde 'bezwaren' van Apple.
Dus gewoon een bouwpakket van github gedownload en met xcode gemaakt.

[Reactie gewijzigd door skatebiker op 16 januari 2016 15:44]

iOS 9.3 beta 1 met Night Shift is gewoon beschikbaar hoor.
Hoe kun je blauw licht wegfilteren zonder de kleuren aan te passen? Vreemd.
Ik gebruik f.lux op m'n laptop juist altijd, behalve.. als ik een serie kijk ;)
Het is veel fijner aan je ogen als je bijvoorbeeld in Word bezig bent of iets op internet opzoekt, zeker met lichte pagina's. Maar als ik dan weer een serie of film ga kijken, erger ik me juist aan de veel te warme kleuren.. Mij toch iets te onnatuurlijk (ja, ja kan de intensiteit zelf aanpassen, I know).
F.lux heeft dan ook een movie mode waarbij de kleurtemperatuur weer normaal gemaakt wordt.
*Normaler, want de kleurtemperatuur wordt tijdelijk (2 uur?) iets kouder. Wel is er een optie om het een uur lang helemaal uit te zetten voor 'color sensitive' klusjes.
Ik gebruik hem ook op het werk de gehele dag op de laagste setting, het is echt een stuk rustiger om naar je scherm te kijken heb ik het gevoel. Ik krijg in ieder geval minder hoofdpijn
Kan niks anders dan het met je eens zijn. Mijn ogen raken minder vermoeid in de avond en werken tot in de late uurtjes wordt toch aangenamer met Flux.

En idd, zelf testen of het nou echt werkt kan gemakkelijk door rond een uurtje of half 11 even flux uit te schakelen. Dan sta je echt wel even een half minuutje te knipperen :P
Prima programma inderdaad, ik gebruik het zowel op m'n windows bak als op m'n mac-pro. Het is er voor mij eentje uit de categorie standaard installeren bij een nieuwe installatie :)
Nu Apple zelf met een vergelijkbare functie komt, beredeneren de ontwikkelaars dat de benodigde api opengesteld zou moeten worden, zodat ook derden vergelijkbare apps uit kunnen brengen.
Volgens mij moet Apple helemaal niets. iOS is hun platform en zij mogen ermee doen wat zij willen, waarbij de belangrijkste consequentie kan zijn dat ze minder mobiele apparaten verkopen. Apple heeft geen monopolie, dus zij kunnen met hun gesloten speeltuin doen wat zij willen.

Als je dat niets vindt, dan is de oplossing simpel: gebruik geen iOS. ;)

[Reactie gewijzigd door The Zep Man op 15 januari 2016 11:28]

in de basis geef ik je gelijk. Het is een (eco)syteem van Apple dus ze mogen ermee doen wat ze willen.

Of het verstandig is om zo met je (3rd party) developers om te gaan betwijfel ik. Zonder developers geen apps voor je systeem en hoe minder interessant je systeem dan ook is.

Het zou Apple sieren als ze hun API open stellen.
Of het verstandig is om zo met je (3rd party) developers om te gaan betwijfel ik. Zonder developers geen apps voor je systeem en hoe minder interessant je systeem dan ook is.
Je schetst een extreem scenario ('zonder developers geen apps'). Hoeveel externe ontwikkelaars en applicaties betreft het niet openstellen van de betreffende API? Volgens mij is dat een fractie van het aanbod, dat Apple kan missen zonder een centje pijn.
Bovendien heeft Apple waarschijnlijk ook al punten gescoord door gebruikers via Xcode te laten sideloaden. Hoewel het niet bedoeld is als een alternatief voor de App Store, zie je wel dat er al een levendige groep ontwikkelaars op Github en elders is.
ik stel 'm inderdaad heel breed. In dit specifieke geval , voor deze API zal de impact niet groot zijn. Het zend wel een signaal uit natuurlijk.
Alsof Apple zich drukmaakt im eentje of minder. Er zijn genoeg developers die exclusief voor iOS ontwikkelen en die zullen ook niet 123 vertrekken
Apple komt er simpelweg mee weg. Zo gaan ze al sinds jaar en dag met third party developers om, zowel op OSX als iOS. Veel jailbreak features hebben zo hun weg gevonden naar iOS. Het zou de developers simpelweg inkomsten kosten. Ik denk niet dat Apple hoeft te vrezen voor een exodus van developers, dus kunnen ze het maken.
Retorisch gezien valt het enige bezwaar van Apple weg, dus de redenering van f.lux is wel zuiver
Je bedoelt bezwaar tegen de functie zelf? Apple maakt ook bezwaar tegen apps die invloed kunnen uitoefenen op andere apps en het systeem in het geheel. Dat is iets wat Apple voor zichzelf reserveert. Het komt niet vaak voor dat Apple zulke API's aanbiedt.
Dat zou kunnen, maar dat was kennelijk geen officiŰle reden voor de weigering, anders stond het vermoedelijk wel in het artikel. Het enige bezwaar genoemd in het artikel valt nu weg, dat was mijn punt.
Dat is helemaal niet het geval. Als de reden was dat het programma geen gebruik mocht maken van private API's dan is dßt nog steeds een geldige reden, want de API's zijn nog steeds niet publiek. De reden waarom het waarschijnlijk niet publiek is of zal worden, heb ik al gegeven. Het enige argument van F.lux is: iOS heeft de functie nu, dus moet Apple ook API's aanbieden.

[Reactie gewijzigd door Eitot op 15 januari 2016 11:57]

Apple heeft geen monopolie, dus zij kunnen met hun gesloten speeltuin doen wat zij willen.

FTFY ;)

Het is wel het zoveelste bewijs dat Apple behoorlijk goed is om ideeŰn van anderen in hun apparaten te implementeren. Niet dat anderen dat ook niet doen natuurlijk. :)
Apple heeft geen monopolie, dus zij kunnen met hun gesloten speeltuin doen wat zij willen.
Er zijn (veelgebruikte) alternatieven voor iOS. Met iOS heeft Apple geen monopolie op de markt.

[Reactie gewijzigd door The Zep Man op 15 januari 2016 11:47]

Binnen hun eigen producten dus wel en dat geeft hun het recht om met iOS te doen wat ze willen. Tenminste zo heb ik het in jouw reactie gelezen. ;)

Er zijn gelukkig prima alternatieven voor Apple. Sinds Apple mijn iPod Touch 2 verknald heeft met een update van iOS komt er bij mij geen Apple product meer in huis. Bij andere software-ontwikkelaars worden producten vaak beter bij iedere update op oudere hardware. Bij Apple heb ik het idee dat ze dat nog niet goed onder de knie hebben. ;)
Binnen hun eigen producten dus wel en dat geeft hun het recht om met iOS te doen wat ze willen. Tenminste zo heb ik het in jouw reactie gelezen. ;)
Ah, op die manier. Nee, mijn reactie ging echt over de markt en de mogelijke wettelijke beperkingen. Zolang je geen monopolie hebt, kan je erg veel maken.

Natuurlijk een kleine kanttekening: patenten. In bepaalde landen moet Apple geld afstaan om bepaalde softwarematige functionaliteit aan te bieden. Dit doen zij ook, en wordt waarschijnlijk uitgebalanceerd door het eigen patentportfolio en het geld wat ze daarvoor opstrijken. Natuurlijk kan het zo zijn dat als f.lux patenten toegewezen krijgt voor het betreffende idee dat ze geld van Apple kunnen eisen.
Ik mag hopen dat f.lux hun product goed beschermd heeft en dat ze hier wat mee kunnen. Maar goed we kennen allemaal Apple en hun bezigheid op het gebied van patenten. Eerst doen en dan pas kijken of er iemand wakker wordt. :)
Apple heeft <30% marktaandeel. Zoek even de definitie van monopolie op.
Monopolie op het gebied van iOS, is dat zo moeilijk te begrijpen? 8)7
Als je iets zelf maakt is het logisch dat je er een monopolie op hebt.

Dan kun je ook zeggen dat Microsoft een monopolie op Windows heeft, of Google op Android.
Nee, dat is niet helemaal waar. Apple heeft een heel gesloten systeem en houdt alles heel streng in de gaten. Ze doen vaak ook heel moeilijk als een ontwikkelaar creatief wordt en het systeem optimaal wil gebruiken. Daar heb je bij Android en Microsoft veel minder last van aangezien die een veel opener systeem gebruiken.
Apple heeft regels opgesteld. Als app ontwikkelaar heb je die regels te accepteren. Er staat heel duidelijk wat er wel en niet mag.

Dus als bepaalde API niet toegankelijk zijn dan is dat zo. Wil je dat de app in de app store terecht komt, dan heb je je aan die regels te houden.

Mijn auto kan ook veel harder dan 130km per uur rijden, maar dat mag niet. Ben ik dan ook boos op de auto fabrikant omdat hij een auto maakt die harder kan dan dat de overheid mij toestaat? Of moet ik boos zijn op de overheid omdat ik niet sneller mag, terwijl mijn auto wel harder kan?
1. Wat is dat toch altijd met die auto vergelijkingen op tweakers? Een auto is zelden een vergelijkbaar product.

2. Dat Apple een paar regeltjes in een gebruikers- of ontwikkelaars overeenkomst stop wil niet zeggen dat dat altijd maar een vrijbrief is of juridisch sluitend.
Vergelijkingen gaan nooit 100% op dus dan kan het net zo goed een auto-vergelijking zijn waarbij iedereen zich iets voor kan stellen en verstand van denkt te hebben ;)
Maar feit is wel dat je de keus hebt om het te doen. Als de regering echt niet wil dat jij harder kunt rijden dan 130km/u dan moeten ze de wet veranderen en net als bij vrachtwagens en bussen begrenzers verplicht stellen. ;)
Ja beter ja, Android is 1 grote anarchie. Leuk voorbeeld is bijvoorbeeld de folderstructuur op je sd-kaart/interne geheugen, data word in het wilde weg weggeschreven.
Dat is natuurlijk een heel ander verhaal. ;)
andere ontwikkelaars mogen Windows / PC software Ŕn hardware maken (Ms is natuurlijk ook geen eigenaar van het PC platform) en hetzelfde geld voor Android dat bovendien ook nog eens open source is. Dus je vergelijking slaat werkelijk nergens op.

[Reactie gewijzigd door k7of9 op 16 januari 2016 09:53]

Net zo goed als andere ontwikkelaars ook software voor iOS en OSX mogen maken...er zijn (gelukkig) alleen regels wat er wel en niet mag.
Maar voornamelijk bij iOS bepaalt iOS wat wel en niet mag. En dat gaat lang niet altijd over wat wel en niet wenselijk is, maar zo vaak over wat de mening van Apple ergens over is. Een RSS reader weigeren in de Appstore omdat deze in een screenshot van de app namelijk een nieuwsartikel liet zien waar het woord Android in stond...

Bij de andere platformen is daar geen sprake van. Om over het verschil op hardware gebied maar niet te spreken. Of heb jij wel eens een iOS tablet van een ander merk gezien?

Hoe je het ook wend of keert, je vergelijking is simpelweg onzin.
Dit soort discussies is al eindeloos gevoerd hier, maar toch zal ik onvermoeibaar proberen het iets helderder te maken.
dat gaat lang niet altijd over wat wel en niet wenselijk is, maar zo vaak over wat de mening van Apple ergens over is.
CommerciŰle bedrijven zoals Apple, Microsoft, Google etc doen dit allemaal. Hun doel is gewoon: Zoveel mogelijk geld verdienen en dat lukt beter als je zelf beslist wat er wel en niet met je producten kan.

Pakweg Microsoft doet precies hetzelfde als het ze uitkomt. Zo herinner ik me dat de inlog van een site van de ene op de andere dag niet meer werkte. Bleek dat men bij MS had besloten de hele functie weg te laten uit een minor update van Internet Explorer. En dat is nog maar een klein voorbeeldje. MS heeft het 'onder controle houden van andere software-bedrijven' met allerlei creatieve - al dan niet technische - trucs uitgevonden. Apple wordt op deze pagina verweten te werken met gesloten API's maar dat doet MS al decennia.

Voor Google is het hele Android-gebeuren bijzaak: Ze verdienen hun geld met de zoekmachine-advertenties en Android is feitelijk onbelangrijk voor hun core business. Zij kunnen zich daarom wat Android betreft royaal opstellen naar de gebruiker, want het gaat om andere zaken zoals gebruikersgegevens verzamelen. Zolang dat blijft lopen, zullen ze vooral proberen Android te gebruiken om aandeel van de anderen af te snoepen, die moeten liefst niet al te machtig worden want dat is maar lastig aan de top.

[Reactie gewijzigd door breakers op 16 januari 2016 12:46]

Dat is vrij makkelijk te begrijpen, maar totaal niet relevant. Het product is de telefoon, niet iOS. Apple heeft een marktaandeel van 30% in smartphones. Apple hindert marktwerking op geen enkele manier omdat er genoeg alternatieven zijn als je een iPhone niet prettig vindt.
Apple's marktaandeel is volgens mij <20%...
Dat is volgens mij niet waar. Het is eerder concurrentie vervalsing en dat mag natuurlijk niet. En apple heeft daar al vaker problemen mee gehad. Google maps debacle toen imaps apple maps uitkwam.

[Reactie gewijzigd door Aeternum op 15 januari 2016 12:55]

het geeft mij ook een bittere smaak. Dus snap je punt. Of het concurrentie vervalsing is weet ik niet, ben ik niet juridisch kundig genoeg voor. Maar helemaal zuiver is het niet nee.

Op z'n minst de API openstellen en de consument laten uitmaken of ze van flux of Apple feature gebruik willen maken.

Ga je echter dat pad in, dan moet je je ook afvragen of ze dan niet ook de browser technologie helemaal open moeten gooien (alles is nu onder water Safari meen ik op iOS). Ik denk dat Apple daarom daarin heel voorzichtig is. Voor je het weet bevind je je op een hellend vlak :)
Waar heb je het over? Ten eerste bestaat 'iMaps' niet. Ten tweede, concurrentievervalsing is nooit een issue geweest m.b.t. Apple Maps. Het is Google die een tijdje geen iOS app had, toen Google die wel had werd deze direct zonder problemen toegelaten in de AppStore.
Het ging me om het punt dat apple er een handje van heeft om zelf functionaliteit te ontwikkelen die anderen al eerder gemaakt en hebben en dan de competitie toegang tot de appstore te ontnemen of te weigeren om ongrijpbare gronden. En apple heeft wel heel ten degen google tegengewerkt toen ze met hun maps app kwamen.
De toegang is niet ontnomen, de toegang is geweigerd. De gronden zijn niet ongrijpbaar, de regels zijn vrij transparant. Daarnaast zijn de regels in dit geval goed verklaarbaar: Apple geeft 3rd party ontwikkelaars geen toegang tot low level API's, en dat is hun goed recht.

Tot slot heeft Apple Google echt nooit tegengewerkt. Geen idee hoe je hier bij komt. Ik zou graag een bron zien die je toelicht. Toen Google hun app klaar had, kwam deze gewoon zonder problemen in de AppStore. Dit zuig je gewoon uit je duim.

[Reactie gewijzigd door TMC op 15 januari 2016 13:24]

Dus Google mag inmiddels Chrome voor iOS uitbrengen die hun eigen rendering engine gebruikt?
Nee, maar wat heeft dat ermee te maken?
Mja.. Google's eigen rendering engine, dus eigen API, precies wat Apple niet toestaat aan ontwikkelaars. Dus ook niet aan Google. Kun je dus niet als argument gebruiken om te bewijzen dat Apple Google tegenwerkt.
Het maps debacle had te maken met de teleurstellende kwaliteit van de Maps app tijdens release en had verder niets te maken met het niet meer standaard meeleveren van Google Maps. Google Maps kon (en kan) gewoon nog ge´nstalleerd worden.

Waar het hier om gaat is een App (f.lux) die nooit beschikbaar is geweest op IOS, die toegang wil tot bepaalde low level API's. Dat laatste staat Apple nu niet toe en ik denk niet daar in de toekomst verandering in gaat komen. Dat men de functionaliteit die f.lux biedt standaard in IOS gaat inbouwen doet hier verder naar mijn mening ook niet echt ter zake. Het zou eerder nog een reden voor Apple zijn (hoewel ze dat nooit zouden toegeven) om f.lux nog steeds niet toe te laten op IOS.

[Reactie gewijzigd door Tjoekie op 15 januari 2016 11:38]

Het maps debacle had te maken met de teleurstellende kwaliteit van de Maps app tijdens release en had verder niets te maken met het niet meer standaard meeleveren van Google Maps. Google Maps kon (en kan) gewoon nog ge´nstalleerd worden.
Apple Maps is er gekomen als gevolg van een dispuut over Google Maps turn-by-turn navigatie.
Van Google mocht dat alleen als Apple meer gebruikers informatie ter beschikking stelde.

Steve Jobs antwoord (op zijn typische manier)
" We did not enter the search business. They entered the phone business. Make no mistake they want to kill the iPhone"

En tada Apple Maps was geboren.

Pas veel later is Google teruggekomen op z'n standpunt vandaar de iOS versie van Google Maps nu ook turn-by-turn navigatei heeft.

[Reactie gewijzigd door Carbon op 15 januari 2016 13:04]

Wow Apple heeft letterlijk f.lux gekopieerd. Niet dat het slecht is, ik kan niet meer zonder op mijn telefoon/tablet/gsm. Het werkt echt fijn, vooral 's nachts.

Maar wel raar dat Apple het zonder enige vorm van compensatie of op zijn minst vermelding kopieert en hun nog steeds niet de kans geeft om in de app store te komen.
Dat is niet raar. F.lux is gestoeld op een extreem simpel principe wat iedereen kan implementeren.

Apple heeft al sinds jaar en dag het beleid om apps geen toegang te geven tot low level API's. Dat beleid heeft ten grondslag gelegen aan het succes van iOS, de AppStore, de iPhones en dus ook Apple als geheel. Waarom zouden ze dat gaan veranderen?
Wow Apple heeft letterlijk f.lux gekopieerd.
1. Onderzoekers komen erachter welk invloed het blauwe licht van m.n. LED schermen heeft.
Voor de hand ligende oplossing! Verlaag de intensiteit van het blauwe licht.

2. Er verschijnen diverse implementaties (waaronder f.lux).

3. En nu volgt Apple

Van letterijk kopieren is helemaal sprake!
Maar wel raar dat Apple het zonder enige vorm van compensatie of op zijn minst vermelding kopieert
Als er al iemand gecompenseerd moet worden dan zijn dat de onderzoekers.
en hun nog steeds niet de kans geeft om in de app store te komen.
Dergelijke functionaliteit is globaal en heeft invloed op alle apps maw gaat niet gebeuren.
Mooi praktijk voorbeeld heeft een andere tweaker al gegeven, de RaboScanner werkt niet met f.lux wel met de Apple implementatie..

[Reactie gewijzigd door Carbon op 15 januari 2016 13:42]

Dit komt me heel bekend voor, een OS bouwer die ingeboude API's niet vrijgeeft en enkel zelf gebruikt. Alleen is het nu tegen Apple en op een enkeling na wordt er niet moeilijk over gedaan.
Ha, een sneer naar Microsoft? Je beseft toch dat OS X en iOS (net als Windows) al sinds jaar en dag APIs hebben die andere niet zomaar mogen gebruiken en die dus binnen de muren van respectievelijk Apple en Microsoft blijven. Heck, zelfs Android heeft verschillende van dat soort APIs. En zo is het met ieder ander stukje software: Facebook, Google, Snapchat, YouTube, Instagram, WhatsApp, Chrome, etc., etc. zitten allemaal stokvol met APIs die niet zijn gedocumenteerd.
Ja was het maar niet zo zeer naar MS, in het verleden werd er verdome moeilijk gedaan dat MS API's voor zichzelf hield. Terwijl het overduidelijk is dat iedereen dit doet (En dan doel ik ook weer op andere comments over de niet-openheid van f.lux)
Ik kan me niet herinneren dat er tegenover MS ooit moeilijk over werd gedaan. En evenmin bij Android of iOS. Volgens mij is het gemiddelde inzicht daarin gewoon te laag. De meeste mensen weten amper het verschil tussen hard- en software. De term Android-hardware is daardoor normaal geworden, hardware die hangt aan specifieke software. Nooit hoor je iemand zich afvragen waar dat op slaat.

Maar dichtgetimmerde API's zijn imho pure noodzaak. De mogelijkheden van de computer zelf gaan tegenwoordig meestal veel verder dan wat het OS met API's toelaat. Dit aan de consument 'weggeven' zou de hele markt vernielen. Dan kan ineens veel te veel op hardware die economisch al lang over de top is. De meeste bedrijven in deze sector zitten daar echt niet op te wachten. Dan moeten ze echt iets nieuws verzinnen.
Dit verhaal is daar op zich een redelijk voorbeeld van. Sinds wanneer heeft grafische hardware "specialistische" programmatuur + een API nodig om de kleur blauw in de schermoutput te regelen? Voor een beetje GPU is dat toch kinderspel voor alle kleuren?

[Reactie gewijzigd door blorf op 15 januari 2016 15:53]

Over gesloten API's is wel degelijk gezeur geweest, bovendien hoeft de minder ingevoerde tweakert daarvoor in feite niet te begrijpen hoe het precies werkt: Die klaagt meer over de effecten. Uiteindelijk is het ook een beleidsmatige beslissing.

Ik stoor me ook aan allerlei dom taalgebruik maar soms is er ook wel wat te zeggen voor creatieve oplossingen. Android-hardware bestaat zuiver technisch gezien niet maar het is wel praktisch kort omschreven wat je bedoelt. En hoe vaak zal een tablet die gekocht is met Android al ge´nstalleerd, van een ander systeem worden voorzien?

Wat betreft API's dichttimmeren want "Dan kan ineens veel te veel op hardware die economisch al lang over de top is.", dat suggereert dat je iPhone 3GS ineens alles kan wat je iPhone 5S kan, ik denk dat dit in de praktijk niet zo is. Juist met iOS werkt oude hardware nog heel lang. Je kan er veel van zeggen zoals duur etc maar het wordt goed bijgehouden en geoptimaliseerd.

Wat betreft het implementeren van een blauwfilter: Natuurlijk kun je dat wieltje door elk appje opnieuw laten uitvinden, maar gezien je kennis van zaken begrijp je ook wel dat dat een rommeltje wordt. Elke keer als je van app wisselt, moet die app precies hetzelfde blauwfilter toepassen. Alleen al om de instellingen niet per app opnieuw te moeten doen, zou een API veel handiger zijn.
Het is het meest recente nog gebruikt in de browser oorlog een paar jaar geleden, dat Google en Mozilla liepen te miepen dat IE9 sneller was "vanwege MS only API's" en dat hun daar ook bij wouden komen. MS Office en Open Office hebben hier vele jaren geleden nog publiekelijk over lopen bekvechten. Zelfs de Extended-MAPI die door Outlook en Exchange gebruikt worden (wegens gebrekige standaard API) is nog moeilijk over gedaan.

Kan zijn omdat ik met 1 been in het water bij Linux sta dat ik dit meer tegen gekomen ben.

Ik vind de closed API's ook niet meer dan normaal, niet alleen laat je dan zaken toe die je de consument niet met de PC wilt laten uitvreten, veiligheid is vaak ook een kwestie. Tevens vanuit Windows (heb hiervan geen ervaring in andere OSen) zijn de ongedocumenteerde "features" juist de API's die door de Windows (en zelfs SP) releases heen stuk gaan. Waar ze dus express derde partijen gewoon niet bij willen laten komen.

Voor de rest zie ik de API's juist weer wat meer direct naar de hardware gaan. Je kan op Windows, Linux (OSX e.d. ook wel) ook gewoon rustig de gehele API omzeilen en in assembly bezig gaan en doen en laten met je hardware wat je wilt. En in het geval van Windows is de systeem load van de API's juist de afgelopen jaren enorm afgenomen. OSX weinig ervaring mee, maar daar lijkt OSX met elke release weer net wat zwaarder te worden. Terwijl Linux sinds het begin eigenlijk altijd lichtgewicht gebleven is.
" OS X en iOS (net als Windows) al sinds jaar en dag"
onzin, noem me 1 geheime API die sinds Windows 2003 nog in Windows aanwezig is? Sinds de ".NET server", later toch maar Windows 2003 genoemd, is Microsoft daarvan af gestapt.
Het wordt dan ook eens tijd dat f.lux zijn software open gooit. Zo is het op de pc geheel niet mogelijk zelf een scriptje te schrijven dat f.lux op bepaalde tijden aanstuurt. Je zit geheel vast aan de beperkte instel mogelijkheden die standaard aangeboden worden. Dat betekend dat ze met zonsopgang en ondergang aan een uit gaat, maar bijv om 10:00 een graadje donkerder zit er niet in.
Ik moet ook zeggen dat ik nogal verbaasd ben over hoe gesloten F.lux eigenlijk is. Ze hebben ook voor strenge bewoordingen in hun licentieovereenkomst gekozen en houden het ontwikkelproces kennelijk achter gesloten deuren. Dit is door en door een commercieel bedrijf, ook al proberen zij dat imago niet uit te dragen.
Night Shift Devices (iOS 9.3)

Night Shift is a feature in iOS 9.3, but as it turns out, it isn't a feature that's available on all of the devices able to run iOS 9. Night Shift requires a 64-bit processor, which encompasses the A7, A8, A8X, A9, and A9X. The iPhone 5s and later, the iPad mini 2 and later, the iPad Air and later, the sixth-generation iPod touch, and the iPad Pro can be used with Night Shift.
Wat is dat nou weer voor vage beperking? Waarom zo een dergelijk "simpele" feature een 64bit processor nodig hebben. Ik ben echt blij dat ik na de iPad 1 gestopt ben met Apple producten, deze artificiŰle beperkingen slaan nergens op. iPad 1 kreeg ook na iets meer dan een jaar al geen updates meer.
Dit zal wel een -1 krijgen, maar wat fucking typical weer van Apple. Een app weigeren omdat ie niet gebouwd is zoals zij vinden dat dat moet. JA het is hun AppStore, maar het is niet hun app, de iphones zijn niet van Apple, en de AppStore is de enige legitieme manier om aan een app te komen.

Dit is machtsmisbruik. Meer niet.
Het is wel Apple's architectuur/platform, en Apple beheert dat behoorlijk strak en consequent, en dat is ÚÚn van de redenen dat ik iOS een uitstekend platform vind. Als je een beetje de principes van iOS begrijpt, zou je inzien dat de App een aberratie is volgens de principes van iOS. Apple is gewoon heel logisch en consequent, dat heeft niets met machtsmisbruik te maken maar met het is eigenlijk hun verdomde plicht om te zorgen dat het geen zootje wordt.
Behalve dan dat ze zich als dictators gedragen tegenover developers. Je maakt een app, die prima werkt, die niets doet wat voor een gebruiker boven de wet gaat, en Apple weigert em. Alleen maar omdat ze dat kunnen.

Dat heeft niets te maken met een wonderschoon platform, dat heeft alles te maken met machtsmisbruik. Apple vindt het geen coole app, dus komt-ie er niet door. Zo simpel is het. Developertje pesten.
Ik ben het absoluut niet met je eens: Apple heeft richtlijnen en normen voor applicaties. Een developper heeft zich daar aan te houden. Als hij dat niet doet, moet hij maar elders gaan knoeien. Dat doet Apple inderdaad behoorlijk consequent en goed. En daarom is iOS nog altijd het platform met de meest kwaliteitsvolle apps.
Behalve dat iOS zo'n groot platform is, dat Apple min of meer de plicht heeft om tot in redelijkheid toe te laten wat er gebouwd wordt. Dus alle apps toelaten die niet iets doen wat tegen de wetten is. Apple heeft een absolute monopolie op het verspreiden van apps op iOS, en zou daarmee bepaalde plichten moeten krijgen en bepaalde rechten moeten verliezen.

Open is het platform zeker nog niet. Niet dat dat ooit gaat komen, want Apple de controlfreak, maar apps weigeren omdat ze vinden dat het niet zo'n leuke app is, gaat echt te ver. Apple is een distrubuteur, feitelijk. Ze hebben niets te maken met de relatie tussen developer en gebruiker.
Ik vind helemÓÓl niet dat Apple "alle apps moet toelaten die niets doen wat tegen de wetten is", integendeel. De waarde van het iOS platform is net dat Apple het redelijk goed bewaakt en dat de eerste de beste idiote developer daar niet zomaar gelijk wat kan op gooien. DÓÓr betaal ik een premium voor als klant, en dat betaal ik graag. Wat jij vraagt te veranderen, is net wat het platform zo waardevol maakt - ook met name voor de developers die zich wel aan de regels houden en daar goed aan verdienen, net omdat het iOS platform is wat het is.

Apple heeft overigens helemaal geen monopolie: als je geen iPhone wil, kan je 1000en andere modellen telefoons kopen.
Apple heeft een monopolie op het iOS platform. En als developer is de AppStore (dus) de enige legitieme manier om je app te publishen.

Speaking of which, jij betaalt helemaal geen premium. Jij betaalt gewoon een hoge aankoopprijs voor een mainstream telefoon. Het zijn de developers die moeten betalen om iets op de AppStore te zetten. Feitelijk dus betalen om ingeperkt te worden. En de enige reden dat ze het zo doen, is omdat niemand ze durft aan te klagen.

Zie ook KPN bij ons. Het telefoonnet is van hun. En toch moesten ze het openstellen. Zie ook Microsoft: Windows is hun IP, maar toch moest het opgesteld worden voor developers, en wel gratis.
Je begrijpt niet waarover het gaat blijkbaar: Apple heeft normen die gelden voor alle developers. Die normen bewaken de kwaliteit van het iOS platform en de kwaliteit van de gebruikerservaring op de iDevices. Die normen zijn legitiem, verhogen de kwaliteit en daarom ook de waarde van de Apple toestellen, maar ook de waarde van de applicaties op het platform. Met andere woorden, de developers op het platform verdienen meer geld dankzij die normen en regels.
Apple weert zelden developers, en als dat wel gebeurt is dat wegens het overtreden van voorwaarden die voor iedereen gelden. Apple weert vaker applicaties, en dat is altijd omdat die niet aan de normen voldoen.

Dat developers (een developer account) moeten betalen vooraleer ze iets op de AppStore te zetten werkt ook kwaliteitsverhogend: als een developer niet een paar tientjes over heeft om te investeren in zijn applicatie(s), betekent dit dat hij geen vertrouwen heeft in zijn product(en) en kan het beter ook niet op de AppStore komen, want dan is het ongetwijfeld troep.

In jouw denkwereld betaal ik inderdaad een hoge aankoopprijs voor een hoop hardware. Ik mijn denkwereld betaal ik een hoge aankoopprijs voor een uitstekende gebruikservaring - en dat betekent goede hardware, goede software en goede processen die er voor zorgen dat mijn telefoon altijd up-to-date software heeft, dat ik een goede support heb, en dat ik in de App Store betrouwbare en coherent werkende applicaties vind. Als je dat allemaal niet kan waarderen kan je inderdaad beter geen iPhone of een iPad of wat dan ook van Apple kopen.

Overigens staat het developers vrij om:
- een gratis developer account aan te maken;
- alle ontwikkeltools gratis te downloaden;
- een app te schrijven die zo goed of zo crappy is als je maar wil;
- die te sideloaden op hun eigen iPhone;
- die App te verkopen buiten de App Store om te verkopen aan anderen, zodat deze via sideloaden kan ge´nstalleerd worden.
Heel veel geblaat van Apple, maar het komt erop neer dat ze je beperken op het enige platform waarop je legitiem kunt publiceren, en ze komen ermee weg. Het is machtsmisbruik, controlfreak, terwijl de gebruikers hebben al genoeg betaald voor een glimmende shit-foon.

Sorry, maar je gaat iemand die een hekel aan Apple heeft, niet overtuigen van hoe restrictief de appstore voor zowel gebruikers als developers is. Het staat bomvol met achterlijke troep en betaalde shit-rommel, maar een echt handige app komt er niet door. Sorry hoor, maar waar de fuck is Apple dan mee bezig?!

Ohja, puur eigenbelang. Geld. En zoveel mogelijk touwtjes strak trekken. In elk geval zolang ze geen straf krijgen.
Ha, de aap komt uit de mouw: je voert geen rationele discussie op basis van argumenten, je bent gewoon een gefrustreerde loser die behoeft heeft om ergens zijn gal over te spuwen. Je doet gelukkig niemand kwaad. Anderen trekken in jouw situatie naar SyriŰ. Of naar Parijs om zich op te blazen.
Dat kan ik van jou ook zeggen. Maar dat doe ik niet, want ik ben rationeel genoeg om niet meteen een pesoonlijke aanval te beginnen. Toedels!

[Reactie gewijzigd door _Thanatos_ op 23 januari 2016 19:54]

Je bent helemaal niet rationeel, je hebt blijkbaar heel erg negatieve gevoelens over zaken en mensen en bedrijven waar je in se niets mee te maken hebt. Dat heet frustratie en is ook wat mensen drijft om zichzelf op te blazen.
Tja, daar heb je patenten voor, enige manier om Apple te verslaan. Op hun eigen platform maak je ze sowieso niks."Patent pending" staat er te lezen bij f.lux, ik hoop dat ze het goed geregeld hebben. No access to api is no access for Apple zou ik dan redeneren als het patent binnen is.
Vraag is zowiezo of je het aanroepen van een API kan patenteren?
Nee, maar het gebruik van die specifieke API op een bepaalde manier wel.
Dat is nu nog in onderzoek of dat wel te patenteren valt, omdat het eigenlijk een beetje raar is. Oa Oracle v Google in de VS gaat daar nu over.

Je kunt de techniek zelf wel patenteren, waardoor de functie die Apple zelf uitbrengt mogelijk inbreuk maakt op de patenten van de derde partij. En dat wordt interessant.

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True