Category: business
Docset Viewer update v1.5
The past year has been quite a ride, to say the least! I have been so busy with work, creating awesome features and technologies on iOS apps that over a year has raced by without an update to my blog!
I’ve also been neglecting my own apps due to being so overwhelmed with the requirements of my work as the lead developer for Salesforce.com’s iOS Chatter app, so it wasn’t until recently that I updated Docset Viewer to add support for iOS 7. I’ve adapted the design to fit more in line with iOS7, while still providing the same experience as before on iOS6 and earlier.
In addition to iOS 7, I’ve added support for full-screen mode in landscape on iPad, hiding the sidebar. I also added search term highlighting in search results to make it easier to find the matching text you’re looking for.
Announcing Docset Viewer v1.1 for iPad and iPhone

Over the years my blog has transformed from the usual “Wordy geek ranting about first-world problems” content toward more educational and informative posts on what I do for a living: developing awesome iOS applications. I don’t usually talk about the actual applications I’m writing though, since most of my work is on other people’s apps (and I’m not allowed to spill the beans on anything fun). I still consider myself an “Indie” developer though, and just like many other developers out there, I like to solve the problems that I myself face on a daily basis.
In this case what started with me complaining on Twitter turned into a new app due to the resounding and immediate “Me too!” responses I got from some of my followers. And with that I decided to create Docset Viewer.
Revenue Canada wants me to buy an iMac 27″
Ideas On Tap, or “Speed Dating for Entrepreneurs”
Category: continuous-integration
My App Store release checklist
For the longest time it seemed that releasing an update to an iOS app was a random whack-a-mole process that I’d invariably get wrong in some way. It was maddening, especially since iTunes Connect has only recently become a decent web application. By switching to Jenkins for continuous integration of my iOS app builds I’ve greatly improved my process, but things didn’t really improve until I created a checklist for keeping track of my releases.
Since I’ve been asked many times about this very topic recently – both at work and on Twitter – I thought I’d write a post about how I bring some sanity to my release process so my app updates are timely and predictable.
Building a static library with Jenkins
One of my pet peeves is Open Source iOS libraries distributed as just a collection of Objective-C classes, rather than being bundled as a static library. I know a lot of people prefer it that way, but from a maintainability standpoint it really doesn’t make much sense to me. So when I’m faced with another library I want to use that doesn’t have a static library readily available for it, I typically wrap it up in my own Xcode project, check it in to Github, and configure my Jenkins continuous integration build server to compile it for me.
I thought I’d walk you through the steps I go through to make this happen, so you can use this technique too.
Building iOS apps for Over-The-Air AdHoc distribution
I’ve written about building iOS applications with Hudson Jenkins, but until recently there hasn’t been a convenient way of getting those applications to your testers. Of course the most important part of your build output will be the app bundle you send to Apple’s iTunes Connect web interface, but throughout your development cycle you’ll want to test your app. Sure you could build and deploy a debug build straight to your own personal device, but you get the most benefit from having other people beta test your app.
With recent releases of Xcode and the iOS SDK, Apple improved their AdHoc distribution support with two main enhancements:
- Mobile provisioning files can now be embedded in the App’s IPA itself, meaning you don’t have to maintain and update separate .mobileprovision files separately;
- A specially-formated manifest Plist file can be created that, when linked to properly, allows test devices to install new versions of your AdHoc app without needing to plug into a computer to sync the app using iTunes.
These improvements are huge, but require some changes to your build scripts and your Continuous Integration environment. I’d like to show you how to do this in your own installations, and show you some options for how to distribute your apps to your testers.
Continuous Deployment to CPAN
Recently I was working on a refactor of one of my CPAN modules which, among other things, involved changing its name from Test::A8N
to the specific Test::Story
. Doing so made me think about the process I usually go through when I consider releasing a CPAN module.
Building iPhone apps with Hudson, Part 2
Last minute talk on automated Perl builds using Hudson tonight
How to automate your iPhone app builds with Hudson
As any iPhone application developer who’s released at least a single app to the App Store will tell you, releasing your app is a terrible pain in the…well, it’s not a fun experience. After your second or third app you start to get the hang of things, but there’s still pain and suffering involved. Managing certificates, getting settings configured properly, and iterating between development, AdHoc beta builds, and the final App Store release builds, all make the process seem tediously manual and prone to human error.
Category: development
Don’t live to work…
Many people have heard the phrase “Don’t live to work; work to live”. This usually means that the goal of working should be to enable you to live your life, rather than allowing work to consume your life. Far too many people in the tech industry sacrifice their families, spouses, children, and even their sleep, in order to make it in this industry.
A Git Workflow for Agile Teams
iPhone Certificate Woes
When to refactor, and when to slash and burn it
Managing sites with Git and intelligent post-update hooks
Harder, Better, Faster, Stronger
Category: general
🎉 Celebrating my two-year anniversary at Okta
Rebooting my blog, again
I feel that every few years I write a post like this. It’s filled with statements like “Life got busy”, or “I had a problem with my server and didn’t notice”, or some other reason that seems insignificant in the grand scheme of things.
This time around though I have a very good reason for a 5-year break in my blogging activities. It started out as being just generally busy with travel, and ended up with the birth of my beautiful daughter who, at the time of this writing, is about to have her 3rd birthday. It’s been a very fulfilling experience that regardless has eaten up any spare time I have for such frivolities as blogging.
So let me take this moment to recap the past few years to kickstart my blog again!
Blogging every day ≤ Coding every day
Most blog templates suck
I’m trying to blog every day this month
I’ve moved away from Blogger
Marketing, are you stupid or enlightened stupid?
Long weekend at the Spiller Estate B&B
So much to do, so little time
Where are the Simpsons? My wife might have the solution
Anti-Valentines day, 2009
GM Bailout PR fumble
How do you name your business?
Getting started
Category: life
Don’t live to work…
Many people have heard the phrase “Don’t live to work; work to live”. This usually means that the goal of working should be to enable you to live your life, rather than allowing work to consume your life. Far too many people in the tech industry sacrifice their families, spouses, children, and even their sleep, in order to make it in this industry.
Allergies, and why Kimpton Hotels Rock
As some of you may be aware, I have enough allergies to various common foods to have earned the name “bubble-boy” from my friends. In fact, my wife’s friends used to semi-joke about me while we were first engaged that she should take a good life-insurance policy out on my, “just i n case”. She used to laugh at that, until she had to race me to the hospital a couple times, or stay up all night to make sure I didn’t stop breathing. Now it’s not a laughing matter. Now she’s paranoid for me wherever I go, always carries a spare epipen with her, and arranges our travel schedules around flights and hotels that can accommodate allergies.
Even geeks forget their passwords
This is not the toast you are looking for…
I’m now a Canadian Citizen
New job, and new career path
Filtering great ideas to fit my available time (and budget)
Silent no more…
I’m in Movember this November
I really need to broaden my music horizons
Why, oh why did I ever leave California?
Category: mobile-development
Building a stretchable UITableView header
Someone on Twitter recently asked how to implement a TableView header that will stretch and resize as the content is scrolled, so I thought I’d spend a few minutes to provide a good example. Since I thought it’s a neat trick that’s often overlooked, I felt it was worthy of wrapping a post around it to explain how it works, maybe giving others the ability to replicate this pattern for themselves.
UIMotionEffect: Easily adding depth to your UI
One of the “delightful” features of iOS is the almost imperceptible UI effects they add to give the illusion of depth. One of the most under-appreciated features is UIMotionEffect, which ties the device’s gyroscope to your views to make them adapt to how the user moves their phone.
This can be seen throughout iOS, from your lock screen to your app icons in Springboard (the iOS app launcher). Done right, the user won’t consciously notice these views moving, but it helps set certain views apart from the rest of the app’s UI, helping them “pop” and be more noticeably separate from the rest of the app.
In this post I’ll go over what UIMotionEffects are, how they work, and will share my approach for simplifying how to add motion effects throughout your application.
Styling your app using custom UIAppearance properties
UIAppearance is analogous to CSS for UIKit, while being compatible with both Interface Builder and traditional styling in code, without sacrificing performance. It’s a way of declaratively assigning UI style values to your views, without needing to manually tweak settings throughout your codebase. This makes it easy to define your app’s visual style centrally, which makes maintenance simpler when changes are necessary.
In this post, I’ll talk about how you can define your own custom UIAppearance properties in your views, allowing you to declaratively style your app giving you more flexibility and reusability.
Working with multiple architectures & compiled binaries
When working with iOS apps (or really anything within Apple’s ecosystem) I’ve sometimes found the need to deeply introspect the libraries and executables built in my project to answer questions like “Is bitcode enabled for all architectures?” or “Which architectures was this binary compiled for”, and so forth.
These aren’t easy questions to answer unless you know your way around the command-line, and which commands to invoke. So I thought I’d go over how to analyze compiled binaries, and share some helpful scripts I wrote to simplify the process.
In defence of Apple’s bug process
Everyone has a love/hate relationship with bug reports. For the user, they’re a nuisance to file. For the engineer receiving a bug report, it means extra work and the sad realization that your product isn’t perfect.
I’ve been frustrated with Apple’s handling of bug reports just as much as everyone, but haven’t really thought much about it recently. But with some recent talk on the topic, I felt like playing the devil’s advocate and wanted to share a few thoughts in defence of Apple’s engineers.
LLVM Module Maps to the rescue!
I recently wrote about Cocoa / Cocoa Touch frameworks, and in writing about it I was sorely tempted to dive into Modules, since they are pretty important to modern frameworks. But it was such a huge topic, I decided to break it out into a separate post.
In a nutshell, LLVM Module Maps were invented as a way to improve how source code imports other frameworks.
If you’ve ever worked on traditional C/C++ software projects (Makefile, CMake, gcc…any of these ring a bell?) you’ll know that the more code you add, the longer it takes to build, and the more likely you are to have conflicting types or macro definitions.
Category: objective-c
Working with multiple architectures & compiled binaries
When working with iOS apps (or really anything within Apple’s ecosystem) I’ve sometimes found the need to deeply introspect the libraries and executables built in my project to answer questions like “Is bitcode enabled for all architectures?” or “Which architectures was this binary compiled for”, and so forth.
These aren’t easy questions to answer unless you know your way around the command-line, and which commands to invoke. So I thought I’d go over how to analyze compiled binaries, and share some helpful scripts I wrote to simplify the process.
LLVM Module Maps to the rescue!
I recently wrote about Cocoa / Cocoa Touch frameworks, and in writing about it I was sorely tempted to dive into Modules, since they are pretty important to modern frameworks. But it was such a huge topic, I decided to break it out into a separate post.
In a nutshell, LLVM Module Maps were invented as a way to improve how source code imports other frameworks.
If you’ve ever worked on traditional C/C++ software projects (Makefile, CMake, gcc…any of these ring a bell?) you’ll know that the more code you add, the longer it takes to build, and the more likely you are to have conflicting types or macro definitions.
Cocoa Dynamic Frameworks
If you don’t know the nuts and bolts of how your code is compiled, linked, and executed on target devices, you aren’t alone. And lets be honest, this is perfectly fine! That’s the great thing about abstraction: not everyone need be an expert at everything in order to be effective.
There are times though where a little bit of knowledge can go a long way to help troubleshoot particularly onerous problems. So I thought I’d explain a bit about how apps work in Cocoa (and by extension, Cocoa Touch), particularly how frameworks work.
Forcing a method to run on the main thread
You know how many times, as an iOS developer, you want to ensure some method or delegate call occurs on the main thread? We do this dance countless times, and while it’s straight-forward enough, it can be a burden sometimes.
Here’s an easy way to keep your thread access safe, without having to write a lot of code in the process.
Logging with CocoaLumberjack and TestFlight
Consider the following situation that happens far too often in mobile app development: You’ve just released an app that works perfectly for you, and you’ve tested it extensively. You’re proud of your accomplishments and submit the app to the world, only to have several emails sent to you from users who have nothing but difficulties in running the app. You send a bug fix release to the App Store, but since you’re still unable to reproduce the problem you’re at the whim of luck and end-user feedback. You can hope your users know how to send you a crash report, but what if the app isn’t actually crashing? Wouldn’t it be great to be able to access your app’s log information from that client to be able to troubleshoot the problems?
Docset Viewer v1.2 and how to customize iCloud backups
I’ve recently released version 1.2 of Docset Viewer, which fixes a number of bugs people experienced with the previous version. If you had problems with the previous release, please give this one a try.
One of the improvements I’ve added is the ability to customize whether or not you would like to back up your Docsets (which can get quite large) into iCloud. To keep with the instructional nature of this site, I’ll show you how you can do that in your own apps.
Docset Viewer: Resuming large downloads with NSURLConnection
As I’ve shown in my previous post announcing Docset Viewer, I want this series of posts to be more than me talking about my new app. In keeping with the instructional nature of my site, I’m going to show you a few things that I did in my new app Docset Viewer and how I put it together. This time around I’m going to show how I use NSURLConnection
for downloading large files, and even resuming them.
In Docset Viewer I’ve added the ability to download docsets directly from Atom feeds, either from custom URLs or from a pre-configured list of Apple’s available docsets. Since you may not be consistently connected to the Internet, it’s important to be able to download documentation packages incrementally, especially since they can be anywhere from 300MB to 500MB.
Announcing Docset Viewer v1.1 for iPad and iPhone

