Under the Bridge

App Marketing: ASO Explosion

So you’ve probably noticed that the ASO space has been getting pretty crowded since our last marketing roundup, but here’s developments of striking interest to both us little indies and big serious people from MobileDevHQ:

Today I’m extremely excited to announce a big new release for our users. First, we’re making big changes to our best-in-class pricing plans, expanding our free plan with huge additions. Second, we’re launching an API for our Enterprise users — allowing our customers access to their data on their own terms, in their own internal dashboards or to run custom analyses.

So if you’re another overloaded indie that’s been wondering whether this ASO thing is actually worth the trouble, go check out their presentation and sign up to try it!

Other options providing various combinations of services and tools — here’s a somewhat outdated comparison to start with — are




App Promo




ASO Professional


Mobile Action


Sensor Tower

Tried any of these — or one we’ve missed so far, which given how quickly these things are sprouting up is pretty likely — and they worked for you? Or didn’t work for you? Let us know!


The ASO Super Bowl: “We are pitting the #1 paid app, Slayin, against the #1 free app, Flappy Bird…”

Our Best App Store Optimization and Marketing Tips for App Developers

App Annie Launches New App Store Optimization Tools

The Future of ASO; Why ASO Is Not A Silver Bullet; Keyword Difficulty in 3 Easy Steps

What Game of Thrones Teaches Us About App Store Optimization

MobileDevHQ’s Ultimate Guide to Keyword Research

Preparing Your App for Launch Part 1: Why App Store Optimization is Key

Top 5 App Store Optimization Mistakes

Why App Store Keyword Rankings Drop Dramatically Seven Days After Launch

What to Do When Apple Deletes App Store Keywords Without Telling You

Preparing Your App for Launch Part 1: Why App Store Optimization is Key

Do You Need App Store Optimization? 3 Questions to Ask Yourself

Continue Reading →

Tip: Secure Charles Cert

No doubt if you’ve done any web-using apps or applications you’re familiar with Charles Web Proxy for debugging — and if not, go check it out right now — but there is the niggling concern that when you use it to debug SSL communications you tell it to trust Charles’ root cert, which leaves a hole open for anyone who cares to sign themselves a cert and go to nefarious work on your device.

But fear not! If like us you’d managed to overlook this option so far, here’s a step by step guide to setting up a

Custom SSL Certificate With Charles Web Proxy

Luckily Charles supports using your own custom SSL certificate as the root certificate, which you have to create yourselves. This can be done using openssl. You will be asked some information about the certificate. I recommend at least setting Organization Name to something meaningful as for instance Charles Proxy Custom SSL certificate. This makes it easier to find the certificate in Keychain…

… Now simply select the charles.pfx file in Proxy Settings > SSL > Use a Custom CA Certificate in Charles. Notice that Charles only saves the path to the file, so place the file somewhere meaningful.

Remember to install the certificate in keychain by simply opening the charles.crt file. It can be installed in the iOS simulator by dragging the charles.crt into the simulator window and on your iOS device by sending it using email. Remember to delete the old Charles certificate if you had it installed.

Worth doing just in case, yep. And if you’re OCD enough to get annoyed entering the password each time, the article goes on with how to trick Charles into thinking your custom cert is its default and skip that. We’re good with QA having to know the password, personally, so we’ll leave over that part.

h/t: iOS Dev Weekly!

Continue Reading →

Objective-C Style Guides

Ah, the great thing about standards is there’s so many to choose from. And here’s a new style standard for all us Objective-C programmers, from everybody’s favourite tutorial centre:

…the team and I are very pleased to announce the official raywenderlich.com Objective-C style guide!

This style guide is different from other Objective-C style guides you may see, because the focus is centered on readability for print and the web. Many of the decisions were made with an eye toward conserving space for print, easy legibility, and tutorial writing…

Pretty conventional most of it; the most interesting is this bit, which after due consideration we’ve decided has successfully convinced us that private properties add enough flexibility to be worth the smidgen of extra complexity:

The part of the guide that was the most controversial by far was the answer to this question: Should you prefer private instance variables, or private properties?

Main argument for preferring private instance variables: Do the simplest possible thing that works (and prefer saving space). Why add the overhead/complexity of private properties if you don’t need them?

Main argument for preferring private properties: Properties bring a lot of Objective-C goodness such as key-value coding, future proofness, a little more consistent overall.

Both approaches are completely valid ways of doing things, and both sides had valid points. However, we felt we should choose one for consistency’s sake.

After a heated 118-comment discussion, StackOverflow discussion, and very close vote, private properties won the day – at least for now :]

[EDIT: Worried about overhead? Check out Should I Use a Property or an Instance Variable? Spoiler: Property.]

And if you get down to the end there’s a list of other style guides, including a few that are new to us:

