Posts Tagged 'Programming'


Gotta hand it to those Facebook engineers, they just keep coming up with cool stuff these days, and they’ve downright outdone themselves with AsyncDisplayKit:


AsyncDisplayKit is an iOS framework that keeps even the most complex user interfaces smooth and responsive. It was originally built to make Facebook’s Paper possible, and goes hand-in-hand with pop’s physics-based animations — but it’s just as powerful with UIKit Dynamics and conventional app designs.

AsyncDisplayKit Nodes are a thread-safe abstraction layer over UIViews and CALayers…

“Thread-safe” and “UIViews”? Cool beans!

Yup. All those things. Go do them!


AsyncDisplayKit Tutorial: Achieving 60 FPS scrolling

Continue Reading →

Resource Management: xcres

Well, this is the handy-dandiest resource helper we’ve seen in a while:

mrackwitz/xcres: xcres searches your Xcode project for resources

xcres searches your Xcode project for resources and generates an index as struct constants. So you will never have to reference a resource, without knowing already at compile time if it exists or not.

It includes loose images, .bundles, asset catalogs (.xcasset) and even .strings in the index.

It gives you code autocompletion for resources and localized string keys, without the need of an Xcode plugin.

Especially if your app is a bit more complex, this will greatly improve your workflow. It ensures a better quality and gives you more safety. You will see directly when a resource is missing, when you renamed it, or you moved it around.

Furthermore it won’t even bother you for trivial name changes like change capitalization or converting name scheme from train-case or snake_case to camelCase and vice versa.

It will warn you in Xcode on build, if certain resources or string keys can’t be references, because their name contain invalid chars, duplicates in the camelCase variant with another key, or would be equal to a protected compiler keyword…

We tend to keep our resource references pretty much in order by reflex when writing them actually, but looks like this might make that more streamlined. And looks like it would be downright invaluable the next time we’re handed some mess to make sense of written by someone who regarded the concept of ‘maintainability’ with fear and loathing apparently…

h/t: CocoaControls!


Working with Localization in iOS 8 and Xcode 6 describes new string functionality

Continue Reading →
0’s Functional Programming In Swift

As you’ve probably noticed us gushing over here and there, is the highest-quality programming journal in the history of ever for us epicurean iOS-centric types; so when we noticed that the good folk over there have branched out into books,

Functional Programming in Swift

  • Thinking Functionally: Get to know the functional 
programming paradigm
  • Functional APIs: Designing functional, composable, and type-safe APIs
  • Purity: Benefits of value types and immutability
  • Purely Functional Data Structures: Use recursive enums to write simple data structures
  • Parsing & Evaluating: A functional parsing library and a simple spreadsheet app as example
  • Map, Filter, Reduce: Higher-order functions and functional manipulation of collections
  • Optionals: How Swift solves the “missing value” problem, and why that’s a good idea
  • Enums: Create your own data types with Swift’s enums for clarity and type safety
  • Generators and Sequences: Understand the machinery underlying Swift’s collection types
  • Applicative Functors and Monads: Common patterns underlying functional code

we figured the least we could do in thanks was go buy it … especially since the last time we did any real functional programming was a course so way back in the day that it used a pre-1.0 Haskell version. So y’know, a little help here to catch up on the last two and a half decades, probably in order, yes. Besides, we were immensely amused with Messr. Florian’s blog post about floundering around during the writing process.

And our evaluation is, they’ve done an absolutely wonderful job here. If you’re not fluent in functionalese, it gets the GO BUY IT RIGHT NOW rating; and if you are, there’s still enough Swift specificities and useful code right up to the complete spreadsheet implementation mentioned above that we’re completely confident you’ll find it more than worth the read!


7 Habits For a More Functional Swift

Getting into functional programming with Swift

An introduction to functional programming

What is Functional Reactive Programming?

Introduction to Function Currying in Swift

Adopting map() & reduce() in Swift; Function Composition in Swift

Functor and Monad in Swift; Monads; Swift Adventures In Monad Land; Functor and Monad in Swift

Tail Recursion Explained

Immutable Types with Changing State in Swift; Conveniently Transforming Immutable Types in Swift; Mutating Functions in Swift Structs

Proof in Functions

Functional Wish Fulfillment; Maps… Wait, They Don’t Love You Like I Love You; Flattenin’ Your Mappenin’

A straw man argument for trying more functional-style programming in Swift

Efficient JSON in Swift with Functional Concepts and Generics; SwiftyJSON; Nice Web Services, Swift Edition

TypeLift: “Libraries to simplify development of Swift programs by utilising the type system.”

typelift / Basis: “Pure Declarative Programming in Swift, Among Other Things.”

