Update: There’s a couple updates to this at the end, including that Apple has accepted my appeal and approved the 1.2 update as-is. That changes nothing about the StoreKit bug, FB21795992, and Apple Creator Studio going so hard trying to trick the user into a “free” subscription.

I was excited about this 1.2 release, as it checked off one of the major features I wanted to ship the first version with: a voicing tone analysis, which would tell you why you might prefer one particular fingering of a chord.

Why? Well, maybe this easier one is missing an important pitch class, or maybe it has an extra one. Consider an easily explained but probably poor example: a C power chord, for instance. It should have C, G, and nothing else. Maybe a common fingering also has an E. That makes it not a C power chord, but it may appear as one anyway in some references. Depending on the context within the song, you may not care about that E.

The point, since you likely don’t care about any of that, is that I’m really excited about this release.

The 1.2 update has been approved twice already, but both times I found bugs that I didn’t want to ship. I really loathed rejecting the second one: without a fix users would need to re-select their instrument when they upgraded.

Apple’s rejection fell under section 3.1.2, on Business — Payments — Subscriptions:

One or more auto-renewable subscriptions are marketed in the purchase flow in a way that may mislead or confuse users about the subscription terms or pricing. Specifically:

• The auto-renewable subscription promotes the free trial, introductory pricing, or introductory period for the subscription more clearly and conspicuously than the billed amount.

Here’s what it looks like:

This is a screen that’s been unchanged since 1.0. Honestly, I actually agree with them. The wrong thing is emphasized here. Free is big. $4.99/year is smaller. This is misleading.

The styling and text here is provided by Apple, not me.

If this styling and text is unacceptable to Apple, they should fix it in their own code.

The Problem

Try It Free is not an appropriate title here. It’s misleading people into starting a subscription that they’re going to be charged for. Here’s the catch, though: App developers like me don’t control that text.

Instead, we specify information about the subscription in App Store Connect.

In this case:

• It’s a yearly subscription.
• It includes a one-week free trial.

If you use SubscriptionStoreView(groupID:) to present the store, a lot of the presentation details are automatic. But here:

• “FretSketch Full,” the icon, and the bullet list are my code.
• The Terms of Service and Privacy Policy are Apple’s code and presentation, though I provide URLs and ask Apple to make them appear.
• The subscription controls are largely Apple’s, based on my configuration in App Store Connect.
• I did specify that I want multi-line buttons, which can be really explicit about the deal.

This screen is the result of that: Some combination of SwiftUI and StoreKit builds the button labels, styles them, and presents them without me having additional controls. In this case, it went with Try It Free and 1 week free, then $4.99/year. I would’ve preferred to have it say Subscribe, but I can’t do that.

Apple has a few things I can control, though: The big one is .subscriptionStoreButtonLabel(). Here, I’m using .multiline. It’s not documented in Apple’s reference, but there is a comment in the header file:

/// A button label that prefers to display two lines.

Note it doesn’t say anything about what kind of details. It certainly isn’t documented to be misleading, though it is.

There are a few alternatives, but the only one that looks like it might satisfy them is using .price. With that, the button text becomes 1 week free, then $4.99/year. I absolutely loathe this, since it’s not an action. It’s a rambling description. An action is something like Purchase, Try It, or Subscribe, right? 1 week free, then $4.99/year isn’t an action, it’s a ramble. I looked through all of these options back in October; .multiline was the least terrible one, but they all suck.

Apple’s Solution

It was at this point I wondered how Apple handles this in their own apps.

Let’s take a look at how Apple solves this problem in Apple Creator Studio, released earlier this week. This should be fully compliant with Apple’s latest standards, right?

It’s really not. I was angry last night. Now I’m just amused.

This is worse than FretSketh. They don’t even put the price in the button, though Free is in there. The price is left as secondary text, medium grey on a light grey background; much less prominent than the word Free.

They’re also charging $215/year in Canada, which is 43x what I’m charging. I should probably bump my price a little; I was originally planning to charge $0.99/month or $9.99/year, but went with an introductory price of half of that.

You can’t use examples of other apps, even Apple’s, to appeal an App Store rejection. Further, I wouldn’t want this to be the reason they approve the misleading button title. But Apple’s paywall should not have happened, and it would not have passed their own review process. Mine is subtly misleading through no fault of my own because Apple coded it so and judged it (fairly) as unworthy. That screen, though, is intentionally misleading.

Maybe that should be fine. Maybe they should just allow this. But when I say I want to be held to the same standard, I don’t want it to be this sketchy one.

I could say something like “it’s good to be the king,” but I don’t think that’s true. I think not being held to their own standards is going to be detrimental to them. Apple, stop being so sketchy.

My Solution

First, I’ve already appealed to App Review. I don’t expect that to go anywhere they’re fundamentally correct. This is misleading UI. I don’t think “but the misleading is coming from your code, Apple!” is a great defence when it can be worked around.

You could be forgiven for asking “Why are your screenshots so terrible?” Remember I mentioned above that this stuff is configured in App Store Connect? The way to control the button title is to change the parameters in App Store Connect.

As I was writing this, Apple changed those parameters by removing my free trial. It’s not quite as egregious as it seems since I mentioned I was willing to drop the free trial to fix this. I still wish they’d asked, or better yet just acknowledged this was their problem. Other developers get to offer free trials, why can’t I? Then again, they haven’t sent a reply yet, so they could just be experimenting to see if what I’m saying is true. Maybe they’ll put it back and just didn’t think I’d notice.

But this morning I read on Reddit about another customization axis for sheets: .subscriptionStoreControlStyle(). The default is .prominentPicker, which is what I’m using. Most of the options are “pickers,” and they all have this same problem: StoreKit generates button titles that Apple will reject.

There’s just one option that’s not a “picker,” though, which is .buttons. That one shows the title of my subscription as the button, like this:

If I remove the .multiline setting, it actually gets even better.

I like this better. “Free” doesn’t appear anywhere on the button, and with all the subscription details with the same prominence I think it would probably pass App Review. This is better than the appearance in FretSketch 1.0, and it’s certainly better than what Apple does in Creator Studio.

Going forward:

1. If Apple approves 1.2 as is on appeal, I’ll ship it. I want this release in the hands of users.
2. If Apple removes the free trial to “fix” the button text, I’ll ship 1.2 as is. I like a free trial, but I’m not going to hold the release for this.
3. The next build, whether 1.2, 1.2.1 or 1.3, will switch to .buttons control style and default labels. It’ll re-add the trial, but probably with a longer duration.
4. I’m calling on Apple to fix StoreKit. That button should be titled Subscribe, not Try It Free. Even if they do that in a future version of iOS, though, it won’t impact iOS versions already out there. I filed this as FB21795992. If this App Reviewer was correct, if you use any control style but .buttons in your app with an intro period you’re risking rejection.
5. I’m also calling on Apple to make Apple Creator Studio more honest. I don’t want Apple to be sketchy like that, and I certainly don’t want that to be our new standard. If you can help get the word out, please do!

Update: Apple has approved the Mac version. It uses the same code and store design. I have not released, because I want to do a simultaneous release.