Personally, rather than set out a style guide as such, we loosely follow these principles:

  1. Clarity. There’s always at least two programmers on a project — you, and you coming back to fix bugs sometime down the road once you’ve completely forgotten what on earth you were thinking when you wrote this junk. Make it easy for the second programmer to understand looking at a single screenful what’s going on at any given line assuming no known/remembered context whatsoever.
  2. Malleability. Separate conditions and consequences; separate not necessarily connected actions; restrict scope to practical minimum. Easier it is to manipulate the code, the fewer bugs you’ll have and the quicker they’ll get fixed. This is why Allman style is The One And Only Correct Bracket Methodology: see the conditional compilation example at the end of that link’s section for the definitive demonstration of why.
  3. Terseness. Given two semantically identical structures, pick the shorter form. Note that this puts us at odds with common practice in the case of dot-notation syntax, as expressed in the raywenderlich.com style guide (cribbed from the NYT’s, apparently): “Dot-notation should always be used for accessing and mutating properties, as it makes code more concise. Bracket notation is preferred in all other instances…” Uh, why? Property-related calls are functions, “all other instances” are functions too. What is the magical unstated difference here that somehow makes concise only a virtue for functions that (conceptually) wrap value storage, and not for all functions? Not seeing any, dude. Use UIApplication.sharedApplication.delegate, or UIColor.whiteColor? Well, why not?
  4. Verifiability. Always write code in a fashion that allows the strictest compile time checks possible. So you should never use “id” for anything with a modern compiler. Use “instancetype”, or a protocol consisting of all calls potentially made to that object. Likewise, use NS_ENUM for enumerations.
  5. Mothership Consistency. If you can’t form a clear argument based on the first four points, go with the style used by the majority of Apple’s SDK headers and/or recent sample code. Most commonly resorted to in the case of holy wars over whether there’s a space in (NSString *)argument or whether it should be a spaceless (NSString*)argument and similar near totally pointless quibbles.

For the most part the raywenderlich.com style guide is perfectly compatible with these principles, the quoted artificial restriction without any justification given on use of dot notation is the only thing that jumps out at us as pointlessly silly. And we’d quibble with the K&R brace style, but wanting to save a line is defensible targeting print instead of our 27+” monitors, so we’re ok with that given the purpose. As opposed to all these other ones in the list, which all advocate K&R it appears; they’re just indefensibly wrong there, which is much worse than defensibly wrong. And none of them save Github’s are even somewhat close to our “everywhere, why not?” stance on dot notation. Hmmm, maybe we will get around to writing a Trollwerks Style Guide, sometime this millennium we run short of fundamentally meaningless things to argue about. But it won’t be soon.


An Xcode Plugin Enabling Easy Use Of The Clang Source Code Formatting Tool

Objective-Clean will set code to follow dozens of rules … and can get Xcode to throw build errors if you violate them.

Continue Reading →

Review: Unity 3D Game Development by Example

So, as we mentioned last time, we’d decided that it’s just about time to get to know the Unity game engine development environment a bit, and Packt Publishing was gracious enough to provide a review copy of their Unity 3D Game Development by Example video course to help us out with that!


The fast, easy way to start developing Unity games

There’s no better way to begin building impressive video games than Unity. The free software gives you the tools you need to create stunning 3D games and publish them for computers, phones, tablets, and the web.

This friendly video course will teach you the Unity from scratch and develop fun example games, deploying them to your favourite platforms…

TL;DR: Most Excellent orientation walkthrough — just exactly the level of getting our feet wet enough to be comfortable if we absolutely had to dive in that we were looking for. Unqualifiedly recommended as your introduction to Unity if you’re Windows and Android centric, minor qualification if you’re OS X and iOS centric that it’s a just a bit of an ill-fitting suit, not perfect but not too hard to match up with either.

Walkthrough Notes: What you download is a folder of HTML-wrapped browser-presented video — reputed to work on any modern desktop browser, but not iOS devices — split up into eight sections:

Section 1. Learning How Unity Thinks [22:01 mins]: Understanding Unity UI; Unity 3D Project Structure; Game Objects and Components; MonoDevelop Explained; Creating your first Component; Pro-Tips: Understanding A MonoBehavior

This section jumps right in to describing the main window, so it assumes that you’ve already figured out how to get Unity installed on your system. Which is a simple and free download, we got version 4.3.2. The video is taken on a Windows machine and the screen is arranged moderately differently than how the sample project shows up in said 4.3.2 OS X download, but nothing that makes any real difference, we thought … until it said “use the middle mouse button to pan”. Yeah, that’s a tough one for us. OK, so it’s not perfect for the OS X user. Still, it’s pretty darn close. We’re also informed that if we don’t know C# we should go learn it first as that’s what all the scripting examples will be in. Yeah, that’ll happen. But any C-ish syntax knowledge is fine to follow along with this course.

