My name is Jake Marsh.
I'm a developer, designer, and writer.

Subscribed via Push Notifications. You can also subscribe via RSS or Twitter.

Subscribe via RSS or Twitter.

Subscribe via Push Notifications, RSS or Twitter.

▸ Little Bites of Cocoa 🍫

 •  5 minutes to read

I suppose it's about time I wrote about Little Bites of Cocoa. I've been having a blast with it. Here's a little about how it came to be:

The idea was simple. Daily bite-sized (get it?) tips and tricks to give readers a brief overview or explanation of a particular concept, technique, or tool.

I drew tons of inspiration from some of my favorite publications and content like Railscasts and NSHipster.

Originally I was planning on making Little Bites of Cocoa as a series of very short screencasts, but I quickly realized just how much work that was going to be. I'm lazy. I thought there might be a way I could communicate the same information, but without all the effort of video production.

Around the same time, I was experimenting with what it might be like to publish content "natively" on Twitter. I'm a big Twitter user, and I knew there was a huge community of iOS developers there. I found an image size that Twitter would display without cropping, and got to work.

The idea of each "bite" existing as a simple image file that could be shared around the web seemed very interesting, and I found it to be a very fun medium.

I composed each of the images by hand in Sketch using Symbols for things like lower thirds. Yes, I still do it this way, even now. It's the only way I can ensure the quality level. I often make fine-tune adjustments to the content to accomodate for showing it in such a contrained medium.

The process of simplifying a particular concept or set of steps to fit in the 1024 x 412 area available in each bite can be extremely challenging, but it's also very rewarding once I finally 'crack' the code. Composing each one becomes a sort of puzzle where I just need to find a way to express the concepts in their purest forms, with as little distraction or 'fluff' as possible.

I created a Twitter account: @lilbitesofcocoa and began posting my bites. The response was humbling, to say the least. So many awesome reactions and pieces of feedback. The biggest complaint at first was readers who wanted a better format for reading on their phones. The widescreen images just weren't cutting it for people trying to pinch and zoom their way around each bite. I began converting each bite into Markdown and posting them to a Tumblr.

Since I now had all the content in Markdown, and by extension HTML, I decided to offer a daily email format as well. I used Mailchimp to create a mailing list and to my surprise folks started signing up!

By now, I was having a ton of fun and looking for more places to share the content. I'd been a reader and subscriber of the /r/iOSProgramming subreddit for years and thought the community there would appreciate the concise image-based tips. It seems I was correct, the folks there loved it so much that the awesome moderators even gave me my own LBoC flair to use for my posts. Neat!

I continued publishing bites and eventually began to realize that I was outgrowing the Tumblr account I'd setup to host the 'web version' of bites. I decided to create my own site and CMS from scratch. This allowed me to have complete control over the presentation and organization of the content. I was also able to automate a fair amount of the work I was doing by hand.

It was around this time that I formed a partnership with my great friends over at the Spec Network. They were looking to broaden the content they provided and Little Bites seemed like a great fit. If you haven't checked out all the great stuff over there, you're missing out.

Finally: I'm proud to say that as of today, the new site is now live, complete with the first Sponsor!

Things I Learned at WWDC Today

 •  3 minutes to read

One of the best kept secrets of WWDC is that random conversations and run-ins as well as the official Labs at the conference are where much of the ticket value lies.

You can often learn tons of interesting details just by talking shop with the Apple employees hanging around.

Here's a summary of all the interesting details I learned today:


The new HomeKit triggers don't let you run arbitrary code, you schedule things like "when the garage opens, turn the thermostat to 70 degrees", and then everything happens out of process from your app.

Notifications about property changes on HomeKit devices are only delivered if your app is in the foreground. Great for privacy, but boo.


Apple is totally fine with developers using this framework to record anything, not just Games. Wondering what interesting use cases (besides the obvious: user testing). This could get really fun.

Developers never get access directly to the video files. They're stored in a system directory and the user is offered the chance to share them with a standard activity view controller once recording completes. You can add custom actions that will appear in the activity view controller that appears though.


