Under the Bridge

So the last couple weeks we’ve been working on rewriting our very first nontrivial app to act like a decent citizen of iOS 7. Which remained essentially unchanged architecturally from late 2008 up until last month, save for the grafting in of IAP to download content instead of ship separate apps in early 2010. Have you taken an iOS 2 architectured app and rewritten it for iOS 7? Makes you really, seriously, appreciate just how far and fast this business of ours is moving, that’s for sure. So in the spirit of those tool posts people like making, let’s list the third party goodies we used, none of which existed when this product was written, just for a get-off-my-lawn chuckle at how hard things were in those sadly primitive days five whole years ago. And to point out some nicely iOS 7 savvy convenience pods that might have escaped you thus far.

1) mogenerator and Core Data reduced the data management code by three full orders of magnitude. Not to mention that being able to preload all your data with an OS X command line tool and test it at creation time saves multiple weeks’ worth of futzing around tracking down mistypes in your plists like we did back in those iOS 2 days. Ah, automation is wonderful.

2) Urban Airship is of course the unquestioned leader in push notification these days — we’d actually started working with iLime at some point here, remember them? — and it took just a few lines to use it to implement remote unlocking of iTunes Store hosted IAPs; functionality the current version manages with delusions of adequacy via a Google App Engine backend and our own content hosting. All of which we will be absolutely enthralled to send packing.

3) Flurry likewise for analytics. We’d almost got around to successfully integrating Pinch Media — remember them? — at some point, but ran into some kind of link problem or something that we forget now and didn’t bother holding up shipping for. And never got back to. Add four years, and why, it’s just amazing how free and easy analytics are to drop in, isn’t it now?

4) Speaking of free and easy, wow does Crashlytics ever rock. Remember when dropping in PLCrashReporter was bleeding edge state of the art crash management? This project does.

5) And finally getting around to our post title here, CocoaPods takes in a walk the Best Damn Hero Award for Awesomeness Of Expedited Development compared to five years ago. For anybody, but especially for us; twenty years of making a living mostly out of porting from Windows before this iPhone thingy happened along has trained us to crank up our compiler warnings to self-righteously OCD level — why yes, everything we write for our own projects does compile just fine with -Weverything, how about you? — and -Werror in release builds too. Which makes it always a time sucker to integrate other people’s code. CocoaPods sidesteps that nicely, as well as real problems, and even sorts acknowledgements for you. What’s not to like, indeed. Bonus mention to CocoaControls for including CocoaPod savviness in their likewise intrinsic awesomeness.

Here’s the pods that we’re linking into the version shipping off to the Apple approval gauntlet soon as we pull all the non-code stuff together:

pod 'AFNetworking', '~> 2.0.3’

Pretty sure most everybody uses AFNetworking these days for their networking needs, RIP ASIHTTPRequest. The funny part here is that after setting up CocoaPods for the new version’s project thinking “we’ll throw in AFNetworking for one pod to start out with, OBVIOUSLY we’ll be using THAT” we ended up not actually having any networking needs in the 2.0 release — everything that we absolutely had to do ourselves over the network in the first version was replaced by the libraries above or rendered obsolete by free Apple-hosted IAP, and what little remained hasn’t turned out important enough to bother with right now. But we probably will later, so we didn’t bother taking it out. Besides, it gives us a chuckle thinking of all the time spent tracking down networking issues back in the day every time we look at it.

pod 'CTFeedback', '~> 1.0.4’

CTFeedback adds a nice info-providing wrapper around your standard mail feedback writer.

pod 'FastImageCache', '~> 1.2’

FastImageCache is woo-hoo! fast. Got any gallery-type displays? Use it.

pod 'JPNG', '~> 1.2’

nicklockwood / JPNG “is a bespoke image file format that combines the compression benefits of JPEG with the alpha channel support of a PNG file.” And you can use it just like a JPEG where you’re not concerned about alpha, convenient that.

pod 'MRProgress', '~> 0.2.2’

MRProgress has all kinds of looking right at home in iOS 7 progress display options.

pod 'RMStore', '~> 0.4.2’

RMStore in our opinion does by far the best job of actually helping you instead of mostly getting in your way of any of the IAP helpers out there. And does iOS 7 receipt verification! Hosted downloads aren’t integrated into the main distribution yet, but this pull request works just fine for us.

pod 'TDBadgedCell', '~> 2.4.1’