typelift / Swiftz: “functional data structures, functions, idioms, and extensions that augment the Swift standard library.”

LlamaKit / LlamaKit: “Collection of must-have functional Swift tools.”

Going Global: A Peek At Swift’s Global Functions

Continue Reading →

SpriteBuilder 1.3

Just in case you haven’t been keeping track of developments over in the Cocos2D-Swift (née cocos2d-iphone) world, you might want to take a look at how SpriteBuilder is continuing to shape up right nicely into a — nay, the — friendly cross-platform development environment:

SpriteBuilder 1.3 Beta

In this beta, you’ll get early access to exciting new features we’re working on for the 1.3 full release, including:

  • The all-new Cocos2D Metal renderer for iOS 8 (and compatible devices)
  • CCEffects UI – add and edit amazing effects in SpriteBuilder with a few clicks!
  • Packages in Cocos2D – load groups of resources dynamically in your game!
  • An improved OpenGL renderer with multithreading option
  • Other iOS 8 optimizations and bug fixes

And, last but not least… the SpriteBuilder Android Plugin, now in public beta!

The what?

The SpriteBuilder Android Plugin extends the Cocos2D game-building power of SpriteBuilder to both iOS and Android. The SpriteBuilder Android Plugin uses clang to cross-compile Objective-C to native ARM and x86 machine code – no virtual machines, emulators, or Java translation. Your app will run faster than a Java-equivalent Android application. Additionally, since you have full access to every iOS and Android API, you maintain complete control over how your application is built. The SpriteBuilder Android Plugin allows you to expand your game’s audience while still using the Xcode environment you are familiar with…

Last few months we’ve been picking away at getting an old school cocos2d game with heavy UIKit overlays up to speed with the apportable library. Our conclusion was that why yes once upgraded to Cocos2D-Swift 3.x the Cocos2D bits went quite impressively smoothly; the UIKit stuff … well, mostly there. With just enough not in that mostly to cut the experience down somewhat from unqualified success. Looks like our experiences there are not terribly unusual, as it seems like Apportable is doubling down on what they do well here and scaling back on the everything to everybody idea. Best of luck to ‘em!

Continue Reading →

Git Stuffed