Just like ReplayKit, you're free to use all of the features of GameplayKit for things other than games. Hey look, a free state machine implementation. Thanks Apple! (GameplayKit has a ton of incredbly useful and awesome features, I was just curious about this particular use case.)


Apple has already been crawling the web and looking at things such as existing meta tags that are commonly included on popular websites. They're also noticing if sites have the old (but still great) Smart App Banners feature. When possible, they're tying the information together. If your app is installed, when a user taps on a search result, it deep links you into the app, otherwise, the website and Smart App Banner are shown.

In fact, this system is so far along that I was actually shown a demo of one of the apps I work on completely working as described above already on iOS 9 (since Apple already crawled the website and the meta tags were already configured correctly.) Neat!


Mango Odwalla is delicious.

Cover header some interesting hints about ios 9

Some Interesting Hints About iOS 9

Today on Twitter, some clever sleuths discovered some interesting info tucked away in the latest WebKit source code.

Specifically, references to iOS 9 and OS X 10.11 were found.

Here are some of the highlights:

App Links

References such as LSAppLinkOpenCompletionHandler could point to a few different sorts of things.

A fair amount of hub-ub has been bustling about lately in regards to UIKit's canOpenURL: methods and the way some developers were trying to be sneaky and use the API for what it was designed to do. (I kid, I kid). App Links could be Apple revamping the URL handling systems in iOS and OS X to be more "safe" (more restricted to be sure).

Another idea that comes to mind is something closer to what Facebook and have attempted. Encouraging and supporting more iOS and Mac developers to create indexable content URLs seems like a smart strategic move on Apple's part. Plus, with all the reports of their recent search efforts, who knows what sorts of things they could be working on.

Dynamic Type

More platform feature-parity happening here. Dynamic Type is a fantastic system and I'm quite happy to see it making its way to the Mac and specifically into WebKit.

There's bound to be more undiscovered goodies littered around the WebKit codebase. If you'd like to poke around yourself, here's a good place to start.

If you find anything interesting, drop me a line.

▸ ComponentKit

ComponentKit takes a functional, declarative approach to building UI. It lets you focus on what your UI should look like, not the steps necessary to build it. It emphasizes a one-way data flow from immutable models to immutable components that describe how views should be configured. It does the heavy lifting of building a view hierarchy from this description.

I've been waiting to play around with this library since I saw this fantastic talk from Adam Ernst and Ari Grant late last year.

There's many pieces to ComponentKit, but one of the most interesting (to me at the moment) is it's declarative layout system:

This is random code I copy/pasted together to show some examples of layout inside ComponentKit. Please refer to their excellent documentation to see the real thing.

    newWithInsets:{.top = 70, .bottom = 25, .left = 20, .right = 20}
                .direction = CKStackLayoutComponentDirectionVertical,
                {[HeaderComponent newWithArticle:article]},
                {[MessageComponent newWithArticle:article]},
                {[FooterComponent newWithArticle:article]},

I've been working in WatchKit quite a bit lately, and I've come to really enjoy it's layout system a lot. It's certainly limiting, but it's fantastic for quickly putting things together when you have an idea. I've been wishing a library would come along that emulated this sort of system for iOS in general, and ComponentKit fits the bill.

Even though some of the ideas and foundations in ComponentKit clash pretty heavily with UIKit's philosophies, I'm encouraged by the pure usability of their system. Even their choice of Objective-C++ as a language was made to make the end-resulting code that uses the library as readable as possible.

It's certainly not meant to be a catch-all and won't be the right choice for every app, but in the cases where it makes sense, ComponentKit seems like a slam dunk.

▸ Apple TV Service Coming in June

Looks like it's finally happening.

The subscription will allegedly cost $30-$40 month, which is a tad pricer than Sling TV’s core $20 package. 25 channels may sound like not that many, but Sling TV’s cable-free subscription only offers 14 with $5 add-on packs like “Kids Extra” and “News & Info Extra.”