Over the years my blog has transformed from the usual “Wordy geek ranting about first-world problems” content toward more educational and informative posts on what I do for a living: developing awesome iOS applications. I don’t usually talk about the actual applications I’m writing though, since most of my work is on other people’s apps (and I’m not allowed to spill the beans on anything fun). I still consider myself an “Indie” developer though, and just like many other developers out there, I like to solve the problems that I myself face on a daily basis.
In this case what started with me complaining on Twitter turned into a new app due to the resounding and immediate “Me too!” responses I got from some of my followers. And with that I decided to create Docset Viewer.
Core Graphics isn’t scary, honest!
For anyone who’s developed exclusively with UIViews on iOS may take the title of this post a bit oddly. “WHAT?!” they might say, “Are you insane? Core Graphics is not only a C-only API, but has confusing function names, and needs way more code to do the same thing I can do in less code in UIView”. Yes, they might be right, but there’s a reason why Core Graphics exists. It’s FAST!
But using Core Graphics doesn’t mean that your code has to be confusing, or that you have to compromise flexibility for performance. You can have your cake and eat it too (aka you can have high-performing code that is easy to read). Read on to see what I mean.
Back To Basics: Simple debugging tips in Xcode
As developers we spend most of our lives dealing with broken and barely-functional software: our own software. We do our best to make the applications we develop somewhat less broken and try to add features to make it functional. And once we finally get our software working bug-free and functioning stably, what do we do? Do we bask in the joy of a stable app and spend countless hours enjoying that moment? No, we move on to v1.1 or v2.0, adding more features and consequently more bugs. It’s kind of sad if you think about it.
Since much of our lives are spent with applications in various states of brokenness, understanding how to debug our software and catch those exceptions that arise is vital to getting our applications to a stable state so we can release, consequently moving on to create a whole new set of bugs that need to be fixed.
Here are some basic tips and tricks to make your life easier dealing with Xcode 4, and tracking down those places where your code runs off into the bushes.
Building a static library with Jenkins
One of my pet peeves is Open Source iOS libraries distributed as just a collection of Objective-C classes, rather than being bundled as a static library. I know a lot of people prefer it that way, but from a maintainability standpoint it really doesn’t make much sense to me. So when I’m faced with another library I want to use that doesn’t have a static library readily available for it, I typically wrap it up in my own Xcode project, check it in to Github, and configure my Jenkins continuous integration build server to compile it for me.
I thought I’d walk you through the steps I go through to make this happen, so you can use this technique too.
Using GCD and Blocks Effectively
With iOS 4.0 Apple introduced two new technologies to the iOS platform: Grand Central Dispatch, and blocks. Simply put, it is to multi-threaded programming what fire is to a barbecue. Sure you can do without it, but the end result is much better.
Despite all this, developers still seem to avoid using it. Some of the reasons for this, off the top of my head, could be backwards-compatibility for older versions of iOS, unfamiliarity with the funky syntax it uses, or simply a lack of practice. The biggest thing I find however is a general misunderstanding about the importance of multi-threading among new developers, which was made worse by the difficulty of dealing with threads before blocks and GCD was released.
Fortunately there’s no reason to avoid multi-threaded programming in iOS, but before I dive into the specifics I’d like to point out just how important it is to use an asynchronous approach to development on iOS, or any mobile platform in general.
Back to Basics: Using KVO
One of the things I like most about Apple’s iOS SDK is the consistent and easy-to-use API they provide. Across all their different frameworks there’s a pattern at work that makes using their classes easy to understand. This is due in part to the simplicity for configuring those objects. In most cases you don’t need to call cryptic methods to setup or teardown classes. If you want to change a label’s font, you just set a property. If you want to add a new set of tabs to a UITabBarController, you simply have to assign an array of view controllers to the “viewControllers
” property and away you go.
Back to Basics: Simple UITableViews
Following up on my previous post in this series, I’m going to continue talking about beginner topics that I and many other developers take for granted. So for this entry in my “Back To Basics” series I’d like to talk about UITableViews, and how to simply and easily construct one without convoluted or confusing code.
This topic in particular is something I’ve struggled over in the past and never managed to find a clear example for how to get started. Certainly there’s a lot of examples to show how to construct a table view, how to create a datasource for it, and the basics for how to construct cells. But hardly anyone tells you how to easily and conveniently construct a menu of options without going down a maze of twisty passages.
So today I’ll show you how you can use simple “typedef” structures to describe and control a simple menu of options.
Back To Basics: Positioning UIViews
These days I’ve been working on some fairly advanced iOS development techniques on my various projects: I’ve taught myself (badly) about Core Audio, I’m learning OpenGL, I’m developing a series of applications using Core Data, asynchronous parsing of JSON from a streaming HTTP connection, etc. It’s extremely fun and easy once you understand the basics.
What I tend to forget however is that you have to crawl before you can walk, and many people still struggle with some of the simpler techniques that I’ve learned that may not be so obvious, even when reading books or tutorials on Objective-C programming.
Since my previous series of articles on Core Animation (Part 1, Part 2, Part 3, Part 4) were so well received, I thought I’d do another series of articles titled “Back To Basics”.
So without further ado, I give you the first part in my series: Positioning UIViews.
Smarter and More Reusable Core Data
Like most developers, I look to Apple’s default application templates to get up-to-speed on what would appear as being the Right Way™ of developing apps on iOS. In practice however what you need to realize is Apple’s templates are meant to be the easiest introduction to a set of tools that can be fairly complicated for beginners to understand. Core Data is one of those areas. The problem is when you try to grow your application you’ve built on top of Apple’s sample template. You’ll experience some annoying growing pains, and will need to give your code a thorough washing and a fresh coat of wax to be able to mature your application.
In my code I’ve learned to share and reuse my classes with other applications I’m writing by encapsulating a lot of the boilerplate into reusable classes, as well as wrapping my whole Core Data model in a reusable static library. This wasn’t the most intuitive thing to get right, but now that it’s done it was really worth the effort. Let me show you how it’s done.
Building iOS apps for Over-The-Air AdHoc distribution
I’ve written about building iOS applications with Hudson Jenkins, but until recently there hasn’t been a convenient way of getting those applications to your testers. Of course the most important part of your build output will be the app bundle you send to Apple’s iTunes Connect web interface, but throughout your development cycle you’ll want to test your app. Sure you could build and deploy a debug build straight to your own personal device, but you get the most benefit from having other people beta test your app.
With recent releases of Xcode and the iOS SDK, Apple improved their AdHoc distribution support with two main enhancements:
- Mobile provisioning files can now be embedded in the App’s IPA itself, meaning you don’t have to maintain and update separate .mobileprovision files separately;
- A specially-formated manifest Plist file can be created that, when linked to properly, allows test devices to install new versions of your AdHoc app without needing to plug into a computer to sync the app using iTunes.
These improvements are huge, but require some changes to your build scripts and your Continuous Integration environment. I’d like to show you how to do this in your own installations, and show you some options for how to distribute your apps to your testers.
Animating Interfaces with Core Animation: Part 4