Update 2: On appeal, the iOS build was approved as-is. I still believe that Try It Free is a StoreKit bug, and Apple Creator Studio goes way over the line with its intentionally subservient pricing information and Accept Free Trial.

It includes chords for standard guitar, low and high G standard ukulele, and baritone ukuleles.

I picked what I hope is a humane way to monetize it: You can access anything int the app, but some of the features are behind a delay. So you can use any feature in the app and subscribe to remove the delay.

It’s available on the App Store. I’ve also got a very basic website for it which includes a support link.

As a developer, there are some things I’m particularly proud of:

1. This is my first entirely SwiftUI app.
2. I really like the way the animation on the key selector wheel turned out.
3. I like the chord player, both the animations and the sound.

Anyway, please check it out. Send me feedback if you have any, write a review if you feel like it, and subscribe if the app is useful to you.

Here’s what I’ve learned so far:

• Subscriptions:

  • Subscription Localizations are not marked as required, but you need at least one or you’ll get “Status: missing metadata” when viewing the subscription. Although App Store Connect typically shows errors for missing data, it doesn’t in this case.
  • Additionally, you need screenshots for the Review Information. App Store Connect at least warns you about this, but they seem completely useless to any purpose but completing metadata. Thanks to Sean Heber for mentioning this; I forgot to put it on the list of recent pain. A lot has happened in the last couple of days.

• Subscription Groups:

  • Subscription Group Localizations are also not marked as required, but you need at least one or you’ll get “Status: missing metadata” when viewing the subscription. That’s not a mistake: the warning about missing data in Subscription Groups appears in Subscriptions, not Subscription Groups.
  • Getting account level banking information submitted (and accepted, it took much longer than 24 hours to process) changed my status from “Missing metadata” to “Ready to Submit.”

• Other

  • You need to specify “Terms of service: (URL)” at the end of your description when using Apple’s service terms, even if you’ve specified the terms of service in the appropriate field. I would love to know the rationale for this.

Overall, App Store Connect needs some small but meaningful usability improvements. It would be enormously helpful if it listed which metadata was missing (and ideally linked to where to set it) instead of just reporting “Status: missing metadata” or, worse, “Preparing for submission.”

This seems to be an iOS bug and is caused by using autolayout within a table cell without a tableView:estimatedHeightForRowAtIndexPath: method.

If you do not implement this method, the UITableView will treat that as an estimated row height of ``. AutoLayout will panic and try to compensate for this, and you’ll still see an incorrect size. (I believe this to be the minimum size that it thinks would satisfy your content without any spacing and taking wrapping into account, but I’m not sure of this.) You see this bug in some of Apple’s apps, including Settings.

To fix it, you need to implement tableView:estimatedHeightForRowAtIndexPath: and return a rough estimate of the size of the row. iOS includes a constant for this, if you have no good estimate: UITableViewAutomaticDimension.

This may introduce a few other (minor) problems, as providing estimates can lead to views being poorly sized as you scroll. Apple discusses this in their documentation. If you are impacted by something like that, a tableView:estimatedHeightForRowAtIndexPath: that returns values closer to actual might help. That said, while I had problems from rough estimation on the simulator I’ve never noticed it on a real device. Seems like the logic is a bit different between them.

However:

• You should not attempt to calculate real height values. The entire point of this method is to short-circuit involved height calculation. It’s just unnecessary.
• You should not attempt to cache heights returned by the real tableView:heightForRowAtIndexPath:, either. The values in that cache will be wrong when estimatedHeightForRowAtIndexPath is first called anyway; they’re really no better than UITableViewAutomaticDimension. And if you return ``, you’ll hit this bug.

So what should you do? It really is this simple:

- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return UITableViewAutomaticDimension;
}

And you’re done!

Let me give you a different opinion:

No, newbie, you don’t need to learn Objective-C first. You’ll miss it from time to time and you might want to pick it up later, but it won’t help you much now. And it will color your thinking in a way that might hurt your understanding.

ARC, an admittedly imperfect analogy

Let me rewind a few years. Apple introduced Automatic Reference Counting, which let the compiler manage its own memory. To this day, people continue to suggest you learn manual release/retain (MRR) before using ARC. I used MRR for years, and it really didn’t help me learn ARC. What helped me was understanding the object graph model, which was actually hidden by MRR. I think knowing MRR can actually make it harder to learn ARC.

So should you learn MRR first? No. You should learn the concepts behind good memory management on iOS — something many programmers never learned under MRR — then apply them to ARC. MRR is mostly unrelated to this.

To any MRR people who just read this and are shaking their heads: No, you really don’t need to know it. You and I know that this chunk of code is slow because it’s doing extra retains and releases, but the ARC user might instead know it’s because they’re assigning a strong reference. And the funny thing is that’s probably a better way to think of it.

And none of this is to suggest that’s not to say people it isn’t helpful to learn MRR. MRR offfers a better perspective on some concepts, such as __autoreleasing, bridge casts, precise lifetime, consumed parameters. But I’m not at all convinced you need to learn MRR first, because I think the ARC concepts are generally more useful for a 5,000 foot view of what’s going on. When you’re hovering three feet over? Knowing MRR is great.

Swift

Just looking at it and playing for a few minutes, I think Swift is another great example of this. Swift is a teaching language that’s probably more useful for day-to-day programming tasks than the language it replaces. It’s also likely to be more performant than Objective-C, thanks to… well, that’s another article. 🙂

If you’re a new developer reading this, ignore Friskics’s article. Get the concepts down and then learn the language you’re going to use. Enjoy it. You don’t have to suffer like we did. You get to start from our shoulders, and that’s a good thing. Nothing prevents you from learning down as well.

In a few years I’ll miss Objective-C. But primarily because I felt there was always something to learn about it, and a better way to write my code. I’m not sure if I’ll still have that feeling with Swift, but that nostalgia doesn’t mean Objective-C is a better language.

To address his points:

1. You can learn the frameworks in Swift just as easily as Objective-C. Apple’s designed Swift to work this way, and their documentation is already ready.
2. Swift will be tried and true before you know it. This isn’t something Apple started working on the Tuesday before WWDC, and it’s not going final way off in 2016. Sure, Swift isn’t the main language yet, but it will be by the time you’re ready to ship something.
3. The learning materials and code examples are already appearing, and they’re going to continue to appear.
4. Just because you can mix languages if there’s a reason for it doesn’t mean you have to. Sure, we Objective-C programmers mix C code in if we have to. But it’s not the first thing we reach for.

It turns out that you can get Xcode to log more information on the handshake with the portal. Quit Xcode, then run these two commands.

defaults write com.apple.dt.Xcode DVTCodesigningAllTheThingsLogLevel 3 defaults write com.apple.dt.Xcode DeveloperPortalLogLevel 3

Then, open Console. Quit anything spewing to it, clear the display, then try to upload your build again. When you’re done, select and copy the spew to Console and paste it into your favorite text editor. You’re looking for DeveloperPortal and DVTCodesigningAllTheThings rows.

The results aren’t exactly easy to interpret, but it does give you a better idea of what’s being reported to Xcode, as opposed to what Xcode displays. Xcode is probably simplifying the error message.