Don’t think we’re ever going to git on board with the rest of the world’s VCS of choice these days, just curmudgeonly mutter forever about the near-infinitely superior Veracity languishing in near-total obscurity; but if you’re going to git on with other people these days you don’t have much choice it seems, and hey we can actually git down with SourceTree these days not too badly (2.0 is just out, and looking sharp) … except when it totally trashes an Xcode project merge. Oh, right, that’s like EVERY @(#$&@%^!!! SYNC it seems. And then all in earshot git treated to a choice Troll Rant™ about burning it to the ground and then nuking it from orbit and then it’ll be time to really git serious. If you have more than one person trying to git any real work done, we’re sure you know the feeling.

But from one Michael Krause comes word of a handy-looking little tool for possibly reducing your blood pressure in these situations:


xcodeprojer is a Python script that brings your project.pbxproj files in order. It can transform any kind of JSON, XML or plist format into an internal representation and generate exactly the same commented plist format that Xcode itself uses.

Without relying on Xcode at all this can be used for tasks like this:

  • Ensure the canonical plist format of the project before checking in a new version.
  • Perform custom modifications via these steps
    1. transform your project into JSON or XML.
    2. manipulate the JSON or XML object tree in a language of your choice.
    3. emit JSON or XML and let xcodeprojer create the proper plist for you.
  • Perform custom modifications directly via Python with xcodeprojer as a module.
  • Repair broken projects, a failed parse reports the line and column where the parser failed.
  • Doing all of the above even on a non-Mac computer because it is written in pure Python…

That should reduce our falling back to the git pretty workflow every time two people work at the same time. We hope.

A considerably lesser but still regularly occurring problem we git annoyed by is figuring out how to git a build number that makes some kind of sense automatically. And we can git you some help with that too: here is the risibly named post

The Best of All Possible Xcode Automated Build Numbering Techniques

This script uses the PlistBuddy command line tool to edit the build number of the Info.plist in the /foo/DerivedData/bar directory, the target’s build directory. This is why git isn’t dirtied when the build number changes. It doesn’t matter what you’ve entered in your Info.plist screen in Xcode. It also updates the build number for every build, not just the first build after a total clean … It uses the git commit count for the build number, but if it detects that we’re using our Debug build configuration in Xcode, it suffixes the build number with the current git branch name. This avoids potential build number collisions across feature branches under simultaneous development

That sounds … well, tolerable, actually, can’t think of a number-related problem we’ve had that wouldn’t have avoided.

And as a final note, it seems that even command line git these days can be somewhat more advanced of interface than banging two rocks together in the dark and hoping sparks fly out:

Git Tutorial – Git Fu With The Command Line


Tool: Handy iPhone And iPad App For Updating Code In A Git Repo On The Go

Git from the inside out

How to write the perfect pull request

Continue Reading →

Apple-Paying The Piper

So between squeeing over the watches and squealing over the bendy phones and free music and all the other nonsense that just seems to get sillier all the time, anybody remember that other little thing Apple squeezed into their do?

Apple Pay For Developers

Apple Pay Human Interface Guidelines

Apple Pay Programming Guide

Haven’t seen very much discussion of that yet, but we’re kinda suspecting here it might turn out to be more of a Big Deal than most people are expecting right now. Here’s an excellent article to catch you up if you’ve been in the distracted by the shiny things crowd:

How Apple Pay works and why it matters for developers

Background: Clover and First Data (our parent company) have been working with Apple to prepare for the launch of Apple Pay to support developers, merchant acquirers, and issuing banks (see First Data’s press release). Clover is enabling all merchants to accept In-App payments, and will be In-Person/NFC enabling all merchants as well (see Here’s a bit of how it works from a developer’s perspective, and why it matters…

Apple Pay marks the first time a popular operating system is making payments a platform service for real-world, non-digital-good transactions, in a broad, inclusive manner that is compatible with the mainstream payments processing industry. At Clover we’re particularly excited because we believe it opens up lightweight apps that can interact and transact with small-and-medium brick-and-mortar restaurants. By lightweight, I mean that these apps won’t need to maintain a user database, require user logins, worry about getting cards on file, or being an unwilling payment aggregator. i.e., it will be at least 10x easier. I expect a huge amount of innovation in real-world mobile commerce as a result over the coming years because of the revolution that Apple Pay is starting…

Generally we tend to dive headlong into Full On Mockery Mode™ soon as we see “revolution” touted in this industry, as perhaps the Dear Longtime Reader may have noticed here and there; but yeah, in this particular case, ok, this just could turn out enough of a thing that “revolution” would only be mild hyperbole. If the details are a bit eye-glazing to you, we’ll tl;dr here from the comments:

This article does explain the advantage Apple Pay has over other eWallet systems. By utilizing Network-Level Tokenization, Apple has integrated with all gateways, processors, issuers, and acquirers in the current payment scheme by negotiating directly with Visa, MasterCard, AMEX, Bank of America, JP Morgan Chase, Wells Fargo, and the list goes on…

This isn’t something that other eWallets have done. Thus, why Apple Pay will be around… and others won’t.

We’re pretty firmly on board with that prognostication.

There’s some more perspectives worth reading collected over at Michael Tsai’s blog.

And here’s a list of Apple-recommended payment platforms:

Authorize.Net : $49 setup, $25 monthly, 2.9% + 30¢ transaction : support, apply

Braintree : 2.9% + 30¢ transaction : support, apply

Chase Paymentech : $9.95 monthly, 1.99% + 25¢ (and up) transaction : support, apply

CyberSource : $CALL! :

First Data (Payeezy) : 2.9% + 30¢ transaction : apply

Stripe : 2.9% + 30¢ transaction : support, apply

TSYS : $5 monthly, 2.7% transaction : apply


“Starting today, any Stripe user can begin accepting Apple Pay in their iOS apps.”: stripe / stripe-ios

Chez Wenderlich’s Apple Pay Tutorial with Stripe

NSHipster’s Pay

Why Apple Pay is the Most Secure Form of Payment

Continue Reading →

Xcode 6 Custom Interface Builder Previews

Ah, yes. This was the thing that kept us scrabbling on by our fingernails to developing applications in PowerPlant (remember that?) long past when everyone else who could read the writing on the wall had long since jumped ship to Cocoa; not being able to lay out your UI with preview seemed so hopelessly retrograde to us that there was no way we’d work without Constructor unless we had to.

And, well, then Carbon never made it to 64-bit, so we had to for a decade. Funny how these things go.

So although we can’t quite work ourselves up to be quite as celebratory as their effort probably deserves, it does deserve celebration that, FINALLY, our workflow can now include


These two new keywords have been added to Xcode 6 to preview our custom views directly through Interface Builder. That’s right: this is a dramatic improvement in terms of re-usability, sharing, and, in a way, testing.

We prefix our class with the @IBDesignable keyword to inform Interface Builder that the class’ instances will try to design themselves when added to the storyboard…

Then, prefixing any properties of the class with @IBInspectable, we ensure that Interface Builder can read and write the value of these properties directly in the inspector view…

The previous code will end up returning new fields in Interface Builder to setup that property … and in the ViewController in the storyboard we get a preview of the view like for any other UIKit component:

That’s pretty much it really, but read the whole thing for a good walkthrough!

h/t: ManiacDev!


Tutorial: Step-By-Step Guide To Creating A Great Looking Custom UI Control In Swift

Custom Live Views and Auto Layout

Xcode Live Views: Killing them softly with PaintCode

IBDesignables in Xcode 6 and iOS 8

Tutorial: Creating Custom Components That Can Be Previewed And Modified In Xcode 6

Modern Core Graphics with Swift: Part 1 and Part 2 and Part 3

Creating Custom Animated Buttons

NSHipster’s IBInspectable / IBDesignable

Creating Your Own Custom Controls Using IBDesignable in Xcode 6

Continue Reading →

iPhone 6 Screen Apoplexia

Starting to feel like you’re totally losing the plot now that your iOS app can find itself living in five different point dimensions,

  • 320 x 480
  • 320 x 568
  • 375 x 667
  • 414 x 736
  • 768 x 1024

and three different point scales,

  • @1x: up to iPhone 3GS/iPod 3G/iPad 2/iPad mini 1
  • @2x: everything later except
  • @3x: iPhone 6 Plus

and even a logical to physical downsampling discrepancy on top of that? Here, go check this out to explain it:

iPhone 6 Screens Demystified

To demonstrate different rendering of pixels on various devices, we compare how 1-point wide line is rendered on

Original iPhone – without retina display. Scaling factor is 1.

iPhone 5 – with Retina display, scaling factor is 2.

iPhone 6 Plus – with Retina display HD. Scaling factor is 3 and the image is afterwards downscaled from rendered 2208 × 1242 pixels to 1920 × 1080 pixels.

The downscaling ratio is 1920 / 2208 = 1080 / 1242 = 20 / 23. That means every 23 pixels from the original render have to be mapped to 20 physical pixels. In other words the image is scaled down to approximately 87% of its original size…

TL;DR: If you haven’t yet … it’s time to buy PaintCode!


Using Vector Images in Xcode 6

Xcode 6: Live Rendering, Visual View Debugging, and Swift

Responsive iOS Buttons with PaintCode

Adaptive Layouts For iPhone 6

How to design for thumbs in the Era of Huge Screens

Adaptive user interfaces

What iOS 8 Means for App Design

What’s our Vector, Victor?

iPhone 6 Plus Pixel Peeping

Open Source: Category For Easy Embedding Of PDF Images In iOS Apps For Scalable Images

jmenter / JAMSVGImage: “Display resolution independent SVGs in iOS.”; timrwood / SVGPath: “Parse SVG path strings into UIBezierPaths in Swift”; The Ultimate Guide to SVG; check out our old SVGKit notes

iPhone 6 Plus Pixel Peeping; … Follow-up

Sizing class for iPad portrait and Landscape Modes

Open Source Swift Library That Greatly Simplifies Working With Auto Layout

Size Classes Tutorial

Adaptive Auto Layout

Continue Reading →

Tip: Xcode 6 Bundle Signing

Having this problem with your shiny new Xcode 6 GM?

Screen Shot 2014-09-10 at 8.12.00 AM.png

Problem also discussed here.

Solution 1:

Adding the `–deep` flag to “Other Code Signing Flags” (OTHER_CODE_SIGN_FLAGS) got me around this.

Solution 2:

Delete Info.plist inside the bundle if it’s only a resource package.

(And if there’s some reason you need it, at least delete the ‘CFBundleExecutable’ key.)

Good luck with that!

Continue Reading →

Layout Best Practices

Read of the day while you’re nervously waiting to see what will need panic rewrites tomorrow:

Screen Shot 2014-09-08 at 8.33.11 AM.png

Don’t think there’s anything in there actually covered by NDA at this point, but we’ll just refer you there for the beta software feature discussion bits. The important parts are not new, but they’ve been widely disregarded to date, at least they sure are in software we get stuck maintaining:

  • Nowhere should you be using screen or window size to do layout. Your view bounds should be the only consideration.
  • At load time, as called out above, you’re not in a hierarchy yet. Therefore you do not know what your view bounds will be. This has always been a thing for any view contained by a view with its own layout, and became more of a thing with iOS 7 when your views developed an inclination to jump under the status bar behind your back, but rumour has it that it will be a big thing very soon.
  • layoutSubviews is the best place to be putting your legacy-type frame setting code.
  • updateViewConstraints is the correct place to figure out your interface for reals; if you’ve so far avoided auto layout, now is a superb time to get on that.

Hopefully none of this is any particular news to you, so getting all those legacy codebases copacetic with whatever novel execution environments actually appear tomorrow from the collection of swirling rumours should be no problem, right?

Continue Reading →
Page 3 of 94 12345...»