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.
Continue reading “My App Store release checklist”
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. Continue reading “Docset Viewer: Resuming large downloads with NSURLConnection”
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.
Continue reading “Core Graphics isn’t scary, honest!”
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.
Continue reading “Back To Basics: Simple debugging tips in Xcode”
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.
Continue reading “Back to Basics: Using KVO”
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.
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.
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.
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.
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.
Read on to see more