Ruthlessly Simple iOS Dependency Management with Carthage

I have been using cocoapods for quite some time and love it, but with the transition to Swift from Objective-C, there have certainly been some issues that have arisen, in terms of projects that haven't been updated to pods, as well as cocoa pods not really being compatible with swift the way I wanted it to. I know over time this will certainly improve, and I won't stop using it, but in the meantime, I have come across an excellent new dependency management tool called Carthage which is certainly worth looking at. 

I would highly suggest you check out the video and slides below of a recent presentation given at, another group of folks that I really enjoy and appreciate. 

3 Trends Marketers Need to Know About Location-based Advertising |

Location-based advertising has exploded in recent years as brick-and-mortar brands shift digital and traditional budgets to mobile.  The result has fueled the growth of one of the quickest moving sectors in an already chaotic ad tech industry where tactics, strategies and capabilities are changing as fast as the companies offering them.

These changes have implications for a host of stakeholders in the local marketing industry. Tectonic shifts in the way the advertising industry operates — namely, the growth of programmatic advertising — will alter the way advertising spending flows. Meanwhile, the development of more refined technology will alter the tactics used by companies to across the industry run campaigns.

At the Local Search Association’s Conference in Los Angeles Wednesday, executives from a handful of mobile marketing firms discussed some of the key shifts in location-based advertising and outlined the implications for publishers, brand marketers and small businesses.

The machines are taking over the advertising industry. Within a few years, a majority of desktop inventory will be bought through software, according to eMarketer, and programmatic already dominates mobile — the fastest growing category of the ad industry.

But the shift to programmatic isn’t just about creating efficiencies for large brands — it could materially change the way small businesses buy media, says Victor Wong, chief executive at PaperG, which sells dynamic creative software. Wong says that the ability to buy inventory through software effectively reduces the cost floors typically required by premium publishers, allowing a small business to potentially advertise on ESPN.

“The fact that transaction costs are so much lower, [the advertiser] can get just what he or she wants instead of buying wholesale,” said Wong during a panel Wednesday. “It has allowed small businesses to have the same technology as the big guys, but to pay only what they can afford.”

That shift — the ability to buy an ad without a formal relationship between advertiser and publisher — is starting to “democratize” the media business, says Wong.

Points to polygons
There’s an often-overlooked difference between location and place. A location is a point on a map — a latitude-and-longitude that often comes down to a nine digit number. But to understand what is at that location — say a mall or stadium — technology companies need to understand where one place ends and another begins. That’s a much more difficult, and time-consuming process.

Over the past few years, location technology companies have identified millions of places, creating zillions of polygons that represent everything from Best Buys to book stores. The ability to attribute a person to a place — not just location — has opened doors for technology companies to begin to flesh out a clear picture of the people behind the data.

“You create a gradual image of broad behaviors rather than making a massive assumption from a single data point,” said Tyler Bell, director of product at Factual, one of the largest location data startups. “All of these observed activities, where people are moving from one point to polygon, give you a holistic broad-based view of the user.”

Better creative
“When you can blur that line when consumers no longer realize that they are seeing a templated ad — that’s when things start to take off,” said Greg Crockart, CEO of North America at WPP-owned creative agency Candyspace. He was talking about the need for marketers to continue to push the creative used by firms on mobile.

Crockart says his agency has started to invest increasingly in mobile campaigns that tie into other forms of media as a way to buttress both experiences. For instance, the company ran a campaign for the the film Hot Tub Time Machine last year where it allowed users to digitally throw a beach ball from a mobile phone to a digital-out-of-home ad placed in Times Square.

We’re getting that double impact of hitting on both screens,” said Crockart. That’s another form of retargeting for us, and the data proves that if you hit people across multiple screens you will increase engagement.”

Be sure to subscript to StreetFight, to get your fix (pun intended) of location-based marketing journals. 

Resolve Xcode code-signing issues by following these guidelines

@jaredsinclair has written a great set of guidelines for you to follow, so can resolve most of your Xcode code-signing issues. The first point is certainly the most intriguing, and I never take note of what Xcode actually does when you use the built-in signing helpers. 

