Apple accepteert vanaf eind april alleen apps gemaakt met Xcode 13

Apple accepteert vanaf 25 april in de App Store enkel nog iOS-, iPadOS- en watchOS-apps die gemaakt zijn met Xcode 13. Die versie kwam in september vorig jaar uit en bevat de sdk's voor iOS 15, iPadOS 15 en watchOS 8.

Door Xcode 13 te verplichten, zijn alle nieuwe apps die vanaf april aan de App Store worden toegevoegd, compatibel met de nieuwste versies van iOS, iPadOS, watchOS, tvOS en macOS. Oudere versies blijven echter ook ondersteund.

Met het gebruik van Xcode 13 krijgen ontwikkelaars toegang tot de nieuwe features van iOS 15, iPadOS 15 en watchOS 8. Volgens Apple levert het potentieel ook betere prestaties op. Apple bracht de eerste versie van Xcode 13 vorig jaar in september uit. Inmiddels is de ontwikkeltoolkit bij versie 13.3 aanbeland. Die update verscheen op 14 maart.

Reacties (36)

[J2S]

Begrijp ik het nou goed en heb je geen keus in IDE als je voor Apple wilt programmeren?

[h3x4d3c1m4l]

Wij gebruiken op de zaak Flutter voor onze mobiele apps, en programmeren daarmee op Android Studio of VS Code, beiden werken prima.

Debuggen op de iOS-emulator of op een fysiek iOS/iPad-toestel kan ook gewoon vanuit die twee IDE's, wel alleen op macOS overigens. Op de achtergrond wordt er Xcode gebruikt om de app te builden, maar je hebt zelf weinig tot niets met Xcode te maken tijdens het ontwikkelen.

Het releasen van je app naar de AppStore is een ander verhaal. Dan heb je wel direct Xcode nodig of de command line tools van Xcode (bijvoorbeeld voor het automatiseren middels CI/CD).

[BikkelZ]

Je kunt ook bijvoorbeeld AppCode gebruiken. Maar de Command Line tools zijn verplicht voor Apple platformen. Wel kun je Swift ook onder Linux en Windows gebruiken.

[Wolfos]

Niet verplicht. Adobe had ooit tools om iOS apps te kunnen builden op Windows.

[BikkelZ]

Ik weet het er fijne niet van maar om te signen en dergelijke moet er ergens een Mac zijn die Command Line Tools draait

[WhatsappHack]

Om enkel te signen niet perse, daar zijn third-party tooltjes voor op Windows. Om te publiceren naar App Store of TestFlight is echter een ander verhaal.

[Jakkie.be]

Om te signen voor LOB apps gaat dat idd op Windows en Mac. Resignen voor appstore moet altijd via Mac met Xcode command line tools en transporter of full Xcode.

[Travelan]

Niet echt, dat was voor PhoneGap waarbij je code werd geupload naar de server van Adobe en door hun werd gebuild en gesigned. Op een Mac waarschijnlijk dus :-)

[Snowfall]

Nee dat begrijp je verkeerd. Je kan gewoon elke IDE en elk framework gebruiken voor het ontwikkelen van applicaties. Het gaat er gewoon om dat Apple oudere versies van Xcode uitfaseerd zoals ze al jaren doen wanneer er een nieuwe versie is uitgebracht.

[Wolfos]

Je kunt iedere IDE gebruiken die je wilt voor ontwikkeling en de command line tools voor MacOS zijn ook los te downloaden. Het is alleen wel zo handig om Xcode te gebruiken voor deployment.

[NLkaiser]

Het artikel is niet helemaal juist, Apple verplicht vanaf april dat apps gebouwd worden met de ios 15 sdk (die komt meegepackt met xcode 13.x of de developer command line tools 13.x) wanneer je een andere dev tool zoals appcode gebruikt dan linkt deze vaak ook naar de command line tools.

[Snowfall]

Jeetje. Wat een nieuwsbericht. Dit is echt niets nieuws. Het gebeurt al jaren dat oudere Xcode versies worden uitgefaseerd. Vooral omdat Xcode gewoon standaard ondersteuning heeft voor alle OS versies die vanuit Apple worden ondersteund.