When you’ve solved your problem, you’ll probably want to turn it back off:

defaults delete com.apple.dt.Xcode DVTCodesigningAllTheThingsLogLevel
defaults delete com.apple.dt.Xcode DeveloperPortalLogLevel

In my case, I solved my major problem literally seconds before I learned about this logging trick: I had used a bundle ID of com.company.product, whereas I was now using com.company.${PRODUCT_NAME:rfc1034identifier}. That made the effective bundle ID of the new product com.company.Product, which was enough that Xcode couldn’t find a corresponding application for my bundle. I don’t know what that would have looked like in the log.

This logging trick did solve me with a subsequent problem, however, by letting me know it was based on permissions. As a result, I spent only seconds on that one, and my app is now waiting in Apple’s review queue.

I don’t know if this will help you or not, but if you’re getting only a generic error message it’s worth a try.

I’ve since decided that this replay says almost everything I wanted to say, so I decided to just edit it a bit.

I’m pretty torn on this whole subject. Dynamic libraries can lead to inefficiencies in storage space if a developer isn’t careful, and I’ve no reason to believe iOS developers are careful. Include Google Toolbox for one function? Sure, why not? Apple’s always balanced the experience towards users, and even when it makes my life more difficult I like that.

The static library approach isn’t a good approach either. Sometimes I’ve had less than complete debugging info, and been missing information in crash logs. And its code stripping isn’t as good as it should be, either. The final straw for me was when HockeyApp’s crash reporter stopped producing useful stack crawls. I spent a few hours trying to fix this, even got a little help (HockeyApp is excellent, and their support is outstanding) but quickly realized I was spending too much time on a problem with a very pragmatic fix.

(What was the problem? I’m not sure. It seemed to be related to an Xcode update, but after a few hours I grew less interested in solving it and more interested in shipping what was a critical update to my app.)

Cocoapods tries to solve this, but I think it does so the wrong way. You still have the same problems, it’s just a little less trouble to keep it going. It’s probably better than nothing, but it wasn’t the approach I wanted to take.

What I’ve been doing recently is including the sources in groups within my project. This is harder for me, but better for the compiler/linker (it has a better sense of everything I’m trying to do), debugger (all the symbol information is built as part of the main project) and the end user (who gets a better stripped executable).

What we need is not static libraries or dynamic libraries or frameworks. We need something better, more tuned to iOS.

There’s a few options:

• A project include file, which lets you specify a source group to build but is linked into the main project. This has the advantage of being linked separately.
• A dynamic dynamic library, where the library is built by the main project based on the subproject with an understanding of what parts of library the main project uses.

Until Apple has a good solution to this, I’m going to continue to avoid static libraries (except for very specific libraries, like HockeyApp) and put the sources in a group.

I really hope Apple comes up with a good solution soon, though. This is indeed painful. I think Landon’s radar is entirely positive; Apple isn’t too likely to just do the easy thing. They’ll think about, evaluate possibilities, then do something that we can hopefully live with. Hopefully something better than any of us anticipated.

Although this can be initially confusing, this actually makes a lot of sense. If two different view controllers (say, Circles and Squares) might push the same view controller (Details), shouldn’t the text in the top left of that view controller depend on which controller pushed it (Circles or Squares)?

Think of it this way:

thisViewController.visibleBackButtonTitle =
    previousViewController.navigationItem.backBarButtonItem.title
    ?: previousViewController.navigationItem.title
    ?: previousViewController.title;

This won’t compile; visibleBackButtonTitle doesn’t actually exist.

There are a few reasons to show custom text on the back button.

More generic

The most obvious reason is that your title relies on user input that may be too long, and you want something simpler and more generic.

This might be the case if the user taps an event. The title in the navigation controller should be the event’s title, but you might want to use something shorter like Event on the back button.

This case is simple: select the parent view controller and give it a custom Back Button value.

More specific

You might also have the opposite problem, where your context is not visible in the navigation title because it’s obvious from something else in the view controller. But you still want to leave that more specific title as a breadcrumb for the user.

An example of this might be an address without a label. The first line of the address doesn’t make sense as a navigation title, as it duplicates the view. But if you tap deeper than that, you might want to include something about the address, such as the house number of the position in the list.

This is a little more complicated. You’ll need to do this at runtime: Set the title of the backBarButtonItem for the navigation item of the view controller the button leads to. That will prevent the navigation item’s title from being used.

But there’s a wrinkle. Let’s assume you want to set the title dynamically. You might have something like this in your parent view controller, which is called by your viewWillAppear and whatever triggers updates of the view controller:

- (void)loadData {
    // lots of other stuff
    self.navigationItem.backBarButtonItem.title = @"dynamic title";
}

This probably isn’t going to work for you as is.

You’ll find lots of crazy solutions to this; manipulating the backBarButtonItem by hand and restoring it after for instance. (There are much, much crazier solutions.)

The key is understanding why it’s not working: backBarButtonItem is nil.

To make it not nil, you have two options:

1. Select the navigation item in the storyboard editor and give Back Button a value. This value will cause the backBarButtonItem to be automatically created with the view controller is instantiated.
2. Create the backBarButtonItem at runtime in your viewDidLoad or awakeFromNib (suggested by @calebd). I don’t recommend doing this in code; you’re already using a storyboard or nib, so it’s much simpler to just put a Back Button value into your view controller.

Once it’s created — whether in code or by storyboard — its title can be changed. You can change backBarButtonItem’s title at any time when the parent is displayed, as often as you like: it’ll only be shown when you push something else on top of it.

Summary

If the text is always the same:

1. Select the parent view controller’s Navigation Item in the editor.
2. Put the text into the Back Button value.

If the text is dynamic:

1. Select the parent view controller’s Navigation Item in the editor.
2. Put some text into the Back Button value.
3. Set the title in the parent view controller, when its contents change: self.navigationItem.backBarButtonItem.title = dynamicText;

This is a simple and obvious technique, but it took me a while to adopt it: You can do by asserting with NSAssert or NSCAssert for [NSThread isMainThread], just as you would assert any other condition.

Like this:

- (void)updateUI {
    NSAssert([NSThread isMainThread], @"Only update UI from main thread");
    // update UI
}

- (void)backgroundWork {
    NSAssert(![NSThread isMainThread], @"Only do work off main thread");
    // do work
}

With assertions like this in place, you’ll sort out what executes where in short order.

I wish I had done this to my code right away; it’s much simpler to get it right than to go back and fix it all later.

For various reasons, you sometimes can’t use NSAssert in a block easily. I’m going to explain why and describe a new macro, BlockAssert, which solves this.

Background

