For the last six months I’ve been quietly working away on an iPad app with the goal to get experience developing for iOS. Given that there are many alternate routes a developer can take, the politics of choosing technologies to adopt are quite polarising, with a titanic struggle currently underway between vendor, enterprise and the customer! Anyway, on with the show…
My approach to designing an application will start with a statement of intent (or vision) i.e. an app to manage job searches. An initial data model and screen design iterated over several times provides a starting point, or as stated in The Mythical Man-Month “Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.” Of course, we don’t use flowcharts these days and even tables are becoming a distant memory (replaced by Cloud service API’s), but the point is still valid, that key design concepts can be communicated simply and improved in an iterative way as the development progresses.
The first phase (or milestone) in building this app was the CRUD phase, where the database and data entry screens were created. My purpose throughout this project has been to learn the techniques of building for iPad, so my priorities were often driven by a desire to explore the essential aspects of iPad development. In this first CRUD phase then, CoreData and UITableView were prominent, as was the Storyboard, Auto Layout & Segues. CoreData is an immensely powerful library for managing relationships in an object graph, extensibility points for validation (through Categories), rich functionality for querying (through predicates) and persistence. Source control was Git through the Xcode interface with a private master repository on Bitbucket.
I’ve become confident working with Xcode and find it a very capable development environment, so achieving my goal to experience the Apple platform. While the learning curve is quite steep, as can be expected for any programming environment, steady progress can be made with a determined effort. The greatest compliment I can give is that the Cocoa Framework more than holds its own against .Net and Java platforms. Proprietary platforms though, have the downside that apps are standalone, they don’t integrate well with other apps to form coherent workflows e.g. a common requirement when applying for jobs online is to provide a CV and unfortunately, Microsoft Word is the defacto standard. This presents a challenge to the Job Search app, how to include an attached document when applying?
The Job Search app is only partially built, but has still met my goals of learning how to program on the Apple platform. The tooling (Xcode) is pleasant enough and Objective-C is sublime. My main criticism would be that developing iPad apps requires me to in some way adopt the attitude of creating a standalone app that locks the user into a specific workflow.