Who wants to?
Been working on a new version of an app of mine called Closeby that I haven’t touched since iOS 6.
A few thoughts about the process:
- My design taste has come a long way in the last two years. Some features in I remember spending time on that now I can’t imagine why I’d want them. Others I didn’t do then seem obviously necessary and I have no idea why I didn’t.
- I really like iOS 7+ style design.
- I’m a lot better at programming than I was two years ago. It’s not awful, but there’s code in here I’d never have written today, and it’s nice to see than I haven’t stagnated.
- Cocoapods can be a pain in the ass, but it’s still the best bad choice.
Maybe I’ll post some before and after screenshots when I get a chance to work on it more.
Brent Simmons is not only a friend, but one of my favorite Cocoa developers. His blog is the most indispensable about writing software I read. Omni is one of my favorite Cocoa development companies. Can’t wait to see what they do together.
What if… in a few years from now, we figure out a way to make deep space travel possible. What if… the first interstellar spacecraft to be built is commissioned by the US Navy and its design is inspired by a science-fiction TV show from the sixties… what would it look like?
Neat! I don’t know why there’s so much emphasis on guns though. Who is it supposed to be shooting at?
About three weeks ago — on a whim — I went and bought a new Nintendo Wii U. The Wii U hasn’t sold great, but Nintendo games are what I grew up on, so it seemed like a good way jump back in. I hadn’t really played a lot of video games since I was a kid, but Mario Kart 8 looked awesome, and maybe I could get some of my work friends to come play it with me. I also bought a copy of the latest 2D Mario and a Zelda game too.
Turns out it’s great. Not only have my friends come over a few times for some Mario Kart, but I think I sort of forgot how fun video games can be. I liked it so much I also went and bought a 3DS XL, which is also fun (my favorite game for it so far is The Legend of Zelda: A Link Between Worlds).
If you haven’t played any games in a while, maybe give it a shot. I was pretty sure I was “not a gamer,” but I was totally wrong. It’s a blast, you can do it with friends, and it’s a nice way to get away from programming or whatever you’re doing without fully turning off your brain and receding into a vegetative state.
The first thing I always want to do when a new application is move to
~/Applications. In the past I used Hazel to automate this, but it works just as well with an Automator folder action.
Here’s the actions I set up to do this in Automator:
- New folder action.
- Receives files and folders from “Downloads”.
- Filter finder items > Kind is “Application”.
- Move finder items to “Applications”.
- Reveal in Finder.
And here’s a screenshot:
Justin Williams recommends that you don’t spend more than ninety days on a 1.0. I’m with Brent that I want to see apps that take more than three months to make, but I still think Justin has the right advice.
Some apps are deep, and there’s no way around the time they’ll take to get right. Coda comes to mind. Overcast might too. A majority though — especially on iOS — are really all about one thing that makes it unique and everything else falls out of that one thing.
Don’t ship garbage. Do figure out what your app is really about, do the hell out of it, and then start shipping updates.
Alamofire is a new networking library — written in Swift — from the creator of AFNetworking. So far I’ve just read the post on NSHipster about it, but I like what I see. It’s not a value judgment, but something AFNetworking has never quite sat right with me. This looks very lightweight and more like something written to be idiomatic Swift rather than Objective-C in Swift’s clothing.
I understood the concept of optionals right away, but since the debugger doesn’t work with Swift in the third beta of Xcode 6, I’m given no clue what I’m actually doing wrong when my app explodes. This article did a pretty good job clearing things up for me.
Objects that may or may not be nil (and the nil-checking code that accompanies them) are the cause of many common programming errors. Swift’s optionals offer compile-time cues to developers about when it’s necessary to nil-check and when it’s not, and makes it harder to write code that misbehaves in the presence of nil.