Category Archives: Software

Almost six months have passed since the last NewsBee update and I’m glad to report version 1.3 is now in the App Store queue!

Version 1.3 fixes a number of small annoyances, such as preventing you from deleting all of your sites or closing all NewsBee menus while the app is still running. There are also a few QA slips from 1.2 that keen-eyed users caught post-launch. Of course, the main problem corrected by version 1.3 is the “random” crash experienced by some users when launching NewsBee under Mavericks. I put random in quotes because for some users this happened every single time. Today, I duplicated the error myself, caught the bug in action and stomped it out.

Big thanks to Mike who kept pinging me about the problem and sorry to users around the world who had problems! 1.3 should be available in just a few days!

It’s raining here today and you know what I’d really like? I’d like some sushi.

I live in the “wilds” of Northern Virginia and while there are a few places relatively close by I’m feeling a little lazy. I want something closer. And yeah, I’m a little bored too, so I want something I haven’t tried. So, like everyone else in the world, I figure I’ll just search for a place and see what I find…

Y U NO SUSHI APPLE?!

Below is a screenshot of the search results in Apple’s iOS7. What you’re really seeing here is that I haven’t received any emails about places to get sushi. Of course, what you could be seeing though places close by that have delicious sushi.

I don’t know about you, but I find this annoying. Why? I guess it’s the fact that I’m holding a powerful, radio-enabled device in my hand that should be able to tell me just about anything I want whenever I want and in this case it doesn’t. Heck, it doesn’t even give me an option to search the web. I’m also not particularly in love with empty search results. It just seems like such a waste of time. It could also be that the rain is just getting me down, but really, this could be sooo much better.

Why Didn’t I Just Open Safari?

Remember when I said I was feeling lazy? That’s one reason. The other is that Apple has made it ridiculously simple (to borrow from Cupertinospeak) to search by just swiping down just about anywhere.

Spotlight search (aka looking for apps, contacts, and other documents such as email) has been part of Apple’s iOS for quite awhile. What’s changed is that Apple has made this feature more accessible. Prior to iOS7, a user got to the spotlight search prompt by by swiping right on the home screen. In iOS7, Apple changed this behavior by adding a “search anywhere” feature which allows users to bring up a search bar by swiping down.

This easy access sort of begs the question: Why not web search results instead of just what’s on the device?

Ok, I hear the chorus firing up and talking about user experience. There are some who are likely to say that this would be confusing to users. Undoubtedly, somewhere, someone has already done a variety of studies to prove that users are expecting different things from different search channels. Personally, I doubt the veracity of this claim but I have three other reasons Apple should pursue this.

30% of Google paid search clicks now come from mobile and tablets.[1]. This number is growing fast and is something Google itself readily acknowledges. This mobile shift is something that every consumer company on the planet is struggling to manage. And for companies who make their money selling ads, it’s becoming an all-out war. [2]

iAd inventory is notoriously weak and underserved. If you follow the Apple developer community like I do, this is pretty much the number one complaint about iAd. In iAd’s favor, it’s very easy to implement in an app, but there just isn’t enough inventory to go around. As a result, most developers end up serving Google AdMob ads first and if there is no inventory there they use iAd as a backup.

Incorporating iAd and general web results into device search results would address both of these concerns. First, it would immediately impact Google (and Bing’s) share of mobile search in general. Second, it would expand the number of impressions for iAd but more importantly it would open iAd to a very different sort of audience: the motivated searcher. This is the consumer that advertisers are desperate to reach. The increase in inventory would undoubtedly have a major impact on network iAd sales.

Oh, and that third reason?

Apple already incorporates web search results in Siri…

So there you go… If I search on the device, I get nothing. If I search with Siri, I get a list of local restaurants. Why the difference? Is this really a good user experience? I think not.

On the other hand, if Apple brings these elements together, I’m able to find whatever I need in one place with one interface. I don’t need to go tapping about for the right app. I can just get what I need with just a quick swipe. This is the best reason to incorporate web search results. Of course, the side benefit is that by tacking on iAd, Apple can get a swipe in of their own against the big G.

None of this has gotten me any closer to that sushi, but I do have to say that I’m feeling a bit more spry having gotten this out my system.

