Vince Mansel
iOS Mobile Application Development
Show Menu

4Loader – A Simple iOS Multithreading Demo App


As I have been digging deeper into multi-threading aspects of iOS development, I wanted to investigate several “patterns” for application architecture to support concurrent i/o (downloading/networking), and multi-processor/multi-core CPU bound task (batch calculations and processing of large data sets).

For  CPU bound tasks, I like to refer to a generic producer-worker-consumer pipeline pattern where the producer supplies data that is divided up to mulitple workers then merged to produce the result to hand to the consumer. I will talk about that in a future article.

For concurrent i/o, I designed a simple app called 4Loader that utilizes an overall Model-View-Controller application architecture, and for concurrency is guided by a “request-control-operation-task-event” pattern (i use these terms loosely to not refer to other well-known design patterns by similar names). In its current form, the app has four hard-coded URL of San Francisco images that are downloaded when the user taps one of the quadrants in the view and touches Go. The image in quadrant 1 is over 3MB in length, and the other three are various sizes. The point is to demonstrate how the app handles i/o concurrency by starting the download of the image in the first quadrant, then seconds later, the user downloads another image or two in the other quadrants. Concurrency is “happening” at the networking layer (task-event) while the concurrent operation (the client to the networking task) maintains state in the form of the quadrant view that requested the download.

Check out the demo. On the controller layer, It utilizes NSOperationQueue to manage the concurrent DownloadOperations (which are NSOperation subclasses). Each DownloadOperation also fires off a NSTimer for timeouts which execute in its own NSRunLoop. In additional, to maintain the networking layer, the operation layer keeps an NSRunLoop “alive” until the download is completed, results in an error or times out. NSURLConnection, in its asynchronous form, it utilized to capture the data and keep progress updates. Download images are cached with a custom NSCache object (only for demo purposes. I would use a different storage/caching scheme for large image downloads). At the operations layer, Grand Central Dispatch is used to handle callbacks to main queue (through Delegation) to update UI (progress updates, displaying the image or timeout alerts).

The code is available at github.

A Jenkins Automated Build & Test Environment for iOS App Development Part 5


Here is some more progress and learnings:

  • ShowPlan has three third party libraries that require special handling. They are not saved in the main repository and must be integrated individually.
  • Some additional scripting is required to reconstruct the project to a state where the build environment resembles the development environmnent.
At the moment, the job of building the Appirater third party is failing with:
stderr: fatal: ambiguous argument 'AP/^{commit}':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

The work up to now has been focused on geting the Jenkins git-plugin and xcode-plugin configured and working. Although the end result of full zero touch, automated build and test has not been achieved (due to third party library handling and deployment via Jenkins), these are good success points along the way, and I can pick up on this progress later.

I want to shift focus away from the ShowPlan project to accomplish the end to end task, i.e.:

  • Developer compiles and performs automatic unit test.
  • Upon passing, unit test triggers commit and push to github for code review and integration
  • (For this proof of concept, code review is skipped)
  • Jenkins picks up new changes and runs functional tests.

A Jenkins Automated Build & Test Environment for iOS App Development Part 4


This seems like inching along at the moment. The Xcode Code Signing error still plagues the process but at least it is manifiesting in a slightly different way. On the remote build machine, once the admin user’s keychain was copied to the jenkins user’s ~/Library/Keychains, the fail transformed to:

Code Sign error: A valid provisioning profile matching the application's
Identifier '' could not be found

A few more spins did not improve the situation. Another thing I noticed is the remote build machine does not have a public key for the Developer profile in the keychain so I am not clear if that is an issue, but it is worth investigating. (Not required). Also, I will check if a “valid provisioning profile” should be specifically generated for the specific app that is targeted for build on the remote build machine. (Not Required)


It turns out the jenkins user on the remote build machine was not setup completely for xcode builds on the command line. The xcodebuild command looks for “a valid provisioning” profile in the directory ~/Library/MobileDevices/Provisioning Profiles. These are not kept in the project but instead are assigned on a per MAC OSX user basis. I created the additional directory structure for the Jenkins user and manually copied the <long string of numbers>.mobileprovision file from the admin user to the jenkins user. (See StackOverflow: 4744959)

Now, Jenkins builds the project up to a point where it fails in the compile phase because it cannot find a third party library. In the original source file, that library is manually included in the project but the git commit/push from the dev machine does include it in the repository. So the next step from here is automating the cloning of the third party project.

A Jenkins Automated Build & Test Environment for iOS App Development Part 3


Here’s today’s update on results and learnings:


  • Installed Jenkins git-plugin and xcode-plugin
  • Build Now accesses remote git repository.
  • Xcode Compile fails due to Code Signing Error during Xcode

