(Lesson learned: Always download the developer preview and give it a try, before running Software Update…)
Facebook updated xctool. And I’m happy to say that XcodeCoverage now works with Xcode 5.1! Thanks to my coworker Mike Maietta for figuring out how to create a wrapper around the new gcov so that it continues to work with lcov.
For my European readers: I have two speaking engagements coming up in January 2014. The first is with Mobile Central Europe in Warsaw on January 11. I’m honored to be part of this brand new developer’s conference! Here’s the cool conference trailer:
Then after an eBay iOS Developer Meeting in Berlin on January 13 (for eBay Inc. employees only), I’ll be speaking at eBay Tech Talk in Berlin on January 14 (open to the public).
Update: Apple took this to heart, and fixed things in Xcode 5.1.
Bug or feature? “You have to call __gcov_flush() to collect coverage data with the iOS simulator.” According to Apple, this is a feature. But not if you actually want to measure your code coverage.
But it worked on Xcode 4 / iOS 6…
Code coverage… oy vey! Back in the days of running on iOS 6 using Xcode 4, measuring code coverage for unit tests was fairly straightforward. A set of coverage scripts I published made it easier still.
Then along came iOS 7 and Xcode 5. Coverage still worked if you continued to run on iOS 6. But on iOS 7, you’d get “ERROR: no .gcda files found” indicating that coverage data wasn’t being captured. “Well, maybe I need to switch from SenTestingKit to Apple’s new XCTest framework.” Nope, that didn’t help. Continue Reading…
I just wrapped up a great weekend with CocoaConf San Jose. I’ve gotta say: if you’re looking to maximize bang for your buck, save the money you’d spend on WWDC and consider CocoaConf instead!
First, there’s the stress of trying to get a WWDC ticket. Then the expense. Sure, there are all those great talks, but Apple makes the videos available to registered developers. I think the main reason to continue going to WWDC is if you’re really desperate to get help in the Apple labs.
I’d never been to another iOS/Mac developer’s conference before this past weekend. I was impressed by:
The small size. With only a hundred developers, there were many opportunities to build relationships, even with the speakers.
The speakers. This is a class act of experienced people. Many of them are published authors. They’re there because they’re passionate about their craft.
The food. Remember when WWDC food used to be decent, before the iOS-induced population explosion? This was like that, only better. Much better.
The duration. My brain is full by the third day of any conference. CocoaConf wisely stops there.
The price. Way cheaper.
I came away having learned good stuff. But maybe just as important, I made genuine human connections. (Good luck doing that at the great cattle-herding of WWDC.)
In #imports gone wild! we looked at the problems caused by having too many #import directives. But it’s also possible that you have too few, resulting in bad header files — especially if you don’t pay attention to #import order in your .m files.
Minimal and complete
When it comes to imports, header files should satisfy these two conditions:
They should be minimal
They should be complete
“Minimal” just means a header file should import no more than it needs. “Complete” means the header file imports everything that needed to compile it. Consider Continue Reading…