Archive for 'Programming'

Stylish Setup: KZBootstrap And Fabric

We’ve scattered here and there various references to goodies that make managing your Xcode project easier and/or more reliable, but here’s a particularly sweet-looking collection of most all the best bits we’ve noted plus some new clevernesses:

krzysztofzablocki / KZBootstrap: “iOS project bootstrap aimed at high quality coding.”

Each configuration can be put side by side on same device, and you can clearly distingiush each build. Easier to find issues across different version and branches…

Automatically generate macro for current developer, that way a team can have different code paths while they are working on features, or different logging levels. Without git changes.…

Often when working with big clients, you need to have multiple environments for Staging / Production / QA etc. They usually differ in some kind of configuration … Environments can be changed without reinstalling application, even while it’s running…

assertions when UIKit is layouted/displayed on background thread, so you can fix your code…

Let’s put it this way, even if you’re not particularly interested in adopting all the goodies here wholesale, it’s a useful exercise to go through all the various capabilities and understand them for when they or something along their lines might prove useful. As well as the various source references:

And while we’re on the subject of setting up new projects, if you haven’t looked at Twitter Fabric yet we’d recommend that’s a good thing to do; as Crashlytics is the only third party service we regard as an absolute necessity for any project at the moment, and if the other services Fabric provides are as competently executed and easy to manage as Crashlytics is, well we for one welcome our new Twitter overlords!


futurice / ios-good-practices: “Good ideas for iOS development, by Futurice developers.”

Continue Reading →

Core Motion Slickness

The always-invaluable NSHipster has some particularly nifty trickiness in an article on Core Motion:


Let’s say we want to give the splash page of our app a fun effect, with the background image staying level no matter how the phone is tilted … Using the gyroscope, Core Motion separates user movement from gravitational acceleration and presents each as its own property of the CMDeviceMotionData instance that we receive in our handler…

We can also use the other, non-gravity portion of this composited gyro/acceleration data to add new methods of interaction. In this case, let’s use the userAcceleration property of CMDeviceMotionData to navigate backward whenever a user taps the left side of her device against her hand…

Lastly, let’s try using the device’s attitude to enable a new interaction for a flash-card app, designed to be used by two study buddies. Instead of manually switching between the prompt and the answer, we’ll automatically switch the view as the device turns around, so the quizzer sees the answer while the person being quizzed only sees the prompt…

Read it all!

Continue Reading →

SceneKit and Swift

Hmmm, looks like we’ve managed to completely overlook the existence of SceneKit in the annals herein thus far, even though it’s been around for a couple years on OS X now. So hey, why not skip learning about SceneKit in Objective-C completely and go straight to SceneKit in Swift? Everybody seems to have that idea lately:

Create Stonehenge with iOS SceneKit and Swift

SceneKit has been described as the casual game developer’s framework. Since I started playing around with it a few weeks ago, I’m having a little trouble putting it down…

Straightforward exposition of how to set up ground, sky, and build Stonehenge.

Introduction To SceneKit – Part 1 and Part 2 and Part 3

Let’s look at creating a new project that uses SceneKit. Apple provides a template for SceneKit projects(Application -> Games) but for this tutorial we’ll be adding SceneKit to an existing project to get a better understanding on how it works…

Exhaustively detailed introduction to 3D basics in SceneKit with the latest Xcode.

Beginning Scene Kit Tutorial

In iOS 7, Apple made a huge push in the casual, mobile gaming space by introducing Sprite Kit, an incredible 2D-graphics framework. Developers had plenty to chew on for a whole year, and Sprite Kit gave everyone the capability to make simple iOS games with relative ease.

However, the 3D space continued to be largely inaccessible, requiring expert knowledge of computer graphics (OpenGL ES), or a sizeable wallet (Unity Pro).

Well, not anymore. :]

A teaser for the SceneKit chapters in the Wenderlich publishing empire’s iOS 8 By Tutorials, which we’d recommend purchasing as part of the Swift By Tutorials bundle, as we did!

UPDATES: #18, Games: Scene Kit

kconner / KMCGeigerCounter: Make your app click like a geiger counter every time it drops a frame.

Example: A Nice First Person Shooter Control Scheme For SceneKit Games

Merry Swiftmas from InfoQ

Continue Reading →


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

Introduction to Function Currying in Swift

Adopting map() & reduce() in Swift

Functor and Monad in Swift

Tail Recursion Explained

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

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


“Starting today, any Stripe user can begin accepting Apple Pay in their iOS apps.”

Chez Wenderlich’s Apple Pay Tutorial with Stripe

NSHipster’s Pay

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

Continue Reading →
Page 2 of 98 12345...»