Gerucht: Apple wil universele apps die werken op iOS en macOS

Apple wil dat ontwikkelaars apps kunnen maken die zonder grote aanpassingen werken op zowel iOS als macOS. Dat schrijft financieel persbureau Bloomberg. Dat moet mogelijk zijn met de volgende versies van de besturingssystemen, die vermoedelijk volgend najaar verschijnen.

De bedoeling is dat iOS-ontwikkelaars vaker apps gaan ontwikkelen voor MacBooks en iMacs, schrijft Bloomberg. De auteur van het artikel, Mark Gurman, staat al jaren bekend om juiste informatie over onaangekondigde Apple-producten en -diensten. Behalve dat er nieuwe apps voor Apples desktops verschijnen, moeten met het nieuwe systeem huidige apps meer updates krijgen.

Afhankelijk van het apparaat kunnen apps dan werken met de input van een touchscreen of met toetsenbord en muis. Dat gaat vermoedelijk wel aanpassingen vergen in huidige apps, omdat die vaak gemaakt zijn met het kleine scherm van een iPhone in het achterhoofd. Wel zijn er al veel apps die werken op iPhone en iPads, met een aangepaste interface voor de Apple-tablet.

Apple zou niet de eerste zijn die het mogelijk maakt om zonder veel aanpassingen ontwikkelaars apps te laten publiceren voor desktops, tablets en smartphones. Microsoft doet al jaren met zijn Universal Windows Platform, dat onder meer werkt op Windows 10, Xbox One en Windows 10 Mobile. Google doet dat nog niet, al laat het wel Android-apps en de Play Store functioneren op Chrome OS-laptops.

De Mac App Store bij release

Reacties (102)

[jsaturnus]

Ik schrijf al mijn applicaties volgens het DDD (Domain Driven Design) principe. Daarbij heb je een strikte scheiding tussen de presentatie en het domein waarin alle bewerkingen plaats vinden. Applicaties worden er heel testbaar van. Maar het grootste voordeel is wel dat het domein steeds her te gebruiken is, terwijl de aanpassingen in de UI minimaal zijn wanneer je van OS of platform wisselt.

Eric Evans heeft DDD op de kaart gezet, en ook Martin Fowler is een DDD adept.

[Macshack]

Natuurlijk kan DDD je helpen om die scheiding te bevorderen. Maar ik zie daar meer correlatie dan causatie. Deze scheiding kan wat mij betreft net zo goed gerealiseerd worden door een meer SOA georiënteerde benadering (niet dat ze elkaar noodzakelijk volledig uitsluiten). Zo lang je jouw controller of viewmodel gescheiden houdt van je view is elke vorm van architectuur mogelijk. Of je nou services met anemic models gebruikt of meer een rich model benadering maakt volgens mij niet zoveel uit. Waar ik het meest mee worstel in relatie tot DDD is het streven naar het weerspiegelen van hoe het domein in de echte wereld opereert. Voorbeelden waar werknemers zichzelf een salarisverhoging kunnen geven of een bestelling dat zichzelf persisteert naar een datastore zijn mij niet ontgaan. Ook overtreedt, in mijn optiek, een rich model benadering het SRP principe. Je rich model heeft meer redenen dan één om te wijzigen omdat het meerdere verantwoordelijkheden belichaamd. Ik kan mij voorstellen dat jij hier heel anders naar kijkt en ben daarom erg benieuwd naar hoe jouw code er dan uitziet. Meeste voorbeelden die ik tot nu toe van DDD heb gezien zorgen er bij mij voor dat allerlei alarmbellen afgaan met betrekking tot code smells. Als je het leuk vindt zou ik hier met jou gedachten willen uitwisselen. Ik ben altijd nieuwsgierig en enkele ervaringen zijn voor mij nooit reden genoeg om een methodiek als DDD af te schrijven. Al is het maar, zoals bij veel dingen in het leven, het erg afhangt in welke context men software ontwikkelt.

[Reactie gewijzigd door Macshack op 23 juli 2024 20:41]

[jsaturnus]