For at least a year now I haven’t had any struggles with Xcode’s code signing, thanks to the following habits. Some of them seem like overkill, and all of them are a lot “harder” than using the built-in “support” in Xcode, but — fuck all that noise. Do these things1 and get back to work:

  1. Never use Xcode’s built-in code signing helpers. Especially avoid any button that says Fix Issue. It fills your Developer portal with dozens of worthless “iOS Team Provisioning Profile Blah…” profiles and leads you towards Provisioning Profile Rot.

  2. Never use wildcard app identifiers. These are especially problematic when you belong to multiple teams, each with multiple wildcard app identifiers. Take the extra few seconds it takes to log into the developer portal on the web and create an app-specific bundle ID for every app, even proofs-of-concept. By avoiding wildcard app identifiers you eliminate an entire vector of shit on the path to code signing hell. If you have any existing wildcard profiles, delete them all immediately. Modern versions of Xcode make this much harder to do than it used to be. Let me Google that for you.

  3. Use build configs and shared schemes. Make life easier on yourself and check the “Shared” box in the “Manage Schemes…” window next to at least two schemes. Have one for development and one for App Store releases at the very least. Consider adding a third for beta builds if necessary. Select the appropriate build config in the editing window for each scheme. If you use the default build configs provided by Xcode that’ll be Debug for your development scheme and Release for your release scheme.

  4. Use explicit code-signing identities, and automatic profile selection.Since you’re now using shared schemes linked to specific build configs, you can make your Xcode project settings even more helpful. In the Code Signing Identity and Provisioning Profile sections for your project settings, specify explicit signing identities for any build configs that require distribution certificates (Ad Hoc, Enterprise, or App Store distributions). You can also try the automatic iOS Distribution setting if you’re lazy, but I’m on too many teams and don’t trust Xcode to do the right thing. I do recommend using the iOS Developer automatic setting for your Debug build configs, since this scales better when working with other developers. I have found that by using the above settings for signing identities, I can use the Automatic provisioning profile setting for allbuild configs without hiccups.

  5. Repeat your project-level settings at the target level. Another common problem is when project-level settings for code signing and profile selection don’t match the target-level settings. Unless you think you’ll never make this mistake (I used to think I could handle this. Now I know better.), manually set the code signing and provisioning profile settings at both project and target levels. Periodically check them to make sure they didn’t get out-of-sync.

  6. Delete expired certificates from Keychain Access. Keychain Access makes this pretty easy to do. Most certificates (Ad Hoc, APN, and App Store) expire after 365 days. Some Enterprise certificates may last up to three years. Create calendar alerts the same day you create new distribution and APN certificates, to remind yourself to get them updated and ready to go ahead of time, before they expire and your APN server starts flaring up with signing errors.

  7. Make sure you have all the certificates you need in Keychain Access. You will need at least two certificates for each team to which you belong: 1) A developer certificate that gives you permission to install apps on your own devices. 2) A distribution certificate that allows you to sign Ad Hoc and App Store builds. You might also need two additional certificates for push notifications (one for development and one for production builds). Developer and Distribution certificates apply to all apps on your team. APN certificates are specific to each application. Expand the carets to ensure that you also have the private keys for all these certificates. Store your certificate exports someplace that is both secure and convenient. Everyone on your team should be able to ship to the App Store in case all your senior engineers get serial-crushed by some huge friggin guy.

  8. Relaunch Xcode whenever you install new profiles or certificates.Cached expired certificates are particularly prone to caching errors.

For more posts from Jared, check out his website at:

How to do a Retention Analysis | Keen have posted a fantastic article on what Retention Analysis is, why it is important and how to do one

retention analysis will allow you to see, in numbers, things like:

  • What percentage of your users are coming back week after week?
  • What percentage of your users are paying month after month?
  • Do people typically stick around for months, or leave after a few days?
  • Did that product overhaul you released last month increase retention or hurt it?

Meaningful Metrics

It’s not hard to make a graph that looks like this. Invest more in advertising and marketing each month and you will see your usage increasing over time. 

A company with a chart like this could have abysmal retention, though. Perhaps all the users in a given month are NEW users, and none of them are going to stick around to make this app profitable.

That’s why retention analysis tells a more compelling story than “number of users doing x”. A retention analysis tells the story of “users doing X over time”.

