Excellent post by Victor Jalencas about his experience of RubyMotion:

Nowadays I know better. No matter whether you develop in Ruby or in Objective-C, the hardest part is getting intimate with the Cocoa frameworks. There’s no way around it. The way the Cocoa framework is architected, you have two ways to work with it: swim upstream, or go with the current. If you go with the current, easy things are easy and hard things are still hard, but doable. If you pretend to go against the current, you’ll have a hard time just to make the simplest of things.

I agree. Cocoa Touch is inescapable on iOS. You need to know how it works. Victor’s advice is great. Learn Objective C. Learn Cocoa Touch. Xcode is a free download from the Mac App Store, anyway.

The one thing I would add, however, is that RubyMotion can help you experiment with Cocoa Touch in a way that you don’t get with Apple’s current tool chain. The live console REPL that let’s you poke around with your objects or specific controls while your code is running—it’s simply amazing.

I know I linked to Drew’s series already, but his second installment is just so great. If you do anything with Core Data at all, you need to read these posts.

In other words, where with MobileMe there was a single truth database in the cloud, there is now just a collection of transaction logs from different devices, and a number of clients doing their best to independently reconcile those logs. As long as the updates are reasonably distinct, it works well, but when changes overlap considerably, you can get quite tricky situations. A lot of the discussion in this series of posts revolves around working around the conflicts that can arise.

Oy.

Speaking of Core Data, Matt Diephouse has a repo on github where he’s been experimenting with migrating Core Data stores though Objective C rather than the data and mapping model editors in Xcode. I know these graphical tools are supposed to help, but you’ll get much more mileage out of them when you understand the problem those tools are trying to solve.

Drew McCormack on his challenges with Core Data and iCloud:

To say it has been a challenge would be an understatement — it has probably been one of the hardest tasks I have ever undertaken for a Mac or iOS app. And so, in an effort to move the state of Core Data/iCloud syncing forward, I have decided to pen a number of posts, in the hope that others will be able to cross the same hurdles faster.

I’ve watched Drew McCormack emote on Twitter as he’s been fighting with this. I’m really looking forward to his series of posts.

Wendell Berry on technology:

In this age so abstracted and bewildered by technological magnifications of power, people who stray beyond the limits of their mental competence typically find no guide except for the supposed authority of market price. “The market” thus assumes the standing of ultimate reality. But market value is an illusion, as is proven by its frequent changes; it is determined solely by the buyer’s ability and willingness to pay.

The whole lecture was great; good food for thought, and very different than the tone of stuff you’ll see referenced in the echo chambers of reddit, Hacker News, or Tech Crunch.

I’ve been using this script to quickly find the device UUID of the first device plugged into my machine. I figured it could be useful to the rest of you, too.

Simperium is a new beta product to help developers sync data between clients and servers. It looks promising because it’s made by the Simplenote guys who know their stuff, and it integrates seamlessly with Core Data. I don’t know for certain, but I’d bet that it’s using the incremental store feature that shipped with Core Data in iOS 5.

I’ve used Simplenote before. It was solid, fast, and it still gets rave reviews from users today. Given all the iCloud Core Data syncing woes floating around on Twitter, this tool looks like it could be a good thing to keep in mind.

Graham Lee has a great point about how to use breakpoints that don’t stop to log values to the console. As a bonus, he also demonstrates a proxy object that logs out all selectors sent to it before forwarding the message along to the wrapped object.

MDSec published an impressive whitepaper on all the security issues iOS app developers face. It’s a free PDF and well worth your time to read. It has snippets about how jailbreak detection works (and is thwarted), insecure API usage, actual code examples for hacking and debugging running apps, and even how to hack the Objective C runtime from the outside to your will. If you’ve ever jailbroken your device and wondered how people altered SpringBoard to do crazy stuff, that’s covered in here, too.

Biting my tongue on this has been hard. I’ve been beta testing RubyMotion since earlier this year. It’s pretty slick. This Ars Technica article by Ryan Paul is a stellar description of it’s history, how it works, and the caveats.

Yes, this isn’t an official Apple product. Laurent created the open source MacRuby while at Apple, but struck out on his own to try and actually make a business around this tool. That’s why you have to purchase a license to use it. I consider this a feature, not a bug. Laurent and his company, HipByte, are committing to keep this tool up to date in the face of the rapidly changing iOS ecosystem. That’s worth paying for.

FYI, I already bought a license. ;-)