@Macshack Ik herken veel van wat je schrijft. Zoals ik eerder al schreef zijn Evans en Fowler vaag in hoe de concrete implementatie eruit moet zien.
Ik moet eigenlijk zeggen dat het heel wat jaartjes heeft geduurd voordat ik een implementatie had waar ik mee kon leven. Ook ik heb lang geworsteld met de weerspiegeling van de wereld in het domein (en niet andersom zoals je schrijft)
Maar uiteindelijk zijn de dingen zoals ze zijn, m.a.w. het domein moet de echte wereld weerspiegelen.
Ook hoe TDD op DDD staat is iets waar ik wel even mee geworsteld heb.
Ik neem aan dat je het over SRP hebt (en niet over SPR), iets waar IMHO een klasse altijd aan moet voldoen. Dat staat eigenlijk los van DDD.

@fabrikater De detail zaken die je noemt komen eigenlijk pas aan de orde op het moment dat je het domein gaat inrichten. Domain Events is ook wel iets wat altijd lastig is. Vaak zijn implementaties afhankelijk van hoe je e.e.a. op het hoogste niveau (dus meteen na applicatie start) aan elkaar knoopt.

MVC en MVVM liggen er weer boven, die keuze maak ik vaak aan de hand van de taal waarin ik implementeer. De ene taal (en omgeving) leent zich nu eenmaal meer voor MVVM dan MVC. Bij XAML gebruik ik bv vaak MVVM, terwijl bij JAVA ik vaker voor MVC ga.

[fabrikater]

Ik denk dat je DDD veel te technisch benaderd.

[keeperson]

Op het moment van schrijven is DDD razend populair in de wereld van webontwikkeling. Facebook heeft een framework gelanceerd een aantal jaar geleden genaamd React. Hiervoor is een extensie geschreven genaamd Redux.

Het mooie aan Redux is dat het de ontwikkelaar in staat stelt om de data te binden aan verschillende componenten op een pagina of een applicatie. Terwijl de staat van de applicatie verdeeld wordt over alle componenten, houdt Redux één grote data "store" waar alle data netjes bijgehouden wordt.

De kracht en de crux van het Redux verhaal is dat het de ontwikkelaar in staat stelt om de data over ieder mogelijk component te verdelen die de data accepteert. Dit betekent dus ook dat je een Angular (een framework van Google) component kan voorzien van data of een React Native component. React Native is een framework dat de JavaScript applicatie die je schrijft omzet in machine code die je kunt draaien op zowel een iPhone als Android toestel, zonder té veel performance op te geven. Gedeelde back-end, maar aparte front-end.

[Sandor_Clegane]

Leg dit eens uit als je wilt. Want het logische domein kan natuurlijk technisch in een niet porteerbaar stuk code zitten.

[mcdronkz]

De logica die jouw applicatie van alle andere applicaties onderscheidt, de business logic, weet niets over infrastructuur en andere zaken die aan implementatie gerelateerd zijn. Dat is volledig van elkaar losgekoppeld. Dat stuk van de applicatie heeft er dus geen weet van of 't op een laptop, smartphone of arcade-machine draait en is hoe dan ook portable mits het fysiek op dat platform kan draaien.

[jsaturnus]

Het komt er in basis op neer dat je geen enkele UI code in het domein opneemt. Ook geen verwijzingen naar enige UI libs.
En je maakt de koppeling tussen het domein zo los mogelijk. Bij het starten van de App knoop je domein en UI aan elkaar, bij voorkeur over een interface. Waar mogelijk laat je de UI en domein in aparte threads lopen.

Je kunt vanuit de UI het domein vragen om data (een pull), maar mooier is om waar mogelijk vanuit het domein data naar de UI te pushen. Reactive (niet te verwarren met React) werkt dan heel erg mooi.

Daar waar je tegen porteer problemen aanloopt kun je eventueel facade klassen gebruiken om e.e.a. op hetzelfde niveau te brengen. Mocht de overgang zo groot zijn dat je met een facade niet meer weg komt kun je ook nog overwegen om het domain server based te laten draaien, en de UI op de client.