OK, so far, OK. Progress feels slow while I am learning more about the Jenkins tools, interface and “way” of life.


  • A special github user is not specifically required for Jenkins access
  • Jenkins access does require a SSH Key setup on github but that could be a re-used quantity of main user from different machine.
  • Using ~/.ssh/config is a great way to organize what build goes with what key
  • Jenkins does not support use of passphrase in the SSH authentication challenge. ssh-agent not accessible by jenkins user so this is fail. ssh-keygen becomes almost anonymous.
  • Can setup host alias to point to github hard IP but not required.
  • Projects do not specically require Deploy Keys per project at GitHub. Admin can determine if specific keys or account wide keys are need per revision build
  • Build machine requires Xcode licensing details to be specified on initial launch.
  • Repositories are transferred to $JENKINS_HOME/workspace/<Build Name>
  • Set the SCM > Branch appropriately to the build phase. For now, */master suffices for a Build Now testing and troubleshooting runs.
  • Build > Xcode > Target specifies the target within the Xcode project itself. Default is blank which suffices for now.

So at the moment, I need to solve the Xcode Code Sign Error issues. Initially, the original project had a Code Sign Error due to Provisioning Profile expiration. After renewing, and exporting the renewed certificate to the build machine, everything is green. But I suspect that Jenkins is not configured the access the keychain which was setup by the admin user. Hence the current message:


Code Sign error: The identity 'iPhone Developer' doesn't match any valid,
non-expired certificate/private key pair in your keychains 

Fail Fast Fix Faster = The FQuatro Effect


To achieve continuous integration, we must fail fast faster… in fact,

let’s make that fail fast and fix faster. Here is what I mean by that…


Fail fast – deploy automated test tools and unit testing methodologies to get feedback on code progress.

Fix faster – at every step of the process, fix issues and fail forward. At the same time, re-inject code back to unit stage for clean automation regression. This creates spin loops and the organization determines how many spin loops are in play at any one time concurrently, based on tracking, monitoring and server load/optimization.


Once unit passes, code is automatically promoted to the integration build for integration test.

In parallel with this, code reviews are processing code for feature fit and readability for gold revision.


Once a revision set is triggered, the gold revision is to a continuous integration server for new acceptance, functional

and regression tests.


Upon passing, code is automatically deployed for beta testing, or parked for full feature suite.


Upon failing, code is triaged and combed for defect and artifact investigation and fix.


The Spin Loop and the Clean Build Cycle

The team decides the amount of spin desired for current theatre. All points in the process can produce spin to create revision for fail-fix or pass-promote. The system operates on at least 2 full spins that result in a clean, repeatable, zero touch revision launch candidate. The revision launch candidate can be cataloged and stored for purposes of product launch or update. The luanch decision is the policy of the delivery team, and varies based on product set and customer attention requirements.

Here is the quick thought overview in picture format. 

A Jenkins Automated Build & Test Environment for iOS App Development Part 2


Here is progress and findings so far based on yesterdays work.


  • Purchased, picked up and installed Mac Mini
  • Installed Jenkins, configured email properties, played with creating a new job
  • Researched what others have done, re: google searches:
    • jenkins github xcode
    • continuous integration of ios apps
  • Evaluated available github and xcode plugins

So far, so good.

There are a few interesting tutorials that I will tackle today and some seemingly ready made solutions. So this project is not a reinvention or pioneering, but it will prove valuable to get my development environment automated and stable. I will document individual findings of the process as I go.

Here are some basic findings so far:

  • I downloaded Jenkins directly from the website (instead of with homebrew from command line, a popular method)
  • Mac OS X 10.8.1 is preinstalled on the Mac. Java 1.6 was not. The installation from the .dmg package starts Jenkins as a service on port 8080 automatically.
  • Setting up email on Jenkins is a snap using with SSL on port 465.

Time so far: 5 hours.

A Jenkins Automated Build & Test Environment for iOS App Development Part 1


Yesterday, I attend the Mobile Test Summit 2012 in San Francisco. It was a great event. Listening to the speakers talk about a range a technologies and approaches, it occured to me that I could really benefit from an additional layer of automation in my freelance development enviroment for ShowPlan and other projects. So while I have a break in the ShowPlan development activities (I re-submitted ShowPlan to the AppStore to fix a submission bug in reference to guideline 11.3), I am tasking myself with architecting and deploying an automated build and testing enviroment.

From the project side, here is what I want to accomplish:

  • Use this project as a Proof of Concept
  • Learn by doing, experimenting and documenting my findings
  • Treat this as Hacker Quest (aka: a Vision Quest with a Hacker mindset) with a 4 day time limit
  • Follow a Rapid Learning Process, (i.e. investigate, learn on the fly, deploy and implement, iterate)
  • Prepare to teach others about the process, learnings, results and pitfalls.
  • Do a first hand analysis and evaluation of tools and technologies being used by leaders in the field
  • Blog at least once daily about the process, and definitely blog about quick successes and learnings