TDBadgedCell does up your cell badges nice, looking fittingly in place in iOS 7.

pod 'TWSReleaseNotesView', '~> 1.2.0’

TWSReleaseNotesView shows release notes — either included with the app or pulled from the store automatically.

pod 'UAAppReviewManager', '~> 0.2.0’

UAAppReviewManager is like your usual review beggar alert, and extra niftiness like affiliate support and OS X support.

pod 'WYPopoverController', '~> 0.1.7'

WYPopoverController is pretty darn sweet for laying out your iPhone + iPad storyboard-based iOS 7 UI with optimal aplomb.

Kinda cool to look at this list of third party goodies that made your 2013 app development faster and better and compare with the “absolutely nothing” that would have made up an empty post on the same topic for the 2008 version of the app, isn’t it now?

So, you ever written any objects conforming to the NSErrorRecoveryAttempting protocol?

“The what?” you say?

NSErrorRecoveryAttempting Protocol Reference

The NSErrorRecoveryAttempting informal protocol provides methods that allow your application to attempt to recover from an error. These methods are invoked when an NSError object is returned that specifies the implementing object as the error recoveryAttempter and the user has selected one of the error’s localized recovery options…

Must admit, we’d managed to completely miss the existence of that protocol up until now. And so has pretty much everyone else in the world, going by all the other people’s Cocoa code we’ve ever looked at. But the clever sparks over at Realmac are an exception to that pretty much:

Cocoa Error Handling and Recovery

We’ve developed our very own RMErrorRecoveryAttempter class which harnesses the power of blocks to provide recovery options for an error. The class conforms to the NSErrorRecoveryAttempting informal protocol.

Let’s assume we’ve an entry object that a user has created. The user then tries to save this entry but because they haven’t set the required date property a save error occurs. To recover from this error we’ve created an RMErrorRecoveryAttempter object that has two recovery options.

RMErrorRecoveryAttempter *errorRecoveryAttempter = [[RMErrorRecoveryAttempter alloc] init]; [errorRecoveryAttempter addCancelRecoveryOption];

  [errorRecoveryAttempter addRecoveryOptionWithLocalizedTitle:NSLocalizedString(@"Use Today\u2019s Date", @"RMEntry date error use today's date recovery option") recoveryBlock:^ BOOL (NSError *recoveryError) {

  [entry setDate:[NSDate date]];

  return YES;}];

The first is a cancel recovery option that does not attempt to recover from the error and whose recovery block returns NO. The second recovery option has the title Use Today’s Date and a recovery block that sets the entry’s date to today and then returns YES. The errorRecoveryAttempter is added to the user info dictionary of an NSError object and then presented in an alert. For iOS projects we wrote the category UIResponder+RMErrorRecovery to present the error that includes a completion handler. If the recovered parameter of this completion handler is YES then the user chose a recovery path and so the message to save the entry can be resent.

The class is fit for use in both iOS and OS X projects and we use it throughout all our apps…

Check it out at realmacsoftware / RMErrorRecoveryAttempter!

Now this is a truly awesome example of Gratuitous Preprocessor Abuse™:

Introducing OCUDL

OCUDL is an experiment to bring user defined literals to Objective-C. A literal is a shorthand expression that creates a value of a certain type. For example, 25ul creates an unsigned long of 25, and @”hello” creates an NSString of hello. User defined literals bring this brevity and expressivity to our own types…

OCUDL defines literals using prefixes or suffixes. Here, we’ve defined a UIColor literal that uses the # prefix.