Net zoals Swift ondersteuning ook van Xcode ondersteuning afhankelijk is. Oudere Xcode versies ondersteunen niet de nieuwste Swift versie. Die ondersteuning komt altijd uit met een nieuwe versie van Xcode.

[DestroBan]

Groot gelijk, maar zelf ben ik heel blij dit op voorhand te lezen via Tweakers , aangezien ik standaard niet op mac werk, maar wel een app deploy op iOS, loop ik keer op keer tegen hetzelfde:

- Na maanden van ontwikkeling op Android: alles ok
- Laten we de iOS build doen om te zien of de cross platform zo goed is als ze beloven
- Build faalt door nieuwe requirement van Apple (meestal xCode)
- xCode updaten => build faalt door 1001 redenen (meestal combinatie van React-Native en xCode)
- Minimum 1 week extra development en/of devops werk

Handig dit op voorhand te weten

[Snowfall]

Handig dit op voorhand te weten

Het heet developer.apple.com en of email. Dit soort keuzes krijgen developers vaak weken of maanden van tevoren al via de mail te horen

[DestroBan]

Veel te kiezen is er niet aan Maar zou inderdaad op de hoogte kunnen blijven door al hun mails te lezen. Echter, het account is daar gekoppeld aan algemene software-email van het bedrijf en je kan niet zo maar gratis extra accounts toevoegen zoals bij Google. Ik zou inderdaad tussen de 100-den mails kunnen dit beginnen opvolgen of rules voor het door te sturen, maar er zijn zo ongeloofelijk veel zaken die ik moet bijhouden en opvolgen dat er geen houden aan is.

[readefries]

Je kunt gewoon developers toevoegen aan je Apple Developer portal. De enige limiet die er is, is een soft limit van 100 devices. Maar die kun je ophogen door contact op te nemen met Developer Relations.

[karel97]

Tweakers is juist een nieuwsplatform (en meer) waardoor je niet continue op allerlei website hoeft te gaan zoeken naar updates & nieuws.

Niet alle info is relevant voor iedereen. Dit heeft wellicht geen betrekking op jou, maar is juist weer relevant voor andere & visa versa met met andere nieuws artikelen.

[!GN!T!ON]

Bijhouden wat er gaat gebeuren met tools en applicaties die zakelijk gebruikt en afhankelijk van bent via random nieuwssites... juist ja...

[Wolfos]

Ik heb hier geen mail over gehad hoor.

[nemsiz]

Sorry hoor maar dit ligt gewoon aan je workflow als je na maanden ontwikkeling pas gaat testen op een van de platformen waar je voor ontwikkeld.

[DestroBan]

Zeker waar... Maar ik ben hier begonnen als programmeur voor de backend en het webportaal. Ondertussen hebben we 6 java servers, 1 python server, 2 portalen, 2 apps die zowel op iOS als Android moeten werken en Bluetooth gebruiken, een IoT server, en 2 soorten BLE hardware devices... Buiten de embedded development / hardware devices ben ik voor alles alleen verantwoordelijk, inclusief AWS, devops, support, analyse, development, testing, QA, security, regulatory, on-prem HL7-koppeling in ziekenhuizen... en dat voor een medical device met ISO certificering, dus onder hevige regulering... Maak daar maar eens een goede workflow van Gelukkig is er recent eindelijk een collega ter versterking gekomen.

Dat iOS deployment lastig doet is ambetant, zeker voor de tijdsinschattingen, maar ook least of my worries...

[bzzzt]

Een weekje tijd nodig om iOS bij te werken na maanden aan een app op alleen Android gesleuteld te hebben klinkt eigenlijk helemaal niet verkeerd. Misschien handiger een teamlid tegelijkertijd op iOS te hebben zitten om dit soort 'verrassingen' te voorkomen.

Waarschijnlijk had je andersom hetzelfde probleem gehad bij het bijwerken van een voor iPhone ontwikkelde app voor Android.

[biteMark]

PICNIC Builds falen normaal gesproken niet zomaar omdat je Xcode (of beter gezegd ,de Xcode CL tools) hebt geüpdatet, het kan hooguit zijn dat je het pad van de Xcode CL tools ergens moet aanpassen maar normaal gesproken zou het geen abnormale build errors moeten uitkotsen.

