Posts Tagged 'Programming'

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

iOS Dev Tools: First Aid Git is an info base; check all the similar tools too

GitHub Cheat Sheet

mergepbx: A Better Way to Automatically Merge Changes in Your XCode Project Files

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

Custom Views in XCode 6 “use Option+Shift+Click on the file name of the view, which will give you an option to pick where you want to open that file”

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

Custom Fonts in Swift

Working with IBDesignable Part 1 and Part 2

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!


See Tips: Auto Layout and PaintCode By Numbers

The Ultimate Guide To iPhone Resolutions

Using Vector Images in Xcode 6

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

How to design for thumbs in the Era of Huge Screens

What iOS 8 Means for App Design

What’s our Vector, Victor?

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

JAMSVGImage: “Display resolution independent SVGs in iOS.”; 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

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 →

Standards Marked Downer

Here’s an interesting case study on how to not make friends:

Standard Flavored Markdown

It took a while, but I’m pleased to announce that Standard Markdown is now finally ready for public review.

It’s a spec, including embedded examples, and implementations in portable C and JavaScript. We strived mightily to stay true to the spirit of Markdown in writing it. The primary author, John MacFarlane, explains in the introduction to the spec

Well, that all sounds well and good, aside from having a snicker at the obligatory xkcd 927 mention, doesn’t it? Um, no. After not too many yay! great! finally! comments on the above, we start getting

… We all use Markdown, not just you and your pals. It isn’t yours to do with as you please. Create something new, and respect prior art…

… Besides that, the hubris involved in calling your fork standard is a bit much…

… any such effort needs to do so under a new name. Not to do so is confusing to users and needlessly hostile toward John Gruber…

… Ignoring this term means you’ve broken the deal, and opens you up to a copyright infringement lawsuit…

Oops. The comments devolve from that last point into wrangling over the legal definition of ‘derivative’ … but if you’re down to arguing on that level, well, you’ve already lost, haven’t you?

Screen Shot 2014-09-05 at 2.59.35 PM.png

… yeah, that’s a pretty darn good example of exactly the kind of reaction you want your new project to avoid at all costs.

Now, we generally try to actively avoid pointless drama like this — what led us to this donnybrook was actually a handy looking new pod


TSMarkdownParser is a markdown to NSAttributedString parser for iOS implemented using NSRegularExpressions. It supports many of the standard tags layed out by John Gruber on his site Daring Fireball. It is also very extendable via Regular Expressions making it easy to add your own custom tags or a totally different parsing syntax if you like…

which looked like a particularly nicely lightweight way to manage some easy attribution of strings. ‘Course, there’s lots of other implementations around too, if that particular one isn’t adequate to your needs. Or you could always start your own flavour. “Definitive Markdown”? “Authoritative Markdown”? Those aren’t taken yet!


And the first attempt was to try “Common Markdown” and that didn’t work either … so now it’s CommonMark!

Continue Reading →

Terminally Illin’

Now here’s a veritable novelette on a topic you almost certainly know less about than Craig Hockenberry does:

The Terminal

I’ve been using the Unix command line since 1983 and like most software developers, the Terminal app is a permanent fixture in my Dock. Over the years I’ve learned a lot of things that make working in this environment more productive, but even old dogs like me are constantly learning new tricks.

As much as I love them, these long “trick lists” on Stack Overflow have a problem: they’re poorly organized with little narrative describing why you’d want to use a technique. This long homage to the command line is my attempt to remedy that situation…

As developers, we live and die by our clipboard. Code and data moves between different contexts all day long thanks to Cocoa’s NSPasteboard. It should not be surprising that pbcopy and pbpaste are simple and powerful integration points at the command line…

Most apps have preferences that are managed by NSUserDefaults. You can easily view or modify these settings from the command line using the defaults command…

Speaking of designers, one of the best ways to communicate with them is through pictures. The screencapture tool let’s you do some things you can’t do using the Command-Shift-3 and Command-Shift-4 keys in the Finder…

Spotlight search on the Desktop has become an essential tool for developers. We find code, documentation, messages and all kinds of information that’s related to our projects using Command-space and a simple text field. Would it surprise you to know that you can do more complex searches of the same dataset using the command line?…

It’s incredibly handy to control your desktop apps using the shell. Since AppleScript has always been the best way to control apps, it makes sense that there would be a command line tool. The osascript tool is one the Swiss Army would love…

A lot of the files we deal with are executable. Even if symbols have been stripped from the app, you can still infer a lot of information by looking at the null terminated strings present in the data…

If you’re developing for Mac or iOS, you already know how damn useful Instruments is for tracking application behavior. DTrace is the framework that makes all that possible. Well, take a look at all the stuff in the shell that “uses DTrace”…

Have you ever had a folder full of files that you’ve wanted to access through a web browser? You could setup Apache to do this by editing the httpd.conf file, or just enter the following command in the folder you want to access…

Data is never in the format you need it, is it? The shell’s notion of standard input and output has always made it great for doing data conversion. Here are some tools that you may not know about…

Pretty much guarantee you’ll find a whole bunch of somethings you didn’t know in there!


awesome-sox-command-line: “Use your OS X terminal shell to do awesome things.”

Continue Reading →

Tip: Open Settings URL

Oops, we managed to miss this in the WWDC videos:

Open Settings URL

A quick tip I picked up from WWDC 2014 session 715 on User Privacy. Starting with iOS 8 there is now a settings launch URL to send the user directly to the settings for an App. The code snippet below will do the trick:

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:

If you’ve got any functionality that the user can say no to, it’s guaranteed they will, and then they’ll send you angry letters and one-star reviews when it doesn’t work, you’ve all been there right? So make sure you put on your iOS 8 upgrade checklist putting in a helpful remediation option wherever deniable things can fail!

Continue Reading →
Page 4 of 95 «...23456...»