If you missed your chance for WWDC 2012 but can still make it to San Fransisco during the second week of June, you might want to head to the Indie Developer Lab. Looks like it will be a great place to meet up with other like-minded iOS devs during the flurry of WWDC.

Bwoken is an interesting UI Automation test runner from the guys at Bendyworks. It tries to take some of the drudgery out of running your tests from the command line for doing continuous integration. I like the colored output, and I’m intrigued by the use of automatic CoffeeScript compiling to JavaScript for the tests. Check it out if you’re not afraid of Ruby, CoffeeScript or rake tasks.

If you’re a newbie to UI Automation, I’d still recommend rolling your own test environment first before you try this out. If you start adding in layers before you understand the magic that those layers give you, you’re in for more hurt than help when things break and you have to go digging to find out why.

No, not MacRuby. MobiRuby, which is a port of mruby for iOS. Confused yet? :)

Like Lua, mruby (short for “minimalistic ruby”) is meant to be small, lightweight and easily embeddable. Lua is used frequently for things like scripting in video games and can already be embedded on iOS. Building off of Ruby’s C legacy means that it could be a really good fit for embedded scripting.

Don’t go into this expecting easy integration with Cocoa Touch, though. I’d recommend treating MobiRuby/mruby as embedded scripting to augment your app and encapsulate algorithms that would be a pain to write in Objective C.

Marvelously impractical. But a great way to get to know how the Objective C runtime works.

(via Brad Larson)

Looks like it’s a good time to learn lua.

More good stuff in the Objective C department. Patrick Beard over on the objc-language Apple mailing list brough up the new syntax for boxed expressions they are working on. You’ve probably noticed the ability to specify numeric literals in the upcoming Xcode like so:

// Old
NSNumber *num = [NSNumber numberWithInt:1];

// New
NSNumber *num = @(1);

But you weren’t able to pull that off at run time. With this change coming, you’ll be able to use that syntax to automatically box numbers and strings with this new syntax. Apple cleared a lot of cruft out of the way by supporting clang development to replace gcc. These new syntax changes are coming faster and faster, now.

I’ve been waiting for this one for a while. Graham Lee just hit the publish button on his latest book, Test Driven iOS Development. Graham’s got great chops when it comes to Mac and iOS security. I have no doubt that he’ll deliver good stuff in this book as well. He walks through developing an entire application from start to finish on iOS with TDD. I’m curious to see how he deals with the kinks testing around the Cocoa Touch frameworks and what tradeoffs he makes in his strategy to test.

From Ars Technica:

Apple’s motion to intervene was filed last June, and developers entered 2012 still unsure if Apple would be able to assist in their defense. As noted by FOSS Patents, the original judge assigned to the case had since resigned, and the case had to be reassigned. The new judge overseeing the case, Judge Rodney Gilstrap, agreed that Apple should be allowed to present evidence of its patent exhaustion argument on behalf of iOS developers.

This is great news.

Slick looking app that automatically generates png graphics based on Photoshop layer names in PSD files. Built simple with drag and drop import and export. A great gift for that special front end app designer in your life.

If you’ve been wanting to dabble in audio processing on iOS or Mac, give Novocaine a look. Alex Wiltschko shares his experience building audio engines through this library that uses simple block based callbacks. A block gets called when audio comes in and a block gets called when audio needs to go out.

I can’t vouch for any performance penalty when using this, but I’m planning to reach for it in my next project with meager audio processing needs.

The Australian Government has certified iOS 5 for use by it’s agencies and they’ve released a comprehensive pdf explaining quite a bit of the security infrastructure and what to watch out for to keep devices as secure as possible. It gathers a lot of good security information in one place.

(via Macdrifter)

Telerik recently announced their new Test Studio for automated iOS application testing. I’ve played around with the beta a bit and I’m impressed with how easy it is to use. You build a library into your application (kind of like iCuke makes you do) and then you activate a “record mode” in your app and walk through your use cases. Unlike most other record and playback solutions I’ve seen, this one tries hard to keep from being brittle by letting you abstract your expected results and build tests out of sets of actions.

I think this is a good tool to have if your QA team wants record/playback testing. And it works great if you need beta testers to record how they are creating bugs. Personally, I’m more interested in well maintained, hand written scripts for tests because of the power it gives you to express your intent. Version control is more straightforward with written tests, too.

But I’m keeping this tool in mind.

Thanks to Craig Hockenberry, I finally know how to get the Mountain Lion preview installed on a VMWare Fusion instance.