Evans en Fowler omschrijven het vrij abstract, maar als je eenmaal een praktische implementatie gevonden hebt werkt het echt heel fijn.

[Reactie gewijzigd door jsaturnus op 23 juli 2024 20:41]

[Sandor_Clegane]

Ok thanks. Je zou nu, bij het gebrek aan een Portable Class Library zoals in Xamarin of .Net alsnog je domein moeten porteren niet? Als ik het goed begrijp zijn de API's in iOS en OSX dusdanig anders dat het op het moment niet mogelijk is zoiets als een PCL, waarin je je domain specificeert, cross platform te maken.

[fabrikater]

Je kunt domain-driven design gebruiken bij iedere software-architectuur die een scheiding van UI met overige applicatielagen bewerkstelligt. Denk aan MVC, MVVM, etc. Hoewel domain-driven design absoluut bijdraagt aan zo'n scheiding, zou ik dit niet noemen als belangrijkte eigenschap.

Belangrijkere eigenschappen zijn:
- De ubiquitous language, ofwel de taal van business die terugkomt in zowel requirements, documentatie, software en testen. Iedereen spreekt dezelfde taal.
- Aggregate roots (objecten met identity) en Value objects (objecten zonder identity)
- Repositories (potjes met aggregates), UnitOfWork (denk transacties), Services
- Bounded contexts, de erkenning dat er binnen een domein verschillende contexten zijn, waarbij domein objecten in iedere context kunnen voorkomen, in soortgelijke maar veelal in een enigzins andere hoedanigheid. Een bounded context is bijna altijd een kandidaat voor een microservice die dan alleen die context afhandelt en ook zijn eigen database of schema heeft.

Mijn ervaring met DDD is dat developers vaak een aantal van de patterns implementeren, maar dat er zelden door een goede analist aan de ubiquitous language wordt gewerkt. Ook zie je zelden value objects of meerdere bounded contexten.

[Sandor_Clegane]

Dit is waar ik op doelde met mijn vraag. DDD ligt nog een stapje hoger dan wat hier in het nieuwsbericht besproken wordt in mijn optiek.

[Loller1]

Ik kan me nog herinneren dat Apple zei dat het idee van een universeel platform tussen smartphones, tablets en desktops onzin was en nooit zou werken. Die goeie oude tijd.

[Metro2002]

Een app maken die zowel op een 5 of 6 inch beeldscherm werkt en met dikke vingers bediend wordt als op een 24 inch beeldscherm die je met een precisie aanwijzer kan bedienen. What could go wrong.

[JaapN]

Microsoft doet dit toch redelijk goed met (het weliswaar beperkte aantal) UWP Apps, Groove Music bijvoorbeeld, schaalt prima mee waardoor het gewoon prima eruitziet en bruikbaar is op een monitor, net zoals met Edge bijvoorbeeld, als ze dit soortgelijk implementeren dan kan het prima werken.

MS werkt op dit moment ook aan CShell, volgens mij is dat ongeveer hetzelfde maar dan voor Windows in zijn geheel

[Verwijderd]

Apple gebruikt een intermediate language welke in de store verder wordt gecompileerd naar het target device, zij het OSX, iOS, WatchOS dan wel tvOS: https://developer.apple.c...Thinning/AppThinning.html
Dat is een andere insteek dan die van Microsoft waar developers de grootste gemene deler van de diverse API kunnen aanwenden voor een universele Windows app. Nadeel van die insteek van Microsoft is dat apps niet optimaal gebruik maken van de hardware die een device heeft waar dat bij de insteek die Apple er op na houdt wel het geval is.

[Verwijderd]

Ik kan me vinden in de omschrijving 'prima'.
De vraag is of je tevreden moet zijn met prima, ik denk dat apps die ontwikkeld zijn voor één specifiek platform veel sneller 'uitstekend' zullen zijn ipv 'prima'.

[teacup]

