I don't know what happened inside Apple that caused their engineers to become so active on Twitter but I am a huge fan of it. When WWDC rolls around some of the most interesting and important information is just mentioned off the cuff on Twitter. So I took the time to collate what I think are some of the more interesting tweets.
This seems like the best tweet to lead with because we are only a week out from WWDC and I already feel that I'm being left behind because I haven't tried SwiftUI yet. Obviously this is an irrational fear but some part of me believes that if I am not a part of this charge I won't be able to truly understand it.
I am not a fan of this change but I'll be honest and admit that I don't know a lot about Z shell. I try to make my macOS environment as close to what the Linux distros I work with are out of the box so I don't have to install a bunch of software to feel at home. If you're constantly moving between and spinning up new servers it can be a real pain.
I have seen a number of people express confusion above what
some View does, usually in conjunction with the need to create conditional body content. Hopefully these tweets help steer you in the right direction.
This is one of the things that developers coming from UIKit are going to have the hardest time groking. We associate so much state with our UIView objects and even treat them as a source of truth but with declarative UI they are always to be a mirror of your models. When you get to this point the UI is an implementation detail and one that Apple can optimize to hell out of across all of their platforms.
My first thought was "this is a real cool technique" and then my mind immediately went to "how are developers going to abuse this to hide implementation details so that tracing code will be a major pain". This is a symptom of PTSD I bare from working at a company with 400 mobile developers.
I am 100% on board with breaking your data source out into its own class. Abstracting the addition / deletion of items and sections is also great. I am not a fan of using anonymous functions to generate the cells. It encourages information to bleed in from outside the data source. I'd rather you pass everything necessary to create the cells into the initializer and the data source is responsible for holding onto it.
The first of what I am sure will be many rough edges of bringing your iPad app to the Mac.
I can only imagine how many bugs this is going to cause for unsuspecting developers.
This could be another nasty little bug that sneaks in if you are not careful. Developers have always treated going to the background as meaning your app has been dismissed but that is no longer the case.
I swear Apple has changed the layout margins on table view cells every year.
Even though SwiftUI is the new hotness there is no reason to abandon the amazing workhorse that is CoreAnimation.
I'm sure there were valid reasons why this was written in C++ but I gotta admit I am disappointed that there doesn't seem to be a real push to build everything using Swift. If there are shortcomings in the language let's address them instead of falling back to C++.
There are many delightful little additions like this. Stuff that is small and somewhat insignificant that you rarely think about but are super happy to find when you do.
An excellent little cheat sheet for those of you migrating to Combine from RxSwift.
Apple's code samples mixed with Stack Overflow really do create a skewed vision of what iOS architecture looks like. I understand that you have to stay simple to teach someone but there is no clear path to learning higher level abstractions. I still believe the solution is getting people to test their code sooner. If developers just create one massive file they will quickly see how much of a pain in the ass that is to test and hopefully it will drive them to break their code up into smaller more focused chunks.
A great thread on the "Cryptography and Your Apps" session. This example of how easy it is to work with Secure Enclave really jumped out at me.
This will be super useful for collating the results of your tests across all of your projects. I can't wait to see the third-party dev tooling that sprouts up around this.
One less reason to use Fastlane.
Compilers doing God's work like always.
I know some people are going to be annoyed by some of the applications and tooling this breaks but I am always for prioritizing security first especially in this day and age.
As someone who has deprecated multiple iOS versions at Uber I echo Kyle's sentiments. I really want to use SwiftUI but at work it probably won't happen for three years at the minimum.
Speaking of Uber's scale...
It is little nuggets like this that give a glimpse of how you're going to need to fundamentally rethink stuff when using SwiftUI.
It isn't even just SwiftUI that will cause you to rethink your code. These Swift 5.1 language features are going to unlock whole new ways of solving problems.
Apple's accessibility game is on point like usual.
Super cool. I wonder if something like this will come to the App Store one day.
How...how is this useful?
If it can do this then a Magic Keyboard and Trackpad should be no problem.#WWDC