According to the Journal, the likes of ABC, CBS and Fox are lined up as partners with Apple. But NBCUniversal is not on board because Apple has interestedly had a falling out with the network’s parent company, Comcast.

I've been thinking about Apple's TV service for long time now, and this seems about on par with what I was expecting out of a first generation product.

In the wake of the apparent success of iCloud Photo Library and CloudKit itself, (in that we haven't heard much about them in the press) I'm happy to see Apple has gotten back on the proverbial horse when it comes to launching new services.

Also, I've heard similar things about the Apple/Comcast relationship. I'd be surprised if Comcast isn't already planning to cave a few months after the new device launches.

Confirmed: Apple Watch Runs iOS

 •  6 minutes to read

Today's release of WatchKit definitely had a few developers scratching their heads.

While on the one hand, many of us weren't expecting as many different integrations points as we got in this first release, the APIs that were announced certainly leave a bit to be desired. Specifically for those of us with aspirations to build full-fledged native apps for the Apple Watch.

Apple has of course said that "full" support for building "full" apps will come later this year, but some enterprising developers are already starting to poke around and discover what it might be like.

Many have speculated about what sort of operating system Apple Watch will run, with not much data to pull from. Now that WatchKit has been made (at least partially) public, we seem to have some much more solid evidence for that operating system being iOS.

Here's a stream of tweets from Steve Troughton-Smith (everyone's favorite neighborhood tinkerer), as well as Andrew Pouliot (iOS at Facebook), regarding WatchKit:

It seems that the framework powering the more elaborate Apple Watch apps is called PepperUICore (at least internally). The framework is still private and will likely remain that way until WWDC where I imagine it may gain a much more public-friendly name.

PepperUICore contains some fun classes like PUICCrownView and PUICNavigationController. You can rummage through the full private headers here if you'd like.

Also of note are all the other private Apple Watch-related frameworks present in the iOS 8.2 beta. There's a new Nano prefix with frameworks that have intriguing names like NanoLeash (seems to enable some kind of "find my device" functionality), and NanoTimeKitCompanion, which contains references to "monograms" (my guess here is this is the internal name for Watchfaces, and Apple is likely planning some sort of special App Store section for these, there's a huge market there. Watchfaces will be the new Ringtones).

For fun I decided to read through some of the PUICTableView classes and see what sorts of goodies I could find.

It seems that PUICTableView (you can view the full file here) is primarly used as a way to tie together the familiar scrolling workhorse that is UITableView with the new Digital Crown hardware found on the Apple Watch:

- (void)crownInputSequencer:(id)arg1 previousDetent:(id *)arg2 nextDetent:(id *)arg3 forOffset:(double)arg4;
- (void)_crownInputSequencerIdleDidChangeNotification:(id)arg1;
- (void)_crownInputSequencerOffsetDidChangeNotification:(id)arg1;

sidenote: I love the name 'detent' for describing the "steps" along a 'notched' wheel like the Digital Crown.

It seems that the Watch reports itself to be in what's called UIDeviceFamily "4". iPhone reports "1", iPad reports "2", and Apple TV reports itself as "3".

That's about as conclusive as it gets and I must say is actually quite reassuring that the Apple Watch is built on the solid foundation of iOS.

The limitations of many of the APIs in today's WatchKit release definitely felt like a temporary measure, and I'm happy to see that there's tons of good stuff in the pipeline, it's just not ready for public consumption just yet.

It's not hard to be reminded of the conversations (before it's announcement) of the possibility of the iPhone running OS X. (A seemingly unlikely feat at the time).

But as Apple has done for many years now, they managed to leverage their earlier hard work and solid foundations to leapfrog themselves forward with their next product. OS X's Foundation, CFNetwork, and countless other battle-tested APIs gave both Apple's first and third party developers firm starting points to build upon.

Well that was almost 7 years ago. It seems that iOS (then iPhone OS) is now all grown up, and ready to help it's new little brother, the Watch, find success.

▸ Apple Releases First Beta of WatchKit


