I saw a blog post making its way around iOS developer networks last week. It was retweeted and included in newsletters, but I kept avoiding it because I was afraid what it was going to say would bother me. And here we are.
When iOS 6 launched, I was so excited because Apple added a new class to UIKit: UICollectionView. At the time, I was working at 500px, so displaying photos in a grid was like 80% of my job. Understandably, I was excited.
Sadly, collection views are one of the most unjustly maligned classes in UIKit. They have a reputation for being difficult to work with, but I think that if people’s expectations of collection views were more informed, they might see collection views for what they are: a flexible, high-performance way to display collections of data.
Over the weekend, I lamented the death of Dropbox. Well, they’re not dead, just dead to me. I discussed setting up BitTorrent Sync and some of the security problems with common setup tutorials, and got some great feedback. A few people pointed to Sync (referral link), which after investigating, I’m pleased to say is awesome and has become my Dropbox replacement.
Dropbox is a jewel of the Y-Combinator industrial complex: a successful company that provides software as a service to ordinary people. They even allegedly turned down an acquisition offer from Steve Jobs. Their success is no small feat, but sadly it appears that they had to make a deal with the devil to achieve so much.
From my perspective, the company has been acting suspiciously for a while. Appointing George W. Bush’s Secretary of State to their Board was a big red flag. It inspired a whole Drop Dropbox movement. I’ve been uneasy about Dropbox, but when they announced they’d be integrating in with my operating system’s kernel, I decided to move away from them.
There’s been a lot of discussion lately surrounding the efficacy of Swift. Brent Simmons has been writing about his experiences using Swift. As an expert Objective-C developer, his insights are worth paying attention to; he notes that tools at hand when developing Objective-C are either missing in Swift, or clumsy to use. Responder chains, adding functions to objects at runtime, and selector reflection. I suggest you read all his posts.
However, I feel the need to point out that there are a lot of iOS developers out there who don’t use those tools, or may not even be aware of them. Consequently, they may not share Brent Simmons’ frustration at their absence.
Last week, I was getting some weird behaviour from an Artsy websocket API. The API is written in Scala, a language I’d never used before. With some help from colleagues, I was able to debug the strange behaviour and isolate its cause – but I didn’t want to make any changes on my own. While I’ve wanted to dip my toes further into web development for a long time now, I’ve been really nervous about making a mistake.
Then yesterday happened.
I’m a professional iOS developer – world class, if you believe my about page. But while I have a very particular set of skills building iOS apps, I want to be more than just an “iOS” developer. I want to be a bit of a polyglot, to explore other communities and languages and frameworks. For fun, but also because it makes me better at my job. Diverse experience helps me identify solutions to problems I’ve seen elsewhere, and being a beginner in other skills helps me empathize with other developers.
My favourite way to branch out of iOS development is to build this site, my blog. I’ve gotten experience in Ruby, Haml, web design, site deployments, CDN configuration, SVG formatting, etc etc etc. What’s really fun is when I get an idea for an improvement to make, and my skills are perfetcly matched for the task.
We’re seeing an explosion in the number of server-side Swift frameworks, which is awesome. The community needs to go in many directions to find out which ideas it should standardize on. Not all of these new libraries will be long-lived: some will fade out while others will become pillars of the server-side Swift community. Which libraries the community centres around won’t depend solely on code quality; it’ll depend heavily on community quality.
So if you’ve recently created a server-side Swift library (or if you want to (and statistically, you probably do)) then I have some suggestions on how to win the server-side Swift library arms race.
Rome wasn’t built in a day, so the saying goes, but it was built. That may not seem impressive until you consider the scope of Roman accomplishments in the context of their limited technology.
A few months ago, I wrote about normalizing struggle a discussion of failure and a call-to-action for everyone to be more open about that fact that they struggle (because everyone does).
Well, some science happened and it more than validates my viewpoint.