Keen IO Cohort Analysis - 15 Weeks

Here’s an example of a retention analysis I ran recently using this Ruby script.

Reading down the left-most columns, you can see the number of accounts that have been created in Keen IO each week. Moving right across the table, you can see the percentage of those accounts that sent data in the weeks since they signed up. 

This view wasn’t quite what I was looking for, though, because the concept of retention doesn’t apply very well to users who signed up but never took any action. So I ran the analysis again in a slightly different way.

Better Keen IO Cohort Analysis - 15 Weeks

Just like the previous chart, this next chart shows the percentage of accounts we successfully “converted” to sending us data in Week 1. The difference is that the subsequent columns show the percentage of those “converted” accounts that continued to send us data in subsequent weeks (rather than the percentage of all accounts in the cohort). 

To see the rest of the article, check it out on Keen|IO


The Right Way to Ask Users for iOS Permissions | Medium

There is always a right way and a wrong way to ask someone for something, and as a kid you probably learned that if you ask your parents nicely you have a better chance of getting something than when you are more abrupt. The same goes for iOS Permissions and asking users for permissions, whether it is to use their location, address book, photos and so forth. 

I came across a great article by Medium on The Right Way to Ask Users for iOS Permissions,  which I think is an aspect of apps that are a lot of the times overlooked, but are imperative for good app UX. In the article, Brendan Mulligan begins his case by discussing the importance of getting permission-asking right first time.

Getting it Right First Time

If you have a chat app and you ask users for permission to use your contacts and they say NO, or if you have a navigational-app and ask a user for location permission and they say NO, you have pretty much rendered the core functionality of your app useless. Sure, you can then prompt the user to re-grant access to get the app working, by that would then involve going through 5 steps to grant access at a later stage. That involves getting out of the app, going to Settings, Privacy and so on. That's not a great UX. 

Turning permissions back on (source: Cluster as cited in Medium)

Turning permissions back on (source: Cluster as cited in Medium)

The key is to then prevent the user from saying NO and then trying to work out how to change his or her mind. The article proposes three approaches to address this. 

Blitzkrieg approach

This approach involves prompting the user the first time the app is launched for all the permissions needed, one by one, inundating the user, and as the article says, it's like asking someone off the street for a date without even introducing yourself

Benefit Explanation

The second approach was to explain the benefit through a walkthrough, before asking the user for permission. 

Providing benefits before asking (source: Cluster as cited in Medium)

Providing benefits before asking (source: Cluster as cited in Medium)

This is a better approach and according to the author, the acceptance rate increased from under 40% to 66%, but still not within the acceptable range if you want your app to be functional to all. 

Pre-permission Dialogs

The final approach is the preferred approach, by the author and myself. The premise of it is to only ask the user when needed, at which point the user would probably gain some familiarity with your app, and then when a particular requirement to access part of your device (location, contacts) is needed, you would get prompted.

But before you even get the Permissions prompt, ou would get a pre-permission dialog explaining why we need permission. If the user says NO, we don't provide the actual permission dialog but ask at a later stage.  

You only get one chance for the user to deny granting permission, before the user has to get out of the app and find your app within Settings. It's better to pre-ask them and defer that dialog until they are ready. 
For photos alone, 46% of people who denied access in a pre-permissions dialog ended up granting access when asked at a better time later.
— Medium

Within this approach, Cluster tried two sub-approaches, the Double System-Style Dialog approach and the Education Overlays

iOS Dialog used for permissions (source: Cluster as cited in Medium)

iOS Dialog used for permissions (source: Cluster as cited in Medium)

