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 Realm.io, another group of folks that I really enjoy and appreciate. 

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

An excellent article by Steven Jacobs of StreetFight on the 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.

Programmatic
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. 

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)

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)

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)

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)

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)

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)

(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: https://medium.com/launch-kit/the-right-way-to-ask-users-for-ios-permissions-96fa4eb54f2c

 

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


swift-logo-hero.jpgswift-logo-hero.jpg

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 (http://goo.gl/FHpjMq)

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


swift-banner.pngswift-banner.png

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.  

https://gist.github.com/doronkatz/321b5950939850ae6b6f.js

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.  

 

Swift Style Guide: April 2015 Update | Ray Wenderlich


@RayWenderlich has just published a Swift Style Guide update or April, covering Swift 1.2 which was just released from beta a few days ago. 

Multiple Optional Binding

Swift 1.2 now allows you to optionally bind multiple things in one line. Our style guide recommends using this new style, rather than the old style of multiple if let statements:

// old
if let widget = widget {
if let url = options.url {
if let host = options.host {
// widget, url, and host are all non-optionals
}
}
}
 
// new
if let widget = widget, url = options.url, host = options.host {
// widget, url, and host are all non-optionals
}

This new syntax lets you avoid the “pyramid of doom” when you had to test and bind several optionals.

So many spaces saved!

Note you can also include boolean conditions in your if let statements, which can make your code more concise as well.

Enumerations and Case

After a good amount of discussion, we formalized the style we were using in our tutorials: UpperCamelCase for enumeration values.

enum Language {
case Swift
case ObjectiveC
case ObjectOrientedFortran
}

There’s a bit of an inconsistency since enum values are like class constants inside the enum scope, and feel like they should be in lower-camel case. However, the style guide usage matches our general practice, existing enumerations in Cocoa, and Swift itself – remember, optionals are implemented as enums with values Some and None which begin with a capital letter.

Trailing Closures

Trailing closures are great for keeping the closure expression linked to its function call, without having to wrap them in the argument parentheses.

UIView.animateWithDuration(0.75) {
self.dogeImage.alpha = 1.0
}

Our old guidance was to use trailing closures wherever possible. However, there’s one special case where this isn’t a good idea: when there are two closure arguments! In that case, you should use the normal syntax to keep both closure expressions “on the same level” with named arguments:

UIView.animateWithDuration(1.0, animations: {
self.myView.alpha = 0
}, completion: { finished in
self.myView.removeFromSuperview()
})

The alternative is to have one named and one trailing, which looks strange and we recommend against.

// Don't do this!
UIView.animateWithDuration(1.0, animations: {
self.myView.alpha = 0
}) { f in
self.myView.removeFromSuperview()
}

Function and Method Naming

As in Objective-C, a full, unambiguous function signature includes the method name and its named arguments. When referring to a function in a tutorial, we follow the same formatting as you see in the Xcode jump bar:


 

Previously, we said it was OK to write just the bare function name if the context was clear. That allowed us to write viewDidAppear rather than the full viewDidAppear(_:).

After some discussion, we decided it was best to be clear about whether something was a function or a variable. The new guideline is to always include the full signature. That means something like viewDidLoad() where there are no arguments, and tableView(_:cellForRowAtIndexPath:) where there are arguments.

MARK

In the last style guide update, we introduced the rule of one extension per protocol. That keeps the protocol conformance together with the protocol methods, and makes adding and finding related code easier.

As an addition to that rule, we want to start adding MARK comments to provide better navigation.

// MARK: - UITableViewDataSource
 
extension MyTableViewController: UITableViewDataSource {
// table view data source methods here...
}

Extensions are great for grouping methods together, and the MARK comment should help navigating your way around source files even easier than before!

Code flows out much easier when your files are well organized!

Shadowing

Speaking of optional binding, one thing that hasn’t changed in the style guide is that we use the same name for the optional and the unwrapped version:

var subview: UIView?
 
// later...
if let subview = subview {
// referring to "subview" here is the unwrapped version
}

The benefit is that the names remain short and we avoid things like maybeView and unwrappedWidgetand optionalTableView. Once you understand Swift and optionals, the code makes sense. The downside is that the code just looks strange and can be hard to read and understand for beginners.

The issue thread on variable shadowing is still there and we’re open to change things if you’re especially convincing. “Especially convincing” includes offers of an Apple Watch Edition, of course. ;]

You can also follow the style guide updates on their official Github page, at: https://github.com/raywenderlich/swift-style-guide.

 

A Beginner’s Guide to Growth Hacking | ThinkApps

A fantastic article by fellow ThinkApps writer Katelan Cunningham (@kalivia), on growth hacking.  


taxicabs-498436_1280.jpgtaxicabs-498436_1280.jpg

One of the startup buzzwords that you’ve no doubt heard a lot lately is “growth hacking.” Some see it as the anti-marketing. In fact, Morgan Brown, who cofounded Full Stack Marketing and leads growth for the Growth Hackers community, says that marketing can kill a startup. When done poorly, marketing can suck up a lot of time and money early on, when you’re still shooting in the breeze and have nowhere to aim.

But, if you’ve always thought that “marketing” and “growth hacking” were just different words for the same thing, others might say you’re right. The lines are getting more and more blurred, and some make the argument that they’re just different stages in the evolution of the same job.

Rather than pointing out what marketing isn’t, it may be more productive to define what growth hacking is.

What Is Growth Hacking?

Growth hacking is where engineering and marketing meet. We’re talking tracking, tracking and more tracking, which leads to rapid growth that goes as viral as possible for little money.

Growth marketers focus on the complete user funnel from “Awareness” all the way through “Referral” rather than just raking in users and letting the numbers stop there because the full product story goes way beyond the buy.

In his lecture, From User Zero: Lessons in Growing Startups from Scratch, Morgan Brown talks about getting started in growth marketing and how to begin from nothing. 

Start with a Must-Have Product

If founders have said it once, they’ve said it a million times — you can’t build a good business from a bad product. Period.

This is a bigger deal for growth marketers than traditional marketers because a growth marketer won’t be on the outskirts of your team; instead he or she will be in the thick of it. This process is ideal for coming up with really genuine ideas for growth that will resonate with your audience.

Brown said that your growth journey starts with product-market fit and from there you transition into growth, and then actually attain growth. In fact, Sean Ellis, who coined the term “growth hacker” and cofounded the Growth Hackers community, says that product-market fit is the very first stage of your startup growth, which is followed by growth preparation and then scaling growth.

Write Your Story

Native user acquisition starts with a story, so what is yours? Once you know your story, you can better find your audience and focus in on your mission.

A great example of a company tapping into where there audience lives is when Airbnb integrated with Craigslist. There was already a huge audience on Craigslist (tens of millions!). They simply added a button to a user’s Airbnb posting and made it easy to post right to Craigslist, without having to do much with the messy Craigslist interface at all.

Have a Tracking Plan

You’re going to be tracking way more than page views. You’ll want to keep tabs on click-throughs and signups, but it’s even more than that. In his Medium post about researching the world’s fastest-growing startups, Brown said that successful companies don’t just report on numbers. They gather insights from them and use them to grow.

There’s certainly no shortage of potential metrics and tools for measuring them out there. But if all you’re getting from the numbers is numbers, then you’re missing the point.

Having a clear cut tracking plan, like the one shown below, will ensure that you’re getting the most out of your analytics. (The spreadsheet was created by 500 Startups and originally shared by Tammy Camp in her AMA on the Growth Hackers site.)

Know Your Acquisition Channels

The type of acquisition channel you should tap into is dependent on what type of company you are.

Paid Acquisition

You’re basically paying for customers. Brown gives the examples of Groupon and e-commerce companies.

Virality and Referrals

According to writer and entrepreneur Andrew Chen, not every product can be viral. That’s the case for SaaS products.

Marketer and entrepreneur Ryan Gum says that you have the best shot of going viral if your product is social in its nature, involves communication, or is something that people will naturally talk about.

SEO

If you can optimize all of your pages for SEO, that’s a good place to start for any business. Brown gives the examples of Quora and TripAdvisor as companies that benefit most from this channel.

Sales

If you fancy yourself a salesman, then over time, you’ll narrow in on your perfect pitch. But as you’re growing more and more, it’s just not feasible to rely on this channel for acquiring users through demos.

Checkout the rest of the article at: ThinkApps.

Capture the Attention of Venture Capitalists with the 10|20|30 Rule


A man I respect a lot, @guykawasaki, who has worked with Apple, Google and has been behind a lot of great venture projects under Garage Technology Ventures, evangelizes a great approach towards capturing the interested investor or investors, without over-burdening them with unnecessary crap. It’s called the 10|20|30 ruleSimply put, it means:

10 Slides in your presentation

Humans aren’t meant to read more than 10 concepts in a meeting, so 10 is the most optimal number of slides a person can read and internalize. If you need to go beyond 10 slides, it means you can’t articulate your business well enough and perhaps should re-think your venture. 

20 Minutes

You have 20 minutes to pitch your 10 slides, allowing the rest of your time to be taken up by questions from the audience. Less is more, and being succinct captures imagination without inundation.

30-Point Font

Don’t have essays up on your slides, use 30-point fonts to force yourself to be concise. More text isn’t more convincing but rather the opposite, it means you are nervous and need to continuously justify your claims and hypotheses. 

Instead, fewer text allows for impressions to be embossed in the audiences minds, 

 

Guy suggests you focus on the following points which venture capitalists care about the most:

  1. Problem
  2. Your solution
  3. Business model
  4. Underlying magic/technology
  5. Marketing and sales
  6. Competition
  7. Team
  8. Projections and milestones
  9. Status and timeline
  10. Summary and call to action

 

 

Programming on iOS with Swift: Working with Functions and Nested Functions (Beginners)


Nested Functions

An under-utiilzed but interesting use of functions are as nested functions, functions that are essentially not global but privately embedded within another function. Sure you can have functions declared as private, but that will only protected the function from being accessed by another class. 

Protected from external access, nested functions can be called and used by their enclosing function, which can also return the nested function. I see nested functions as providing an encapsulated convenience like closures, allowing you to complete your function within the function rather than chasing the calls across the class. In the following code, the nested function is only accessible within it’s parent or enclosing function:

https://gist.github.com/doronkatz/f2ec5901b46f325032ad.js