Het kan een ander verhaal worden als de Xcode CL het eindstation is van je toolchain, wat bijvoorbeeld met React Native het geval is. Als de React Native build tools niet up-to-date zijn (of nog erger, niet aangepast aan de nieuwste versie van Xcode, wat je aan de React Native devs zou mogen weiten) dan krijg je mogelijk een output waar de Xcode CL niks mee kan, met allerlei rare build errors tot gevolg.

Over het algemeen is het aan te raden om je toolchains up-to-date te houden. Met Visual Studio 2022 kan ik mijn Xamarin.Forms apps prima compilen met Xcode 13, geen centje pijn na het uitvoeren van de Xcode en Visual Studio updates.

Waar ze bij Appel wél eens wat aan mogen doen is de onduidelijke errors die de Xcode CL soms uitkotst

[Carbon]

Laten we de iOS build doen om te zien of de cross platform zo goed is als ze beloven

Ik ben al meer dam 35 jaar actief als software developer en ik heb nog maar één framework gezien die die belofte waarmaakt voor desktop apps, en dat is Qt (C++)

React Native Flutter, Ionic, Electron etc... resulteren bij wat complexere apps al snel in een wirwar van platform afhankelijke (native) code en third-party dependencies.

De apps zelf zijn een compromis mbt de features die het onderliggende OS biedt, zijn merkbaar trager, gebruiken meer resources en houden zich vaak niet aan de UI conventies van het gebruikte platform

[Reactie gewijzigd door Carbon op 23 juli 2024 23:33]

[DestroBan]

Inderdaad. Wij ondervinden hetzelfde met React-Native. Zeker omdat we BLE gebruiken, wat een seriële communicatie-flow is en ingaat tegen react-native principes.

Maar ik moet wel zeggen dat React-Native al véél volwassener is geworden de laatste 4 jaar. Het draait stabieler, minder issues met builden / upgraden, etc.

Zelf ben ik wel heel benieuwd naar Flutter: als ik ooit eens een weekje tijd heb zou ik er graag eens mee experimenteren.

[Cluefull]

Het gelinkte artikel op developer.apple.com is van March 15, 2022. Heet van de pers, dus.

[mOrPhie]

Voordat men denkt dat je geen andere IDE's mag gebruiken: dat mag wel. De uiteindelijke (command line) build tool zit alleen bij xcode inbegrepen.

[robcoenen]

Overigens doet Apple dit ieder jaar medio maart/april (m.u.v. 2020 door corona):

2021 - Deadline 26 april
2020 - Deadline 30 juni (oorspronkelijk 30 april)
etc.

[Digital-DNA]

Ik weet nog wel toen met de update naar iOS 7 dat de UI ineens helemaal anders was. Dan gebruikte je expres nog een oude Xcode om met de iOS 6 SDK te builden. De app bleef dan ook op iOS 7 toestellen er uitzien als een iOS 6 app.

Op gegeven moment moet je er wel aan geloven je app om te bouwen natuurlijk.

[ari3]

Apple zou gewoon applicaties op basis van de JVM en JavaFX moeten toestaan. Het is van de zotte dat we verschillende frameworks moeten gebruiken voor Linux/OSX/Android/iOS/Windows als verreweg de meeste applicaties gewoon generieke UI-controls gebruiken.

[ro8in]

Apple laat gewoon applicaties toe gebouwd op allerlei frameworks. Het gaat enkel alleen om de uiteindelijke build code die moet met xcode gecompileerd zijn.

[stefanass]

Klopt, alleen staat dit niet (duidelijk) in het artikel, vandaar dat er in de reacties veel verwarring ontstaat (bij mensen die er zelf niet direct mee te maken hebben)

[Aaargh!]

Apple zou gewoon applicaties op basis van de JVM en JavaFX moeten toestaan

Alsjeblieft niet zeg. Er staan al genoeg matige apps in de store.

[Crazy D]

Android zou gewoon Swift moeten ondersteunen Het is toch van de zotte dat je op Android een ander framework moet gebruiken dan op iOS.

[Kusanagi]

Ik develop wel voor iOS, maar zit zelf nog op iOS13 xD Misschien toch maar eens met de tijd mee, opa...

[rgcreator]

Worden apps van thunkable dan ook niet meer goedgekeurd.