This will be interesting to watch. Drew McCormack of Mental Case fame is taking Wil Shipley to task over Wil’s piece I linked to yesterday.

Wil says that paid upgrades are an important part of a software shop’s business model. Without that incentive, he would be economically pressured to only create new software rather than keep upgrading what he’s already made. Drew says this is falling into the same “old media” trap that the music industry fell in to. The app store a new delivery and discovery mechanism for customers. Upgrades bring about spikes in new sales and the reach under the new model is such that market saturation is a non issue.

I don’t think that app upgrade sales should be so quickly lumped in with “old media” dilemmas that the content industries face in the digital era. Software has a different kind of social contract involved than content you consume. The biggest issue I see with paid upgrades is that there’s no way for multiple versions to be supported in the App Store. In order to get bug fixes you would have to get the paid upgrade even if you were quite happy with the funcitonality you have now.

You know how you’ve always wanted to have git automatically take a picture of you and insert your commit message lolcat style to preserve for your amusement and posterity?

Wonder no more.

Wil Shipley gives a well researched article on the necessity of paid upgrades in the Mac App Store.

For developers, upgrades fund the new software we’re writing, not the current stuff. Think of upgrade revenue as the Kickstarter project for our next product, whether it’s a major version of an existing product or something totally new. We live for those upgrade humps. They keep us warm in the cold months.

Of course, this should also be adopted on the iOS App Store.

Mugunth Kumar and Rob Napier have delivered an impressive book packed to the top with all sorts of tips and tricks that you’ll want to know for iOS development. iOS 5: Pushing The Limits exposes the details of Xcode schemes, KVO in practice, handling multiple devices and platforms, and error handling better than other books I’ve read to date.

It’s not a beginner’s book. I’d recommend it for devs who’ve already built apps but want to better understand Apple’s conventions and the tools at their disposal.

Mike Swanson makes a compelling case for when to consider vector over pixel art in your applications. With the retina iPad and the hints of high DPI Macs, vector artwork starts making more and more sense. Keep in mind that the iOS imaging system is optimized for the specially coded PNGs that Xcode emits when packaging your app. If you need raw speed right at launch then you’ll want to stick with PNG pixel art. But there will be many cases where rendering vector images can happen asynchronously or cached off, and that’s where Mike’s technique can be a great win.

James Duncan Davidson did some sweet investigative work to find out why Mobile Safari downsamples some very large JPGs. Good research for web devs who want to take advantage of the retina display and tips to make sure you don’t trigger the downsampling.

Spotted this great tip on Drew McCormack’s twitter feed:

Good tip for iCloud Core Data testing from @dlpasco: Use launch args -com.apple.coredata.ubiquity.logLevel 3 to debug.

A great introductory article to good RESTful API design by Mgunth Kumar. Covers organization of your resources, behaving as a good HTTP citizen, and versioning. Nice place to start if you’re rusty on your server side chops.

PaintCode is a vector drawing tool that is built for one kind of output, Core Graphics source code. I’ve been messing with the demo today and I’m very tempted to buy. Its got a nice interface, basic shapes, a reusable palette of colors and gradients, and it lets you build more complex paths out of simpler ones through union, difference, and intersection. You can choose between OS X or iOS code and you can watch the code update in real time as you draw on the canvas.

I’ve used Opacity for things like this in the past because it lets you “export” vector drawings as Objective C code. In addition, it also has a nice workflow for exporting png graphics in all the different resolutions and icon sizes these days. But it can be a bit buggy. And it’s such a full featured vector drawing tool, that often you’ll create something that just can’t be rendered into code. By contrast, all PaintCode is good for is drawing things that Core Graphics can do. That simplicity seems to be a strength here.

They have a time limited demo to try before you buy and a set of videos to show off the power.

I had the pleasure of meeting Heath Borders at the Chicaco CocoaConf. He pointed out his HBCollections iOS library and I just had to mention it here.

He originally wrote it as a way of easily encapsulating operations on collections, like you would in Lisp. Mapping, reducing, filtering are all fundamental operations over there and they are slowly making their way to Objective C with things like enumerateObjectsUsingBlock:.

The best part is the way Heath handles the idea of breaking out of an enumeration. Those who use enumerateObjectsUsingBlock: and the like will recall that the only way to break is by assigning a value to the stop parameter that must be accepted by the block you write. It’s a fundamental limitation from the way blocks are implemented in C. Heath built his solution so you can pass in another block that decides if enumeration should continue or not. It’s pretty clever.

