Waveboard was (en is nog steeds) de eerste applicatie waarmee je Google Wave op de iPhone kunt gebruiken. De ontwikkelaar was bezig met een update, die push notificaties en een Inbox-functie zou bevatten. Maar helaas ziet Apple de update niet zitten, omdat er gebruik is gemaakt van een framework met de naam Three20. Dit is een project van Joe Hewitt, de voormalige ontwikkelaar van de Facebook-applicatie voor de iPhone. Hewitt publiceerde een deel van zijn code, zodat andere ontwikkelaars er gebruik van konden maken.
Maar het blijkt dat daarbij ook private API’s worden aangeroepen en dat is voor Apple reden om een applicatie af te keuren. De manier waarop Apple hiermee omging was voor Hewitt ook precies de reden om uiteindelijk de handdoek in de ring te gooien. Hij meldt, dat hij in de loop van de tijd steeds herbruikbare code van de Facebook-applicatie aan Three20 heeft toegevoegd, zonder de consequenties te overzien. Nu hij met de Facebook-applicatie is gestopt heeft hij Three20 open source gemaakt en overgedragen aan de ontwikkelaarscommunity.
Bepaalde libraries van Three20 blijken niet door het App Store-goedkeuringsproces te komen, waardoor ontwikkelaars een risico nemen als ze de code in hun projecten gebruiken. De ontwikkelaar van Waveboard staat nu voor de klus om zijn code na te kijken en de applicatie daarna opnieuw in te dienen.
Via: @Holtwick (Twitter)
Taalfout gezien of andere suggestie hoe we dit artikel kunnen verbeteren? Laat het ons weten!
Offtopic, melden dat je de eerste bent voegt niets toe aan discussie.
Wat een onzin zeg..
Kijk, ik snap dat Apple de touwtjes in eigen handen wil houden. Hierdoor zijn ze natuurlijk ook succesvol 🙂
Maar hierin draven ze een beeetje door. Inbox en Push zou worden toegevoegd aan de app, leuke verbetering zou je zeggen. Maar waarom moet apple dit in godsnaam afkeuren? Omdat er gebruik wordt gemaakt van een onderdeeltje dat eigenlijk niet gebruikt mag worden. Maar waarom niet??? Apple wordt toch niet slechter van deze 2 nieuwe functies? Hun merk wordt toch niet aangetast? Hun uitstraling niet? Hun exclusiviteit niet? Nee, ze krijgen juist een slechtere naam door steeds zulke rare afwijzingen te doen.
De iPhone leeft op de community, maar in plaats van de community goed en respectvol te behandelen ontstaan er volgens mij alleen maar meer irritaties. Ik kan hier zelf niet over meepraten omdat ik niets te maken heb met het ontwikkelen van apps, maar als ik de verhalen zo lees dan wordt ik wel moe van apple.
Jammer, want push updates voor Google Wave zou ik wel een goede plus vinden! 😛
Regels zijn regels! Er moet ergens een grens zijn.
@:
betekent niet dat de regels goed zijn voor het merk Apple en de iPhone community
Aan de andere kant vind ik het niet erg dat dit waveboard overkomt. Als wave verder wordt uitgerold komt google zelf met een gratis app, dan kun je waveboard wegmieteren. Daarnaast ziet het er exact zo uit als de webversie. Zonder deze upadte voegt het dus helemaal niets toe.
Hoewel ik steeds minder enthousiast over Apple en hun beleid wordt hebben ze hier gelijk. Een programmeur weet dat je private api’s niet moet gebruiken doe je dat toch dan is dat jouw eigen probleem.
Uiteindelijk is iedereen daar bij gebaat want anders valt bij een nieuwe firmware alles om
Gonny, een iphoneclub nieuws applicatie voor de iPhone. Dat zou echt geniaal zijn 🙂
Waarom zouden die libraries private moeten blijven. Dat heb je bij OSX toch ook niet ?
@Niels:
Ik denk dat je niet begrijpt hoe een software platform werkt. Apple levert een OS met bepaalde functionaliteit, die aangesproken kan worden via een gedefinieerde interface (de API). Deze interface is vastgelegd en gedocumenteerd en de OS leverancier zal deze dus moeten blijven ondersteunen. Om het OS te kunnen maken en de afgesproken API’s te maken zal de OS bouwer gebruik maken van code, die wellicht interne interfaces aanroept om code te hergebruiken (Beter 1 keer iets in een bibliotheek zetten en aanroepen dan op 20 plaatsen (net iets anders) implementeren).
Deze interne code is, zoals de naam al zegt, intern.
Deze zal dus niet gedocumenteerd hoeven te zijn richting de normale ontwikkelaars en kan, als de OS bouwer dat nodig vindt, met iedere software versie veranderen.
Een voorbeeld: Een resultaten lijst is in v1 een normale lijst, in v2 een hash table.
Voor de bovenliggende API, die gewoon de gevonden gegevens wil hebben en dat ook aangeleverd krijgt via de API, geen probleem. Als echter code van de ontwikkelaar direct in deze resultaten lijst probeert te kijken, zal het niet meer werken. De hash table kan echter bijvoorbeeld 10 x sneller zijn en dat is voor iedereen leuk…
Daar het interne code is, hoeft de OS bouwer geen zeggenschap af te leggen richting de 3rd party ontwikkelaars, zolang ze de afgesproken API’s maar intact laten.
Het probleem is dus dat er gebruik gemaakt wordt van deze prive bibliotheken, terwijl die niet officieel geleverd zijn. Als ontwikkelaars ecter gebruik maken van functies, zorgt dat er opeens voor dat deze niet aangepast kunnen worden (of verwijderd), zonder dat dat impact heeft op de applicatie die er gebruik van maakt. Dit is voor de door de OS bouwer geleverde programma’s geen probleem, daarvan is bekend welke App gebruik maakt van een interne functie en deze zullen zijn aangepast. Echter, voor de Apps in de buitenwereld is dit niet het geval… Oftewel: App gaat stuk, OS bouwer krijgt de schuld. Als ze dit niet willen, moeten ze de API in stand houden, maar dat levert een probleem op voor innovatie en onderhoud. Als alle oude (Interne!) code moet blijven werken, inclusief de bugs waar mensen workarounds voor hebben gemaakt, krijg je een systeem wat steeds logger en groter wordt.
Om dit te voorkomen zal de OS bouwer dus niet willen dat ontwikkelaars gebruik maken van dit soort interne interfaces…
@Nmz:
Deze regel is dus juist zeer goed voor de community: Apple kan de interne structuur dus wijzigen en bijvoorbeeld opeens multithreading of GPU code toevoegen voor de interne implementatie van de code, waardoor deze beter/sneller/kleiner zal zijn, waar iedereen profijt van zal hebben. Kijk naar OS X: Iedere versie is sneller (en kleiner) geworden, omdat ze interne zaken anders oplossen. Dat had niet gekund als ontwikkelaars de interne code aanroepen….
@Jens Kortmeijer:
Zeker weten van wel.
Kijk maar in /System/Library/PrivateFrameworks/
Sterker nog, bij mij (10.5.8), staan er 128 PrivateFrameworks en slechts 82 publieke in /System/Library/Frameworks/ …
@yoenoesz: Beetje teveel FML’s gelezen?
Wat is er toch gebeurd met de slogan ’think different’. Alles wordt ingeperkt en tegengehouden. De vrijheid van de gebruiker neemt hierdoor ernstig af. Erg jammer.
@Niels:
Vergeet niet dat ontwikkelaar Storm8 door (mis)(ge)bruik van deze private API’s onder vuur ligt i.v.m. het naar de server sturen van het Iphone telefoon nummer.
Alhoewel ik ook baal van dat restrictieve beleid, vage criteria en slechte communicatie klopt die stelling in deze nog wel. Want alleen Apple handelt op deze manier; de rest van de markt niet. Dat kun je met recht different noemen.
@avdvee:
Vergeet het maar.
Ook andere OSen en programma’s die een plug-in architectuur hebben (Denk aan Photoshop) zullen dit statement hebben, anders kun je nooit de code van het OS/de applicatie wijzigen.
Heb je de illusie dat de nieuwe Windows Mobile Marketplace dit toelaat? Of een game die gaat draaien op een PS3/Wii/Xbox360?
Apple is hier niet de enige in.
@Pieter: heldere uitleg 🙂
Maar wat ik dan niet begrijp, als Apple volledig in haar recht staat om applicaties zo af te wijzen, waarom er dan zo vaak aandacht aan wordt besteed als er een app wordt afgekeurd. Dit moet dan toch niet echt veel nieuwswaarde hebben?
En de reden waarom de ontwikkelaar van de Facebook app stopt is dan ook vaag, omdat Apple hier dan niets fout zou doen en hij weet wat hij wel en niet kan gebruiken toch?