Section 2. Building a Scene [16:13 mins]: Creating and Loading a Scene; Building and Manipulating GameObjects; Adding Components to GameObjects; Building and Using Prefabs; Pro-Tips: Understanding Unity Cameras

All pretty straightforward, and workable if not precisely elegant. Yep, we’re starting to see why Unity is widely considered the premier design environment.

Section 3. Scripting Interactivity [20:26 mins]: Component Basics; Useful pre-built components; Trapping Player Input; Communicating Between Game Objects; Pro-tips: Building a Messaging System

On the other hand, nothing to confirm your low opinion of the development environment like finding out that building a messaging system is considered a “pro tip” instead of something taken for granted, that’s for sure. And this MonoDevelop thing you use to write your C# scripts in … well, it’s no Xcode, that’s for sure. Prejudice about this kind of environment being suited well only to projects that don’t involve any serious programming: Confirmed.

Section 4. Sound and Music [17:49 mins]: Unity Audio Basics; Building and Playing Game Music; Adding 3D Audio to the world – Controlling Audio Sources; Pump Up the Volume – Setting Volume and controlling Music Playback; Pro-Tips: Saving Player Preferences

Another straightforward section to breeze right through. Saving preferences counts as a “pro tip” as it points out the existence of System.Xml.Serialization. Yep, if you’re used to iOS SDK programming adopting this is going to be quite the shock.

Section 5. Building UI [30:51 mins]: Unity GUI Basics; Skinning your GUI; Game Experience as GUI; Game Experience as GUIScore and Time Displays; Pro-Tips: Pausing and Ending a Game Round

By “UI” here they mean HUD-type displays.Throws in some side tips like internal glows to add a little style to the experience too.

Section 6. Finishing the Game – Title Screens and Menus [11:38 mins]: Building a Title Screen; Building the Main Menu; Pro-Tips: Create a Pause Menu by Reusing your Work

Which is tying together the screen creation and GUI layout stuff that we’ve been introduced to already.

Section 7. High Score (Saving and Loading) [19:28 mins]: Tracking Player Score in Your Game; Building the High Scores List; Displaying High Scores from the Main Menu: Pro-Tips: Building your Finished Game

Some more UI/navigation tweaks, and how to output a Windows executable. Which differs by only one popup selection from outputting an OS X executable.

Section 8. Where to Go from here [27:00 mins]: Extending Your Work – Expand Score into Combo Scoring; Where to Go From Here – The Unity Community; Where to Go From Here – Unity 3D Pro; Where to Go From Here – Porting to Android; Pro-Tips: Publishing Your Finished Game

And of course being a person of taste and style Dear Reader, you have no use for the bits on how to publish on Android, but no doubt the pitiable intern you fost that nonsense off on will find that bit of interest. No mention of iOS in the porting bits, but presumably touch handling would be similar and looks like controls are about the only necessary difference.

So overall, we’re quite completely satisfied with how that went for the time investment. Nice efficient introductory walkthrough touching on enough to get off to a flying start yourself without getting bogged down or distracted much of anywhere; and if you’re doing simple games, that’s all you need! Would have been nice to something that was OS X aware, but there’s only a couple of places where things like referring to the middle mouse button show up, no particularly big deal. On the other hand, we were just a touch disappointed to not find any discussion of porting and native code integration across various platforms, a little more discussion of that as opposed to “here, add a touch handler and you’ve ported to Android” would be rather welcome. But that’s mainly because being a real — that is, iOS — developer, our skin was crawling with revulsion watching that C# coding in action and our thoughts immediately jumped to how can we write as little code as possible in MonoDevelop should it actually ever become necessary to work with a Unity project.

So yeah, the end result of this exercise is a switch from “intense skepticism” to “downright loathing” of the prospect of ever having to code ourselves in this environment. But for those who don’t have a project with heavy coding needs, or are Windows people who are happy programming C#, first off we’re sorry for you, and second off yep Unity most likely actually is a good choice for you and this is a definitely worthwhile fast start on getting orientated with it. Thoroughly recommended!

Continue Reading →

Learning Unity

So if you follow the news at all, it’s been kinda hard to miss that the Unity game engine has pretty much taken over the cross-platform game development space lately. And whilst we tend to incline to the opinion that anything worthwhile is going to involve so much native code that you’re better off not putting on one of these straightjacket development environments, it’s getting harder all the time to defend that position. And with the release of Unity 2D,

All you need is a little knowledge of JavaScript, C# or Boo and the enthusiasm to take the industry-leading Unity engine for a ride, and you’ll find your ideas will spring to life in no time…