Yay! Apple approved the build for NewsBee and 1.2 is now in the App Store! Below is a reprisal of my 1.2 announcement post plus a little extra.

I’ve been using version 1.2 for the last few months now, making tweaks and changes to the way the application handles extended characters (i.e. “international”) and parses RSS and HTML data. Oh, and I completely rewrote the event handling code to rely on GCD instead of performSelector. Yeah, that was a biggie. I really had no idea how big of a job it would be until I made the changes and then began the process of stripping out all the old code. Woof!

I’m glad I did it though. Under GCD, NewsBee is running very smoothly even with a large number of active sites. No more momentary delays when you pop open a menu or perform a manual refresh. Sure it was just a few milliseconds, but it seemed a little sloppy to me. Well, delays no more!

It’ll take Apple a little while to get back to me, but I want to thank all of the testers who helped me with this version. I especially want to thank those of you from around the world who sent me feeds to test and helped me deal with the thorny issues of character sets. NewsBee 1.2 is way better because of your help!

About the About…

As it sometimes the case, a developer forgets something when updating their app. In this case, I forgot to update the “About” splash screen with the 1.2 label. Doh! No worries though, it’s still version 1.2.

It’s been awhile since I’ve released a new version of NewsBee, but it’s not like I’ve been idle. I’m happy to announce that NewsBee 1.2 is complete and waiting for Apple’s review!

I’ve been using version 1.2 for the last few months now, making tweaks and changes to the way the application handles extended characters (i.e. “international”) and parses RSS and HTML data. Oh, and I completely rewrote the event handling code to rely on GCD instead of performSelector. Yeah, that was a biggie. I really had no idea how big of a job it would be until I made the changes and then began the process of stripping out all the old code. Woof!

I’m glad I did it though. Under GCD, NewsBee is running very smoothly even with a large number of active sites. No more momentary delays when you pop open a menu or perform a manual refresh. Sure it was just a few milliseconds, but it seemed a little sloppy to me. Well, delays no more!

It’ll take Apple a little while to get back to me, but I want to thank all of the testers who helped me with this version. I especially want to thank those of you from around the world who sent me feeds to test and helped me deal with the thorny issues of character sets. NewsBee 1.2 is way better because of your help!

Now, I recalled back in the mists of time that there was a nice way to take an OSX crash log and extract the line number, but for some reason I couldn’t make my brain give me the information beyond the fact that I needed to use atos. Now that I’ve unraveled the bits and pieces I already knew, I figured I’d drop it in a blog post so that I could recall it later (when I inevitably forget once more).

What is this “atos” of which you speak?

The atos command converts numeric addresses to their symbolic equivalents. If full debug symbol information is available, for example in a .app.dSYM sitting beside a .app, then the output of atos will include file name and source line number information. Mac OS X Developer Tools Reference

Buh? Don’t worry, that’s just some fancy talk from the Apple docs. What it means is that if you give atos your application’s binary and a starting memory address it can tell you things about related memory addresses, including the source file and line number.

Great, so how do I use it?

To begin, open up your crash log and scroll all the way down to the “Binary Images” section. You should see the name of your application on the first line. The very first HEX number is the starting address:

Next, I need the address where the bad things happened in my app. To get this, scroll up to the top of your crash log and look for the “Application Specific Backtrace” section. There are probably a number of lines here, but what you want to locate is the specific call out for your app.

From the example above, I want to grab 0x000000010ae5e276. This tells me where my app tried to be bad an insert items out of turn. Now, I’m ready to put it all together and get the mystery reveal on the offending source code.

In the first line, I’ve provided the command. The “o” option is for the binary. In this case, I’m looking at the NewsBee app and drilling down to the compiled executable. The “l” option is used to specify the load address I want atos to use when bringing the binary into memory. The final number is the place where the code went wonky.

On execution, atos loads up the binary and helpfully repeats my explanation above in obfuscated language. Then, it’s kind enough to tell me right where the problem is: line 325 in newsBeeController.m. As it turns out, the problem is happening right where I expected it to be (the _loadMenu function), but knowing for sure is awesome because the error itself is difficult to replicate.

Of course, everything I’ve said here can be gleaned by simply reading the man page for atos, but why do that when you can google, right? 😉