The first approach was to utilize the iOS system dialogs and ask twice, and their findings showed that only 3% of users who clicked Give Access, went on to deny (Don't Allow) permission, which is a great success rate. The second approach is Educational Pre-permission overlays, which I will explain.

Educational pre-overlay (source: Cluster as cited in Medium)

Educational pre-overlay (source: Cluster as cited in Medium)

This approach provides a more custom UI, with an explanation of what is needed, and what the subsequent popup will ask for. It also interestingly enough provided an alternative method if the user did not want to take that approach (which is important, you shouldn't force users to give up some of their privacy if there is another way). This dialog can of course be asked at a later stage, which is also great.

Triggered Dialogs

So, there's another third sub-approach, which I will discuss. The authors of the article discovered that users didn't make it to the final permissions dialog because they didn't want to provide access at all to the app.

What the pre-permission dialogs had done was mitigate the times where the user wasn’t expecting it, not necessarily making more users accept it. We knew we could do better.
— Medium

Intentionally triggering the prompts was the way they discovered got permission allowance close to 100%. With contacts, Cluster discovered through analyzing the biggest benefits of granting contact access was by letting them see why it would be more beneficial to allow access. 

Asking for permissions after realizing how empty the results are without (source: Cluster as cited in Medium)

Asking for permissions after realizing how empty the results are without (source: Cluster as cited in Medium)

Seeing how empty their results are (carrot and stick approach) they would eventually be prompted to grant permissions. This is a bit more cheeky in my opinion, but Cluster found that they got 100% acceptance rate as a result. The same applies to push notifications, letting them know the benefits of allowing push notifications.

(source: Cluster as cited in Medium)

(source: Cluster as cited in Medium)

The bottom line in the article, context is criticalwhen it comes to permission granting, just like life. When asking for something, the context and time is key to getting the results you want. A really compelling article, and I urge you to read the original article, published at:


The author of the article at medium have open-sourced the code, which you can get to by clicking here.

Learning Swift: Being Lazy with Lazy Instantiation


Lazy loading, or what is also referred to as Lazy Initialization is the process of delaying the instantiation of an object, deferring it until needed. Working with limited or scarce memory resources, it can be helpful to sometimes only take what you need (or in this case use what you need when you need it).

A lazy stored property is a property whose initial value is not calculated until the first time it is used. You indicate a lazy stored property by writing the lazy modifier before its declaration.
— Apple Swift Documentation (

The usefulness of this is apparent when you are in a situation where your variable value cannot be assigned immediately, but is rather dependent on 'outside factors' where the values won't e known until a dependent initialization is completed. Having complex or computational properties are expensive and deferring initialization is a way of optimizing memory usage, accordingly. 

Mike Buss conveniently illustrates how this was done in Objective-c:

@property (nonatomic, strong) NSMutableArray *players;

- (NSMutableArray *)players {
if (!_players) {
_players = [[NSMutableArray alloc] init];
return _players;

Fast-forward to the future and Swift, and we can do the same, simply as follows:

lazy var players = [String]()

Marking the variable with the lazy modifier means the property is only created when the players is first accessed. This is a great example of being explicitly efficient. 


Swift 1.2: Working with __nullable and __nonnull


Xcode 6.3 and Swift 1.2 brought about a sleuth of new features and changes, none-more prominant than  Nullability Annotations. Swift provides great distinction between optionals and non-optionals, as you noticed when you began to get accustomed to the language. 

 NSString? and NSString are treated as different types per-se, and you would only be able to inter-operate between them through wrapping and un-wrapping, which makes for safer coding. This distinction was lacking however in the predecessing Objective-C, which was constrained to representing the type as NSString*. When working with Objective-C libraries in Swift, not being able to distinct between optionals and non-optionals forced the language to forcably unwrap the NSString as an optional NSString!.  Enter __nullable and __nonnull

What is __nullable and __nonnull?

The first annotation pointer, __nullable permits the object to be denoted as either be NULL or nil, whereas __nonnull is non-null.  

In the above example, prior to Swift 1.2, we would have had the app crash, as the serial integer cannot be nil, due to it's signature as a non-optional earlier on.


 func serialAssignmentForCat(cat: Cat, forSerial serial: Int?) {


 snuggles.assignOwnerForCat(cat, withSerial: serial) 


In the latest Swift update, we don't declare serial as serial! in the Pet class function, as Swift will work out whether it is null or not. We would therefore get a warning rather than a crash, to remind us.

In the Objective-C example, we could declare, in the method call something like:

forSerial:(nullable NSNumber*)serial  

This would then signal to us if we imported the Objective-C code into Swift whether we should treat it as optional or non-optional. I think this is a great improvement and makes writing safe-code, safer when working cross-language.