An assertion is a predicate (a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place. (Source: Wikipedia.)

NSAssert and NSCAssert are Foundation’s assertion macros. They’re kind of like C’s assert macro, but provide an error message in the same form as NSLog. The difference between them is that NSAssert references self, which is only defined for Objective-C methods. NSCAssert, then, is NSAssert for C functions.

Blocks are often defined in Objective-C methods, but they’re not themselves Objective-C methods. Although they’re actually implemented as objects of their own, the syntax is more like a C functions. They don’t define self, though anything you want from the method scope are captured strongly into the block expression. This means that if you use NSAssert you’ll be capturing self. But that strong reference can cause a circular reference.

A circular reference is formed the block owns the object and the object owns something that owns the block. None of the memory will ever be cleaned up. Even you do clean up the memory, you’ll get a compiler warning that you need to ignore.

Rather than sort out which of these compiler warnings is valid, a lot of people use this pattern:

__weak typeof(self) weakSelf = self;
foo.completionBlock = ^{
	__strong typeof(self) strongSelf = weakSelf;
    [strongSelf doSomething];
};

This breaks the circular reference, and because we’ve used __weak we’re assured that weakSelf is not a dangling pointer. If self no longer exists, weakSelf is nil. Reassigning back to a __strong variable presents the variable from being deallocated

In this case, it’s not actually necessary to assign weakSelf to a __strong variable. The recipient of a message won’t be deallocated until the message returns. However, if you are doing multiple things with weakSelf — such as doing assertions against it and sending it a message — it could become deallocated between those messages.

The catch? NSAssert still uses the self variable by name. This led to an interesting question on StackOverflow about defining a block-scope self, a technique that’s valid but requires you to remember to do it every time and causes a warning if GCC_WARN_SHADOW is on.

A new assertion macro

In the past, I’ve mostly done avoided this by not using assertions in blocks. You don’t need them very often, as you can usually do your assertions in the method’s scope. But inspired by that question, I’ve found a better way: I define my own assertion macro.

I have several such macros I define, in a single file that’s imported in as part of my precompiled header.

The macro looks like this:

#define BlockAssert(condition, desc, ...) 
    do { 
        __PRAGMA_PUSH_NO_EXTRA_ARG_WARNINGS 
        if (!(condition)) { 
            [[NSAssertionHandler currentHandler] handleFailureInMethod:_cmd 
            object:strongSelf file:[NSString stringWithUTF8String:__FILE__] 
                lineNumber:__LINE__ description:(desc), ##__VA_ARGS__]; 
        } 
        __PRAGMA_POP_NO_EXTRA_ARG_WARNINGS 
    } while(0)

This is basically a copy-paste of NSAssert, but uses strongSelf instead of self. (Note, however, that we have not pretended to be part of Foundation by using a NS prefix.)

To use BlockAssert, you need to use the weakSelf = self; strongSelf = weakSelf; pattern, but you probably already are. And if not, the compiler will throw an error: Use of undeclared identifier: ‘strongSelf’. You can either adopt strongSelf or switch over to NSAssert.

For example:

- (IBAction)clickButton: (UIButton *)sender {
    sender.disabled = YES;
    [self performActionWithCompletion: ^{
        BlockAssert(state, @"Invalid state");
        sender.disabled = NO;
    }];
}

Conclusion

I think this is a pretty good approach: If you use NSAssert where you meant to use BlockAssert and it matters, you’ll get a warning about a potential circular reference. If you use BlockAssert where you meant to use NSAssert, you’ll probably get a compiler error.

GCC_WARN_SHADOW is essentially drawing your attention to you possibly doing something other than you intended. This is like most warnings, but the difference is that the behaviour GCC_WARN_SHADOW is blocking is very useful.

This is the sort of things the more paranoid compiler warnings are good at. The downside is that it’s difficult (not impossible) to drop a particular warning to indicate that you know what you’re doing.

With GCC_WARN_SHADOW on, this code will generate a warning:

int a = 5;
int b = 3;
int c = 4;
int value = MAX(a,MAX(b,c));

Despite that, it will function perfectly. The reason for the warning is that it compiles down to this:

({
   int __a = (a);
   int __b = (({
       int __a = (b);
       int __b = (c);
       __a < __b ? __b : __a;
   }));
   __a < __b ? __b : __a;
})

This is horribly ugly code. You wouldn’t want to write this code. You wouldn’t want to read it. But here’s the catch: it’s perfectly valid to the compiler, and hiding the ugliness is why MAX() exists.

There’s a few ways to avoid this. The first is to not use the MAX() macro at all:

int a = 5;
int b = 3;
int c = 4;
int value = a < b ? (b < c ? c : b) : a;

Or, you could do this:

int a = 5;
int b = 3;
int c = 4;
int temp = MAX(b,c);
int value = MAX(a,temp);

If you’re interested in temp — if it’s a value that has meaning — this is a fine approach. Give it a better name than temp and run with it. But if it’s a value that has no meaning other than an uninteresting temporary variable on your way to value, you’ve made your code worse.

Next up, you could turn off the warning:

int a = 5;
int b = 3;
int c = 4;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wshadow"
int value = MAX(a,MAX(b,c));
#pragma GCC diagnostic pop

This last method can be simplified (a little):

#define PUSH_NOSHADOW _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored "-Wshadow"")
#define POP_NOSHADOW _Pragma("GCC diagnostic pop")
int a = 5;
int b = 3;
int c = 4;
PUSH_NOSHADOW
int value = MAX(a,MAX(b,c));
POP_NOSHADOW

This last technique suggests permanent fix: Apple could change the definition of MAX to avoid this (10296999).

But really? Just stop using GCC_WARN_SHADOW. It’s an unnecessary pain in the ass.

These are artificial examples, granted. But let’s pull this back to Objective-C, and something a typical Cocoa or Cocoa Touch programmer might have to do:

Also, if you use this you’ll need to name error variables in blocks differently:

NSError *e;
[self somethingWithError: &e];
[self runWithCompletion:^{
    NSError *e;
    [self recoverFromError:&e]; // warning, or rename inner error to e2
}];

Overall, I didn’t think it was worth the extra effort anymore. Your mileage will (of course) vary.

One thing Reachability is not, however, is a crystal ball. Please don’t use it as if it were.

In this article, I’m going to discuss how to use it. Because this is one thing I see a lot of developers get wrong.

How should you use Reachability?

1. Always try your connection first. If you need to upload a change to the server, go ahead and try it. Don’t worry about what Reachability last said, or currently says. Your attempt may be what kicks iOS into powering up the wireless hardware or re-establishing a connection. Networking is really hard; the only way to know if your connection will succeed is to try it and see if it did succeed.
2. Use Reachability to diagnose a connection failure. Reachability can’t tell you if your request will succeed, but if your request fails Reachability probably accurately reflects the reason why. Use what it tells you to improve your reporting to the user.
3. Use Reachability to retry when the connection goes back online. Something else may provoke iOS into powering up the wireless hardware, and it may succeed. When this happens, Reachability will send out a notification. It’s absolutely appropriate to use this notification to retry your networking.
4. Don’t stop the user from trying networking anyway. Even if you think the device is offline, you should still allow the user to attempt actions that require a network connection.

Reachability is a great tool, but it’s a tool for particular tasks. Learn the tasks Reachability is suited to, and your app will be better for it. You wouldn’t use a hammer to change a light bulb. Please don’t use Reachability to determine if a connection will fail.

When your iPad application first launches it will be in portrait mode, even if it’s held in landscape mode. The rotate event is already in the queue and is consumed early enough that it’ll never actually be shown like that. So no problem, right?

The problem is that the rotate event will not have been consumed when your viewWillAppear: is first called. Opening a new view controller in viewWillAppear: (whether using presentModalViewController: or a storyboard segue) will open that new view controller in portrait mode, rather than landscape mode. Even that wouldn’t be a problem, except iOS will not add a rotate event added for the new view controller.

This all makes a great deal of sense when you think it through: The rotate events for the initial view controller or controllers are already on queue before viewWillAppear is called. iOS already recognizes the device has been rotated; as far as it’s concerned, the rotation is done. Your app is just lagging a bit behind as part of the startup process, with everything all queued up.

Conceptually, this is a hard problem.

But in practice, there’s a very simple and very elegant solution using blocks.

All you need to do is delay your view controller’s appearance. Before blocks, you might have had to use a timer. But now you can just use dispatch_async to schedule the new view controller for later.

That’s a little confusing, so here’s an example:

I have a view controller that appears when my application is first installed, to walk the user through the signup process. (Later, if there’s an authentication problem, I fall back on the standard username and password alert view.)

This view controller, then, needs to appear when my main view first appears. If I use this code, the view controller that appears will always be in portrait, even if the device is started in landscape.

- (void)viewWillAppear: (BOOL)animated {
    [super viewWillAppear:animated];
    if (freshInstall) {
        [self performSegueWithIdentifier: @"firstRun" sender: self];
    }
}

If I use this code, however, the view controller that appears will match the device (and the view controller it’s appearing over):

- (void)viewWillAppear: (BOOL)animated {
    [super viewWillAppear:animated];
    if (freshInstall) {
        dispatch_async(dispatch_get_main_queue(),^{
            [self performSegueWithIdentifier: @"firstRun" sender: self];
        });
    }
}

Later in this case is still before the user has a chance to interact, or even before the UI really and truly appears onscreen. The block for showing the view controller will be added to the queue. Everything will just work. By the time your block is run from the main queue, the rotation event will be dealt with and your app will really and truly be in landscape orientation. However, it’ll still be early enough for your view controller to look like part of early application startup.

Note: This was done on my “stable” branch, so it was probably on iOS 5. I have not yet tried this on iOS 6, but I’ve read reports this is no longer necessary. Either way, it’s a good trick if you plan on maintaining iOS 5 compatibility (which you should, for a while at least).

I’m going to discuss how to do so, and why it’s a good idea.

Here’s an example, which I submitted to AFNetworking:

#if !__has_feature(objc_arc)
#error AFNetworking must be built with ARC.
// You can turn on ARC for only AFNetworking files by adding -fobjc-arc to the build phase for each of its files.
#endif

When the user builds the unit, the error will be highlighted. They’ll see the comment just below, explaining how to resolve the problem.

Adding it to every .m file may seem overkill, but there’s two good reasons for this:

1. No matter which file gets compiled first an error will top the list instead of warnings. It’s sufficient to add it only to a central file, but you’ll probably still get support requests that way. You’re better off adding it everywhere; this is all about reducing your work.
2. ARC can be decided on a per-file basis. If you include it in only one file, the user may add -fobjc-arc to just that one file!

But do not add this to your headers. Even if your code requires ARC, there’s no reason to require that the user’s code also use ARC. Apple did the right thing here.

And despite user demands, you also don’t have to support 16:9 right away either.

It’s fine to get real hardware into your hands. More than fine; it’s being responsible. Apple has you covered with letter boxing; let the 16:9 screen be their problem until you’re really ready to take full responsibility. By all means, do whatever development and simulator testing you want now. But wait for real hardware to ship.

Always measure before cutting.

(But measure and cut quickly.)

The first one was clarification on how to fix a bug demonstrated by some Apple sample code. I got a response, but it wasn’t especially satisfying. But that’s okay, because in the end I found a way to do a different UI and avoid the bug entirely. Let’s call it a draw.

The second one, however, was a mistake in how I was using UIKit that I didn’t realize was a mistake. I boiled it down to a test case and submitted the project to Apple. As part of solving the incident, Apple not only explained what I was doing wrong, but provided snippets of code that would work.

This would be gold, but they also fully corrected my code the code I’d sent.

Of course, when I tried to integrate the solution back into my real application, I ran into other problems. However, the explanation Apple had offered me was enough that I was able to solve those other problems, too.

Basically, I got a fantastic code review out of that DTS incident by someone who clearly knows iOS and UIKit better than I ever will. Total win.

I don’t plan on wasting these in the future, but neither will I horde them in case of emergency. They’re worth using for the really nasty problems, and they’re not incredibly expensive to replace — $99 buys another two incidents.

You should never consider a deallocation in viewDidUnload a proper balance for an allocation in viewDidLoad. In fact, you should probably shouldn’t write a viewDidUnload.

Make your outlets unload automatically

The idea behind viewDidUnload is that the view is being unloaded out from behind your view controller. This gives you a chance to detach any pointers to it and clear any information you can rebuild easily. Your view will probably be loaded back in, at which point you’ll need to rebuild any caches. Apple describes this in UIViewController Class Reference:

When a low-memory condition occurs and the current view controller’s views are not needed, the system may opt to remove those views from memory. This method is called after the view controller’s view has been released and is your chance to perform any final cleanup. If your view controller stores separate references to the view or its subviews, you should use this method to release those references. You can also use this method to remove references to any objects that you created to support the view but that are no longer needed now that the view is gone. You should not use this method to release user data or any other information that cannot be easily recreated.

This was mostly about handling dangling pointers before Automatic Reference Counting (ARC). But now that you’re using ARC and zeroing weak references, the dangling pointers will be cleaned up automatically. No need to write a viewDidUnload!

Generally, the stuff people put in viewDidUnload is better handled in viewDidDisappear or dealloc. The only thing left for viewDidUnload is nilling any of your caches that can be rebuilt without data loss while the view controller is still open, when needed at some point after the view has been reloaded. Really, these caches should be handled in didReceiveMemoryWarning instead.

Clearing out caches

Clearing out cached information fits better into didReceiveMemoryWarning, so you should write it instead. Apple describes didReceiveMemoryWarning in UIViewController Class Reference, too:

You can override this method to release any additional memory used by your view controller. If you do, your implementation of this method must call the super implementation at some point to allow the view controller to release its view. If your view controller holds references to views in the view hierarchy, you should release those references in the viewDidUnload method instead.

Not only does writing your cache purging in didReceiveMemoryWarning better suit the documentation, but you’ll be less confused when you read didReceiveMemoryWarning in your code than viewDidUnload.

I’m not taking a ridiculous position here, either. viewDidUnload is deprecated with iOS 6.

Summary

1. Use ARC.
2. Use weak references for IBOutlets that are part of the view hierarchy. They’ll automatically be zeroed when the view is unloaded.
3. Use didReceiveMemoryWarning to dispose of anything you can rebuild easily, by (for example) removing all objects from a NSDictionary. Or, better yet, use NSCache where this behaviour is automatic.
4. Use dealloc to dispose of any external resources that ARC will handle automatically.
5. Don’t even write a viewDidUnload, unless you’re observing values of outlets with KVO.

If you’re still using Manual Release Retain, none of this applies. You should use retained outlets instead. It’s better to potentially use memory a little too long than to have a dangling pointer. And you should really think about climbing that fence and joining us on the Automatic Reference Counting side. Unbelievably, the grass is just as green here as it looks.

Instead of writing:

NSString *value = [dict objectForKey: @"Key"];

You can now write:

NSString *value = dict[@"Key"];

Unfortunately, this requires SDK support. While the OS X SDK provides this support, the iOS 5 SDK one doesn’t.

I’m going to show you how to add it.

Allow subscripting everywhere

The iOS SDK provides routing from the new messages to the old via arclite, a library included automatically whenever you use Automatic Reference Counting. To add support for subscripts to Objective-C, you just need to inform the compiler it’s allowed to make those calls using a category.

Peter Steinberger explains and offers such a header in Using Subscripting With Xcode 4.4 and iOS 4.3+

You can #import this where needed, or add it to your precompiled header. There’s no need to add an implementation; it’s handled automatically by arclite. (If you are not using ARC, you will have to force the linker to include arclite. But you don’t have to actually switch to using ARC.)

I don’t recommend this, however. This will let you use subscript syntax with every type, not just those actually provided by the runtime. But if you use subscript syntax with a class that doesn’t support it, you’ll get a runtime error.

For instance, this will work:

NSMutableDictionary *dict = [NSMutableDictionary dictionary];
dict[@"foo"] = @"bar";

This, however, will build but cause a runtime error:

NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
NSLog(@"the value of key is %@", userDefaults[@"key"]);

We can do better.

Target only those classes supporting subscripts

We can also add subscripting support only on types you plan to use that you are certain arclite adds subscript support to.

Use a header like this:

#if __IPHONE_OS_VERSION_MAX_ALLOWED < 60000
@interface NSDictionary(subscripts)
- (id)objectForKeyedSubscript:(id)key;
@end

@interface NSMutableDictionary(subscripts)
- (void)setObject:(id)obj forKeyedSubscript:(id <NSCopying>)key;
@end

@interface NSArray(subscripts)
- (id)objectAtIndexedSubscript:(NSUInteger)idx;
@end

@interface NSMutableArray(subscripts)
- (void)setObject:(id)obj atIndexedSubscript:(NSUInteger)idx;
@end
#endif

This will add subscripting support only to NSArray and NSDictionary. I don’t know what other classes Apple provides subscripting support for via arclite; if there’s a list, I haven’t found it yet.

I have put this code in a public github repository; do with it as you will.

What are you going to do if they enter something else in there?

UITextField’s keyboard type is a keyboard type, not a validator.

Here’s two examples:

Emoji

1. Edit a contact in Contacts.
2. Tap a name field.
3. Switch to the Emoji keyboard.
4. Tap the phone number field.

Contacts will stop you from actually putting Emoji into the phone number field, but this is a feature of Contacts not of UITextField. If you try this in your own app, you’ll be able to enter Emoji there.

Paste

1. Edit a contact in Contacts.
2. Tap a name field.
3. Tap and hold.
4. Select some text.
5. Tap Copy.
6. Tap the phone number field.
7. Tap and hold.
8. Tap Paste.

So what do you do?

Now that you’ve started thinking about this, I bet you can find other ways to reproduce this.

This is not your bug. It’s probably not a bug at all. But you need to adjust your expectations appropriately.

You could probably trap textField:shouldChangeCharactersInRange:replacementString: like Contacts does. This may be doing more work than necessary.

However, you absolutely should test your code to see how it handles bendy inputs. If it crashes, you really should make your code more paranoid about its inputs. Whoever’s bug it is, it’s not a good excuse to crash.

The simplest example is a JPEG. You may get the JPEG you expect, but it’s also possible for the proxy to deliver a smaller JPEG than you expect. The cell provider considers it “close enough”, and the doubly-compressed JPEG is smaller (and far uglier).

This may be true of other file types as well, if they’re commonly recognized as lossy and computationally easy to re-compress.

I have read reports of T-Mobile and O2 doing this. I think it’s been noted with other cell providers, too.

There’s two possible fixes:

• Switching to HTTPS will fix this problem as the proxy will no longer be in the middle of the communication. If your resource is available via HTTPS, this is a fantastic and simple fix.
• Add a HTTP header to defeat this. The idea is to add a no-transform cache-control HTTP header to your request. This should disallow the server from making this kind of change. See RFC 2616, section 14.9.5.

Thanks to Tony Milllion for pointing out the HTTPS solution, and letting me know it affected O2 as well.

I haven’t been using github for long. That said, AFNetworking is the best-managed git project I’ve seen. It’s being managed so well that I wanted to write about it. In doing so, I’m not trying to praise Mattt Thompson’s efforts. It will probably come across that way, and he deserves it. Instead, I want to say that if you plan to maintain a git project, you should handle it as well as Mattt does.

Codebase

AFNetworking is, ultimately, a simple library. It has only a few classes, and reuses lots of the sane bits of iOS frameworks. Its main class is AFURLConnectionOperation, which encapsulates a NSURLConnection and its delegate methods in a subclass of NSOperation.

Without going into the gory details of Foundation framework classes, this is how iOS networking should work. Of course, you could get into a lot of trouble even with the right fundamentals. But AFNetworking doesn’t. It’s ten source files with headers, and one header to rope it all together.

Issues

As I write this, AFNetworking has 368 closed issues. 358 of them are closed. Alone, this tells you something: He responds to issues.

But if you watch how he handles issues, you’ll see qualities to which all developers should aspire:

1. Patience.
2. Humility.

His responses are available to everyone, of course. I came to appreciate how well Mattt was running the project by reading these. Along the way, I learned a lot about AFNetworking.

Pull requests

I have no idea what percentage of the code Mattt has written, vs. code brought in by other contributors. I can tell you that at the moment, AFNetworking has 99 pull requests total. 98 of these are closed. Whether they were merged or not, he’s dealt with them.

Some of these pull requests are pretty mundane. I’ve landed three myself, all very small and ordinary. However, in each case Mattt not only merged the request, but thanked me for it and explained what had happened. The thanks are appreciated. The explanation isn’t necessary, but gives me a better feeling of connectedness.

For the pull request that he didn’t accept, he explained what I was doing wrong (gently and politely), and provided me with an alternative that actually worked better than the pull request I’d made.

Looking through a few pull requests, I don’t see anything unusual about the way he treated me.

Conclusion

Look, I’m not saying Mattt Thompson is handling AFNetworking perfectly. That’d be impossible to prove, and you could probably prove otherwise pretty quickly. But he’s handling it well.

I’m also not going to claim the code is perfect. The library actually swizzles itself, which is one of the craziest things I’ve seen. But the craziness is localized to a small section of code, and minor overall.

I’m feeling connected to the project, I’m feeling confident, and I’m learning more about it. Even the bits I don’t care about yet. And if that isn’t a successful open source project, I’m not sure what is.

Although Objective-C supports exceptions, they’re not commonly used. A thrown exception is usually not caught, making it a fatal error.

The Objective-C Programming Language describes it thus:

Important In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object. For more information, see Error Handling Programming Guide.

What, then, is the usual pattern for handling non-fatal errors. The answer is the NSError class, along with a few simple conventions:

1. Any method that can fail should return 0 (or an equivalent) on failure.
2. Any method that fails by returning 0 (or an equivalent) on failure should take a pointer to return a NSError instance, which it populates with error details.
3. If the error pointer is NULL, the method should not return an error.

For instance:

- (BOOL)doSomethingWithError: (NSError **)error {

    // other code
    NSError *e;
    if ( ![self bitWithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    return YES;
}

This seems pretty reasonable, but can get unmanageable quickly:

- (BOOL)doSomethingWithError: (NSError **)error {
    
    NSError *e;
    
    if ( ![self part1WithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    if ( ![self part2WithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    if ( ![self part3WithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    return YES;
}

Thankfully, blocks can simplify this for us!

- (BOOL)doSomethingWithError: (NSError **)error {

    BOOL(^fail)(NSError *e) = ^(NSError *e) {
        if (error) *error = e;
        return NO;
    };
    
    NSError *e;
    if ( ![self part1WithError: &e] ) return fail(e);
    
    if ( ![self part2WithError: &e] ) return fail(e);
    
    if ( ![self part3WithError: &e] ) return fail(e);
    
    return YES;
}

Using a fail block has a few advantages:

• You have a single place through which all errors in this method are routed. You can put a breakpoint here, or add logging.
• If you change what doSomethingWithError returns, you change just the return type of the block and the return within the block.
• You eliminate a lot of redundant code, therefore lessening the chance of an error in one of the copies.

Footnote: Usually, if I am writing an if statement, I’ll write it like this:

if (foo) {
    // statement
}

I do this even when it’s not necessary, because what if I expand on it later? And I think this is a good principle. But for a fail block like this, I’m never going to add an extra statement. The whole point of the block is to make sure that the failure code is a single statement.

What I’m going to cover:

• The basics of networking using NSURLConnection, part of Apple’s Foundation framework.

What I’m not going to cover:

• How to determine if a connection is available before trying a request. (Hint: Don’t.)
• How to retry an operation when a connection becomes available. (Hint: Reachability.)
• How to abstract this without losing anything important, and bring it all under control. (Hint: Use AFNetworking.)

All of these are topics I’ll write about in future articles. But today, just the basics!

Also, this code will assuming you’re using Automatic Reference Counting. Because you ought to be.

For any HTTP operation, you’re going to use NSURLConnection. It’s not safe to use synchronously from the main thread. This will cause the main thread to stop responding to user-level events, and iOS will quit your application. It behaves exactly as if your application crashed.

On Mac OS X, the system will not quit your application, though your application will become unresponsive and look like it’s frozen. So on Mac OS X, you should follow the same pattern of avoiding synchronous network requests on the main thread of your application.

That leaves three options:

1. Asynchronous networking on the main thread.
2. Synchronous networking on another thread.
3. Asynchronous networking on another thread.

Under normal circumstances, you don’t need to run networking operations on a different thread. There’s very few problems that require moving to another thread.

Using asynchronous operation will cause the networking itself to run in the background. You can consider this a dedicated thread by Apple. Your delegate methods will be called in the correct sequence on the main thread to catch up with networking as iOS determines it is appropriate.

Apple includes an example of how to use NSURLConnection in URL Loading System Programming Guide, Using NSURLConnection. It’s a short article, full of simple code examples. You should spend a few minutes to read this.

In a nutshell, here’s the pattern:

1. Keep a NSMutableData for your response data.
2. Clear the contents NSMutableData instance in connection:didReceiveResponse:. (You may receive multiple connection:didReceiveResponse: events as the request is redirected, but you should only use data from the last one.)
3. Append the data you receive from didReceiveData to the NSMutableData. Don’t try to process it immediately; you will usually receive multiple connection:didReceiveData: events for a single transfer.
4. In connectionDidFinishLoading:, your data is complete. Here, you can do something with it.

The idea here is that your start (or restart) accumulating data in connection:didReceiveResponse:, append data in your connection:didReceiveData:, and actually do something with the data in connection:connectionDidFinishLoading:.

Processing the data shouldn’t really be done on the main thread, either. You can start another thread, but it’s easier to just dispatch_async to a queue that isn’t running on the main thread.

It is possible to run an NSURLConnection on another thread, of course. That thread will need to be using a run loop to receive the delegate events from networking. But unless there’s some reason you need a separate thread, using asynchronous networking is Apple’s solution to this.

Using NSURLConnection requires a class member to accumulate data as its transferred. That means that if you’re going to have multiple simultaneous transfers, you’ll need something more complicated. Probably a wrapper class to drive NSURLConnection, and keep each response separate. By the time you’ve written this wrapper class, you’ve probably written a naive version of AFHTTPRequestOperation, a part of AFNetworking.

But we’ll get to AFNetworking in a future post.

Assuming you only have a single transfer going on at once, your code should look a bit like this:

- (void)doNetworkThing {

    NSURL *URL = [NSURL URLWithString: @"http://tewha.net/"];
    NSURLRequest *request = [[NSURLRequest alloc] initWithURL: URL];
    NSURLConnection *connection = [[NSURLConnection alloc]
                                   initWithURLRequest: request];

    receivedData = [[NSMutableData alloc] init]; // should be a class member
    [connection start];
}

- (void)connection:(NSURLConnection *)connection
didReceiveResponse:(NSURLResponse *)response {
    [receivedData setLength:0];
}

- (void)connection:(NSURLConnection *)connection
    didReceiveData:(NSData *)data {
    [receivedData appendData:data];
}

- (void)connection:(NSURLConnection *)connection
  didFailWithError:(NSError *)error {
    // do something with error here
}

- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
    dispatch_async(someQueue, ^{
        // do something that takes a long time with receivedData here
        dispatch_async( dispatch_get_main_queue(), ^{
            // access the UI here
        });
    });
}

See also:

• URL Loading System Programming Guide, Using NSURLConnection
• NSURLConnection Class Reference

This is pretty simple. There’s very little reason not to write for iOS 5.0.

Market share

According to iOS 5 penetration percentage, iOS 5 has more than 80% of the market at this point. This is only covering one developer’s apps, but it’s cool nonetheless because the data is updated daily.

A bigger sample has been analyzed in iOS Ebb and Flow. This article says that across multiple developers’ apps iOS 5 had captured 76% of all iOS users by March 1, 2012.

Technology

As big a release as iOS 5 was for users, it was even bigger for developers. You’re going to want to use some of Apple’s new technologies.

If you try to target anything older, there’s a couple major features you’ll be unable to use at all:

• Automatic Reference Counting with weak references. Instead of writing memory management code, you describe the relationship between objects and the compiler writes the memory management code for you. On iOS 4, you can get Automatic Reference Counting without support for weak references. But ARC and weak references are a huge deal; see Automatic Reference Counting for more.
• Storyboards. Storyboards aren’t available on iOS 4. Storyboards mean that instead of creating each screen’s layout in its xib and writing code to connect them, you define a single storyboard defines all your screens and even strings them together. You’ll still need to write code, of course, but the code will be less concerned with the minutiae of transitioning between screens.

There’s several more features you can take advantage of iOS 5. Unlike the above list, you can build these into an iOS 4 project, but you’ll need to be careful not to try to use them on iOS 4:

• iCloud
• Twitter integration
• Notification center
• Enhanced AirPlay
• Enhanced Core Image

Hardware

You’ll have a much harder time finding devices to test on. It isn’t enough to target iOS 4, test on iOS 5, and declare it’ll work on iOS 4. It probably won’t without some fixes.

Remember, also, that iPhones cannot be downgraded to a previous version of iOS. If it ships with iOS 5 or you ever accidentally update it, it’s an iOS 5-only device.

But what about hardware support? Who can’t run iOS 5?

Well, every iPhone since the 3GS can be upgraded to iOS 5. The newest iPhone that can’t run iOS 5 was discontinued in June 2010. Apple hasn’t released a software update to it since November 2010. It not only doesn’t run iOS 5, but doesn’t run the latest version of iOS 4. Even if a person bought that phone on its last days on a two year contract, that contract will be up before you finish your app.

Finally, you’ll get to skip supporting the armv6 CPU architecture. Apple’s had some significant armv6 code generation bugs. While at the moment they’re still trying, how long will they continue to try?

Apple doesn’t ship armv6 devices anymore, and the effort to keep the armv6 code generation working seems significant. Each time they slip up, someone gets embarrassed. I can’t imagine they’ll continue to support armv6 code generation for long.

Over The Air

Now that I’ve convinced you to target iOS 5, let me suggest you target only the latest version of iOS, currently 5.1.1. The comments above about not being to downgrade a device from iOS 5 to iOS 4 also apply on downgrading from iOS 5.1.1 to iOS 5.0.

I think you’d probably be on much more solid ground developing for 5.1.1 and allowing operation on 5.0, but if you ever find a bug that occurs only on iOS 5.0 you’re probably not going to be able to recreate it.

Meanwhile, updating from iOS 5.0 to 5.1.1 is just a simple, small over the air update away, and is supported by every device running iOS 5.0. It turns out that users upgrade fast.

Conclusion

If you try to support iOS 4 you are giving up a lot of OS features, and going against the grain of Apple’s tool development, just to chase an ever-shrinking (in both real and percentage terms) market of users who are less likely to be interested in new software.

Are you nuts?

Odds are, the compiler understands Objective-C and Cocoa better than you. I don’t mean this as an insult; it certainly understands it better than me. I think you could safely say it understands the rules better than all but maybe a dozen people worldwide. And it knows tricks to use them to a degree that you and I can’t repeat, even if we understood as well as it does.

The rest is just details, but they’re important:

1. You will write a lot less boring code. Code so boring it’s easy to make mistakes.
2. As a blended compile time and run time process, it has access to tricks that you don’t.
3. It will a better a job of writing memory management code than you can, even if you write the theoretical perfect memory management code.
4. It will reduce “high tide” memory usage (somewhat) without any effort on your part.

If you are starting a new application, stop thinking about it and just use it.

If you have an existing application, you need to think about it. You’re balancing the ease of future development vs. a need to re-test the app. The ARC conversion isn’t awful, but it isn’t painless or foolproof either. You will need to make sure you have no circular references, and you will need to make sure that objects don’t disappear sooner than you think.

If you have an existing application that targets iOS before iOS 5, zeroing weak references are not supported. You can find people who will tell you that zeroing weak references aren’t a big deal. They’re wrong. While it’s true you can use assign to prevent circular references, weak references are what turns ARC from a useful way to write less code to a fantastic way to write stable applications. You should seriously consider requiring iOS 5.

If you have an existing application that targets iOS before iOS 4, you can’t use it at all. What are you thinking, supporting a version of iOS that old?

See also:

• Transitioning to ARC: Apple’s ARC overview. A great overview, but possibly less than you need to know.
• Automatic Reference Counting: The living and detailed ARC specification and rationales. Certainly much more information than you require.

With HTTP status codes 302 and 303, the user agent (in this case, NSURLConnection) will change the request type from POST to GET. This is just how 302 was usually implemented; status code 303 was added to HTTP/1.1 to make this behaviour explicit.

HTTP/1.1 also added a status code to redirect without changing the request type from POST to GET. If you can change the web site, getting it to redirect you with a 307 instead will fix the problem.

If not, you can make NSURLRequest ignore this aspect of RFC2616.

NSURLRequest sends an event to its delegate, in which you can see what NSURLRequest plans to do and customize it:

- (NSURLRequest *)connection: (NSURLConnection *)connection
             willSendRequest: (NSURLRequest *)request
            redirectResponse: (NSURLResponse *)redirectResponse;
{
    if (redirectResponse) {
        NSMutableURLRequest *r = [[originalRequest mutableCopy] autorelease];
        [r setURL: [request URL]];
        return r;
    } else {
        return request;
    }
}

By doing this, you’re cloning the original request and changing the URL to match the request suggested by NSURLConnection (which is following the RFC).

See also:

• w3.org: RFC2616 HTTP/1.1, section 10: Status Code Definitions

After a couple years, I’ve come to adopt some very simple rules for memory management.

Concepts

The first step is to pick up a few concepts that will help you as you code.

• Be lazy in memory management. Rely on the compiler to do everything it possibly can. The compiler can synthesize property setters that handle memory management according to the rules you set. Rely on this.
• Ownership. Think in terms of ownership, rather than reference counting. Thinking in terms of ownership makes problems and solutions obvious. Thinking in terms of ownership will help you keep in mind the why of what you’re doing, rather than the what. After you’ve got a good grasp of why, the what becomes obvious.
• Protect your objects. Own any object that you want to keep around as long as self is around.
• Avoid circular references. Never own an object that could own self. This means never owning self’s delegate or data source.

Practical guidelines

But how does this translate to code? There’s a few specific and concrete things you can do to make this easier on yourself:

• Use properties to centralize memory management rules. Use @property to establish the rules for memory management of an instance variable. (And @synthesize your properties to underscored instance variables to prevent naming conflicts.)
• Pick the right memory management rule. Use retain properties as your default. Data sources, delegates or other objects that might own the object you’re working in should be assign properties instead of retain.
• Rely on the centralized memory management rules. Use property set notation (self.foo = nil;) or the property setter ([self setFoo: nil];) everywhere you change the property’s value except in the property’s setter (if you need one) In this way, you rely on the retain or assign in your @property to specify the memory management. If you need to use retain, release or autorelease outside of a setter you’re doing too much. (And, also, you’ll have more work to do to be compatible with ARC.)
• Avoid being called once deallocated. In dealloc, nil any delegates you’ve set to self. (This eliminates the possibility that the object will survive longer than self and try to send messages to self.)
• Protect your private bits, too. Don’t use raw instance variables in objects requiring memory management. Use anonymous properties.
• Containers own their contents. You not only don’t need to but must not try to manage memory in a system container. An NSArray will send a retain to objects that are added to it, and a release to objects as they are removed. If you try to manually retain and release objects, you’ll miss a case.
• Verify. Analyze your code frequently. And profile your code early and often for leaks.