This is the fourth in a series of posts I’m writing on animating iOS interfaces using Core Animation. In the first post I created a planetary orbit demo using nested CALayer objects. The second post showed how to dress up a UI by animating an image. The third post shows how you can trigger animations in response to button actions.
This post will show how you can create the beginnings of a full game using Core Animation combined with CAShapeLayer and UIBezierPath objects.
Animating Interfaces with Core Animation: Part 3

This is the third in a series of posts I’m writing on animating iOS interfaces using Core Animation. In the first post I created a planetary orbit demo using nested CALayer objects. The second post showed how to dress up a UI by animating an image.
This time I’ll show how you can trigger animations in response to button actions to illustrate to the user that an action is taking place.
Animating Interfaces with Core Animation: Part 2

This is the second in a series of posts I’m writing on animating iOS interfaces using Core Animation. In the previous post I created a planetary orbit demo using nested CALayer objects.
This time I’m going to show how you can dress up a UI by creating a simple effect using an image and Core Animation.
Animating Interfaces with Core Animation: Part 1

One of the greatest things about the iOS platform and applications people see on it is its beauty. Smooth gradients, consistent transitions, and animations that illustrate the transition of UI elements from one state to another. Animations are more than flashy eye-candy; they tell the user what’s happening. If an element is being deleted, instead of it simply disappearing it fades or slides out of view. Unlike traditional desktop or web applications where a “2 items deleted” statusbar message is necessary, these animations are in many cases enough.
Knowing where to start with animations can be a problem for developers though, because there’s many different steps involved. Instead of walking you through it fully here in the blog, I highly recommend you watch the WWDC 2010 videos on the topic. I truly mean it; anything I do here will simply be a rehash of that material, and I don’t see the point in reproducing perfectly good documentation unnecessarily.
- WWDC 2010 Session 123 – Building Animation Driven Interfaces
- WWDC 2010 Session 424 – Core Animation in Practice, Part 1
- WWDC 2010 Session 425 – Core Animation in Practice, Part 2
iOS Development Link Roundup: Part 1
I’ve often been asked by people about where to start with iOS programming, whether they be co-workers, colleagues in the same line of work at other companies, or even total strangers who happen to see me happily working away on my personal projects in Xcode. Some rather naïve people assume that I learned from a book, still others even think I took a class to learn all of this! I can say definitively that it’s in my opinion that to be a great iOS developer, you just need to write apps, and lots of them. Experiment, try different things out, and more importantly, buy a few really good iPad and iPhone apps so you can see for yourself the design patterns that make good apps, and those that make poor apps.
Fun shadow effects using custom CALayer shadowPaths

