Core Intuition(@coreint) 209: We Need A Grand Gesture

I’ve been listening to Core Intuition with Daniel and Manton for a very long time. Being new to the Apple and iOS ecosystem it’s nice to hear from guys that have been around for a while. They have some pretty unique insights and experience to share with those of us new to community.

I feel like it’s time for me to give back a little. In Core Intuition 209, the talk a bit about Swift. With the advent of Swift, and Apple’s deep commitment to it, it’s tough as an old-time Objective-C developer to see and hear all the attention being given to the new baby. I’ve been in your shoes.

Back in the early 2000’s as Microsoft was making a big push with .Net and C# I was still hacking away on C++ applications written straight against the Windows API. Early on I had my doubts about .Net and C# becoming the development tool of the future on the Windows platform. Fast forward to 2015 and it is the dominant development tool. It just took a bit of time for people to become comfortable with the idea and, more importantly, it took time to people to trust Microsoft was all in with .Net.

I think something Apple has done a really good job of is convincing the development community they’re committed to Swift. It’s the only development tool at Apple that has really reached out to the community. They have a weblog and just this week released Swift to the open source community. Apple is committed.

Does it mean you should run out and rewrite everything in Swift? Probably not, but that is a choice you will have to make on your own. Apple has a huge investment in Objective-C and Cocoa and even if they stopped making huge advances to either it’s going to be years and years before writing code in Objective-C is not a good idea. In fact, Craig Federighi said as much this week in an interview with The Next Web.

“Objective C is forever. I don’t think anyone should fear for the future of Objective C. We’re going to continue to support Objective C for ourselves and the developer community.”

On Core Intuition the guys each said something that really stuck accord. Manton mentioned Swift’s syntax was a bit too punctuation happy, which I can agree with, and he says it reminds him of C++, which I also agree with. In my case I actually like the C++ language, whereas Manton said he’d rather not go back to it. I would never hold that idea against anyone. It’s an unforgiving language.

Daniel mentions his reluctance to add the Swift runtime to his products just so he can include a new class here or there. I had this same feeling when adding C#/.Net code to an existing C++/Windows API application. It just felt so weighty to get such little support. In those cases I’d say why change? Just keep hammering away in Objective-C if you’re good at it and you can move to release new product quickly. When building a new product give Swift a whirl.

Another great point discussed by Daniel and Manton was how people embrace new languages and find a way to over complicate things. Think about the Architecture Astronaut. Swift brings all kinds of interesting syntax sugar to the table, but it doesn’t mean you have to use it. Start simply, experiment. You’ll find things in the language you love and things you hate. It’s true of every language I’ve ever learned. Keeping your code readable and maintainable is way more important than any syntax sugar offered by the language.

I’ve been working in Swift for the past few months and we’re doing more and more at Agrian with it. All new features are being written in Swift. The language is expressive and once you get going I think you’ll find you can move pretty quickly. We still have large portions of code in Objective-C. We’ve been selective about moving bits of that code to Swift and other parts we leave alone.

If you’re an iOS or Mac developer I recommend you listen to Core Intuition. Daniel and Manton are thoughtful and very experienced developers. Listen and you’ll learn something new.


Open Source Hardware

Business Insider: “Hardware engineers across the industry are using OCP to ask each other questions. ‘It’s hard to get even two companies to work together. We’ve managed to get couple of hundred companies to work together and to let engineers be engineers.'”

You can read more about Open Compute here. It’s fascinating.

Development iOS Work Note

Work Note: When to share?

I do freelance work. As a freelance developer I’ve had times where I need to write code I know others could use. I use plenty of open source software, so I figure I should try to contribute something back.

That said, I’m working on a project right now that needs to parse RSS feeds. I know there are some existing RSS parsers available for Objective-C, but I’m going to write my own for a few simple reasons.

  1. I need it for this project
  2. I can reuse it later
  3. I’d like to give back
  4. I wanted to do something block based
  5. I wanted to publish it using CocoaPods

This exercise is primarily about two things; Sharing and self learning.Duct Tape, fixer of all things!

If I’m the only person that ever uses it, at least I’ve learned something new (packaging with CocoaPods) and I have something I can use again.

Update (6PM): I’ve published what I’ve completed. Some warnings. This code is very much as is. I’ve only tried it with well behaving RSS 2.0 feeds. The code definitely stands on the backs of giants. It depends on TouchXML to do all the hard work, all this code does is create RSS objects. Do not expect much.

I still need to add CocoaPods support and it could use a bunch of unit tests. I’ve done a few, but I can go a whole lot deeper.

Anywho, lots to do.

Development Indie iOS Objective-C

Better JSON to Object Serialization

Duct Tape, fixer of all things!Krzysztof ZabÅ‚ocki: “I don’t like passing around JSON so I write parsing on top of native objects like NSDictionary/NSArray. If you get data as JSON just write a simple category that transforms JSON to native objects using NSJSONSerialization.”