In terms of technologies, here is my initial approach before diving in

  • Use Jenkins for Continuous Integration
  • Deploy on a Mac Mini platform for automated build and test (for a freelance team of 1: this will be plenty. More about scaling to dev teams of 10, 100, and 1000 later)
  • Develop on a MacPro (already in place)
  • Unit Testing with SenTesting
  • Trigger automated for functional and integration testing after dev build passes unit test and commits to main github repository
  • Automate blackBox testing with a combo of Selinium, Appium, Bwoken, Calabash, Cucumber, Frank. (This is the evaluation part to see what can “attached” to the automation environment)

I will not focus on any new features of ShowPlan. With that, I plan to test ShowPlan’s use of ios-Trello API Wrapper so this will likely involve automatically building a new project from scratch, populating the project with its ShowFlow, Scenes and Production Elements, then pushing that ShowFlow to Trello for Sharing. To verify this integration, the automated test will need to access data from   Trello (board, lists and cards) and compare that information plucked out of the ShowPlan project CoreData store.

OK. Enough said. Off to the Apple Store to pick up the Mac Mini (2.5 Ghz/500MB/4GB)

Today is a great day!


As I ready the ShowPlan app (and its entire ecosystem) for the hotly anticipated AppStore launch, it occured to me that I have a serious case of multitasking. Mind you, I am getting things done, working 20 hour days, writing code, doing music, writing code, working on websites, testing code…

This is a long one and I realize any one of these topics is up for an individual blog post.

OK, here is the list:

  1. Code development
    • Focused on submitting app to the AppStore
    • Dropbox checkpoint (need TestFlight for adhoc distribution, need to do this before Beta)
    • Bug Fixes – there are still a few
    • Final features:

      • Gesture support in Project Depot
      • Handling project copy on export
      • Project naming convention (to simplify user experience)
      • Tutorial Project
      • Vimeo integration
      • Flickr integration
      • Google Drive integration
        • ShowPlan site For Tutorial Project Restoration
        • Cross-integration with Trello for documents
    • Getting ready for beta test
      • TestFlight integration
      • Configure for adhoc distribution to Dropbox
  2. Graphics Design
    1. ArtText 2
    3. Pixelmator
  3. Website development
    • Establish “beachhead” hosting account a
      • Learning about cPanel, mysql, phb, redirects
      • AppifyWP LaunchPad for prelaunch
      • AppifyWP 2.5 to drive potential customers to AppStore
      • Appify affiliate link
    • (better would be but godaddy restricts subdomains to local DNS)
      • Setting up forum with phpBB3
      • adding mod (first one is Akismet for phpBB)
      • automated moderation, manual triggers for Akismet caught ham (vs. spam)
    • >>
      • Using this as a living, online Help Guide, separate from interactive forum
    • (here!)
    • WordPress and phpBB plug-ins, security, user registration confirmation, etc.
  4. Marketing and Outreach
    • Establish ShowPlan presence
      • @ShowPlanApp on twitter
      • facebook/ShowPlan
      • ShowPlan Google+ Page
      • Vimeo
  5. Blogging (now)
  6. Preparing a ShowPlan case study with Alexa
  7. Travel and equipment arrangements for jazz gig in Seattle
  8. Preparations for Session at Silicon Valley Code Camp
    • ios-trello
    • it’s all about the right mix of story and technical content
    • developers, developers, developers love code
    • code is poetry!
  9. Sprucing up the resume
    • It is now one page looooooooong!
    • Reading Cracking the Coding Interview (Gotta have a Plan A and a Plan 1)
  10. New Productivity Apps / Sites
      • A powerful way to track interest (97 clicks across 20 countries after Trello retweeted ios-trello talk)
    • Skitch
    • Evernote
    • GDrive
  11. Fun Stuff
    • Soundcloud and Vimeo for new blueStarStudios indie label, haha!
      • posting some compositions, following the occasional
    • Netflix, YouTube, CNet Apple Byte on TiVO
    • facebook
  12. Keeping track of most of this with Trello
  13. USPTO
  14. Thinking about affiliate marketing programs as a future source of “passive” income
  15. Next purchase is an AppleTV to watch vimeo in HD.
  16. Thinking about analytics for websites and apps
  17. ProTools, mixing, getting ready for the bata/dancing app (video and audio is captured)

As you might have guessed, I am learning alot in a compressed space of time. Life is good!

Today is a great day.

Creatively speaking…


If you are interested in ShowPlan, go here.

If you are interested in ios-trello, visit github.

You can visit my profile at linkedin or follow me @vincemansel

Also, I occasionally blog at Code::Net::Waves