myView.backgroundColor = $(#FE22AA);

Pretty cool huh? Or how about

• NSNull *n = $(null);
• NSURL *url = $(http:www.apple.com);
• NSUUID *uuid = $(68753A44-4D6F-1226-9C60-0050E4C00067uuid);
• UIImage *img = $(pic.img);
• UINib *nib = $(MyNib.xib);
• UIStoryboard *board = $(MyBoard.storyboard);

The basic trick here is that “$” is a macro that sends the bracketed string to a factory method that keeps track of what to do with strings of a registered prefix or suffix. And of course, you can register your own for whatever class strikes your fancy. The savings in typing time and reading conciseness might or might not be worth the trouble, but seeding these throughout your shared code quietly and forgetting to notify your teammates of the new preprocessing tricks lying in wait to confuse them utterly, well that’s just priceless.

More details in OCUDL in Depth;

Code at dbachrach / OCUDL;

CocoaDocs at OCUDL Reference;

h/t: ManiacDev!

So today we’re adding hosted IAP content to a project for the first time — right out on the cutting edge with those iOS 6 features, that’s us — so that makes it a good time to check out what’s new in the way of IAP support libraries since a long time ago we last had occasion to check out the state of the art. The two we checked out then are:

• MugunthKumar / MKStoreKit: Seems quiet for the last year, latest README notes “I’m working on In App Purchase hosted content support on iOS 6. It’s implemented, but for some apparent reason, download doesn’t happen.” Next!
• anystone / AnystoneStoreKit: Also appears to be languishing since initial release, nothing in nine months.

Hmmm. Alright, let’s check on other libraries that we’ve noted the existence of since then:

• mattt / CargoBay: Fairly active; looks like there’s an open ticket on iOS 7 offline validation; includes hosted download support.
• ApptitudeNOLA / iTunesConnectHelper: Looks pretty quiet for the last year.
• dreamengine / DEStoreKitManager: Likewise.
• robotmedia / RMStore: Somewhat active; only one here supporting -refreshReceiptOnSuccess and other iOS 7 goodies. No hosted download support yet.

And let’s go trawling around to see what other libraries we can dredge up that we hadn’t noted the existence of until now. Making the probably reasonably safe assumption that anybody serious these days is doing a CocoaPod for their project and/or will be listed on CocoaControls, that gives us the new entrants

• chendry / SimplePurchase: No content or verification handling. Too simple.
• AwaraiStudios / ASBanker: Another lightweight.
• ebutterfly / EBPurchase: And another.
• stefankendall / IAPManager: Likewise. Although stefankendall / IAPAdapter for Simulator use is a nice touch.
• brynbellomy / iOS-CrackRock: focused on ReactiveCocoa supplementation

CargoBay has a couple extensions out there as well:

• rsanchezsaez / CargoManager /  CargoManagerExample “abstracts most details of StoreKit and CargoBay by providing a simple and pretty much automated manager…”
• lxcid / LXReceiptStore “provides a simpler interface aims at helping you make sense out of your In-App Purchase receipts.”

And here’s a selection of tutorials and snippets regarding the hosting and verification process to help smooth out all the rough edges on your choice (if any) of framework:

Introduction to In-App Purchases in iOS 6 Tutorial

Apple In-App Purchase: Creating App Store Hosted Content

Configuring and Creating App Store Hosted Content for iOS 6 In-App Purchases

In-App Purchase content downloads in iOS6

Updating content when using Apple-hosted content for In-App Purchase

App Store Receipt Validation on iOS 7

rmaddy / VerifyStoreReceiptiOS “parses and validates the payload and the PKCS7 container itself.”

DarkHorseComics / DHAppleReceiptParser “A library to parse the apple receipt file in iOS 7 “

A complete solution to LOCALLY validate an in-app receipts and bundle receipts on iOS 7 — check out the epistle from hpique the RMStore author

Well, adding hosted download support is pretty straightforward looking, and iOS 7-savvy receipt validation is most assuredly not straightforward looking in the slightest, so we’re going to go with RMStore here. It looks very nicely done indeed — check out these slides — for making things simpler without getting in your way a lot, which is a pretty fine line to walk. You may find that line for you somewhere more congruent with some of the other options up there of course; and CargoBay is definitely worth a very close look if you’ve already got (or insist on getting) server side verification. We’re perfectly good with the on-device verification here, because there just isn’t enough money at stake with our handful of IAP options to bother getting overly uptight, so RMStore being apparently the current best available drop-in solution for that floats our boat just fine. And besides, there’s already a pull request for download support — yep, looks just about as straightforward as our guess at doing it ourselves would be — so chances are, by the time we get all the content sorted packaged and uploaded, it’ll be there waiting!

Here’s a handy site to add to your feeds collection:

iOS Dev Tools

iOS Dev Tools is a list showcasing the greatest iOS development tools, including websites, desktop and mobile apps, and back-end services. I’ve tried to group the tools into logical categories and will mark any newly added tools as NEW.

Think most everything there of great interest we’ve bothered mentioning at some point over the years — with the notable exception of the ‘Networking and APIs’ section, have to check those out sometime —but it certainly is nice to have them all nicely curated in one place!

While we’re on the subject, here’s a recentish list along the same lines:

75 Essential Tools for iOS Developers

and here’s another:

My Ultimate Developer and Power Users Tool List for OS X (2013 Edition)

The only real comment we have here is, where the @)(#$&!! are the translation/localization helpers? Yes, we’re thinking in particular of that poor sad orphan which has been THE. MOST. AWESOME. EVAR. at making our multilingual duties much less effort and far more correct, but none at all? Really?

Any-ways, check those out in case there is something you missed.

And here’s a last one to throw in here, as hey managing a website is a fairly common aspect of iOS development too, right?

Inside BraveNewCode.com: Some Tools We Use

I was going through our own administration panel here at BraveNewCode today and thought it would be interesting to share our set-up with other people. Our WordPress website isn’t just a blog, it’s also a full-featured eCommerce store, support centre and product licensing/upgrade server. To turn a normal WordPress website into one that can handle all of that takes quite a few tweaks, external services, and WordPress plugins.

Here is a list of all the tools we use here at BraveNewCode.com – from hosting, to sales, to support…

By the way, in case you didn’t know, the best way to get your WordPress site mobile painlessly is BraveNewCode’s

Buy and enjoy!

UPDATES:

The nice people at Binpress would like me to remind you all to check out their commercial open source offerings when you’re putting together your toolkit. And hey, if CocoaPods and CocoaControls don’t turn up anything absolutely perfect for your needs, that looks like the next possibly worthwhile stop, sure.

Now this is a tutorial you should bookmark for next time you need to display point info on a MapKit map:

How To Efficiently Display Large Amounts of Data on iOS Maps

This tutorial will demonstrate how to handle and display thousands of points of data on an iOS map in a way people understand and enjoy.

We are going to make an iOS app which ships with 87,000 hotels, each with a coordinate, a name and a phone number. This app will never ask the user to “redo search in area”; it will update the map as the user pans and zooms, allowing the user to freely explore the data.

This will require us to come up with an ultra quick data structure built for the task. We will need to build it in C for it to be performant. Once we have constructed our data structure we will come up with a clustering system, as to not overwhelm the user. Finally, we will give it the professional polish that is required for apps to compete in today’s market…

That is one seriously detailed tutorial. Check out the accompanying app at thoughtbot / TBAnnotationClustering!

h/t: iOS Dev Weekly!

Now here’s a truly novel approach to monetizing your apps:

New Plugin Allows Developers to Turn iOS Devices Into Bitcoin Mining Bots

Unity plugin developer Icoplay has come up with a new way for developers to monetize free apps on the App Store while avoiding in-app purchases, through the use of bitcoin mining.

Because new bitcoins are generated via complex math problems, Bitcoin mining requires an incredible amount of processing power. Icoplay is aiming to use mining software hidden within apps and games to take advantage of the latent processing power of mobile devices, rewarding the developer with bit coin…

Mind you, the economics don’t seem to make any sense. Checking the latest stats,

Bitcoins Mined — 3,525 BTC

Electricity Consumption — 55,866.44 megawatt hours

we’re somewhere in the range of 16 megawatts per Bitcoin. Takes an awful lot of iPhone 5.5-odd watt-hour charges to add up to one of those. And somewhere in the region of $2300 of electricity. Which would only produce you a couple cents per user-year expected return, at best, and burning out a couple dozen Li-Ion batteries along the way. That would seem to put the usefulness of this somewhere between “laughably negligible” and “wasteful on a scale qualifying as downright evil”.

But hey, if you want to give it shot, check out their FAQ; maybe if you’re really super lucky, you’ll earn enough to buy a coffee in the trendy places around town here sprouting Bitcoin ATMs these days!

h/t: @justinlbaker!

So the last while you’ve probably come to the conclusion that we’d reached the end of the line for cocos2d as a good development choice, what with the original author dropping support and the introduction of SpriteKit, yes?

Well, not so fast there. The good folk at Apportable stepped up to support continued development of both the library and toolchain, and you can take a look at what’s been brewing away there now:

Cocos2d version 3 preview

The Cocos2d-iphone team, is very excited to share, what we have been working on for the last couple of months; namely the first preview version of Cocos2d version 3.

Version 3 will be the most extensive update to Cocos2d up to this day! This preview is still in alpha, and is not yet meant for use in production. Instead the idea behind the release, is, to collect feedback on the features and API, before everything is finalized.

Together with the release of Cocos2d, a first version of SpriteBuilder is released. SpriteBuilder is developed out of CocosBuilder, with a focus on improved user experience and new features. SpriteBuilder will manage your resources, graphically build your scenes and levels, do your animations, and your particle systems…

There’s a nice demo of SpriteBuilder in this video, “Apportable – One step iOS to Android”:

Compile Android apps directly from Objective-C and Xcode. Watch Zac Bowling explaining ‘Apportable’ and how to create Angry Birds in a couple of minutes using SpriteBuilder.

Yeah, getting to use a tool like and cross-compilation to Android whilst remaining in the friendly … ok, accustomed … environs of Xcode and native iOS development, that’s a pretty solid argument for preferred choice of platform, isn’t it. And there’s a good bit of other upgrading besides, here’s the full highlights list:

• Starting with version 3, Cocos2d will conform to semantic versioning. This means that point updates will not break backward compatibility.
• The whole API has received a thorough spring cleaning. Private properties have been hidden, naming is more consistent and old broken or unused classes have been removed.
• Much improved touch handling. Any node can now handle touches and multiple touches can be handled on a per node basis.
• Physics has been integrated with Cocos2d and will work seamlessly with your sprites or any other nodes. Best of all, it’s all objective-c!
• Cocos2d now comes with a UI-kit. Add your buttons, text fields, scroll views or sliders with only a few lines or code.
• Improved multi-resolution support. With the new positioning and scaling options making your game work on different form factors, such as tablets and mobiles is a breeze.
• Graphical editor support. Integrated support for SpriteBuilder, where you can lay out all your interfaces, components and even edit your games physics.
• Much improved truetype labels that support outlines, shadows and attributed strings.
• Official cross platform support through Apportable. Your games will now compile for native Android without modifications!

All this, and it still runs back to iOS 5. So be sure to keep the cocos2d option in mind when deciding on a platform for your next game!

So the last while you’ve probably come to the conclusion that we’d reached the end of the line for cocos2d as a good development choice, what with the original author dropping support and the introduction of SpriteKit, yes?

Well, not so fast there. The good folk at Apportable stepped up to support continued development of both the library and toolchain, and you can take a look at what’s been brewing away there now:

Cocos2d version 3 preview

The Cocos2d-iphone team, is very excited to share, what we have been working on for the last couple of months; namely the first preview version of Cocos2d version 3.

Version 3 will be the most extensive update to Cocos2d up to this day! This preview is still in alpha, and is not yet meant for use in production. Instead the idea behind the release, is, to collect feedback on the features and API, before everything is finalized.

Together with the release of Cocos2d, a first version of SpriteBuilder is released. SpriteBuilder is developed out of CocosBuilder, with a focus on improved user experience and new features. SpriteBuilder will manage your resources, graphically build your scenes and levels, do your animations, and your particle systems…

There’s a nice demo of SpriteBuilder in this video, “Apportable – One step iOS to Android”:

Compile Android apps directly from Objective-C and Xcode. Watch Zac Bowling explaining ‘Apportable’ and how to create Angry Birds in a couple of minutes using SpriteBuilder.

Yeah, getting to use a tool like and cross-compilation to Android whilst remaining in the friendly … ok, accustomed … environs of Xcode and native iOS development, that’s a pretty solid argument for preferred choice of platform, isn’t it. And there’s a good bit of other upgrading besides, here’s the full highlights list:

• Starting with version 3, Cocos2d will conform to semantic versioning. This means that point updates will not break backward compatibility.
• The whole API has received a thorough spring cleaning. Private properties have been hidden, naming is more consistent and old broken or unused classes have been removed.
• Much improved touch handling. Any node can now handle touches and multiple touches can be handled on a per node basis.
• Physics has been integrated with Cocos2d and will work seamlessly with your sprites or any other nodes. Best of all, it’s all objective-c!
• Cocos2d now comes with a UI-kit. Add your buttons, text fields, scroll views or sliders with only a few lines or code.
• Improved multi-resolution support. With the new positioning and scaling options making your game work on different form factors, such as tablets and mobiles is a breeze.
• Graphical editor support. Integrated support for SpriteBuilder, where you can lay out all your interfaces, components and even edit your games physics.
• Much improved truetype labels that support outlines, shadows and attributed strings.
• Official cross platform support through Apportable. Your games will now compile for native Android without modifications!

All this, and it still runs back to iOS 5. So be sure to keep the cocos2d option in mind when deciding on a platform for your next game!