Tenzij Apple het platform echt gemeenschappelijk weet te krijgen. Door al het vallen en opstaan is Microsoft tot het inzicht gekomen dat naar een gemeenschappelijk platform moet worden toegewerkt. Het OS moet hiervoor modulair opgebouwd gaan worden om dit te bereiken. Hardware is te divers. Als ik het goed heb begrepen ligt de fase waarover ik nu praat nog voorbij die van Cshell en Andromeda.

In de huidige Windows en Apple OS-sen zou een app logger kunnen worden omdat die met de verschillende platformen rekening moet houden. Dan nog is het de vraag of dat voor de toepassing een probleem is.

[Verwijderd]

Leestip: https://developer.apple.c...Thinning/AppThinning.html

[dakathefox]

Niets eigenlijk. Ik draai al Android apps op Chrome OS en daarbij worden apps die niet geoptimaliseerd zijn voor tablets gewoon in een klein venster getoond.

Dit kleine venster is bovendien nog steeds groter dan mijn telefoonscherm is. Dat klikken komt dus wel goed.

[RobinJ1995]

Bij Android is het altijd al zo geweest echter dat UIs schaalbaar gemaakt moeten worden voor verschillende schermformaten. Volgens mij is dat bij iOS apps niet het geval, en werken die maar op een handje vol schermresoluties. Correct me if I'm wrong.

[johnkeates]

Dat is bij iOS apps wel het geval, maar de UI elementen zijn net als bij Android gemaakt om met de vinger gebruikt te worden. Je hebt op een desktop-OS met desktop-UI nog steeds muis-sized elementen met hints voor wat wel en wat niet actief is. Op mobiele systemen is dat toch anders, vooral ook op dat het vaak single-task oriented design is.

[Zeror]

Responsive apps. Hetzelfde zoals responsive websites werken. UI aanpassen aan het formaat beeldscherm wat gebruikt wordt.

[Reactie gewijzigd door Zeror op 23 juli 2024 20:41]

[Verwijderd]

Beter nog, adaptive apps: UI aanpassen aan de gebruikte invoermethode (grotere iconen op een touchscreen, etc).

[Zeror]

Precies dat. Kon er ff niet opkomen hoe dat heet.

[Stoelpoot]

Maar werkt dat nou echt goed voor dingen van desktopformaat? Bijvoorbeeld Photoshop feature-complete porten zou alleen maar een adaptive UI nodig hebben? Bij veel apps gaat het IMO over compleet andere principes.

[Zeror]

Niet alle apps zullen hier geschikt voor zijn natuurlijk. Vaak gaat het om kleinere apps zoals een agenda app ofzo.

[xouns]

Dit is beter dan andersom. En werkt op Windows al een tijd heel goed naar mijn mening.

[stefanhendriks]

zolang je voor elke device daar de juiste schermen voor maakt zie ik geen probleem. Zo kunnen er toch ook al apps gemaakt worden voor zowel iPhone als iPad?

[Iva Wonderbush]

Je bedoelt iets wat elke website tegenwoordig al moet kunnen?

[Verwijderd]

ChromeOS doet dit wel aardig anders, speel net zo makkelijk Heartstone op een 15,6 inch Chromebook als een 5 inch telefoon.

[Verwijderd]

Denk eerder dat in eerste instantie dat je voor macOS ook UIKit kunt gaan gebruike. Nu gaat hele interface via AppKit.

Als je UI vervolgens goed scheidt van de rest is het veel makkelijk om een universele app te bouwen. En dan kan je nog steeds een uitgebreidere interface voor de Mac maken. Nu moet je echt twee totaal verschillende apps maken en zou je je code onder de interface kunnen delen via een library. Dit zou het een stuk makkelijker maken.

[SG]

Beetje App past MVC of MVVC toe.
De Core van de App "Model" is waar werk wordt gedaan "Controller" is de gateway naar de "View" de UI kant. Die de-koppeling maakt mogelijk om UI gebeuren als module apart voor elke target te optimaliseren.
Dus het is niet dat van scratch het hele ding opnieuw moet maken.

Wil je dat goed doen dan vereist dat wel extra werk. In Xcode kan je dan ook Sjabloon kiezen met de voorbedachte rade van cross platform.