WatchKit apps have two parts: A WatchKit extension that runs on iPhone and a set of user interface resources that are installed on Apple Watch. When your app is launched on Apple Watch, the WatchKit extension on iPhone runs in the background to update the user interface and respond to user interactions. WatchKit provides three opportunities to extend your iPhone app to Apple Watch: WatchKit apps, Glances, and actionable notifications.

Extremely excited for the opportunities WatchKit and the Apple Watch will open up for third-party developers and users.

Also nice that we get more than just simple notifications out of the gate. Although it does seem that communication is only one-way for now:

One fun note is that Apple has also released the system font for Apple Watch, called San Francisco. Gruber points out another memorable typeface with that name.

Make sure you check out the WatchKit Human Interface Guidelines, the WatchKit Programming Guide and the WatchKit Framework Reference.

▸ Apple Releases Xcode 6.1.1 GM

Chris Lattner on the Apple Dev Forums:

We care a lot about the pain that is affecting you now, and Xcode 6.1.1 available now as a GM Seed should address the worst of the SourceKit, DerivedData and module cache issues (among other bugs).

It has been wonderful to see Chris Lattner (father of Swift) taking such an active role in the developer forum discussions about the language and platform. It's a big step away from Apple's notoriously quiet attitude about works-in-progress.

Today's release of Xcode has seemingly eliminated many of the nagging issues that have been plaguing Swift development for a while. I haven't seen any SourceKit crashes and haven't had the module cache issues that previously had been wreaking havoc.

Twitter seems to agree, here are some reactions from other developers:

It appears that the Swift tooling is finally becoming stable enough to work with on a regular basis. With this latest release, I've been able to debug Swift code and work without any issues for a few hours.

I'd like to say thanks to the all the teams at Apple for their hard work getting things up and running.

▸ Amazon Echo


Amazon Echo is designed around your voice. It's always on—just ask for information, music, news, weather, and more. Echo begins working as soon as it hears you say the wake word, "Alexa." It's also an expertly-tuned speaker that can fill any room with immersive sound.

Very interesting move from Amazon. This will be their fifth major consumer hardware product category, and one that certainly makes the future seem exciting.

Although it has a bit of an informercial vibe, Amazon's video does a nice job explaining the product, and the use cases it might have:

The response time demonstrated in the device's promotional video is impressive. The biggest user-facing problem with systems like this is the lag time between when you say your ‘key phrase’ and when the device begins listening for speech that it can interpret as some kind of input.

In the video, Amazon makes it seem as if this “waiting” time is not needed with the Echo. If this is the in fact the case, it will be a huge breakthrough for speech recognition consumer electronics products.

It may have been a good idea to set the default ‘wake word’ (as Amazon calls it) ‘Echo’, and not ‘Alexa’ (the apparent ‘wake word’ that the device ships with as default). Two different names just seems unnecessarily confusing.

I can’t help but wonder if Apple is working on a device like this. Would be a perfect fit for a future Home Kit-enabled, Cable-box-replacing, always-on Apple TV.

▸ Calcbot for Mac

Graham Spencer for MacStories:

If you do end up buying it, be sure to check out the difference in the animation of the buttons being pressed when you click with a trackpad versus tapping with a trackpad – it's an impressive level of attention to detail.

I've been testing Calcbot for a few weeks and I can't believe I missed this little gem. Attention to detail like this is why Tapbots continue to be regarded as one of the best indie software shops around.

I've been keeping Calcbot open pretty much all the time and have found it to be a wonderful way to perform quick calculations or conversions. It is far more functional and usable than the built-in OS X calculator, Dashboard widget, or the new Notification Center widget in Yosemite.

I also love PCalc, but sometimes I don't need all the bells and whistles it provides.

Before Calcbot, I was using Alfred's entry-box to perform quick calculations. Alfred is a fantastic app, but it wasn't really built to be a full-featured calculation machine, and it doesn't support easily retrieving previous calculations.

Calcbot for Mac's website is also a great example of how to create a beautiful and effective landing page for your app.

You can download Calcbot for Mac here on the Mac App Store, and Calcbot 2 for iOS is coming soon.