No final do ano passado, a Bloomberg lançou um rumor-bomba afirmando que a Apple estaria trabalhando num projeto interno chamado “Marzipan”, o qual consistiria em algum tipo de novo framework para desenvolvedores criarem apps que rodem tanto no iOS quanto no macOS. A grande expectativa era de que ouviríamos algo sobre isso nesta próxima Worldwide Developers Conference (WWDC), em junho.
Bom, temos boas e más notícias. A parte legal é que, citando fontes próprias, John Gruber confirmou ontem no Daring Fireball a existência de algum projeto desse tipo na Apple. A questão é o que podemos esperar dele e, principalmente, quando.
Indo diretamente ao ponto-chave da coisa, Gruber afirmou que esse rumor não é algo planejado para este ano, e sim para 2019 — provavelmente chegando no macOS 10.15 e no iOS 13. Ou seja, é bom já irmos ajustando as nossas expectativas quanto ao que será anunciado na WWDC18 e, sinceramente, algo me diz que essa informação não “chegou a ele” por acaso…
Adentrando na coisa em si, Gruber começa afirmando que o projeto na verdade *não* se chama “Marzipan”. Pessoas com quem ele tem contato envolvidas no desenvolvimento afirmam nunca nem ter ouvido esse codinome antes da reportagem da Bloomberg no ano passado; se ele realmente existiu, pode ter sido algo bem preliminar.
Além disso, as fontes de Gruber dão a entender tudo baseia-se numa espécie de API de controle declaratório — meio que uma forma de montar elementos da interface declarando-os (com seus atributos) de alguma forma similar, por exemplo, a como fazemos em HTML/CSS. A ideia seria universalizar esse processo, quebrando as grandes diferenças que existem hoje ao se construir apps para o iOS (com o UIKit) e para o macOS (com o AppKit).
Trocando em miúdos, todo o projeto está realmente de acordo com o que Tim Cook falou recentemente sobre a Apple não ter planos de mesclar o Mac com o iPad. Não se trata, nem de longe, de uma fusão dos dois sistemas; e sim, provavelmente, de algumas novidades que facilitarão o trabalho de desenvolvedores ao criar apps multiplataforma.
WWDC 2019 is shaping up to be huge, with a new iOS UI revamp, new UI framework for iOS & macOS, and what must surely be an announcement for the ARM transition for the Mac
— Steve Troughton-Smith (@stroughtonsmith) 1 de maio de 2018
Fica a dúvida: o que será que vem de bom aí, afinal, na WWDC18?
Atualização 01/05/2018 às 15:05
Questionado sobre as novas informações, Mark Gurman — da Bloomberg, autor original do rumor — rebateu:
Sounds like that‘s referring to a pair of separate projects (known alternately as “Amber,” “Infrared” and “Ultraviolet”) from the Swift team. Not the same as the iOS apps on Macs initiative. There are many moving pieces with a major multi-year, multi-step project like this. https://t.co/jXKa5vRTzi
— Mark Gurman (@markgurman) 1 de maio de 2018
Parece que isso refere-se a um par de projetos separados (conhecidos alternativamente como “Amber”, “Infrared” e “Ultraviolet”) do time de Swift. Não é a mesma coisa que a iniciativa de apps de iOS em Macs. Há muitas peças soltas para um projeto de vários anos e passos como esse.
This initiative likely intends to replace NIB files with Swift, linked to Interface Builder, which could allow developers to declare their UIs by hand or by using the existing visual tools, much like XAML on Windows.
— Mark Gurman (@markgurman) 1 de maio de 2018
Essa iniciativa provavelmente pretende substituir arquivos NIB com Swift, conectados ao Interface Builder, o que poderia permitir que desenvolvedores declarem suas UIs à mão ou usando ferramentas visuais existentes, tal como o XAML no Windows.
Com isso, já pipocaram algumas reações por aí — que não vou traduzir, até porque há coisas bem técnicas que só interessam mesmo a desenvolvedores:
Replacing NIBs with declarative UI via Swift sounds fascinating. It would surely do away with IBOutlets et al, and should make nib diffing much easier. I like the idea of being able to switch from IB's visual UI to a markup editor to make tiny changes
— Steve Troughton-Smith (@stroughtonsmith) 1 de maio de 2018
I’ve got a feeling that this is a prerequisite for bringing Xcode to iPad
— Louis D'hauwe (@LouisDhauwe) 1 de maio de 2018
I desperately want intermixing of code with IB conf. Machine-readable Swift (or ObjC – Xcode UI testing already does both) seems like a very Appley way of doing it.
— Zach Waldowski (@zwaldowski) 1 de maio de 2018
UI by Swift team… Yearly UI rewrites. Redraw times measured in seconds. redColor not available because its not colorblind safe. Sign me up! https://t.co/A5mzu7g4Fc
— Paul Haddad (@tapbot_paul) 1 de maio de 2018
Why would they do this? UI editors just spitting out code sucks, and the editor itself still needs a non-code description of the UI to load the UI into the editor. Nothing wrong with serializing and then deserializing interface objects, a la NIB files.
— Sean Ridenour (@s_ridenour) 1 de maio de 2018
The Swift language model hates delayed initialisation. Interface Builder nibs require delayed initialisation to function. Happy to hear of significant work-in-progress to fix that (coming from someone who vastly prefers UI-in-code than IB anyway). https://t.co/7OVlXKMjmh
— Benjamin Mayo (@bzamayo) 1 de maio de 2018
Em outras palavras, algo virá por aí mesmo. 😉