zelf aan bedenken hoe Music Theory Math libary opzet. Wat de Core van de app gaat gebruiken die elke platform gemeen schappelijk heeft.

Een andere aanpak is Reactive Functional programmering. Mogelijk nog beter voor mijn ideetje.

Daarnaast mijn app concept schaalt juist niet naar kleine scherm. Dus dan moet je die veel eisende Functies eruit hakken of beperkt vorm toepassen.

Een app waar je juist grote canvast intensief gebruikt of dingen toont die de ruimte moeten hebben. Is dat porten naar kleine iPhone lastig . De app zal dan toch een gereduceerde experience worden. Als je toch full port pakt kan je toch een mindere experience komen doordat het te friemelig klein wordt.

Andersom een app die van de iPhone komt krijgt meer canvas en daarmee kan je het uitbouwen geavanceerder maken.

Denk ook meer dat app dan recommended voor TVOS MACOS is en IOS iPad iets minder kan zijn iPhone plus nog reductie en iPhone maar je wel door met je app kan gaan. Soms heb net die lichte features nodig.

[Mellow Jack]

Geen idee hoe het zit op de iPhone. Ik gebruik Drawexpress diagram op mijn Chromebook. Het is wel touch gericht dus het duurde even voordat ik het onder de knie had maar het is het ultieme voorbeeld van hoe een redelijk complex programma kan werken. Nu is Android app ondersteuning vrij nieuw in Chrome OS dus mist Drawexpress wat tweaks en optimalisaties voor de muis/keyboard combinatie maar verkies het nu al boven ms Visio.

On topic: ik snap Apple wel, MacOS miste altijd wel een beetje de massa aan apps die Windows heeft en hiermee kunnen ze (hoewel niet geoptimaliseerd) in 1 keer miljoenen apps in het eco systeem. Voor mij is Chrome OS icm Android apps een ideale combinatie en kan me voorstellen dat een MacBook met iOS vergelijkbaar is

[SG]

Nou ik zie het zo. Kleine studio die een app ontwikkeld wordt hiermee gepushed om synchroon multi platform release te doen. Meer platformen houd ook in multi test traject voor elke target platform.
Naast UI ontwikkelen geoptimaliseerd voor elke target platform maar ook features implementeren met aanpassingen voor elke platform is voor kleine app ontwikkelaars extra werk.
En testen maakt de productie stuk groter. Daarmee kosten waarvoor gepland moet worden.

Kleine app ontwikkelaar zou om hun studio of kleine team niet al te zwaar belasten meer richten met single release platform waarbij kleine team kan focussen op die ene platform.

Als appgebruiker merk je van deze Productie planning niet veel van. Als de app bevalt en crossplatform app goed werkt en UI per platform goed werkt. Is deze app ontwikkelaar dus sucsesvol multi platform release gedaan.
Daar tegen zijn er dus ook andere dev die multiplatform juist in problemen komen.

Er zijn uiteraard al veel producties die gericht zijn op alle iOS platformen. iPhone en iPad
MacOS erbij vergt uiteraard een andere Project sjabloon met gedachte van architectuur en API gebruik met IOS en macos in de planning. Meeste dev gebruiken een van de vele framework die crossplatform probleem opvangen waarbij de dev minder met lowlevel platform abstractie bezig moet houden meer meer kan focussen op applicatie layer en UI design per platform.

Zo ben ik recent van Visual studio 2012/2015 naar 2017 cummunity edition overgestapt.
Waar er ook meer mobilie platformen ondersteund worden en Mac en Linux.
Unity er bij en installer voor Unreal

Mis nog steeds een UML tool die betaalbaar is net zoals de community edition van VIsual studio.

[Mellow Jack]

Het is geen multiplatform in de traditionele zin. Het draait dan in een iOS omgeving waarbij de API's vertaald worden van iOS instructies naar MacOS instructies. Qua architectuur hoef je hier niet iets compleet anders voor te verzinnen. Zoals ik al heb gezegd, kijk eens naar Drawexpress (iig beschikbaar op Android)... Het enige verschil is het ondersteunen van een muis/keyboard ipv de touch schermen van de tablets.

