Say hello to try! Swift World. Instead of just one big conference, try! Swift World will be a continuous set of workshops taught by top Swift developers from around the World in a personal way. Each workshop will be limited to only 10 participants, so everyone has a chance to connect and get their questions answered. The first set of workshops will start on May 4th (May the 4th be with you!).
Lately, I've been thinking a lot about functional programming... in relation to life.
I started This Week in Swift for selfish reasons. In July 2014, Swift was still in Beta, Playgrounds would crash after only 100 lines of code, and we were all still super confused about Optionals... 150 issues later, it is time to end it...
For try! Swift NYC, we are playing with the idea of adding QR codes to conference badges that will add attendee’s contact information business card to your Wallet app...
I recently wrote about why I prefer not to use default implementations in Swift protocols. Here is how you can still optimize using a default implementation without the unintended side-effects...
Why I decided against a nice refactor...
One thing I’ve noticed recently in my code-base is that I tend to default to guard vs if. In fact, whenever I write an if statement, I facepalm myself and change it to a guard without thinking much. But that’s become a problem. There is in fact a difference between guard and if and thought does need to be put into which one to use.
A few months ago, I gave a talk titled Build Features, Not Apps at iOS Conf SG – you can view the full talk here. It was clearer than ever to me after WWDC 2016 that the future of apps is a web of distributed features instead of one concentrated app. Think of Apple Watch, Today’s Widget, Rich Notifications, App Search, iMessage Stickers, and the list goes on…
I've been trying to figure out how to reuse the same interface controller code for all my interface controllers in a watchOS paging navigation, and finally did. But this solution comes at a price...
The try! Swift app runs on both iOS and watchOS, and I’d like to expand it to support fancy extensions and possibly something with iMessage. While I was ok duplicating the Model layer between the two platforms initially, as more extensions and platforms are something I want to code quickly on, it was time to move that code out into a framework.