… well, on that list of needs we rank “barely, no, no, hell no”, but it’s getting to the point where you need to actively justify not choosing Unity for a project. A useful barometer in this regard is the ever growing Wenderlich tutorial empire, which just posted a tutorial on yep, Unity 2D:

Unity 4.3 2D Tutorial: Getting Started

(And as an aside, another excellent recent game-related tutorial there you might have missed is the 2D Skeletal Animation with Spine Tutorial, which has a Unity runtime of course but can also be used with SpriteKit!)

so we’d grudgingly accepted that it’s worth setting some time aside to work up a bit of cursory knowledge of Unity, in the spirit of know your enemy if nothing else whilst we wait with our fingers crossed to see if apportable’s SpriteBuilder turns into an Objective-C environment with enough cross-platform chops to fend off the C# hordes.

And as it happens, the nice folk at Packt Publishing chimed in right at that moment of weakness — it’s like they’re mind readers, or something — asking if we’d like to take a shot at reviewing their Unity 3D Game Development by Example video course:

The fast, easy way to start developing Unity games

There’s no better way to begin building impressive video games than Unity. The free software gives you the tools you need to create stunning 3D games and publish them for computers, phones, tablets, and the web.

This friendly video course will teach you the Unity from scratch and develop fun example games, deploying them to your favourite platforms:

2 and a half hours of Unity screencast tutorials, broken into bite-sized sections

Create 3D graphics, sound, and challenging gameplay

Build game UI, high score tables, and other extra features

Program powerful game logic with C# scripting

This course is for anybody with some basic knowledge of programming who wants to get started in Unity. Start building Unity games today.

Well hey, “anybody with some basic knowledge of programming who wants to get started in Unity” does indeed qualify us exactly, so why not then, let’s see just how much we can get out of that 2 and a half hours shall we? There’s a sample clip here you can check out while you’re waiting for us to fit those bite-sized chunks around tamping down all the fires that sprang up whilst we were off enjoying the holidays and write a proper review. Or, if you have any experience with a substantial cross-platform project in Unity already, take a second here and let us know how it went. We’re particularly interested in things like Game Center integration, ad network integration, and other platform-dependent native features; but even if you don’t have anything of the sort in your project, a rough estimate of how long it takes to write something in Unity C# as opposed to a native Objective-C cocos2d or whatever is welcome too!


An Unreal Decision — why Jeff Lamarche switched from Unity to Unreal Engine 4

Continue Reading →

Annotated Screenshots

So are you still being a good instructions-following developer and when you’re submitting your screenshots actually listening to Apple when they say:

Show the actual pixels of your app, using the full screen, without graphics or borders around the image…

Rather quaint when you look around at how many people casually disregard those instructions, isn’t that? Well, seems like we can pretty much start considering those instructions officially obsolete, as look who’s setting the pace (h/t: iOS Dev Weekly!):

With the introduction of the Apple Store for iPad app, Apple decided to go with annotated screenshots for on of their own apps for the first time. They did it in an interesting, and unusual way, by showing an image of an iPad running the app below a headline that explains the benefit or feature shown in each screenshot.


So apparently the rules on both device images and annotations in your screenshots have achieved the status of Officially Disregarded. At least if you’re Apple, anyways. But hey, since everybody else is getting away with it, why not you too? (h/t: iosdevelopertips!)

Apple’s guidelines suggest using non-edited screenshots of your app, but by doing only this you’re really giving competing apps a big advantage. As we’ve seen already, App Store images don’t have to be plain old screenshots. Instead, you should think of them as a spot to advertise your app and its features.

I personally like to do one of two things; either include the device within the screenshot or actually photograph the app in use, similar to a lifestyle photo. Both of these options give extra space to describe and sell the features of an app…

If you want to go for what’s called the ‘lifestyle look’ in that article heck out iOS Templates’ photographs for your app-displaying convenience.

If you want to munge up shots yourself, here’s some tips.

Need some examples with more good ideas? Check out Designing App Store “screenshots” and How to Design App Store Screenshots that Sell.

Seen any other particularly creative uses of “screenshots” as little billboards? Let us know!

And just in case you missed this, soon as you get comfortable with the now apparently pretty much official lack of rules for “screenshots”, get ready for adding App Store video trailers to your necessary productions budget…


Designing Great App Store Screenshots

How to Make Great App Store Screenshots

Continue Reading →

Pods in Poses Pro 2

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?

Continue Reading →


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!

Continue Reading →

Custom Objective-C Literals: OCUDL

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!


Categories To Shorten Your Objective-C Code Including JSON Helpers, And NSComparisonMethods For iOS

Continue Reading →

Hosted IAP And Receipt Validation

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:

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

CargoBay has a couple extensions out there as well:

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!

Continue Reading →
Page 6 of 116 «...45678...»