Natuurlijk verschilt dit per applicatie maar we moeten onszelf niet voor de gek houden. Het overgrote deel van de apps is helemaal niet speciaal of complex... Het vergt wel wat creativiteit van een ontwikkelaar

Edit: als jij de kleine dev bent en niet toevallig high performance game ontwikkelaar wil ik je het advies geven eens een ervaren software architect te vragen voor een analyse/advies. Een goede architectuur kan hier tegenwoordig goed mee omgaan. Dan focus je het team als eerst op 1 of 2 platformen maar je weet dat je basis goed is om uiteindelijk overall te gebruiken. Is je eerste release een succes dan ga je snel aan de slag

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 20:41]

[Jerie]

Front end backend. Dit soort dingen bestaan al zo lang joh. Je backend is een server, en je client praat met die server via een protocol als bijv HTTP(S). Die client's GUI kan vervolgens vanalles zijn. Ncurses, Qt, GTK, Metal2, web browser, etc.

[MrAndy9797]

What could go wrong? Dat mensen het zonder argumenten en ervaring al beginnen af te kraken...

Blij dat je Tweakers gebruiksvriendelijk kunt bezoeken op je desktop en smartphone. Maarja, what could go wrong?

[SG]

De website code detecteert platform en met die grote smartphone van tegen wording is 800x600 of FHD weergave geen probleem en dan wil je niet perse in mobile modus voor Smarttelefoons van 3 generaties terug met die amper HD formaat.

[bozotheclown]

Er zijn anders genoeg apps dezelfde code die beschikbaar zijn voor de IPhone, iPad en Mac dus je denkt er iets te beperkt over.

Ps. 24”? We hebben het niet over Windows, 27” is meer een Mac maatje😉

[Reactie gewijzigd door bozotheclown op 23 juli 2024 20:41]

[pieterdebie]

Als het web responsive kan zijn, waarom zouden apps dat dan niet kunnen?

[Mittchel]

Xamarin.Forms lukt het ook al mee ;-)

Beperkt though..

https://blog.xamarin.com/...g-macos-to-xamarin-forms/

[Reactie gewijzigd door Mittchel op 23 juli 2024 20:41]

[swing7wing]

Dat is inderdaad waar ik ook direct aan dacht!
Ze zijn bang dat zometeen iedereen met Xamarin applicaties gaat ontwikkelen voor iOS en macOS.

[Reactie gewijzigd door swing7wing op 23 juli 2024 20:41]

[1973booterror]

Heeft in het kort waarschijnlijk te maken dat UIkit (User Interface library) nu nog officieel 2 versie heeft, 1 voor iOS en 1 voor macOS.
Apple maakt voor zijn eigen software al gebruik van een UIkit welke universeel is voor iOS & macOS., deze zou dan ook officieel gebruikt mogen worden door developers.
Daarom zien de versies van bijv. Foto's op iOS en mac vrijwel hetzelfde eruit, omdat Apple al gebruik maakt van deze library.

En bovenstaande is natuurlijk, naast het al integreren van een Apple ARM SoC in de nieuwe mac's voor beperkte functies, een opzet voor het volledig overgaan op eigen processoren voor Mac.

[Verwijderd]

Hmm, ik stel me toch vragen bij de gebruiksvriendelijkheid van een app die zowel met muis/toetsenbord als via touchscreen bediend moet kunnen worden. Beide verseisen toch een verschillend ontwerp ter bediening...

Ik vond het persoonlijk altijd al een correcte beslissing om macOS en iOS gescheiden te houden (zowel software als de daaraan verbonden hardware).

[gjmi]

Het ontwerp kan nog steeds verschillend zijn.
Net zoals bij websites die een normale en “mobiele” variant hebben.

[WillySis]

Een apart mobiele website is niet meer van deze tijd. Normaal maakt men gewoon een responsive website. De verschillen tussen een klein en een groot scherm kunnen dan best groot zijn, maar je hoeft toch echt maar één website te onderhouden.

[gjmi]

Dat bedoel ik, voor de buitenwereld lijken het echter wel twee verschillende. Onderliggend is het dezelfde site.