Here’s a nice hunk of code that will save you some time when you write your next iOS App that talks to a web service. I don’t like passing around NSArray or NSDictionary either, or even worse the raw JSON you get back from a service. I’ve written a few times about transforming JSON into an Object, and it’s not hard to do, but it’s so “boilerplate” it feels like a waste of time. Time you could use elsewhere. Krzysztof provides a nice way to get past all that boilerplate code and get automagic serialization of JSON to Object. It’s definitely worth a look and worth understanding the pattern.

Development iOS Mac

Fresh Code: RFRddMe

Earlier this week Dave Winer pointed out some neat stuff Readability was up to. Part of the piece pointed out a new URL shortener. I marked it and came back to it today. Since I love writing code to talk to RESTful web services, why not write another one?

The Red Readability CouchThis afternoon I started on RFRddMe, an Objective-C library for the Readability Shortener Service. Late this afternoon I completed the library, and I checked it into my GitHub Repository tonight. Figuring out git submodules took a bit of time, but it works as advertised.

If you just happen to be looking for Objective-C code to shorten a URL, and add an article to Readability, look no further.

Get the code for RFRddMe on GitHub.

Please, drop me a line,, if you use the code.


Business Development iOS Mac

Craig Hockenberry on Chameleon

AHHHHHH!Craig Hockenberry: “In summary, we’re very disappointed with how things have turned out. Not because of the funding, but because there’s some potential here that will never be realized. We’ll continue to add things we need for our own products, but don’t expect to see any documentation or bug fixes that don’t affect our own code. Any changes or fixes will get pushed out to the community on a schedule that suits us best: probably at the end of minor release cycles (every few months.)”

If you’re an iOS developer you probably know who Craig Hockenberry is, he’s the guy that created Twitterrific. Anywho, he’s also a Principal at Iconfactory. I guess my point is the guy has been developing software for a very long time and is well respected. I do find it odd that he’s a bit disappointed in the response to Chameleon. I’m not sure what was expected? Open Source is by nature fickle. What I see is this; people will download it, use it, gripe about bugs, but do nothing beyond that. Sure, there will be diehards that get behind it and contribute, but mostly people will just pull the source down, build, and use it. That’s the way it goes in the Open Source community. I have a couple of Open Source things, granted they’re nothing special, and I doubt anyone has used them, but I never expected anyone to contribute to them, or give me money to support them. I don’t want to sound like an ungrateful person, but I don’t think you should expect to receive any money for an Open Source project. It’s icing on the cake if you could raise money to support it, but I wouldn’t expect it.

Anyway, if you’re an iOS or Mac developer you should take a look at Chameleon, and support it in any way you can, the fine folks at the Iconfactory put a lot of time and money into it.

You can donate to the effort right from the homepage.


Android, Free is King

CNN Tech: “But for developers who wants their programs to make serious money, a nonunified app ecosystem may be less than desirable. Fully 74 percent of respondents said developing for Apple’s iOS gave the best opportunities for paid-app revenues, and twice as many developers claimed their apps were more visible in Apple’s app store than they were in the Android Market.”

Emphasis is mine. Another concern for developers was fragmentation. No surprise. Still, Android is a BIG deal. It’s the Microsoft Windows of Mobile.

You cannot ignore the platform.

Business Development Indie

Chameleon – A UIKit for Mac?

The IconFactory Chameleon Project!
Chameleon: “If you’re an iOS developer, you’re already familiar with UIKit, the framework used to create apps for the iPhone, iPod and iPad. Chameleon is a drop in replacement for UIKit that runs on Mac OS X. In many cases, your iOS code doesn’t need to change at all in order to run on a Mac.”

BRAVO IconFactory!

My wife already said no to a $250.00 T-shirt. Darn.

Development Indie Mac

Pay it forward

A wonderful bouquet of flowers.Mac Indie: “One of my primary goals in starting MacInde last year was to catalog and recognize all the tools that are available to Indie Mac/iPhone developers that can make your development life easier, faster, more efficient, etc. I’ll bet that if you tried to re-create all of the production quality code out there that we’re all using in our OSX and iPhoneOS apps thanks to this community, there’s probably 5-7 man-years of effort that you’d need to spend in doing it.”

Support your local Mac Indie! There’s a lot of really great free, and open source, Mac/iPhone/iPad source code floating around out there. Help these guys out if you can. I know I need to.

Shameless self promotion: Need Objective-C/Cocoa code to shorten a URL, or communicate with, click here.

NOTE: I haven’t built that code in a LONG time, in fact, I haven’t built it for Mac since upgrading to Snow Leopard. It built without error for iPhone OS and Mac OS X the last time I did build it. Your mileage may vary. I definitely need to spend some quality time with it.