Daniel Jalkut walks through some of the undercover work about codesigning and the Apple Developer ID that he and the guys at OmniGroup discovered. If you’re porting an older Mac app over to use the Apple Developer ID to pass the default requirements of Gatekeeper in OS X 10.8, you’d better read over this to make sure your app makes the transition without throwing a fit.

Dave DeLong has opened up my mind to crazy possibilities with his StackKit, an API wrapper to Stack Overflow that lets you access and search the site through NSPredicates. You’re basically treating the site as if it was like a Core Data store that you fetch against.

Let the imagination run wild!

Now, this is how you do a retraction. Kudos to Ira and his team.

While you bask in the glow of your new Retina display today, here’s a piece discussing how Apple devices broadcast MAC addresses of wireless access points that they’ve recently seen. This is bad because MAC addresses are easily mapped back to physical locations using services like Skyhook or the other databases managed by Google and Microsoft. If you leave your iPhone WiFi antenna on, you’re potentially broadcasting the general geography you’ve been near recently.

The article is frustratingly sparse on details, given its “convenience vs. security” rant. I’m disappointed at this MAC address broadcasting myself, but if we’re going to start discussing security tradeoffs then I’d like to know more about what problem Apple thinks they are solving by broadcasting these addresses.

Is this really about convenience vs. security? Or a lazy security hole that Apple should patch?

UPDATE:

Randy Beiter shot me a plausible reason why devices might want to share MAC addresses. Thanks Randy!

@jonathanpenn I can dream up Bonjour/0 config use cases that suggest AP’s to your other devices but overall it’s a pretty scary/dumb idea.

Special thanks to “lldong” for tracking down how to use MacRuby with Xcode 4.3 delivered through the App Store.

For those not in the know, MacRuby has a special hook that lets the interface builder nib editor know about outlets in MacRuby class files. With Xcode now being delivered through the app store and installed in /Applications/Xcode.app instead of /Developer, the MacRuby hook broke. These instructions help you set it back up, but be warned. It’s not a long term fix. It involves altering the Xcode.app package which invalidates the code signing. Everything works okay for the moment, it doesn’t look like Xcode checks itself. But this is obviously a temporary bandaid unless a new hook mechanism is built by the MacRuby core team.

Oh, man. This brings back memories. I cut my teeth as a young nerd hacking my family’s Apple 2gs in assembly language using Merlin 16. 2.4mhz, baby. That was the stuff.

The Free Tools Association was my idol. They were doing crazy things with graphics and sound that many thought wasn’t possible on that trusty old beige box. They’ve long had an browser-plugin emulator, but I just noticed today while following the path of nostalgia that they have an app in the app store.

Behold, the Free Tools Association Apple 2gs emulator for iPhone and iPad.

Objective C has finally joined the 21st Century with a syntax for defining dictionaries the natural way…keys before values;

Daniel Steinberg’s iBook on Kiwi is out and it’s marvelous. If you’re new to test driven design, or to Kiwi (an Rspec-like testing framework), this book is for you. Daniel walks through the testing mindset with plenty of examples and code you can play with. He makes great use of video screencasts and shows off the power of the iBooks platform. I dig it.

Mark Lemley has written a scholarly paper on patents and the myth that patents provide enough incentive for “lone geniuses” to keep innovating. It’s not a quick read, but it is thorough. And it touches so much of our industry.

Invention comes from a web of ideas and crazy experiments across many fields and involving many people. If you like this, you should also check out the Everything is a Remix series.

(via Concurring Opinions)

Zachary Christopoulos gives the lowdown on a *.mobileconfig file you can install to disable the iPad home button. As a parent of small children, I’m filing under comes-in-handy.

Apple’s put up a great slide deck to give a high level walk through the concepts, tools, and steps you take to publish apps to the app store.

We’re always hearing from Apple that we should file radars on things that are important to us. Well this is important to us. So what I want you to do is this…

A call for developers to go on record asking Apple to fix their bug reporting system. And not just the software, but rethink the channel. This isn’t just a developer bitching session. This has a tangible effect on our common customers of the platform.

This series by Tom Ryder tickles me as a fan of Unix and vim. Yeah, you’re probably not going to replace Xcode, but you’ll be kicking yourself if you aren’t familiar with all the tools at your disposal.

Lex Friedman over at MacWorld has a great overview of Gatekeeper and it’s interaction with Applescripts. If you provide external scripts to your users for download, you’ll want to check this link out.