[Verwijderd]

Apple kennende zullen er wel een aantal voorzieningen, guidelines en zelfs verplichtingen zijn om te vermijden dat er teveel rommel in de Appstore komt die niet goed werkt op dit of gene OS.

[Verwijderd]

Ja precies, ze leggen alles aan banden.
In de vrije wereld worden de slechte apps vanzelf kansloos. Dat mechanisme pushed developers kwalitatief goede apps te maken. Van bovenaf reguleren is dus volstrekt zinloos en ontneemt elke beginnende ontwikkelaar kansen.
Bovendien riekt het naar dictatoriaal gedrag en kun je alleen via de rechter je gelijk krijgen wanneer Apple een foute beslissing maakt zoals dat lang bij bijvoorbeeld Opera het geval was die hun web browser in de appstore probeerde te krijgen. Uiteindelijk won Opera deze rechtszaak.

[Verwijderd]

Goede software ontstaat niet vanzelf, daarvoor zijn standaarden en regels nodig. Het is niet voor niets dat Apple altijd al de beste kwaliteit van Apps heeft gehad en dat Google Apple daar meer en meer in volgt.

Bovendien hèlp je net beginnende ontwikkelaars met regels en richtlijnen: zij hebben concrete richtlijnen waarmee ze aan de slag kunnen. Apple heeft bovendien altijd al uitstekende ondersteuning qua documentatie en informatie geboden, zodat zelfs de meest beginnende ontwikkelaar meteen aan de slag kan voor het ontwerpen van een goede app.

Het resultaat van teveel "Survival of the fittest" kan je zien in de Play Store: heel veel crap, voor nu en dan een degelijke app. Als je een kwaliteitsvol ecosysteem wil, kan dat alleen door te zorgen dat er geen crap in je ecosysteem komt, en dus om te beginnen al niet in je App Store. Het is niet door de laagste gemene deler te zoeken dat je kwaliteit krijgt, maar net door te zorgen dat er een zo groot mogelijke gemene deler is. Kwaliteit creëert kwaliteit. Teveel crap doet middelmatige applicaties goed lijken.

[dakathefox]

Het werkt in de praktijk echter prima heb ik gemerkt. Je went er al snel aan.

[Verwijderd]

Kwestie van Model View Controller, Apple was hier een pionier in met de tech van Xerox Park (Smalltalk).

[jabwd]

Je kan al jaren heel simpel een app van macOS naar iOS poorten omdat op iOS en macOS je gewoon foundation kan gebruiken. Je moet welliswaar een nieuwe interface bouwen maar als je je backend, models etc., lostrekt van je interface en puur foundation only houd kan je heel simpel een app tussen de 2 ontwikkelen. Enige manier waarop ik apple dit zie veranderen is AppKit weggooien en UIKit poorten naar de mac. Jammer dat het artikel er niet op in gaat op hoeveel beter UIKit is dan appkit.

Zie Colloquy als voorbeeld. Ik heb het zelf ook met meerdere projecten geedan.

[Reactie gewijzigd door jabwd op 23 juli 2024 20:41]

[Sandor_Clegane]

Maar dit was toch juist not done volgens Apple? Vandaar het verschil in iOS en OSX?

[JustFogMaxi]

Precies, dat is wat ze altijd zeiden. Daarnaast, dit concept werkt zooo goed voor MS...

[Blokker_1999]

Het concept bij MS werkt zeer goed, maar daar heb je ook 1 enkel OS voor alle platformen. Hier heb je het ineens over 2 verschillende besturingssystemen die enkel een gemeenschappelijke oorsprong hebben.

[Sandor_Clegane]

Ik dacht me dat al te herinneren.....

Ah, je moet niet te kritisch denken.

[Blokker_1999]

Niet alleen dat. Hoewel iOS zijn roots heeft in OS X hebben beide besturingssystemen zich de afgelopen 10 jaar onafhankelijk van elkaar ontwikkeld waardoor de APIs op sommige gebieden gewoon incompatibel geworden zijn met elkaar (dezelfde API call maar andere argumenten). Kan je niet zomaar snel even rechttrekken.