Shadowed view using a rectangular shadowPath
I recently had to improve the performance of a few views that utilized CALayer-based shadows on rounded-rect UIView objects. On this particular iPad application, when the device was rotated, the views rotated quite a lot slower than we would have hoped. It wasn’t a show-stopper, but the jerky rotation animation made it look cheap and unpolished. The easiest way to have our cake, and eat it too, was to set a custom CGPath to the layer’s shadowPath property. This told UIKit to set the inside of the path to opaque, reducing the amount of work the rendering engine needed to perform.
Rendering views using CALayer, Part 1
Boomle, the underdog of my iOS apps
Recovering from bit rot
Localizing iOS apps using ICanLocalize.com

As with most things, the amount of work we as developers see when starting an iOS application is just the tip of the iceberg. There’s artwork, “About” screens, tutorial pages, icons, the app’s website, and all the marketing the app needs to get it out there. Even writing the app’s description or taking screenshots for the App Store is a time-consuming process. So anything I can do to cut down on the time needed to release my app, the better I am. Therefore when I decided to have myDrumPad translated to other languages to widen my user-base, I wanted to do make it as painless as possible.
I tried tried to have friends and family who understood foreign languages help with translations, and while they were very well intentioned it really didn’t work out in the end. What I discovered was that there really is no substitute for hiring a trained professional. But luckily it doesn’t have to be outrageously expensive. Read on for more.
Using Amazon S3 as your iOS app’s server-side
While developing myDrumPad, I came across an interesting problem for my in-app purchase support. The app allows users to download additional packs of sounds (referred to as “sound packs” in the app) that they can use to tap out songs and rhythms. The sound packs themselves were a collection of CAF-encoded uncompressed PCM audio files, with a single configuration file describing the labels and arrangement of the sound files on the drum pad’s grid of buttons.
I wanted to be able to add additional sound packs without issuing a new release of the app, but since the information describing the sound packs is largely static, I didn’t want to have to worry about maintaining a dynamic server for the app to continue functioning. I wanted it to largely be “fire and forget”.
What I came up with is, I think, a best of both worlds. The app functions without needing me to maintain a server, but I can still dynamically add additional resources to the app instantly. Read on to find out more.
Showing Apple my app via Facebook
I’ve been working recently on getting more exposure to my existing apps, especially myDrumPad. It’s a fun app, and I have a few more updates that are in the works when I get a couple of free weekends, but frankly I’d like to see its sales figures climb a bit higher than they are now. Of course, if you’re an iOS developer, you’ll know the biggest thing that can improve your sales rankings is to be featured on the AppStore. A large part of getting featured is left up to lucky chance, but to improve your odds, one of the things you can do is to target Apple employees with Facebook ads of your application. Read on to see the results I’ve had so far.
New application: Should I use Three20 or raw UIKit?
Building a custom Dashboard-like UIButton
Dealing with MKMapView’s Google logo with translucent toolbars
One of the iPhone applications I’ve written, Parking Mobility, is primarily a map-based application. Since the iPhone’s screen is so small, we want to maximize the screen real-estate while still providing navigation bars for users to interact with. To that end, the app uses a black-translucent navbar and toolbar at the top and bottom of the screen. In the past this has never been a problem, and most mapping applications do the same thing. I recently submitted a huge update to the app which is a complete re-write as a 100% native Objective-C based application (all vestiges of PhoneGap having been removed). With this latest submission though, we’ve run into problems.
Read on for more, and what I’ve done to (hopefully) get around this.
Building iPhone apps with Hudson, Part 2
Category: perl
Continuous Deployment to CPAN
Recently I was working on a refactor of one of my CPAN modules which, among other things, involved changing its name from Test::A8N
to the specific Test::Story
. Doing so made me think about the process I usually go through when I consider releasing a CPAN module.
Last minute talk on automated Perl builds using Hudson tonight
Have a list of several hundred addresses to get coordinates for? Perl to the rescue!
I ❤ HTTP::Engine
My blog and I are joining the Iron Man competition!
Category: phonegap
Telling your user that a PhoneGap application is busy
How to use the native Alert dialog in PhoneGap
Device.saveScreenshot added to PhoneGap
How to use the ActionSheet in PhoneGap
In-App purchases allowed for free apps on the App Store
PhoneGap officially permitted on the App Store
Updates on Apple / PhoneGap
Things have been busy over the past few days, which is the reason why I haven’t had a chance to post about this until now. But for the PhoneGap community, I have some good news and some bad news. First, the good news: I got a phone call from the Apple app reviewer that was reviewing my test app. And before I go any further, I want to say a few things.
Build process experiments with PhoneGap
I’ve made some quick updates on the train this morning, and ended up creating a Bourne shell script in the iPhone directory of PhoneGap for renaming a brand-new PhoneGap fork to whatever your project is called. This also works with the previous changes I made to my buildprocess branch, meaning that when you’re done, you shouldn’t have any references to PhoneGap in your code at all. It also makes developing quite a lot easier, since renaming my XCode project file by hand is cumbersome, and needs to be done every time I start a new project.