[ZpAz]

Ik denk niet dat je letterlijk een iOS interface voor je neus gaat krijgen, maar dat je wel een desktop interface moet hebben voor je applicatie. Dingen als netwerkberichten versturen e.d dat kan dan natuurlijk wel gedeeld worden en hoeft maar één keer geschreven te worden voor beide platformen.

[Carbon]

Maar dit was toch juist not done volgens Apple?

Nope, Apple zag niets in het gebruik van de macOS desktop UI op een mobiel device,
Dit gaat over het omgekeerde, het gebruik van de iOS UI op een desktop.

btw Het al mogelijk om iOS apps te compileren voor x86 en te draaien onder macOS (iOS simulator)
Als Apple de iOS simulator als runtime beschikbaar maakt onder macOS, dan kun je een iOS app overzetten met een enkele recompile.

[Reactie gewijzigd door Carbon op 23 juli 2024 20:41]

[Sandor_Clegane]

Maar dan hadden ze net zo goed OSX kunnen gebruiken ipv iOs moeten maken.
Het is niet erg om op dingen terug te komen, voortschrijdend inzicht enzo.

[Carbon]

Maar dan hadden ze net zo goed OSX kunnen gebruiken ipv iOs moeten maken.

Wel goed lezen!

Apple heeft altijd gezegd dat de OSX/macOS UI is niet de juiste oplossing voor een touch device.
Daarom heeft Apple iOS ontwikkeld.
Dit artikel gaat om het omgekeerde, apps voor een touch device(iOS) gebruiken onder OSX/macOS
Zoals iedere iOS developer weet kun je iOS apps prima draaien onder OSX/macOS

[Reactie gewijzigd door Carbon op 23 juli 2024 20:41]

[jAnO!]

plaatje van de "huidige" mac store... op een niet zo huidige mac...

[Steenvoorde]

Aan de apps te zien, ook niet echt de huidige mac store.

[MiesvanderLippe]

De huidige store;

https://i.imgur.com/J7ImXe7.png

Ziet er veel moderner uit. Dat met die grijze balken doen we al een tijdje niet meer.

[Reactie gewijzigd door MiesvanderLippe op 23 juli 2024 20:41]

[pBook]

Het screenshot is niet echt 'De huidige App Store' maar de 10.6 Snow Leopard versie van zeven jaar geleden.

[t1mmy]

Wat is er veranderd in de tussentijd dan? Ik bedacht me namelijk het zelfde, maar kon me niks bedenken. De icoontjes in de boven balk zijn anders, I guess....

[MiesvanderLippe]

Zoals ook elder; https://i.imgur.com/J7ImXe7.png

[Exirion]

Vaak kost het platformonafhankelijk houden van dingen meer moeite dan het onderhouden van 2 versies voor verschillende smaken van een platform. Dat heeft zowel met design-aspecten als technische aspecten te maken. Universele apps voor iPhones en iPads OK, maar universele apps voor iPhones, iPads en Macs zie ik echt niet zitten. Een user interface design voor een desktop met muis of touchpad zit meestal heel anders in elkaar dan voor een portable touchscreen device. Als je gaat afdwingen dat die 2 dichtbij elkaar komen te liggen, krijg je zonder twijfel veel brouwsels die het 'net niet' zijn. Afgezien van software van de developers die toevallig een goed gevoel hebben voor het harmoniseren van het e.e.a., en appjes die weinig voorstellen en bestaan uit een paar views en knopjes die je overal kunt gebruiken.

[Rinzwind]

iPads apps zijn <> iPhone apps. Dat was en is een groot voordeel van de iPad. Geoptimaliseerde specifieke tablet toepassingen. Ook waar Windows de mist inging meermaals, al bij Windows Mobile (te klein priegel werk op handheld) en Windows 8+ (te groot/lomp op desktop).

[dakathefox]

Dat lijkt me niet alleen een gerucht, maar gewoon een logische stap waarvan we mogen aannemen dat ieder zichzelf respecterend bedrijf als Apple dat gewoon wil.