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.”

My favourite Tahoe features:

• Group chats now sport animated backgrounds. Yes, it’s a small touch that can make Messages feel livelier… but more importantly, I hope to never send a group a message that I meant for an individual again.
• Safari’s reader mode automatically summarizes the article you’re reading in the right rail, sometimes giving you the article headings.
• Control centre and menu bar extras got another pass. It’s an improvement.
• Spotlight’s new UI now has a dedicated app search, which I’ll use a lot. Spotlight also gains a clipboard history, which I hope I remember to use. But probably not.
• Apple’s Journal app makes its macOS debut for those who like to capture daily reflections.
• I feel that Xcode 26 is a big improvement in many little ways, although I didn’t do much Mac development during Sequoia’s tenure. I may be appreciating two years of changes here! The AI assistant is great at offering code changes, though you need to watch what you ask it and watch it really carefully.

Not everything is great, though.

• The new volume and brightness HUDs are easy to miss, and I expect to overlook them entirely most of the time
• Some of Apple’s own apps still do menu bar extras the old way.
• While Spotlight is improved, I had to force it to re-index—a maintenance chore that should be automatic.

I want to mention Launchpad here. Personally, I just use Spotlight. But others seem to be really missing it.

Then there’s the downright ugly.

• Most of the interface looks muddled unless you turn on “Reduce Transparency,” which defeats the point of Tahoe’s glossy new design.
• Off by one (and more) errors abound in the UI.
• The so-called Icon Jail just adds unnecessary ugliness.
• The menu bar intentionally vanishes into invisibility.
• The alert popups look like they were designed by two different people who didn’t talk. The text is left aligned, which is fine. The icon is also left aligned, which is also fine. But the icon sits above the text, giving it a horrible look overall.

I’m going to continue to use Tahoe, because I like Xcode 26. And oddly, I trust macOS 26 with my data. In the past, it’s felt sometimes like Apple has half executed on a plan and missed as a result. Here, it feels like they locked in their plan early and made very few changes during Tahoe’s development. It was just an ugly and inconsistent design.

I have a couple apps planned for the new feature that I’d planned to release on iPhone, iPad and Mac. I want to use 2026 SDK features, so I’d planned to release them as iOS 26, iPadOS 26 and macOS 26 only. As of today, I’m delaying the macOS version until I’m more comfortable telling people they can update to the new macOS. Part of this is just practical, as I expect to have to re-test the Mac app when some future update to macOS 26 comes out due to a tweaked visual layout.

If you don’t have to use Tahoe, I think you should wait a little to see if the reported inconsistencies are going to bother you. I’ll take the new features and the inconsistencies together, but it’s a trade off you might not need to make.

Before I go any further, let me specify with 100% clarity: This problem was fixed 30 years ago, and has absolutely no bearing on Mac OS X/modern macOS. There is probably almost zero overlap between the Apple of 1990 and the Apple of 2021. Modern Apple may make the occasional mistake, but nothing like what I’m about to describe.

Note also that I’m going to simplify this significantly by talking about only the 680x0, not the PowerPC. Mac OS on PowerPC changed a lot, but the PowerPC came years after these problems were fixed, so it’s irrelevant to this discussion.

Background: Resources and applications

Let’s start with the Resource Manager. Mac files could contain a data and a resource fork. A resource fork contained one or more (and often many) resources, stored by type and ID. There were a lot of resource types defined for both the system software and applications. Just for example:

• Icon “lists” were type ICN# resources.
• General code segments were stored CODE resources.
• Windowing code (frames, hit detection, etc) were stored in WDEF resources.
• Code for custom controls (like buttons) were stored in CDEF resources.
• Code for custom menus were stored in MDEF resources.
• Simple black and white icons were ICON resources.
• Color icons were stored in cicn resources.
• Applications defined their metadata (“This is MacWrite!”) with a BNDL resources.
• Applications defined their document types (“This is a MacWrite document; use this icon to display it!”) with one FREF resource per document type.

The resource fork could be viewed as sort of a limited database, each resource having a type and an ID. It wasn’t intended to scale, and there were no queries except by sequence or by ID. (Just so nobody jumps on me: IDs were unique within a type only. Much of Apple’s System Software relied on this: resources would be extended later with a different type of the same ID so the original resource record wouldn’t need to be updated. For example, ICN# defined a black and white icon and its mask. The Macintosh System Software would automatically draw the color icl8 of the same ID on color Macs when possible. This will not be on the exam.)

Applications were built as resource files. Most applications were only resource files. (Some rare applications stored license info or something else in their data forks.)

This information is hard to look up these days, and it doesn’t matter materially to the rest of this. The point is that you’d build your application, and it would contain code and resources.

• If you wanted a custom window appearance or behaviour you’d put that code in a separate build process and output a WDEF resource. This was all reasonable and by design.
• By convention, you’d use IDs in a given range (128 to 32,767 for most resource types) and the system would use other IDs (-32,768 to 127 for most resource types).
• Apple eventually reserved all resource types not containing at least one uppercase letter for future use.
• Nothing actually enforced any of these rules; they were for developer safety, as conflicting with an Apple resource could cause glitches, a failure to launch, or a crash or other bad behaviour somewhere in your application.

One of the features of the Resource Manager was that resource files opened later would override files opened earlier. The first resource file opened by the system software was System. (Logically, anyway.) Other resource files were opened, including ultimately your application.

This behaviour was actually critically important to Classic Mac OS! Your custom WDEF, let’s say ID 128, was part of the resource chain. If your window specified it should be drawn by WDEF 128, it wasn’t referred to as “WDEF 128 in your application’s resource fork.” It was WDEF 128 in your application’s resource chain, which happened to be satisfied by your application’s WDEF 128.

Likewise, a call to WDEF 0 wasn’t really to System WDEF 0, it was to WDEF 0 in the application’s resource chain… it just happened to be satisfied by WDEF 0 in System. This Wild West approach was even abused “well” in some cases, like overriding the System WDEF to change the behaviour to add features. These could patch the behaviour and then call back to the System WDEF. Window shading was done by third parties before Apple got to it. We’re still good!

(As an aside, there were other ways to customize window behaviour: a-trap patches were probably much more commonly used by legitimate code. Classic Mac OS was a wild beast.)

The Desktop database

One of the things the Macintosh System Software did was track application/file associations. Remember BNDL and FREF? These were part of applications, but they were cached centrally per disk in the desktop database. I don’t actually recall how this was done; I’m not sure if they were still BNDL and FREF resources. I think probably not. Various actions would copy BNDL and FREF resources from the application to the desktop database (whatever form that took). There was a Desktop Manager, but it relied on files that applications could (but shouldn’t) write to directly.

The desktop database would be automatically opened when a disk was inserted by opening the desktop database file — which meant adding it to the resource chain. And if you’ve understood all of the above, you might already see the problem — but don’t worry if you don’t. I’ll explain it!

Pandora’s box was open

Now we’ve set the stage. The way the Resource Manager works is perfectly sensible, but the desktop database which was built on top of it doesn’t take into account all the quirks of it. Remember I said later opened resource files took priority over earlier resources? Everything overrides System! Ouch! And let’s now make it worse: In those days, the System Software didn’t protect itself and it was possible to write to various resource forks.

Let’s review:

• Resources in the desktop database are automatically added to the resource chain.
• Code resources in the later resource files are prioritized over earlier resource files.
• Code is unsigned, and code can write to the system and things considered “the system” can write to other applications (including modifying their code).
• Code can also write to the desktop database.

We have everything in place for a viral horror story. Let’s go through this with an infected app:

• You run an infected or delivery application.
• The virus spreads itself to the system file.
• The virus spreads itself to applications.
• The virus spreads itself to the desktop database of all mounted disks, present and future.

An infection being caused by running an application is pretty typical stuff. But it’s the choice of the desktop database that’s the real killer. We don’t just have an infected app now, we have an infected disk:

• Another user inserts the infected disk — the system software immediately adds the desktop database to the resource chain and starts calling code from it, and just like that, the computer is infected!
• The virus spreads itself to the system file.
• The virus spreads itself to applications.
• The virus spreads itself to the desktop database of all mounted disks, present and future.

In fact, the desktop database is such a great vector for propagation that I lied above. The first successful desktop database virus (WDEF) doesn’t actually do steps 2 and 3 ever. We don’t have infected applications! We just have the delivery application, which you may never see, and infected desktop databases potentially on any disk we touch. As a result, the intention of WDEF was that it be basically harmless. Unfortunately, it had bugs that made it not harmless. Later desktop database viruses, like MDEF/Garfield and CDEF, did infect applications however and were intentionally destructive.

It was hard to get rid of permanently. The next user of the infected disk could be you just a few days after you’ve painstakingly removed all traces of the virus. Wham, you’re infected. Again.

To say this virus spread rapidly was an understatement. It’s hard to imagine a more perfect attack vector for viruses! I was in high school at the time, and some of our network shares were infected by admin. That led to every student’s disks being infected.

The situation was truly awful. Locking down those network shares so admin didn’t casually write to them helped. John Norstad’s freeware Disinfectant (1988) helped, Commercial active virus protection like Symantec Antivirus for Mac (1989) helped even more if you weren’t perfectly careful. It was hard to be perfectly careful. Symantec Antivirus would scan disks as you inserted them and alert you to processes trying to modify code, for instance.

System Software 7.0 saves the day

Apple solved this in 1991. System Software 7.0 changed the way the desktop database worked, at least on larger volumes. I don’t think exactly what they did was publicly documented, but the desktop database was renamed, split and no longer stored in a resource fork. There were likely other fixes to how older style desktop databases were loaded, too, as it solved the problem of viruses being spread as soon as floppies were inserted.

Unfortunately, that didn’t stop infections that spread via applications or system files. Some later viruses included MBDF, co-created by Mark Pilgrim (of Dive Into fame).

But the desktop viruses were the worst.

Epilogue: Mac OS X

Over time, System 7 became Mac OS. Mac OS 8/9 became the Classic environment in Mac OS X, whereas a different version of those Mac OS APIs became Carbon. Carbon was a way to build a proper Mac OS X application.

The desktop database viruses were never a problem in the Classic environment, since it didn’t auto-load resources from disks. There was still a System, and later opened files still took priority over it, but this wasn’t a major problem. Classic was ultimately removed in Mac OS X 10.5.

Meanwhile, resource forks were still supported in Carbon for years. I think the dropping of support for 32-bit applications in Mac OS X 10.15 (2019) finished them off since Carbon was never released in 64-bit form, but they might have survived in more esoteric ways. Custom icons on a file used to be stored in the resource fork, for instance, but this was changed years ago. The resource chain was never a danger in Caron, though, as everything under the APIs was implemented differently.

I’m sure there are people with better info than the above, but I think it’s basically correct.

When you’re writing a condition, you should think carefully about not only what you have to check but why you’re checking it. What is the meaning behind the check? How would a human check this? Often, a condition has prerequisites, a primary rule and a list of exceptions. The expression you came up with to express this might not match how you (or anyone else) thinks of it!

For example, let’s say we wanted to save a person record. You might need to know the following:

• That some value of the record has actually changed.
• That the record is not a built-in that can never be changed.
• That the user has permission to change the record.

The code might look like this (and I should warn you, I’m not even going to try to write this in a real language, let alone compile it):

if (!record.isBuiltIn() && (!record.firstName.equals(oldRecord.firstName) || !record.lastName.equals(oldRecord.lastName) || !record.company.equals(oldRecord.company) || !record.department.equals(oldRecord.department)) && user.canChange(record)) {
    // can't save
}

First, stop and break it into a function.

if (!canSave(record, old_record) {
    // you can't save this record
}

boolean canSave(record, old_record) {
    return !record.isBuiltIn() && !(record.firstName.equals(oldRecord.firstName) || !record.lastName.equals(oldRecord.lastName) || !record.company.equals(oldRecord.company) || !record.department.equals(oldRecord.department)) && user.canChange(record);
}

You’ve already improved the condition because you’ve given it a name.

Now, think about the rule and the exception. The rule here, I think, is that the record has changed. The exceptions are the reasons you can’t save it.

boolean canSave(record, old_record) {
    boolean hasChanged = (!record.firstName().equals(oldRecord.firstName())
        || (!record.lastName().equals(oldRecord.lastName())
        || (!record.company().equals(company.firstName())
        || (!department().equals(department()));
    return hasChanged && !record.isBuiltIn() && user.canChange(record);
}

But that’s still going to be a massive pain to debug. So let’s use the “return early, return often” style to make this more readable:

boolean canSave(record, old_record) {
    boolean hasChanged = (!record.firstName().equals(oldRecord.firstName())
        || (!record.lastName().equals(oldRecord.lastName())
        || (!record.company().equals(company.firstName())
        || (!department().equals(department()));
    if (!hasChanged) {
        return false;
    }

    if (record.isBuiltIn() {
        return false;
    }
    
    if (!user.canChange(record)) {
        return false;
    }
    
    return true;
}

Some would argue that the last two returns should be combined, but I think there’s not much difference between returning frequently and relying on short circuit boolean expressions. What matters is how easy it is to debug, and it’s much easier to put breakpoints on unexpected returns if they’re one per line.

You’ll also notice I put hasChanged into a temporary variable. This is 2020, and even if your compiler/optimizer isn’t smart enough to produce equally efficient code, unless you’re sure this is a bottleneck you can spare the cycle or two to handle that. Naming things helps understand them.

There’s a whole argument to be had regarding keeping function results in local variables for easier debugging, but we’ve mostly sidestepped it here. You’ll be able to tell if the record is built in based on what you hit when you step, for example.

Now remember how I said we should think about the prerequisites, primary rule and the exceptions? Now that we’ve written it out this way, I think we’re checking things in the wrong order. It’s probably more important that function fail early if the user doesn’t have the ability to change it. These are more prerequisites than exceptions.

So let’s tweak that:

boolean canSave(record, old_record) {
    if (record.isBuiltIn() {
        return false;
    }

    if (!user.canChange(record)) {
        return false;
    }
    
    boolean hasChanged = (!record.firstName().equals(oldRecord.firstName())
        || (!record.lastName().equals(oldRecord.lastName())
        || (!record.company().equals(company.firstName())
        || (!department().equals(department()));
    if (!hasChanged) {
        return false;
    }
    
    return true;
}

There’s still room for improvement: that last if is hard to read, after all. How could we make it better? The next step would is to split off hasChanged as its own function, providing a quick way to compare if two records are equivalent. Then we could drop the temporary variable if we liked.

If we did that, we’d end up with a canSave function like this:

boolean canSave(record, old_record) {
     if (record.isBuiltIn() {
         return false;
     }

    if (!user.canChange(record)) {
        return false;
    }
    
    if (record.valuesEqual(oldRecord)) {
        return false;
    }
    
    return true;
}

Not everyone will love this code, but it’s very straightforward to read.

You’ll breathe a sigh of relief years from now when you need to debug this! Whether it’s optimal or not, it’s less shitty than the original.

Here’s a partial list of why you don’t want to run Zoom. The problem isn’t so much these vulnerabilities as that they keep coming, and Zoom seems to have a sense of complete apathy towards them. Many of these are bad ideas to the point where it’s hard to imagine a reasonable programmer would do something that way, which leads me to believe there are probably bad fundamental decisions throughout.

July 2019:

• Zoom runs a local web server that allows computers with Zoom installed to have their cameras remotely hijacked and re-install software without permission.
• Having initially refused, Zoom eventually relents and agrees to fix the flaw (later).
• Presumably, because Apple told them that it was going to block their software from running. (This is the first time Apple has done this with a “legitimate” software package.)

March 2020:

• “Zoom bombing” allows hackers to join video conferences. Mostly used for porn advertising.
• Additionally, they share data without permission with Facebook against their own privacy policy.
• Despite marketing, Zoom chats aren’t end-to-end encrypted.

April 2020 (so far):

• Two new vulnerabilities discovered in Mac client.
• Attackers can use Zoom to steal users’ Windows credentials with no warning.
• Zoom is leaking email addresses and phone numbers to strangers.
• New York has banned Zoom from schools.
• Bruce recommends IT either lock Zoom down as best you can, or — better yet — abandon the platform altogether.

I don’t want anyone thinking I think Apple should set up a back door. I think it would be stupid. But I also think it’s reframing the argument away from reality. (Technically, I’m sure it would be pretty easy to generate a master decryption key pair and encrypt the device’s local key using the public part of the pair. Keeping the private part of the master pair secure is theoretically possible but entirely impractical.)

But even if Apple were to agree to add a back door, it would not help get into any currently locked iPhones. Existing iPhones have no back door installed, and would have to be unlocked to install it. If you can unlock an iPhone, you don’t need to install new software to help unlock it! Unless there’s a known vulnerability (which other parties would know about, too) it’s mathematically impossible for Apple to offer much help in unlocking an iPhone.

So there’s no argument about whether Apple should or can unlock these phones. The argument is if we want all phones unlockable by Apple or whoever else holds a copy of the key in the future (and for certain the US government would do whatever it needed to in order to get a copy).

If Apple were to be forced to install a back door, I hope it is only done to US devices. I also think that if Apple is forced to generate a back door for US phones it should look to relocate its operations and development to a safer country.

The problem with macOS Catalina and iOS 13 isn’t that they’re unusually bad. The problem is they’re exactly the same quality as (nearly) every other major release of macOS and iOS, and it just isn’t acceptable anymore. A further problem is that Apple is actually trying to fix these problems this cycle by rapidly releasing fixes, but the software is just too complex for that to work well.

The six points listed are absolutely the reason. But saying “this is unusually bad” is not just wrong but counterproductive. As long as we keep justifying bugs in major releases as “well, it’s not usually this bad” we give them an excuse to continue.

Let me be clear: No, it’s always been this bad. So much so that I wrote about this in 2016. As long as things keep going this way, it’s always going to continue to be this bad. It’s time to accept a simple truth: This is not a one off, any more than previous releases were. Until things change, the quality isn’t going to improve.

The first step to solving a problem is to acknowledge its existence. When faced with reality, choose to believe reality.

I resolved this by breaking it into many NSOperation subclasses. Because of the new design, it should have supported multithreading a large portion of the sync. But when I allowed those operations to operate concurrently (to a limit, more on that in another post), the application would get into thread deadlocks that I couldn’t understand.

Eventually, I actually read what the debugger was telling me. It turns out that my multi-threaded code was all running on a single thread. I had a Core Data context for each operation and was using private queues, surely this would be enough?

It’s not. My expectations were set wrong by misunderstanding of performBlockAndWait: based on reading too much into NSPrivateQueueConcurrencyType. Apparently this is something discussed in WWDC sessions, but not in Apple’s NSManagedObjectContext reference and I’d somehow missed it.

Given that I was using a managed object context with a private queue, I thought performBlockAndWait: blocks were being executed on the private queue.

That’s not how it works.

I was straightened out by BJ Homer on Twitter:

@tewha If you use performBlockAndWait, it will prefer to run on the caller’s thread if possible. Just has to obtain a lock first.

In fact, calls to performBlockAndWait: make the current thread wait until it can get Core Data concurrency locks, then executes on the current thread. This isn’t documented, but neither was my assumption of how things worked.

In my case, this was the main thread because I was executing code in AFNetworking completion blocks, which default to the main queue. As I had assumed this code would not be run from the main thread, locks here conflicted with those I’d constructed on other threads and caused the deadlock.

I fixed it by dispatching the bulk of my completion blocks to a dedicated background queue.

What does this really mean?

Be dumb about Core Data! Don’t make assumptions about which thread your code will run on. Even if you’re right, there’s no guarantees about the future.

performBlockAndWait calls your block in an environment where it can access Core Data via the target context and waits for the code to complete. You should not assume anything about the thread.

performBlock calls your block in an environment where it can access Core Data via the target context and doesn’t wait for the code to complete. You should not assume anything about the thread.

Other than time, there’s a few things I use my Apple Watch for every day. Added up, I’m very happy with the purchase. I’m not sure I’d get stainless steel again, but at the time I was worried about the glass screen. I wear it whenever I’m awake.

• Messages. I love just getting a tap on my wrist. There’s an entirely different feeling to receiving a message on the watch vs. my phone. Whereas my phone and its text tone says “look at me,” that little tap from my watch tells me “when you feel like it, I’ve got something for you.”
• Screening calls. I usually turn the ringer off on my phone. Instead, I get a tap on my wrist when a call comes in, and it tells me who it is. If I want to answer, I’ll pull out my phone and answer. I could absolutely do this with my phone, and I used to, but this is just easier. (I have used the speaker, and the microphone quality isn’t bad.)
• Apple Pay. To pay for most things, I tap the side button twice. It brings up my credit cards. But it’s actually more secure than a real credit card: Take the watch off my wrist, and it locks. I’m looking forward to more places accepting Apple Pay so I don’t need to carry my cards everywhere, but it’s already available enough to be used daily. (This is in Canada.)
• Sunrise/sunset. I know there’s a lot of ways to do this, but I find the Solar face unbelievably intuitive. It also nicely demonstrates the dark despair of living in the Vancouver area in winter. Give us Vancouverites a break, please, if we get bummed out this time of year. (When I showed the solar face to a coworker, his first question was “What’s the horizontal line?” “That’s the sun.” “Oh. I thought we had more than that.” Nope!)
• Movement reminders. My job is sitting at the computer. I could have my computer remind me every hour to stand up (in fact, I used to do this) but having the watch monitor me means I’m only reminded in hours I’ve been sitting.
• Unlocking my Mac. I can’t believe I forgot this in my first draft! I type my computer password in once per day now. The rest of the time the computer just sees the watch beside it and lets me in.

If I take it off the charger at 6am it’ll usually last until 6pm the next day. But if I forget to charge it overnight, charging it while I get ready in the morning will guarantee it makes it through the day.

Current Canadian starting price is $399 for the 42mm version of the Series 1.

I bought my wife an Apple Watch for her birthday, too. There’s a few differences in our experience:

• She got the 38mm Sport in pink. (This model has the glass screen, but that’s been fine. It’s even a little brighter than mine.)
• While her battery makes it through the day (at least since one of the earliest updates), I don’t think there’s any way she’d get 36 hours out of it.
• She doesn’t wear hers at home a lot of the time, but puts it on if she’s going out. At work she’s able to read messages throughout the day, which she wouldn’t be able to on her phone. If she’s out for fun, she uses it to screen notifications and calls as well since it requires less of her attention than fetching the phone.
• She doesn’t care about sunrise/sunset, and uses the Butterflies face instead.
• She also uses it for Apple Pay. But this is more critical for her, since she carries a lot less at work. Luckily she works at a restaurant, so if it fails for some reason I get to pay when I pick her up. This has happened only once or twice, and only in the early days or when we’ve got new credit cards.
• Her fluoroelastomer band discoloured after about 11 months. Mine was still fine. This might be the chemicals she works with, but it might just be that the lavender colour doesn’t hold up as well. We picked up a replacement nylon band.

To me, this quote from the article completely demonstrates why you might want a smartwatch:

So far, “there’s not a great use case for a smartwatch,” said Jitesh Ubrani, a senior research analyst with market intelligence firm IDC, who studies mobile technology. “A lot of what these devices can do, they’re essentially just mimicking the phone.”

This is both absolutely right and wrong, because it presents but ignores the use case: You can do it from your wrist without pulling out your phone.

If you don’t mind picking up your phone whenever it demands your attention, great. You can trim the notifications down a lot, after all. But if you want to put your phone in your pocket and keep it there most of the time, at your desk or while out… that’s a big part of what the watch is for. You can decide if it’s worth the money for you, but it was for me.

Aside from the stand notifications, I haven’t even started the fitness stuff. That’s still to come.

Walt Mossberg:

In the last couple of years, however, I’ve noticed a gradual degradation in the quality and reliability of Apple’s core apps, on both the mobile iOS operating system and its Mac OS X platform. It’s almost as if the tech giant has taken its eye off the ball when it comes to these core software products, while it pursues big new dreams, like smartwatches and cars.

Jim Dalrymple:

It’s just not like Apple to release software that is so broken.

Although the headline is “apps,” both articles actually talk about a wide variety of Apple software including the core OS.

Look, I’m not here to argue that Apple’s software is perfect. I think it’s pretty good and it’s getting better, but that’s beside the point. What I find ridiculous is the assertion that “this used to be great.” Frankly, it’s setting the bar way too low.

Don’t believe me? Let’s look over some quotes about Apple’s software quality. See if you can guess for what Apple release it was written. Most of these are quotes from the time, but some are in retrospect.

Note: Although I’m presenting these as quotes, I’ve stripped the version number, keywords, old application names and technologies. Further, I’ve been bad and have not marked those edits in the text, so please check the original story for the real quote. This is all done to make the game more entertaining. I hope the original authors understand this comes from the very best place.

Our first quote is about a broken installer:

The release was pulled due to a mistake at Apple, in which some components were not included in the installer.

This was said about 1996’s System 7.5.4 (Source: Wikipedia’s System 7 article).

Next is about Wi-Fi problems introduced in an OS update:

The Mac OS X update installed fine but I lost networking including ability to talk to my Apple Airport Extreme.

This was said about 2003’s Jaguar 10.2.8 (Source: CNET’s Troubleshooting (pulled) Mac OS X 10.2.8)

Now let’s talk lack of polish:

But that’s not to say that this initial release is all sunshine and daisies. I ran across quite a few bugs and flaws in the software as I tested it, and while none are significant enough to recommend against upgrading, this strikes me as the least polished major iOS update in quite some time.

This was 2011’s release of iOS 5. (Source: iOS 5 Review: Ambitious update rings in the changes)

Next, we’ve got a quote about data corruption:

Just connecting a drive using this technology to a Mac running OS X can ruin the data on the drive. The problem does not occur with earlier versions of Mac OS X, however.

This was said about 2003’s Panther 10.3 (Source: Macintouch’s “Panther FireWire Bug”)

On inconsistent UI:

Such basic design flaws demonstrate a lack of unity among Apple’s development team and a lack of overall coordination and user design standards.

This was said about 2005’s Tiger 10.4 (Source: “Macintoch’s Tiger Review”)

On security problems:

Apple has significantly lowered the bar for malicious entities to install and execute damaging code in OS X.

This was said about 2005’s Tiger 10.4 (Source: blueprint for a widget of mass destruction)

On updates that don’t work:

Apple support drones are getting an earful from Mac users who are experiencing frozen Macs while trying to update to the latest and greatest version of OS X.

This was said about 2007’s Leopard 10.5 (Source: Dreaded Blue Screen of Death mars some Leopard installs)

On applications being broken:

Users are reporting a significant number of applications being affected by the issue, including Microsoft Office, older versions of Adobe Photoshop, and various other applications…

This was said about a 2012 security update to Snow Leopard (Source: Snow Leopard Security Update Kills PowerPC Apps Using Rosetta)

On sideways motion:

It has gotten mixed reviews from customers, so far (like other recent versions of Mac OS X, come to think of it). There are real technical and usability improvements, but these are obscured by interface changes and special effects.

This was said about the 2011 release of Lion (Source: Macintouch’s Mac OS X 10.7 Lion Review)

It’s absolutely true Apple’s shipped some stinkers like discoveryd, but that’s nothing new. If we want better, the most important thing is to start from reality. A narrative shared by the blogosphere is different from fact.

So let’s start from reality: We don’t need a return to the “golden era” (which may not even have been any better). We need better.

Note: I reserve the right to add new examples if I feel like it. I’m not a reporter, and this isn’t a news story.

For a while, though, Xcode has supported a build option Create Info.plist Section In Binary, also known as CREATE_INFOPLIST_SECTION_IN_BINARY. If on, this will embed the target’s Info.plist into the executable as a data segment.

I couldn’t find any documentation on how to get it out, though. After a lot of searching, I came up with getsectbyname. This is defined in mach-o/getsect.h like so:

extern const struct section_64 *getsectbyname(
    const char *segname,
    const char *sectname);

(There’s a 32-bit version as well, but I was only interested in 64-bit.)

One of the fields in section_64 was the address of the data in memory, another its size. Easy to wrap with a NSData, right?

Not so fast. This worked in debug and release builds when run in Xcode, but didn’t work when run on Terminal or Instruments. There, accessing the raw bytes caused a segmentation fault.

A tweet from Greg Parker put me on track.

The difference turned out to be Address space layout randomization (ASLR). You can read all about it on Wikipedia, but the gist of it is that in order to make it harder to exploit a vulnerability many operating systems have implemented a system where executables are randomly located in the address space. This makes it harder for injected code to access application or system code. The results returned by getsectbyname don’t take ASLR into account.

Instead of using getsectbyname, I had to use getsectiondata. getsectiondata would return a pointer to the exact data I needed. It took me quite a while to find anything relevant online.

It’s declared like this:

extern uint8_t *getsectiondata(
    const struct mach_header *mhp,
    const char *segname,
    const char *sectname,
    unsigned long *size);

But what’s that fist thing, the mach_header?

It took me a long time to find anything relevant, but I eventually found out that I needed to use _mh_execute_header from mach-o/ldsyms.h.

The resulting code looks like this, and works:

#include <mach-o/getsect.h>
#include <mach-o/ldsyms.h>

- (instancetype)init {
    self = [super init];
    if (!self) return nil;
    
    NSError *e;
    unsigned long size;
    void *ptr = getsectiondata(&_mh_execute_header, "__TEXT", "__info_plist", &size);
    NSData *plistData = [NSData dataWithBytesNoCopy:ptr length:size freeWhenDone:NO];
   _infoPlistContents = [NSPropertyListSerialization propertyListWithData:plistData options:NSPropertyListImmutable format:NULL error:&e];

   return self;
}

This only works in the application; if you need to do this from a dynamic library, try this approach from Cédric Luthi.

Full credit to those two, but I wanted to post something about this so that future searches might find it. Thanks, guys!

Past projects

I’ve worked at Discovery Software all of my career. We’re a small software company specializing in the K12 education market.

I was lead programmer on the original InteGrade/reMark for DOS and Windows.

I also co-created and ended up leading InteGrade Pro for Macintosh, DOS and Windows.

I wrote the first version of Principalm for Palm, and the code that would later become Principalm Connect.

Current projects

I’ve written and maintained the iOS version of Principalm, Teacherpalm and Rubrix.

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!

CBC has a story right now on how Facebook Messanger captures more data than you think. And thanks to how inaccurate that story is, now I have to defend Facebook. Way to make my day, CBC.

It’s replacing a web app

Do you care if Facebook knows which way you hold your phone or which UI elements you use within the Messenger app to work?

How you use the UI is useful to them in aggregate, as it helps them improve the UI if they find people taking inefficient paths, backing out of screens immediately (they probably tapped the wrong thing), etc. They can certainly tell all these things if you use the website; that’s just part of how the web works.

I’m not a fan of analytics and I wouldn’t do it in my own apps. First, if you don’t burst those transmissions with other data, it’ll drain the battery a lot faster. Even if you do it’ll drain it a bit faster. But also, unless you explicitly opt into the analytics – and not as part of a general Terms of Service, like you probably did with Facebook – it’s skeevy.

But remember this app is replacing a website. All of this data would be sent to a website from a web browser anyway. For a company replacing a web browser, building in analytics like this probably seems an obvious choice. Certainly, if you think going back to using the website will save you from Facebook knowing how if you opened this menu here or how you to delete a message you’re wrong.

Going back to my question: Does it matter if Facebook knows which way you hold the phone when you type, to use one of the examples from the CBC article? No, of course not.

I don’t even run basic analytics on this site. I do outsource the creative commons badge on the bottom of this page, and there is a script link to App.net. It’s technically possible that they do something. I write because I enjoy writing. I don’t really care who reads it. I bet CBC runs a lot more analytics. Probably as many as Facebook’s Messenger.

Memory representation

Zdziarski also makes a point about how credit cards are stored in memory.

Memory is memory; the iPhone never writes swap pages to disk. Everything you do on your computer is stored in memory. It’s all transient, and it all goes away.

Worrying about credit cards being stored in memory is alarmist garbage. If you’re worried about someone connecting a debugger to an app, stop.

Private API

Zdziarski says that Facebook Messenger uses private API to get the name of your Wi-Fi SSD.

No, it doesn’t. The Wi-Fi SSID is available as part of the public API since iOS 4. I use this on some of my networking screens to let the user know which network they’re connected to, so my users can tell if two devices are on the same WiFi network.

Holding everything else constant, “No iPhones running MyAppName found on PARKSIDE,” is simply a better message than “No iPhones running MyAppName found on your Wi-Fi.”

I don’t have permission to share the code I use. I didn’t even ask, because I found similiar code on stackoverflow. The key point here is that CNCopyCurrentNetworkInfo (a public API) returns a NSDictionary of information. If you don’t know what that means, a rough translation is “There’s a call in the public API that tells you everything about the network that Apple thinks its okay for you to know.” The SSID is in there. It’s part of Apple’s public API.

Understand, I’m not vouching for Facebook

I have no idea how the Facebook Messenger app works. For all I know, it’s a giant mess of holes.

But I think if there were real holes here, we’d probably have better examples than looking at the name of your SSID, which button you tapped, or which way you hold the phone to type.

Focusing on the wrong thing

You’re missing the point when you worry about these kinds of things.

A better thing to worry about: Has Facebook built a system where your messages are really secure, not just from hackers but from them? No.

You should be worried about sending the contents of your message through Facebook, whether you’re using the website or the app. Are they going to look at it? Probably not. Could they if they wanted to? Absolutely. Will they if it’s part of a broad data collection warrant? Yes, of course.

If you care about privacy, use a secure system. Facebook isn’t one, but neither is SMS.

By the way, did you jailbreak your phone?

Just so you know, that disables a lot of Apple’s security precautions. It won’t make a difference here, but if you’re worried about Facebook Messenger’s security with a jailbroken phone… I’m laughing. Worry first about whatever fly-by-night package manager and packages you have installed.

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.

If you read the documentation for the class, you’ll see this:

Creating Index Paths

• indexPathWithIndex:

• indexPathWithIndexes:length:

• initWithIndex:

• initWithIndexes:length:

• init

Yes, you can use these to construct an index path. But you probably don’t want to. UIKit defines a category on NSIndexPath specific to UITableView’s needs:

// This category provides convenience methods to make it easier to use an NSIndexPath to represent a section and row
@interface NSIndexPath (UITableView)

+ (NSIndexPath *)indexPathForRow:(NSInteger)row inSection:(NSInteger)section;

@property(nonatomic,readonly) NSInteger section;
@property(nonatomic,readonly) NSInteger row;

@end

There’s a similar category defined by UICollectionView:

@interface NSIndexPath (UICollectionViewAdditions)

+ (NSIndexPath *)indexPathForItem:(NSInteger)item inSection:(NSInteger)section NS_AVAILABLE_IOS(6_0);

@property (nonatomic, readonly) NSInteger item NS_AVAILABLE_IOS(6_0);

@end

The absence of section in this category isn’t significant; the same property is already defined by NSIndexPath (UITableView).

UIKit defines other categories, such as drawing categories on NSString.

Why are these separated? Well, NSIndexPath is part of Foundation. UITableView is part of UIKit. String drawing is added to NSString which is part of Foundation, but Foundation, but uses UIFont which is part of UIKit. In short, there’s good technical reasons for this to be splatted out. But knowing that is not helpful to us developers.

So how do you find out about these methods? I don’t think there’s a good way to find categories like these in Apple’s class references. Some of them are mentioned in Apple’s less reference-like material. For instance, there’s ”Collections Programming Topics: Index Paths: Storing a Path Through Nested Arrays”:

In iOS, UITableView and its delegate and data source use index paths to manage much of their content and to handle user interaction. To assist with this, UIKit adds programming interfaces to NSIndexPath to incorporate the rows and sections of a table view more fully into index paths. For more information, see NSIndexPath UIKit Additions. For instance, index paths are used to designate user selections using the tableView:didSelectRowAtIndexPath: delegate method.

Google searches are probably your best bet, such as index path from row and section.

I hope we’ll see improvements on this in the future.

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;

But nevertheless, I wanted to share how I feel about pricing as a user of software.

I’m going to start with something bold, then work my way back to it: Never let me perceive your product’s pricing is unstable and currently at a high.

Introductory pricing

Catching introductory pricing is always interesting. I fight a feeling that your product is not worth its full price yet, whether due to bugs or missing features.

I need to make a decision: Is your product’s value enough to justify its current price? Are you really going to make it more valuable to match its price later? Do I want the current features at the current price, or trust that you’ll make it worth its final price later?

Missing introductory pricing doesn’t necessarily raise my hackles. I am annoyed, however, if I was considering your product and you arbitrarily ended the offer without any notice.

Overall, I think introductory pricing is reasonable. Give me a little warning before you end it, though!

Summary:

• Tell me when (or why) the offer ends.
• Tell me what the new price will be.
• After the increase, eliminate any trace of the old price and update your site to make the product freshly exciting.
• Sticking with your price is better.

Sales

Sales can feel arbitrary, or they can feel generous and deliberate.

It’s perfectly fine to have sales that coincide with a time period that’s knowable but you don’t define. This limits my feeling of arbitrariness on your pricing.

For instance, a Black Friday, Boxing Day or WWDC week sale? I’ll shrug it off when I discover your product a week later as something I missed. Oops.

Likewise, a sale before a new version? Go ahead.

On the other hand, arbitrarily sales give me a feeling of instability. A 50% price drop for the month of March? I’m going to be annoyed when I discover your product in April.

But better yet: Don’t do sales. Putting on my developer hat for a moment, is what you made worth it or not? If it is, it is.

Summary:

• Stick to time periods with meaning.
• Don’t teach me that sales could happen at any time.
• Sticking with your price is better.

Discounts

This doesn’t apply if you’re doing App Store sales, but if you’re doing direct sales you need to be more careful with discounts than some of you are being.

Make sure a discount makes sense to me. If you offer a lower price to someone who purchased something in the past, that’s totally reasonable. If you offer a lower price to everyone who does something and I can still do it, that’s reasonable too. If you offer a lower price to someone for completely arbitrary reasons and I can’t qualify, it’s going to annoy me.

There’s a few exceptions to this. Go ahead and offer discounts to students and teachers, for instance. “We all know” that students are poor, even though most of them probably have more discretionary income than I do. And a good teacher deserves to go through life while being fanned by their admirers. Go ahead and offer to discuss discounts for other groups. Just don’t show me what the discount is and that I don’t qualify for it.

Summary:

• Go ahead and offer bundles or discount cross grades.
• It’s better to tell me discounts may apply in special circumstances than to show me them.
• Education is an exception. Go ahead, I won’t feel slighted.
• Sticking with your price is better.

Price increases

Is your product already under-priced? Go ahead and announce you’re increasing the price at a specific time or event. Then stick to it.

If I’m interested in your product at its old price, I will probably nod and agree with you that you were or are undercharging. And if I catch the price before it goes up, so much the better.

Summary:

• Tell me what your new price is.
• Optionally, give me a reason you’re increasing it. (I mean features; I don’t need to know the details of your business or life.)
• Follow through with your plan.

Conclusions

What do I think you should do?

• Set a fair price. Stick with it.
• If your product is released at an introductory price, say when it’s ending and what the new price will be.
• If your product is under-priced, go ahead and announce and raise the price.
• Don’t have arbitrary sales or offer discounts, especially those that hint that your product is unfairly priced the rest of the time.
• Most importantly, do not make me perceive your product’s pricing as unstable and currently at a high.

A price of $15 is more likely to make me a happy buyer than a price of $10 I think will be $5 next month, or was $5 last month.

Maybe the numbers make enough sense that you want to do it anyway. That’s fine, I’m only expressing how I feel about it.

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.

There’s also C99 initializer syntax.

The main advantage to the C99 syntax is that it gives you some very Objective-C like syntax, where the fields are close to the values rather than implied by positioning. (That’s not to say this is intentionally similar, or that it’s the only advantage. But it is nice.) It also provides type checking, and since fields are named it catches drifts in meaning that you otherwise wouldn’t catch.

It’s sometimes slightly more typing, but I use it everywhere now.

The syntax

Consider the CGRectMake way to make a rectangle:

CGRect a = CGRectMake(a+c/2, b+d/2, c, d);

In order to understand this, you need to understand the order of the parameters. You also need to be able to catch the commas easily with your eyes. In this case, that’s pretty easy, but if the expressions were more complicated you’d probably be storing them in a temporary variable first.

The C99 way:

CGRect a = (CGRect){
    .origin.x = a+c/2,
    .origin.y = b+d/2,
    .size.width = c,
    .size.height = d
};

It’s longer, but it’s more explicit. It’s also very easy to follow what is assigned to what, no matter how long the expression are. It’s also more like an Objective-C method. After all, if CGRect was a class, it would probably look like this:

CGRect a = [[CGRect alloc] initWithOriginX:x originY:y width:w height:h];

Note that any field you don’t explicitly initialize is initialized to zero. This code, for instance, will create a rectangle with an origin of 0,0.

CGRect smallRect = (CGRect){
    .size = mySize
}

The C99 syntax is a nice compromise; it’s more compact than class construction, but still names field values.

Catching changes

Naming fields might seem like extra work, but it’s also extra safety. If the names or meanings of the parameters change, you’re going to get compiler errors. The compiler will help you find these, now! And if you write new code based on the old rules, compiler errors will point out what you’ve done.

This isn’t much of a concern for CGRect; it is how it is. Apple is probably never going to redefine it. But many years ago, QuickDraw used edges for its Rect structure instead of points. If you were still trying to break that habit, the compiler would complain every time you did this:

CGRect a = (CGRect){
    .left = 0,
    .right = 100,
    .top = 0,
    .bottom = 100
};

In your own code, this may be an active concern to you. You may have structs (or use C libraries that have structs) that will change layout in the future.

Type checking

That’s only the start of C99 initializer coolness, though.

You can also do things like this:

CGRect a = (CGRect){
    .origin = myOrigin,
    .size = computedSize
};

Here, you’re building a rectangle using a CGPoint and CGSize. The compiler understands that .origin expects a CGPoint, and .size expects a CGSize. You’ve provided that. All’s gravy.

The equivalent code would be CGRectMake(myOrigin.x, myOrigin.y, size.width, size.height). By using CGRectMake you’re no longer expressing the same kind of meaning to the compiler. It can’t stop you from assigning part of the size to the origin. It also won’t stop you from assigning the width to the height. It doesn’t even give you a good clue about which is the X and Y; if you’ve used APIs that provide vertical coordinates first, you’ll get it wrong. If you’re used to APIs that provide two points or something else (like QuickDraw’s edges) instead of a point and size you’ll also get a compiler error.

You can assign part from a structure and part from floats as well:

CGRect a = (CGRect){
    .origin = myOrigin,
    .size.width = c,
    .size.height = d
};

Drawbacks

As I said, this is more typing than CGRectMake. What I didn’t say is that it’s even more typing than you expect, because as of Xcode 4.6, you still can’t autocomplete the field names. You really do need to type all that extra code.

I think this is a good pay off for being able to read the code so easily later, but you may disagree.

Conclusion

The CGRectMake function predates C99. I have no evidence to this effect, but I think if C99 had come first CGRectMake probably wouldn’t exist at all; it’s the sort of crusty function you write when your language has no direct way to perform the initialization. But now it does.

This doesn’t only apply to CGRect. Any of the simple struct types can be initialized this way, such as CGPoint, CGSize and NSRange.

Avantages:

• Explicit: You’ve named the parameters.
• Type safe: You’ve provided enough meaning to the compiler that it can help you not screw up.
• Easy to read: Especially with longer expressions, you’ve eliminated needing to scan for commas when you read the code later.

Disadvantages:

• More typing: You read code a lot more than you type it, so I think this is a great tradeoff.

Averaged over time, anything you can screw up you eventually will. Using defensive techniques makes sense. Try it for a while; I think you’ll like it!

Special thanks to:

• Peter Hosey for reminding me how QuickDraw worked and inspiring “Catching changes.”

• Luke Bernardi for reminding me that Xcode’s autocompletion can’t suggest field names.

• BJ Homer for tipping me that unnamed fields are initialized to 0.

Let me start with this bold statement, then I’ll back up and explain it: Use instancetype whenever it’s appropriate, which is whenever a class returns an instance of that same class.

First, some definitions:

@interface Foo:NSObject
- (id)initWithBar:(NSInteger)bar; // initializer
+ (id)fooWithBar:(NSInteger)bar;  // convenience constructor
@end

For a convenience constructor, you should always use instancetype. The compiler does not automatically convert id to instancetype.

For initializer, it’s more complicated. When you type this:

- (id)initWithBar:(NSInteger)bar

…the compiler will pretend you typed this instead:

- (instancetype)initWithBar:(NSInteger)bar

This was necessary for ARC. This is why people will tell you it isn’t necessary to use instancetype, though I contend you should. The rest of this answer deals with this.

There’s three advantages:

1. Explicit. Your code is doing what it says, rather than something else.
2. Pattern. You’re building good habits for times it does matter, which do exist.
3. Consistency. You’ve established some consistency to your code, which makes it more readable.

Explicit

It’s true that there’s no technical benefit to returning instancetype from an init. But this is because the compiler automatically converts the id to instancetype. You are relying on this quirk; while you’re writing that the init returns an id, the compiler is interpreting it as if it returns an instancetype.

These are equivalent to the compiler:

- (id)initWithBar:(NSInteger)bar;
- (instancetype)initWithBar:(NSInteger)bar;

These are not equivalent to your eyes. At best, you will learn to ignore the difference and skim over it. This is not something you should learn to ignore.

Pattern

While there’s no difference with init and other methods, there is a different as soon as you define a convenience constructor.

These two are not equivalent:

+ (id)fooWithBar:(NSInteger)bar;
+ (instancetype)fooWithBar:(NSInteger)bar;

You want the second form. If you are used to typing instancetype as the return type of a constructor, you’ll get it right every time.

Consistency

Finally, imagine if you put it all together: you want an init function and also a convenience constructor.

If you use id for init, you end up with code like this:

- (id)initWithBar:(NSInteger)bar;
+ (instancetype)fooWithBar:(NSInteger)bar;

But if you use instancetype, you get this:

- (instancetype)initWithBar:(NSInteger)bar;
+ (instancetype)fooWithBar:(NSInteger)bar;

It’s more consistent and more readable. They return the same thing, and now that’s obvious.

Conclusion

Unless you’re intentionally writing code for old compilers, you should use instancetype when appropriate.

You should hesitate before writing a message that returns id. Ask yourself: Is this returning an instance of this class? If so, it’s an instancetype.

There are certainly cases where you need to return id; namely, if you’re returning a different class. But you’ll probably use instancetype much more frequently than id.

When?

This is straight from Clang Language Extensions:

• the first word is “alloc” or “new”, and the method is a class method, or
• the first word is “autorelease”, “init”, “retain”, or “self”, and the method is an instance method.

Left unsaid is whether it’s better to actually specify instancetype for these rather than rely on automatic promotion of id. Most code I’ve seen relies on the automatic promotion. I’m not sure what combination this is of momentum, readability, compatibility and convention. I’ve kept to using id in these cases, but that’s mostly due to momentum.

However, you should certainly use instancetype if you want to specify that an instance of the receiving class is returned in cases where autopromotion doesn’t occur, such as a convenience factory.

For example, in this case:

MyObject *bar = [MyObject objectWithParameter: foo];

…you would want MyObject to specify that objectWithParameter returns an instancetype rather than an id.

See also:

• Mattt Thompson: instancetype.

In this article, I’ll discuss the advantages of @property which make it worth using, and discuss “dot syntax.”

Properties

Properties are awesome. A @property declaration formalizes some things that previously had to be explained in comments or by convention.

Without properties, you’d specify a getter and setter like this:

@interface Bar : NSObject
- (void)setFoo: (NSObject *)foo;
- (NSObject *)foo;
@end

With properties, you can specify it like this:

@interface Bar : NSObject
@property (readwrite, atomic, strong) NSObject *foo;
@end

Whereas a set accessor defines only the owning object and the new value, a @property declaration specifies the memory management model for the new value. Is the setter going to copy it, own it, or just assign it? With ARC, these become even more useful: You can copy it, specify that it’s kept via a strong reference, specify that it’s a weak, zeroing reference, or specify that it’s a weak reference that could become a dangling pointer.

Further, you can specify whether the property is atomic: If two threads try to access a property at the same time, is the behaviour fully defined?

Even more useful, if your getter and setter are trivial Objective-C can synthesize them for you. (In older compilers, you needed to specify this with @synthesize; in the latest version, the compiler will do this for you.)

Note: If you write your own getter/setter, you’re responsible for making sure it complies with the memory model and atomicity you’ve specified in the @property. The @property is a promise to other compilation units, and your object is not held to that promise by the compiler.

What is dot syntax?

Dot syntax is syntactical sugar for accessing properties. Whereas the @property statement defines the property, dot syntax is an option for calling it.

Excluding dot syntax these are equivalent:

_view1.frame = _view2.frame;
[_view1 setFrame: [_view2 frame]];

There are some unexpected gotchas involving dot syntax. This, for instance, does not compile:

_view1.frame.size.width = 10;

The reason is it’s equivalent to this:

[_view1 frame].size.width = 10;

You can’t change a field in a rvalue like this. Instead, you need to do this:

CGFrame frame = _view1.frame;
frame.size.width = 10;
_view1.frame = frame;

This shows an important distinction: dot syntax may look like struct access, but it isn’t the same thing at all.

Using dot syntax

In some cases the compiler will even let you get away with dot syntax for methods that aren’t properties. But you really shouldn’t; Objective-C isn’t Visual Basic (where this is supported) and this runs counter to the language. In the past, I’ve seen Apple engineers argue that doing so is taking advantage of a compiler limitation that will probably eventually be fixed. Or maybe it’s a compiler limitation that they’ll never get around to fixing. In either case, it’s taking advantage of a compiler limitation.

There’s a huge grey area here. Some will argue setting a property shouldn’t have side effects, shouldn’t perform an action, or many things between.

Clearly, setting something without side effects is a property. I think most Objective-C developers will agree with this, though some argue that calling code at all makes dot syntax inappropriate. The argument is that it looks like struct access, so it should behave exactly like struct access. I don’t agree with this, but some very wise people do.

By UIKit convention, visual side effects (such as changing a frame) is acceptable. Some of these are true properties, complete with a @property definition. Some lack the @property definition, as @proeprty predates much of UIKit but make sense as properties anyway. (I picked UIKit here because it’s more modern than AppKit, but the same applies there.)

However, a method that takes no parameters but does not return a value is clearly not a property. Obviously, a method that takes parameters that do not conform to a getter/setter signature does not represent part of a property.

This, while legal under some configurations, is never appropriate:

obj.release;

Dot syntax should be limited to things that are semantically properties only. Whether you further limit that to things that are only defined with @property is up to you. I do for my own objects, but I prefer to believe that Apple would fix UIKit’s missing @property definitions before enforcing this at a compiler level. If I’m wrong, it’ll be easy enough to remove dot syntax from the affected code. But I think it’s more likely that Apple won’t enforce this at the compiler level.

There are even greyer areas to this. What constitutes a property? For instance, is NSArray’s count a property? I would argue it isn’t; it’s an attribute, a side-effect based on the other properties of the NSArray. But Apple template code uses the count of an array as if it was a property, and the result is not horrible. You could certainly argue it’s wrong, but I view it as just over the line.

Conclusion

Embrace @property. The additional information it supplies regarding memory management and thread safety is great. Not only that, but it’s less code than the old way of declaring your getter and setter.

Use dot syntax where appropriate. You need to decide where the line is for yourself, as there are no hard rules about this. Everyone has an opinion over it, and the only thing you can be sure of is that there’s little consensus, except that some things are always inappropriate.

You may have code that looks like this:

if (_foo) {
    @synchronized(self) {
        // stuff here
    }
}

This can also be expressed more simply:

if (_foo) @synchronized(self) {
    // stuff here
}

Note that you can’t use this if your if has an else statement.

This is also true of @autoreleasepool, and may be even more handy there:

for (NSDictionary *item in items) {
    @autoreleasepool {
        // lots of stuff here
    }
}

Can become:

for (NSDictionary *item in items) @autoreleasepool {
    // lots of stuff here
}

Now, always making C statements compound in a condition or loop is a pretty common convention. And if you stick by this convention in other places (as I do), that’s fine. But the reasoning behind it doesn’t really apply with @autoreleasepool and @synchronized: you can just consider them part of the opening bracket.

Unfortunately, you can’t do this at the top level of message handlers. Wouldn’t that be nice?

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.

Here’s how I created a shortcut key to relaunch Xcode.

You may find Programmer’s KillSwitch more practical, but this is a fun exercise in using Automator.

Ready? Here we go.

Automator

Mac OS X includes a service called Automator, that can be used to build workflows. These are like AppleScripts, but less like code and more like macros.

Start with an Application workflow, and drag a Shell Script action to it. Use this code:

pkill -9 -x Xcode
sleep 0.3

Depending on how fast your Mac is, you may need to increase the sleep value. If Xcode doesn’t always return, increase it.

Next, drag a Launch Application action. Pick Xcode.

In this workflow, I also remove the DerivedData directory.

Save, and you have an application you can run at any time to kill and relaunch Xcode.

This is a great start, but now let’s make it even easier.

FastScripts

Red Sweater Software has a great utility we can use called FastScripts. FastScripts adds a menu to the right of the menu bar, and can launch scripts and other useful things from selecting them in the menu or a keyboard shortcut.

Copy the application you built to FastScript’s folder, then set it to a keyboard command shortcut. I use command-control-delete, which feels like ctrl-alt-del. Very satisfying to hit ctrl-alt-del whenever Xcode starts to act up!

Other possibilities

This combination of shell scripting + FastScripts is great for frequent but annoying tasks. I have shell scripts to purge cached memory, and another Xcode restart workflow that clears Xcode’s derived data.

With a few scripts and keyboard shortcuts, you can make Xcode bow to your whim, rather than the other way around.

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.

You can’t create symlinks in Finder with what Apple provides you, but you can create an Automator workflow to do so easily.

1. Create a new service in Automator.
2. Select: Service receives selected files or folders in any application.
3. Drag a Run Shell Script action.
4. Shell: /bin/bash (Even if you’re using another shell as your default shell, this script is for bash.)
5. Pass input: as arguments.
6. Use this script:

while [ $# -ne 0 ]; do
     ln -s "$1" "$1 symlink"
     shift
 done

7. The result should look like this:
   

Alternately, you can download my finished service from Dropbox. It should be stored in ~/Library/Services.

You should now have a Make SymLink command when you right- or control-click a file or folder in the Finder:

You can even add a keyboard shortcut for it in System Preferences:

Remember: A symlink does not follow the original file if the original file moves on your hard drive.

The secret is symlinks. These are different from the aliases you can create in Finder, so you’ll need to do this in the shell.

The problem with this is that Xcode 4 will not follow symlinks. Luckily, Dropbox will. (Note, however, that Dropbox will not follow aliases.)

On your first computer:

1. Quit Xcode.
2. Create a directory for your sync on Dropbox. I use ~/Dropbox/Sync. In it, I have a subdirectory for Xcode.
3. Move Xcode’s UserData directory to your Dropbox:
   mv ~/Library/Developer/Xcode/UserData ~/Dropbox/Sync/Xcode/UserData
4. Let Dropbox upload everything.
5. Pause Dropbox’s syncing.
6. Move them back to where Xcode stores them:
   mv ~/Dropbox/Sync/Xcode/UserData ~/Library/Developer/Xcode/UserData
7. Create a symbolic link from your UserData to DropBox:
   ln -s ~/Library/Developer/Xcode/UserData ~/Dropbox/Sync/Xcode/UserData
8. Resume Dropbox syncing.
9. Relaunch Xcode.

On any other computer:

1. Quit Xcode.
2. Let Dropbox download everything, if it hasn’t yet.
3. Pause Dropbox syncing.
4. Remove your local Xcode user data:
   rm -R ~/Library/Developer/Xcode/UserData
5. Move your UserData from Dropbox to Xcode:
   mv ~/Dropbox/Sync/Xcode/UserData ~/Library/Developer/Xcode/UserData
6. Create a symbolic link from your UserData to DropBox:
   ln -s ~/Library/Developer/Xcode/UserData ~/Dropbox/Sync/Xcode/UserData
7. Resume Dropbox syncing.
8. Relaunch Xcode.

You can also synchronize your Archives directory, using the same technique.

This technique is not perfect, as Xcode will probably not recognize changes while running. However, it is better than having to manually copy these directories between computers.

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

If I accidentally provide bad XML, I don’t know until my app tries to parse it. That may be some time into its run. If the XML is processed because of a specific user action, I’ve broken that specific user action. So we’re going to build a build phase to validate the XML.

Obviously, I want to test everything in my app before I post it to the iTunes Store. But finding this problem even hours later makes it harder to diagnose and fix. I can detect this error immediately (and fix it right away) by adding a build phase to validate my XML.

I added a run script to my target that does this:

find "${PROJECT_DIR}" -name *.xml -exec xmllint {} ;

See update below.

Xcode will run this script when building my target. It will find all XML files in my project directory, and run xmllint on them. xmllint returns an error if the document is malformed.

I gave this build phase a good name so I can find it easily later, then dragged the script as high in my build phase order as possible to get the results early. This may not actually prevent the project from building, but at least I get a big red error.

This validates all the XML in my project directory. If you have XML you don’t need, you’ll have to do something more complicated:

• Provide a more specific starting path
• Use one of the other variables validate the built .app package instead, or
• Hard code each XML file’s path

Update

This command works better:

find "${PROJECT_DIR}" -name *.xml -print0 | xargs -n 1 -0 xmllint

With this command, the error not only stops Xcode, but Xcode highlights the line that xmllint reports as the offender.

My mind is the part of me that questions things. It’s my inner critic. It does most of the talking in my head. Mostly, it tells me that I can’t do something. This is hard. That’s wrong. You’ve got nothing new to add to this. This is not how I solve problems, though it drives me to find better solutions to problems.

My eyes speak to me, too. This is ugly. How can you keep writing when the font is wrong? There’s a spelling error, go fix it! This is not how I solve problems, though it’s how I see that problems exist.

My creativity flows from something else, the most quiet part of me. It’s actually what I’m using right now to write this. It’s my fingers. It’s not actually my fingers, of course, but it’s the part of my brain that sets my fingers in motion, across a keyboard or across an open page. It’s the part of my brain that, when my mind said I had nothing worthwhile to type today, started typing before deciding what to type. It’s the part of me that tries to draw a face, and doesn’t care that the face looks like something an untalented preschool child might draw. It’s the part of me that produced the first draft of this, spelling errors and crappy fonts and occasional run-on sentence and all.

This is the part of me that I’ve been poor at nurturing in 2011. The part of me that’s been broken. The part of me that my mind has held tightly, that the tiny animal in me has said is worthless.

My mind wants me to stop writing this post, because it has no value. That’s its job, to question things. But when it questions not just my output, but that I am creating at all, it needs to be ignored.

My eyes want me to go change the font so I’m no longer typing in Cochin 17. (Really, Cochin 17? What kind of default is that?) That’s it’s job, to make things beautiful once problems are recognized. But when it wants me to waste time on appearance instead of typing, it needs to be ignored.

Until the words have flowed from my fingers, there must be nothing but my fingers. This is my pledge to myself for the year; to create first, to criticize my creations after they are created rather than before.

My fingers know what they’re doing, and they’re the best part of me.

Recent versions of Xcode have been a lot better. I’m not sure when archives really improved, but in the most recent build of Xcode archive takes only a split second. So far, they seem reliable. And they work by storing the source in a private git repository, so they’re pretty efficient, too. This does not affect your real git repository, even if you’re using git. This is entirely separate, deep in Xcode’s private directory tree deep in your home folder.

Xcode can run a behaviour when a build succeeds. You can customize the behaviour in Xcode’s Preferences. I noticed a few days ago that there’s also an option to Create snapshot.

You may need to scroll down to see the Create snapshot option.

This means that every time my project builds successfully, a snapshot is created. The snapshots are small, basically containing only the changes since the last build. I expect I can leave this on basically forever without running out of disk space.

I commit to git many times during the course of the day, but occasionally I’ll be in a refactor and I won’t be committing every time the project builds. I’ll make a few changes, build and fix any errors, make a few more changes. I’ll keep this up several times, until I’ve made the full refactor I want. Only then will I fully test what I’ve done and commit.

Sometimes I’ll make the wrong change, and break the build in ways I can’t easily fix. At that point, I either need to struggle my way out of the errors I’ve introduced or abandon all the changes I’ve made. Yes, I could commit to git every time. But the smaller each individual change is, the less likely I am to bother.

In my defence, I still think the way Xcode uses snapshots by default is useless. They’re offered before major but atomic changes, which is right after I’ve committed to my source control repository manually.

But these continuous snapshots are another matter. This means I can back out of any particular change back to the previous working code without losing all the changes so far in what I consider the full, atomic refactor.

I’m thrilled this feature exists, and I’ll be using it from now on. I think you should give it a try, too. Even if you commit to your source control system constantly, this will make commits you won’t think to, and without any action on your part.

I’ve heard that this isn’t real GPS or that it’s somehow inferior to real GPS. AGPS is actually superior to “real” GPS. However, there are ways the iPhone is also inferior to a standalone navigational GPS like a Garmin or Tom Tom. I’m going to explain the differences between them.

Positioning

The iPhone includes a regular GPS receiver, just like your standalone GPS. The “assisted” part means the iPhone is able to get a quick lock based on other data sources, such as nearby cell phone towers or WiFi networks.

I’m not going to try to write an explanation of this. There’s a great article on this in Macworld by Glenn Fleishman, ”How the iPhone knows where you are,” which you should read. He’s a journalist who specializes in wireless technologies, and anything I could write on that subject would fail to measure up to his writing.

But I can summarize that article for you in one paragraph, if you didn’t bother to read it:

Because the iPhone has a GPS radio and these other data sources, it’s quicker at finding your location than a standalone navigational GPS.

Your iPhone does this without sacrificing final accuracy, but may give you several approximations along the way. (These are times a real GPS would still be trying to figure out where you are.) This is simplifying a little; the iPhone needs to conserve battery more than your standalone GPS. If you’re not actually using Maps or some other application that needs pinpoint accuracy, it probably powers down the GPS and uses whatever radios it has powered up to do approximate positioning rather than the most accurate positioning it’s capable of. But when you need accurate positioning, it’s there.

Maps

So why do people think the iPhone’s GPS isn’t a real GPS? It’s because of the one way the iPhone is weaker than your standalone GPS. As shipped by Apple, the iPhone is completely dependent on the Internet for map tile data.

That means that without a data signal, whether WiFi or 3G, the iPhone is unable to show you a map. You end up with a screen like this:

From this, you might conclude that without a data connection your iPhone isn’t very good as a navigational tool. You’d be right about that! But you might also conclude that the iPhone doesn’t know where you are. In fact, it knows where you are. It just isn’t able to put it on a map, because it doesn’t actually have a map of the area.

This is where standalone GPS devices are better. Because they don’t have the extra radios that the iPhone has, they can’t download map data from the Internet. Instead, a standalone GPS includes map data on the device. Storing an entire country’s (or even an entire continent’s) map data takes a lot of space, so it’s often rendered more crudely than the iPhone’s maps.

Imagine drawing a map for a friend to get to your house. You know which road they’ll be coming on, and you know where they’re trying to go. You can fill in the roads they need to pay attention to from memory, and mark turns and the destination. This is how a standalone GPS works, except that if it’s up-to-date it knows all the roads and can quickly draw everything quickly and to scale. It’s rendered using just its memory, without the aid of a 3G or WiFi network.

The iPhone’s maps, on the other hand, are from the cloud. The iPhone basically asks for a graphical map from the cloud, with the location and zoom it’s interested in. The image the cloud returns can be beautifully rendered and completely up-to-date, but without the cloud, the iPhone can’t get anything.

But what if your iPhone did have map data on device? Then it would be able to render maps without a data connection AND get a fix faster than a real standalone GPS. This is where the App Store comes in to play. Tom Tom and Garmin both sell apps that include map data. When running one of these apps, the iPhone is able to find its location faster than a standalone GPS. However, even without a connection to the Internet, the app is able to provide a map.

Turn-by-turn navigation

If you’ve reached this point, you’re probably wondering why the iPhone can’t do turn-by-turn navigation. It’s a fair question. The answer is complicated, but boils down simply: Apple does not provide the map data. Instead, Apple’s map display uses data provided by Google. And Google does not allow Apple to use that map data for turn-by-turn navigation. Apple, in turn, does not allow iPhone developers to submit turn-by-turn navigation apps that use the iPhone’s map system.

So why can some Android phones provide turn-by-turn navigation? Google allows it.

This is why any turn-by-turn navigation app is going to require its own map data, rather than working off the cloud when it’s available. There’s been a few hints that Apple may switch to their own data at some point, but it hasn’t happened yet. Being dependent on a competitor interested in keeping your device inferior isn’t a good position to be in, even if the reasoning has nothing to do with competition.

Update: The next version of iOS 6 will switch the data source to Apple’s. The iPhone will still download map data, but instead of downloading just a picture it will now download richer data that will allow it to display rotated maps more cleanly. And Apple is bringing turn-by-turn directions to the iPhone 4S. The iPhone will not get offline navigational data, however.

Conclusion

The iPhone’s GPS us very good. Without extra software, however, iPhone navigation is entirely dependent on the Internet. But you can see maps as long as the iPhone can reach the cloud. You can download software so you can see maps while away from the cloud. And any photo you take, even while away from the cloud, will still be tagged with the location of the iPhone.

The iPhone makes its connection to the cloud a strength, whereas standalone GPS units have made the lack of a radio their strength. It’s a complicated tradeoff. Saying the iPhone does not have “real” GPS or that AGPS is not “real”, though, is inaccurate.

This soon after my post on Steve Jobs, I’m unable to write much on the subject. But the C programming language was a major invention in the history of computers, and a significant step in the evolution of computers from academia and processing centres to programs for the real world.

So why am I choked up about his death? Because I love the man for what he accomplished, and how he’s changed the world.

Way back in elementary school, I used an Apple //e. I moved Logo’s turtle around on the screen. I discovered something odd: being able to understand that computers were predictable machines, rather than mysteries had separated me. There are an infinite number of things others can do better than I. Other kids could run, they could play team sports and not let down their team. But this, I could do. But what use was it? Computers were only good at being computers. FORWARD 10. RIGHT 45. Repeat 8 times, it was a stop sign.

I learned BASIC and Pascal, but on some level I was still drawing stop signs. I was solving problems no one had.

Around age nine or ten, I was at a school looking at various displays. Most were uninteresting. But there was an original beige Macintosh, running MacPaint.

The Macintosh was something else entirely. That was something useful. I had only a few minutes with it. I moved the mouse about, watching the cursor. I clicked a few things; I think I doodled a bit with the pencil, typed some text, and used the eraser. It made sense to me. More than that, it dawned on me that computers could be things other than a computer. The complexity behind it was boggling, but someone had solved it. Therefore, it was solvable. It wasn’t actually magic, it just felt like it. I didn’t know it at the time, but Steve Jobs had made that experience happen. He didn’t write the code, and exactly how much of the design was his I’ll never know. Many talented individuals had brought that experience into being. But he drove the team, and he pushed the vision.

It would be several more years before my next encounter with the Macintosh, but something had changed for me. I knew a bit about programming already, but now I wanted to solve real problems for real people.

I practiced for years, and I impressed some people, and ended up with a job programming computers. And I enjoyed that job, and I enjoyed what we were building, but it wasn’t what I yearned to build. It wasn’t accessible to enough people. It was still hard-to-hit buttons, activated by sliding a cursor around the screen using a plastic box.

It turns out that computers, even the Macintosh, were too complex. It was tough to master the indirectness of the interface. For a time, I smugly assumed I was smarter than the people who couldn’t get this, but that wasn’t the case at all. If anything, just the opposite: these machines were far more hostile than I was willing to admit. I couldn’t see the problems in front of me.

There was Palm. They made a hesitant half-step in the right direction, but it didn’t last. I knew we were going backwards again, but I didn’t know how or why.

Years passed. And finally, the iPhone. In the iPhone, you could see at last the future, what Apple intended for the next generation. Even if it was just a small, 3.5” cut of it. Again, that was Steve Jobs. Not solely responsible. I don’t even know that it was his idea. But either way, he owned that idea. He nurtured it, he cultured it, and he grew it. He turned complex computers and crappy phones into something entirely new.

But I think you could also see echoes of the past: What Apple had wanted to produce with the Macintosh, but been unable to.

A few years later, we got a bigger slice of the future with the iPad. The iPad does not represent finished by any means, but I believe it is the realization of what Apple truly had in mind with the original Macintosh, and an extension of what they tried to achieve with the iPhone. It’s more than a computer — so much immeasurably more — by being less than a computer. And, again, Steve Jobs was responsible. Not solely, of course. But in the same sense that had it gone wrong, one person would be to blame, if one person must be given credit that person is Steve Jobs.

And along they way, he reinvented the music industry. And he’d have reinvented both television and movies for the better, too, had the existing powers in those industries been more eager to follow.

Through demonstration, Steve Jobs had taught me a few things:

• Great products are worth using, so they’re worth building.
• Great things can achieved, even under pressure from others who don’t see the same future.
• Greatness is revolutionary, but does not ignore what’s gone before.
• It’s okay to not achieve perfection. Producing something amazing is good enough.
• Having achieved something amazing, there’s something more amazing just ahead.
• True greatness means the result is not just easy to use, but unbelievable easy. Magical, even.

There are thousands of developers in the world who’ve learned these same lessons. Many of them learned before me. Some of them learned from different sources. But the entire industry has been influenced by the revolutionary evolution of computing from Apple and Steve Jobs. We make up a small part of his legacy. Part of our job is to use these lessons to build magic. The greater part is to inspire others to build magic.

Thank you, Mr. Jobs. Tomorrow, the temptation will be to say the sun rises on a world with less magic. But that’s only true if we don’t create more of our own.

Xcode: You want to enable snapshots yet?

Me: No.

Xcode: I’m just asking.

Me: No.

Xcode: They’re good for you, you know.

Me: I’m sure they are, but see, I’ve already backed up my project. In fact, I checked it all into source control. You were there, right?

Xcode: Yeah, but can I enable snapshots? Please?

Me: No. Stop asking.

Xcode: I’ve caught you at a bad time.

Me: That’s not it. I don’t actually want snapshots. They’re redundant, and frankly a bit stupid. It makes me feel like you don’t respect me enough to make my own backups, you know?

Xcode: Oh. I can see that. I’ll ask again later, then.

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.

I searched for this for a while and found a few wrong and complicated answers.

One way is to use the composite cable instead of the component cable. Your Wii came with a composite cable, and if you’re only using 480i the component cable does nothing extra for you anyway.

But what if you can’t find the composite cable? This was the case for me, after my move. The answer is ridiculously simple:

1. Unplug the component cable on the Wii end.
2. If the Wii is already on, press the Reset button. If it was off, turn it on.
3. Wait a couple seconds. The Wii will notice there’s no component cable plugged in, and switch to 480i mode.
4. Plug the component cable back into the Wii.

Here’s a common operation for me: Split a list into sublists based on some piece of data changing within a loop. When the loop is over, dump whatever’s left into another sublist.

Without blocks, this looks like this:

- (NSArray *)splitArray: (NSArray *)array
               valueKey: (NSString *)valueKey
               labelKey: (NSString *)labelKey;
{
    id sections = [NSMutableArray array];
    id sectionValue = nil;
    id sectionRecords = [NSMutableArray array];
    
    for (id record in array) {
        id recordValue = [record objectForKey: valueKey];
        if ( ![recordValue isEqual: sectionValue] ) {
            if ( [sectionRecords count] ) {
                id lastRecord = [sectionRecords objectAtIndex: 0];
                id label = [lastRecord objectForKey: labelKey];
                id section = [NSDictionary dictionaryWithObjectsAndKeys:
                              [NSArray arrayWithArray: sectionRecords], @"Records",
                              label, @"Name",
                              nil];
                [sections addObject: section];
                [sectionRecords removeAllObjects];
            }
            sectionValue = recordValue;
        }
        [sectionRecords addObject: record];
    }
    if ( [sectionRecords count] ) {
        id lastRecord = [sectionRecords objectAtIndex: 0];
        id label = [lastRecord objectForKey: labelKey];
        id section = [NSDictionary dictionaryWithObjectsAndKeys:
                      [NSArray arrayWithArray: sectionRecords], @"Records",
                      label, @"Name",
                      nil];
        [sections addObject: section];
        [sectionRecords removeAllObjects];
    }
    
    return [NSArray arrayWithArray: sections];
}

The redundancy makes this hard to maintain, but I don’t really want to split it off into a different function. That means passing all the parameters in to the second function.

But wait! Can we use blocks to clean this up? Yes, we can! We can define the code we want to execute in a block, then use the block as necessary within the function.

With blocks, the code looks like this:

- (NSArray *)splitArray: (NSArray *)array
               valueKey: (NSString *)valueKey
               labelKey: (NSString *)labelKey;
{
    id sections = [NSMutableArray array];
    id sectionValue = nil;
    id sectionRecords = [NSMutableArray array];
    
    dispatch_block_t split = ^{
        if ( [sectionRecords count] ) {
            id lastRecord = [sectionRecords objectAtIndex: 0];
            id label = [lastRecord objectForKey: labelKey];
            id section = [NSDictionary dictionaryWithObjectsAndKeys:
                          [NSArray arrayWithArray: sectionRecords], @"Records",
                          label, @"Name",
                          nil];
            [sections addObject: section];
            [sectionRecords removeAllObjects];
        }
    };
    
    for (id record in array) {
        id recordValue = [record objectForKey: valueKey];
        if ( ![recordValue isEqual: sectionValue] ) {
            split();
            sectionValue = recordValue;
        }
        [sectionRecords addObject: record];
    }
    split();
    
    return [NSArray arrayWithArray: sections];
}

Since the block by default has read-only access to any variable it wants as long as it’s in scope, there’s no need to pass parameters into the block.

As I said in the introduction, blocks are a lot more powerful than this. See Apple’s Block Programming Topics for more about that. However, they’re a great tool for small problems as well that you shouldn’t overlook.

What does it do? Well, at sunset it adjusts the color temperature of your monitor to make it warmer and less glaring. At sunrise, it adjusts it back.

I installed it yesterday afternoon; yesterday and today at sunset, it automatically adjusted my monitor’s color temperature. The difference on the eyes is nothing short of amazing. And if you need to do some accurate color work, it has a menu that lets you turn it off for an hour.

For all I know, this has always been a feature of Xcode. But I’ve never noticed it before. So for this stunning display of common sense: Well done, Apple!

Rather than set these per project, I have a .xcconfig file I add to my project. I then base each build configuration off this file. Changing the .xcconfig file changes all projects based on it (though with the current Xcode, it’s sometimes necessary to reload the project to get the settings to take).

// // MoreWarnings.xcconfig // // Created by Steven Fisher: // http://tewha.net/2010/11/xcode-warnings/ // See also: // http://boredzo.org/blog/archives/2009-11-07/warnings //

GCC_WARN_CHECK_SWITCH_STATEMENTS = YES
GCC_WARN_SHADOW = YES
GCC_WARN_64_TO_32_BIT_CONVERSION = YES
GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED = YES
GCC_WARN_ABOUT_RETURN_TYPE = YES
GCC_WARN_MISSING_PARENTHESES = YES
GCC_WARN_ABOUT_MISSING_FIELD_INITIALIZERS = YES
GCC_WARN_ABOUT_MISSING_NEWLINE = YES
GCC_WARN_SIGN_COMPARE = YES
GCC_WARN_UNDECLARED_SELECTOR = YES
GCC_WARN_UNUSED_FUNCTION = YES
GCC_WARN_UNUSED_LABEL = YES
GCC_WARN_UNUSED_VALUE = YES
GCC_WARN_UNUSED_VARIABLE = YES
GCC_WARN_ABOUT_MISSING_PROTOTYPES = YES
GCC_WARN_TYPECHECK_CALLS_TO_PRINTF = YES
GCC_WARN_ABOUT_DEPRECATED_FUNCTIONS = YES
GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS = YES
GCC_WARN_ABOUT_INVALID_OFFSETOF_MACRO = YES
GCC_WARN_NON_VIRTUAL_DESTRUCTOR = YES
GCC_TREAT_WARNINGS_AS_ERRORS = YES
RUN_CLANG_STATIC_ANALYZER = YES

Peter wrote a great explanation of why you’d want most of these warnings, which I’m not going to attempt. I’ve added some C++ warnings, too. They don’t do anything with clang 1.6, but might be useful in the future.

A few notes:

• Like Peter, I don’t turn on GCC_WARN_UNUSED_PARAMETER. Although you can add __unused to each parameter to disable the warning, doing so breaks Xcode’s code formatting. I use code formatting constantly, so anything that breaks it isn’t acceptable.
• The warnings that were the most painful to turn on were GCC_WARN_64_TO_32_BIT_CONVERSION and GCC_WARN_SIGN_COMPARE. If you use int and NSInteger interchangeably, you’re going to have a tough time with these. (I don’t, but some of the internal libraries I use do.) These are also some of the more dangerous warnings to fix; if you’ve got automated tests, you should run them after every few corrections.
• RUN_CLANG_STATIC_ANALYZER will roughly double (or more) the time your project takes to compile. I consider this a good trade: I rarely trigger a static analyzer warning now, but when I do I want to fix it.
• Also note the GCC_TREAT_WARNINGS_AS_ERRORS. If you are applying these to an existing project, you may start with hundreds of warnings. You’ll probably want to start with this set to NO and change it to YES after you’ve fixed the warnings.
• Remember, too, that this changes the defaults for settings. You can still specify different settings in the build configuration! If the static analyzer is taking too long to run in one project, just turn it off in that one project but leave the .xcconfig file alone!

For example, start with Apple’s NavBar sample. Drop this code into initWithNibName:bundle: in PageThreeViewController.m:

- (id)initWithNibName:(NSString *)nibNameOrNil
               bundle:(NSBundle *)nibBundleOrNil
{
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self)
    {
        // this will appear as the title in the navigation bar
        CGRect frame = CGRectMake(0, 0, 400, 44);
        UILabel *label = [[UILabel alloc] initWithFrame:frame];
        label.backgroundColor = [UIColor clearColor];
        label.font = [UIFont boldSystemFontOfSize:20.0];
        label.shadowColor = [UIColor colorWithWhite:0.0 alpha:0.5];
        label.textAlignment = UITextAlignmentCenter;
        label.textColor = [UIColor yellowColor];
        self.navigationItem.titleView = label;
        label.text = NSLocalizedString(@"PageThreeTitle", @"");
        [label release];
    }

    return self;
}

Well, I’m not famous or Internet famous, so I can go out on a limb and give you a guarantee of what you’ll see. And nobody will care if I’m wrong. So here’s my prediction. Are you ready?

• New iPods.
• An updated iTunes.
• That’s it.

You will not see an updated Apple TV. You will not see an iPad nano. You will not see The Beatles. You will not see cloud based syncing, unless it’s the only way to sync the new iPod. You will see changes to the iPod, the iPod, the iPod, and things directly connected to the iPod. Apple will stay on message. Given that the invite is in the shape of a guitar, the message is music.

Update: Well, I was wrong about the Apple TV, but I was right about cloud sync and the iPad nano.

Looked at one way, that’s a 200% estimation overflow. But more realistically, it means it was pretty small and I tackled it in the wrong way. I had to refactor some code early that I left alone for too long. I should’ve written in the right way to begin with, and I should have realized it was wrong sooner, and I should have stopped trying to make it work.

More pragmatically, maybe I should have known better. But, of course, I didn’t. And that’s okay! I know better now.

What’s my point in posting this?

Mostly, it’s this: iPhone development isn’t nearly as hard as I’ve made it out to be. Useful applications can actually be quite small and still be useful. Simple things are simple. When they’re not simple, it’s time to fix something.

I’ll post a link here when I finish the project. It’ll be a bit before I can devote another day to it. But I’m excited by its usefulness, its simplicity, and the idea of having an app in the App Store of my own.

I started at the most basic level, wondering at the language. What are these brackets? What’s with the @ signs? What’s the difference between a - and a +? These aren’t hard things to learn, but understanding the reasoning behind them helps. And then there’s a point where it suddenly makes sense.

But the framework was confusing. How do I do this? Though I was less confused, this one isn’t solved directly. I became competent. And I started to ask the best question: “Why?”

The patterns were still confusing. Why does this work this way? What’s the purpose of this? Why is this done, but not this other thing?

And then there was a point where the patterns became obvious. More, the pattern in the patterns became obvious to me. And now, I look to find more examples of patterns, and patterns of patterns, to better build my knowledge.

It took me a while to get here, and it’s the same for every language. I’m feeling pretty confident about Objective-C now.

Back on the first day, I was confused and lost.

By that, I mean that aside from the standard keyboard shortcuts (Save, Copy… that sort of thing), none of the keyboard shortcuts made sense to me.

So I duplicated one of the keyboard shortcut profiles and deleted most of the keyboard bindings. I was brutal with it — if the combination didn’t make sense to me OR it was something I’d rarely use it was removed. Then I added keyboard shortcuts that I needed. By using about an hour to customize these settings, I ended up having keyboard shortcuts that I fully understood and rolled off my fingertips.

At this point — and this is where it became a useful exercise — I added my ~/Library/Application Support/Xcode to version control so I could easily sync it between computers. So when I find something that isn’t quite working out for me, I make a change and propagate it to my other system.

Am I going to share what I ended up with? No, because that’s not the point of this. Rather, I want to point out a simple fact of Xcode: Xcode will adapt to how you want to use it, and if you feel like you’re suffering at all with it you should spend the time it to takes to make it enjoyable to use.

And when someone tells me I can do something with a particular keyboard shortcut, I switch back to the defaults and see what it’s bound to.

iTunes 9.0 finally fixed this. A click on the zoom widget actually zoomed the window!

iTunes 9.0.1 changed it back to the old behavior. Many people were happy, I imagine. But people who wanted to zoom iTunes windows (or, I imagine, valued standard behavior) were left sad.

It turns out you can get the click-to-zoom behavior back:

defaults write com.apple.iTunes zoom-to-window -bool true

Tip of the hat to zadr on Twitter for this tweet.

Should your new application support skins?

Probably not. Skins are often a programmer’s way of saying “Oh, I don’t do UI. We’ll let someone else get it right.” Only nobody ever does, at least not in your product. Your UI just isn’t as compelling as the one it’s replacing.

The corollary to this is that if lots of people are demanding skins, it means your UI sucks. Once you add skins, you’ll never be rid of those skins, and you won’t have fixed your application either.

You’d probably do better to fix your application’s appearance and behavior.

Now, should you do a custom appearance?

If you’re planning a completely custom appearance for your applications, odds are it will suck. Unless you have artists that are beyond simply competent, but brilliant, you’ll probably fail.

First, you need a UI that looks and feels good. Secondly, it probably needs to fit in with the native platform. If you’re planning a full screen game, it’s fine to not fit in. But if you’re building a Windows-based BIOS updater, that custom UI that you think looks so amazing? The truth is, it looks like complete shit.

You’re better off fitting custom UI into the OS rather than changing your whole application to fit them.

Now, finally: What about plugins?

This one is a little less clear. There’s great reasons to do plugins. Integration with another system (whether technical such as a web site or social such as particular requirements for reporting) is a good one.

But you know what isn’t a great reason? Making your product a platform. Do you want to be a product people use, or a platform people struggle with?

Firefox’s plugins make me flinch. They’re usually poor quality, craptacular tools that lunge for a particular nugget of a good idea and fall flat on their faces a few yards away from it. There are a few that are interesting, but they’d benefit from being rolled in, or being a separate stand-along product on their own.

Pick your features carefully. 37signals didn’t become popular by picking an extensive list of features or allowing people to write their own features. Instead, they built something they wanted to use. And they’re not alone. There are a few things I’d love to see (Markdown instead of Textile, for instance), but even if a hypothetical plugin system could add these things, they’d be overwhelmed by the layer of suck.

Before you build a plugin architecture, put the effort into your application.

Xcode will automatically recognize iPhone OS 3.0.1 and look for a new SDK at a set path. The problem is that SDK doesn’t exist. The good part is that the iPhone OS 3.0 SDK works perfectly for developing 3.0.1. The only apparent change is the SMS fix.

Assuming you’ve installed to /Developer, the iPhone OS 3.0 SDK is here:

/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0 (7A341)

When using Xcode with iPhone OS 3.0.1, Xcode looks for the iPhone OS 3.0.1 SDK here:

/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0.1</code>

The trick, then, is to build a symbolic link that connects what Xcode is looking for with what it needs to find.

So what do you do? Assuming you’ve installed Xcode in the standard location, this is a Terminal command to fix the problem:

ln -s /Developer/Platforms/iPhoneOS.platform/DeviceSupport
/3.0 (7A341) /Developer/Platforms/iPhoneOS.platform/
DeviceSupport/3.0.1

This will not add a SDK to Xcode’s list, it will just teach Xcode to map your device to the 3.0 SDK.

A few other tips:

• If you still can’t debug restarting your iPhone may help. Most of the iPhones I’ve tried to debug on, I’ve had to restart first.
• If you get an error regarding code signing, try downloading your provisioning profile again and re-installing it. Also, select it again in your build settings.

Based on information from iPhone OS 3.0.1 Advisory.

• The Objective-C syntax is strange. It’s really not that hard, though, especially once you realize that part of the reason for the design was to make Objective-C a strict superset of C. That means that the C code you throw at it will compile and means the same thing under C as Objective-C.

• Use NULL for pointers (void*) and nil for instances (NSObject*). They’re defined the same, this is just convention.

  • Use properties and stay sane. You can leave the dot syntax alone if you like (though I like it), but it’s worth using properties anyway because it forces you to document the assignment mechanism you’re using.

  • Method names that return an object where the name does not contain init must not require the object be released.

  • If you’re writing the object, this means you’re probably calling retain and autorelease.

  • If you’re using the object, this means it is probably already calling autorelease. If you release the instance yourself, you’ll crash later.

  • Use alloc, init on the same line.

  • If you’re going to autorelease an object, do it at immediately on creation rather than later: [[[Object alloc] init] autorelease].

  • Sure, you can avoid using autorelease. Sure, it would perform “better”. But can you quantify “better”? Is it significant to you? If it isn’t, stick with using autorelease. When you follow the rules, you idiotproof yourself. See the probably in the previous group of points? Stick with the rules and it’s basically an “always.”

  • Remember that debugging is harder than writing code. While you can write something like textView.text = [NSString stringWithFormat:@"%@: %d", [b field:@"test"], [a precision]]; you are going to have to debug it later. In most cases, you’ll benefit from assigning results to temporary variables before passing them through to Cocoa.

I’m going to write about the major device vs. simulator differences I’ve noticed another time, but there’s one worth mentioning now: CGSize size = [string sizeWithFont:font] with a nil string will return a zero point on the desktop, but will return a random value (stack, maybe?) on the device itself. Check for nil first, as in CGSize size = string ? [string sizeWithFont:font] : CGSizeZero.

• Phil Schiller was great. He seemed to be a little nervous in his delivery, but he was interesting in a casual, friendly way. If he has a chance to do some of Apple’s special events in the future, he’ll be a little less awkward.

• From any other company, this would have been a slam dunk, and people who are unhappy are clearly expecting too much.

  • The iLife 09 upgrades make it a must-have purchase for me. I’m looking forward to working through the Garage Band tutorials, and iPhoto face and location metadata is an omission I’ve been struggling to find workarounds to. And as an owner of a Flip Ultra, I’m really looking forward to having image stabilization.

  • The 17” MacBook built-in battery seems like a great trade-off to me. I don’t have two batteries anymore, I just replace the one I have when it won’t hold enough charge anymore. It sounds like that will still be possible.

  • I’m really happy to see DRM-free music on the iTunes Store. I’m less impressed with the all-or-nothing upgrade, but will probably upgrade sooner or later.

• It’s simple and intuitive. Drop controls, set up outlets and actions.

  • You don’t have to fight the framework. It does what it does with a minimum of fuss.

  • A good UI is a focused UI, rather than one full of features. I love this style of thinking.

I’m less thrilled with Xcode’s documentation viewer. It feels like a really poor web browser that takes more of the screen for junk, runs in the same workspace so you can’t command-tab in and out of it. Just splitting it into a separate process would immediately improve it.

In about a day, I created four screens and linked them all together. That doesn’t sound horribly impressive, but it felt easy. Granted, I’ve previously spent a few hours figuring out UINavigationController, but things were actually simpler than I had understood. Finding things took a while, but they were generally hidden in plain sight. The few times I violated something in the runtime, the error message was simple, direct and accurate.

I do wish SQLite was a more recent version. I would love to use sqlite3_open_v2 in some of this code, especially the SQLITE_OPEN_READONLY flag.

• Desktop & Screen Saver rolled into a single preference pane. Why? Are we that convinced that one day we’re going to have a screen saver running in the background as our desktop, and the only way to configure it is to have it in the same preference panel?

• Keyboard & Mouse are a single preference panel (but Trackpad is separate). Again, why? The only conceivable answer is that Apple thought it important that the battery levels for both the keyboard and mouse are in a single preference pane, which also has an option to add a new device. But the “add device” functionality is already duplicated in Bluetooth.

  • Exposé & Spaces are a single preference panel. Are they related? Well, a little, but not that much. And how does Dashboard fit in here, which is also thrown in for fun?

  • Translucent Menu Bar is in Desktop, rather than Appearance.

  • Scroll bar behavior is in Appearance.

  • The number of recent items to show in menus is in Appearance.

  • The option to automatically adjust keyboard back lighting is under Displays. (But typing “Dim” into the preference pane search only hilights the Energy Saver panel.)

Oh, sure, it’s better than Windows. Of that there’s no doubt. And sure, we got here via a series of small, well-intentioned steps. But let’s not get too smug about Mac OS X: It still needs a lot of tuning to be intuitive.

It makes slightly more sense than the Gates & Seinfeld commercials, but replaces the quirkiness of those ads with banality.

The commercial shows Microsoft doesn’t get the concept behind Apple’s “Get a Mac” ads. Hodgman is not the personification of Windows, and Justin Long is no the personification of Mac. Hodgman is a PC, like he says. Long is a Mac, like he says.

What does that mean? Well, it means that the difference between Long and Hodgman is the ability to run Mac OS X. Long can, and Hodgman can’t. PC’s secret motivation — an undercurrent running through all the commercials that Apple will never vocalize — is that he’s jealous. He knows he can do all the things a PC can do. He wants to do all the things a Mac can do, too. His motives, then, are minimizing the value of Mac OS X: It isn’t really that simple. It isn’t really that easy. You don’t really need that, you can do it without a Mac.

But PC doesn’t really believe it. He knows he can do everything Mac can do. He just also knows he can’t do it as easily. So the secret behind the motivation he won’t state is this: He wants to run Mac OS X, too. And Apple will never vocalize this, because it inspires the question to the masses: Why can’t PC run Mac OS X? ((Sure, there’s lots of good reasons. I’m not denying that. I’m also not denying they are probably all solvable. I’m just pointing out that Apple doesn’t really want people choosing between a Mac and a PC to ask the question, but just to take it for granted.))

So Microsoft runs this ad, showing all the things PC can do. Great. Each one of them is something Mac can do, too.

Microsoft needs to focus on promoting their product, not someone else’s product. And Microsoft does not sell generic PCs. But what does Microsoft sell, really? What are they going to brag about on Windows? Why do they need to?

Every time Microsoft puts out a commercial, they blink. And they don’t have to at this point.

I’m barely past square one, but I found this an interesting title. Of course, what Bruce means is the whole Mac OS X development experience, but it’s interesting that he worded it in the title as learning Objective-C. It’s a simple, concise yet technically inaccurate way to label the knowledge. ((And I’m not intentionally picking on Bruce here. I have said it this way, and probably will again, and he does get it right in the text, as he noted below.))

Objective-C just might be the easiest part of Mac OS X development. The hard part is simply knowing what objects are available in Cocoa, where they are, and how to string them together. Basically, the typical framework problem. Don’t get me wrong, I’m still at the very bottom of the learning curve here!

Objective-C itself is very nice; it’s a truly minimal extension to C. I’m amazed at how it’s still a very complete object-oriented language yet so simple and small, with everything done the simple way.

When I first started with Cocoa, I was thinking of compiling notes together so I could write a short book/essay on “Learning Cocoa for C++ developers,” but as I’ve gone I’ve realized the first chapter should be “Forget everything you know about C++. You think need ___ to do ? You do in C++, but in Objective-C just use the Cocoa class.”

I estimated at the time they were at least four years ahead of the competition in terms of an operating system.

But since then?

Buying and selling themselves to… themselves.

Absolutely nothing on the OS front.

Since then? Windows CE and successors have caught up in many areas, exceeded Palm in others. Blackberry, and iPhone exist, both of which make Palm look pathetic.

Loss of professional-level development tools.

Hardware quality control problems.

It’s hard to believe that Palm has thrown away this much of a lead. But they have.

I think the case itself is fanless, but of course it does have vents and the hard drive inside does whir. So it isn’t silent, but is very quiet.

A matching mini rack is available, though I didn’t purchase one yet. I plan to buy a 750GB or 1TB drive in another couple months to back up to, and will probably pick up the rack then as well. In the meantime, I’m back to doing manual backups of my photos and music.

Running from this hard drive for even an hour has convinced me that my Mac mini’s hard drive is indeed failing. I’d be a lot more annoyed at that if I didn’t have the Quadra to run from while waiting for the replacement hard drive.

After the weekend, though, the smell was more intense. Bruce found a particular spot on the back panel of it that was uncomfortably hot. Time to investigate.

I downloaded Temperature Monitor and found the power supply was at 81° Celsius (about 178° Fahrenheit). That’s far too hot! I found smcFanControl and turned up the fan speeds, and my iMac’s power supply is runs between 55-58° Celsius (131-136° Fahrenheit). That’s much healthier, and the plasticy smell has almost (but not completely) disappeared. The downside is that the iMac is no longer silent, though I’m pretty sure I can turn the fans down slightly over the next few weeks.

I appreciate that Apple was trying to make my workspace more enjoyable by keeping the volume down, but it turns out the smell of burning plastic is more distracting than the fan noise. I can only imagine being without a computer while the power supply and back panel were replaced would have been even more distracting.

I was just wondering if you guys have some sort of “Apple dropped my model the next business day!” policy. I’m not going to lie here – I’m actually satisfied with the old model, I just thought since the timing was so perfect it was worth a two sentence email.

The result? A $200 in-store credit. Which, bluntly, was more than I ever expected. I didn’t have to lie for it, which is good because I wouldn’t have done so. All I had to do is ask.

Thanks, Simply. That was a classy move. I really respect these guys. They’re honest, practical, and not out to screw anyone.

Writing a background task for Touch OS X would be very, very hard. Well, actually, not so much hard as taking a lot of skill, time and effort. I can really understand why Apple wouldn’t want just anyone doing it. But before I get too stressed over it, it’s worth asking a few questions:

First, what kind of program does this actually affect? Not many, probably. In fact, basically, polling network software or network software that receives pushes is the most common scenario. ((Time-based software is also a possibility, but let’s discard that for the moment.)) An instant messenger program is an obvious example; it needs to keep the connection alive and plays some sort of beep when a message comes in.

So we’ve established a program this affects. Now it’s worth asking a second question: Is it possible this rule is up for negotiation? At the right price, would it go away? And if so, what might the right price be?

• An application that background operation is critical to.
• An application that Apple thinks is important enough to be worth the resources on the iPhone and the effort. Because make no mistake, it’s going to take effort from Apple.
• Doing the work on campus with an Apple engineer’s help.
• Payment for the engineer, possibly to be waived in some cases.

In short, if I was to write a program that beeped on the hour, I probably wouldn’t get an exception. I wouldn’t even know who to ask. But AOL Instant Messenger? That might happen. AOL might not even have to ask. (Although I doubt they have anything running in the background at this point. For the purposes of a prototype/demo, a simple, customized back end would make more sense.)

As developers we need to worry more about we are going to do, than what someone like AOL is going to do.

I pay about $60 per year for 500 GB of storage and 5 TB of bandwidth from DreamHost. .Mac costs $100 per year. For that much, it should be really, really special. On a strictly numerical level, DreamHost beats .Mac. Now, it’s true that DreamHost’s reputation for reliability has taken a beating the last year or so, but for $6 per month I can accept a few days per month of down time. And it’s nowhere near that bad; it seems to be less than one evening every month or two.

So that leaves a comparison of features. Now, actually there’s very little overlap between the two. .Mac offers a bare minimum of traditional web hosting features, with low bandwidth and storage, and few of the more dynamic features such as SQL and PHP. DreamHost offers huge bandwidth, huge storage, and lots of dynamic features.

As a traditional webhost, DreamHost wins hands down. But .Mac offers a lot that DreamHost doesn’t.

Apple lists the features of .Mac as Web Gallery, Website Hosting, IMAP email, Back to My Mac, Sync, iDisk, Groups, Backup, and 10 GB storage. There’s also easy publishing with the iApps. The webmail interface shames DreamHost’s webmail, but I download all my email anyway. The most useful-looking features are syncing and Back to My Mac.

Back to My Mac doesn’t work at all for me. There’s no errors, no feedback at all – it just isn’t there where it’s supposed to be. I’ve done a bit of research on this, and I expect it’s because my NAT doesn’t support the features Back to My Mac needs. But this is really just a guess, since there’s no feedback at all.

At first glance, syncing seemed to work for me. But then I ran into an odd problem: The sync created duplicates of a bunch of smart mail boxes. No problem, though: Delete them, reset up to .Mac. It’ll propagate to the other computers, right? Well, it turns out that’s a bad assumption. It worked to a point, but then one of the other computers just adds them again. I’d basically need to delete them from both computers simultaneously in order to get rid of them. No problem, I’ll just use Back to My Mac.

Oh, wait. That’s not going to work.

Well, maybe I’ll check out .Mac in another few years. But for now, I can’t imagine spending $100 on it. I want something that takes the gremlins out of a multi-machine existence, rather than adding bigger, more annoying ones. I feel like I started with a mogwai and .Mac fed it after midnight. Maybe if I was a bigger webmail user or wasn’t comfortable setting up things like WordPress it would be more interesting, but I’m not that guy.

Thanks to Apple for mentioning me. I certainly would have reported the bug regardless, but it’s a nice bonus.

The only thing I wish had happened differently was an earlier acknowledgement from Apple that they realized what I was describing and agreed it was a security problem. I didn’t find out Apple considered it a problem until January 22nd, when they asked how I’d like to be credited for discovery. Most of that time I wondered if I should file more details in an attempt to convince them it really was a problem. But, of course, that’s Apple’s nature.

Especially with most Cocoa apps, where the Find commands are in a sub-menu, and thus take even longer to target using the mouse.

To me, this is a real problem on Mac OS. It is not one that Apple has not only completely failed to address, but has actually made worse in Mac OS X. For technical users, items in hierarchical menus are slightly more difficult to activate. But for non-technical users, items in hierarchical menus are not just a little more difficult to activate, but awesomely so. And in Mac OS X, Apple has introduced more of them!

Hierarchical menus have become a little better now that you don’t have to hold down the mouse button ((And, in fact, this suggests a simple fix Apple could do: Clicking an item with a hierarchical menu should lock that hierarchical menu open so the user can take as long as they want and use whatever motion they want to get into the hierarchical menu.)), but watching a neophyte or novice try to access them is a real eye-opener. I’d really suggest to any developer thinking of using one that they ask a non-technical person to select one. Using the mouse at all is the first major task. Using the mouse to select menu items is almost as difficult. And using the mouse to select menu items in hierarchal menus will often be more difficult than the previous two combined. It’s not only conceptually screwy, but physically difficult.

After doing so with a product used by teachers (including the almost-ready-to-retire), I removed every hierarchical menu from our application. There weren’t many anyway. But one of the most difficult things for me when moving from Mac OS Classic to Mac OS X was how obvious it was that Apple hadn’t tested this.

Now I’m not altogether opposed to hierarchical menus. I think they’re a perfectly valid solution for Services, Open With and maybe even Arrange By ((Arrange By is a valid place to use them only because novices and neophytes are probably looking to arrange by name most often, and that’s easily achieved by switching to list view.)). All of these options can be accessed some other way, except for Services which are rarely used by novices or neophytes. I also think they’re fine for contextual menus, since contextual menus only offer choices that are available elsewhere. (Or should. See Apple’s Human Interface Guidelines on Contextual Menus.) But having Find commands in a hierarchical menu? That’s completely completely insane. Find is something users need to be able to access.

Apple even admits this problem in Apple Human Interface Guidelines:

Because submenus add complexity to the interface and are physically more difficult to use, you should use them only when you have more menus than fit in the menu bar

So far, so good. But they go on:

…or for closely related commands.

This simply does not follow! Making something physically more difficult to use just because it’s closely related to something else is stupid. A good design puts commands in recognizable locations, and puts commands users need to access in locations that are easy to physically access. Closely related is not an excuse for a hierarchical menu. Closely related and infrequently used ((Or an option with an easier access method.)) is a good reason, though. But what genius decided that spell checking and find qualified? If find qualifies as infrequently used, it’s almost certainly because it’s such as a pain in the ass to select!

I do think this is less of a problem now that the menu search has been added to the Help menu. I find myself using this frequently in applications with many infrequently-used menu entries. ((Another symptom of lack of zen in application design. A few unused commands are normal but when a menu bar consists almost entirely of unused commands there’s a problem.))

However, it took a long time to get the search field itself (which uses input type=”search”) working nicely on the iPod touch. Of course, it turned out to be my fault: My CSS had an extra } in it just above the entry that limited the field’s width. So the width is properly limited to something reasonable now. On the other hand, the search field doesn’t seem to get a different appearance from the text field or the search history. I can live with that.

It seems to degrade fairly nicely on other browsers. Of course, it doesn’t get the grey “click here to search”-type text, but I don’t really feel that’s worth adding. Hopefully, this will be adopted by the standard and end up in other browsers, too. In the meantime, I can live with this limitation, too. It certainly makes the code cleaner.

More on the input tag another time

I’ve done some thinking on this subject.

Should you wait on an update check before presenting the UI? Should you ask them if they want to update? If they do want to update, should they need to go through a web browser to download the update? Should it be a standard installer?

One principle I like for automatic update is this:

Assume the user launched your application because they want to do something.

All of these questions have answers that developers assume they know, but when you start looking at it from a user perspective, things are very different.

Update checks shouldn’t be blocking.

Should you wait on an update check before presenting the UI? Let’s imagine your host goes down, and the user is stuck waiting and waiting for your application to launch. Or maybe the host is just slow; that’s even worse. The best case is the user is disconnected from the Internet and failure is immediate.

This doesn’t mean you shouldn’t start a check, of course. Go ahead. Make it run in the background. If the check finishes before the UI is loaded, you can adjust the UI. Otherwise, you can remember for next launch.

Update requests shouldn’t be blocking, either.

Decide if you’re going to apply the update automatically or not. The answer should usually be no.

If the update does need to be applied automatically, install it when it won’t impose (if you can judge when that will be, and if such a situation even exists).

If the user doesn’t need to update immediately, offer the update in a prominent place within your program, but don’t make them click to refuse it. Clicking “Not Now” is just going to become a habit. And don’t just tell them a new version is available and direct them to a web site. When they want to investigate, tell them why they’d want it! Replace nagging with good information.

Make the update as pain-free as possible.

Download the update yourself. Whether automatically or on-demand, apply it yourself.

The decision whether to apply the update can be a painful one for users. It’s your job as a developer to provide the information users need to make that decision, and to do it in a way that encourages (rather than demands) the decision be made, and to eliminate any unnecessary pain associated with the update.

From Apple’s technote on Daemons and Agents:

A global login item is a login item that is launched when any user logs in. Installing a global login item is roughly equivalent to installing that login item for all users on the system: every time a user logs in, loginwindow launches that user’s login items and all global login items.

In Mac OS X 10.5 and later you can install a global login item using the shared file lists interface to Launch Services.

I’m getting the feeling from that description that there’s no UI for managing these. There’s also the possibility that some doc writer made the whole thing up. Anyone know more?

Imagine that you trash an application because of a security flaw. Say, it handles the URL type foofoo, and is proven to be a security risk. But the developer won’t fix it (or hasn’t fixed it yet), so you’ve removed the application from your hard drive to keep yourself safe.

It doesn’t work that way — you’re not safe. Time machine has made a copy in your time machine backup that Mac OS X will cheerfully launch without a warning.

Steps to reproduce:

1. Have existing, up-to-date Time Machine backups.
2. Delete a protocol handler.
3. Visit a web site that uses that protocol.

Expected results:

• Mac OS X will respect that the application has been removed.

Actual results:

• Mac OS X will hand it off to the application on the Time Machine backup volume.

This seems to also be true of standard Finder document bindings. I tried double clicking a TextWrangler document after deleting TextWrangler and it cheerfully launched out of the Time Machine backup. Not that I think there’s anything wrong with TextWrangler; it was just a program I knew I could delete safely (and restore after).

It was pointed out to me on the Macworld Forums by Rob Griffiths that there is a way to permanently delete a file from all backups. You need to use the context menu within time machine to delete all backups of a file. This means there’s a workaround, but it’s still a problem that Mac OS X launches applications from the backup folder without even a warning.

Update: Apparently, some don’t understand why this is a bug. Let me give you a simple example: You find out Adium (for example) has an available exploit that the developers haven’t patched yet. You remove Adium, but it continues to exist in your backup. You visit a web page that activates the Adium bug, and Adium is launched from your backup. That you can launch Adium from your backup is not a bug. That Mac OS X will do so automatically without confirmation is a bug. The backup should be considered a vault for the user, not Launch Services.

I thought Leopard’s menu bar was supposed to be ugly! I guess they’ve toned it down, because this looks pretty good to me. I’m not sold on the dock, but that’s okay: I know it can be turned off.

Actually, if I had to describe it in three words, I’d say “System 7 modernized.” That’s a good thing. I thought Mac OS 8 was quite a step backwards, and Mac OS X has taken small but repeated steps back to the classic Mac look. Tiger is clean, with light backgrounds to its windows and a smooth gradient effect. Sheets are gorgeous.

My biggest complaint is that the window gradient is a little severe, especially on windows without toolbars. The dark end of the gradient is a little too dark.

Other random thoughts:

• Spotlight is reindexing. I’m not surprised.
• System Preferences and Safari are really responsive. More so with Spotlight indexing in the background than they were in Tiger.
• Quick Look is awesome. It would be nice if applications could launch this fast.
• QuickVerse doesn’t work, but I’m pretty sure this isn’t a last minute Leopard change.

I’ll post more thoughts after I have some time to really explore this.

For instance, if you have your own sorted list class ((You shouldn’t. There are some great implementations of sorted lists, and thousands more poor ones. Guess which one you’ll probably write?)), you might do something like assert(list_in_order()) as an entry condition on the search (because the list assumes it’s already sorted, and this should never be untrue), and assert(list_in_order()) as an exit condition on the insert (because the list is trying to guarantee it will always be sorted).

Many months ago I thought of a simple assertion I could put in my application. I was redesigning a UI, and it had a progress bar. I briefly thought about adding a check to catch if the progress bar ever rolled backwards. But I decided against it, because it was so obviously impossible for it to occur. The reason? I’d have to add a miniscule amount of logic to actually keep track of the last progress bar value.

Yesterday we found a bug where the progress bar in our application rolled backwards. I fixed it, checked it in, and briefly remembered the assertion idea. “I wish I’d done that,” I thought to myself, “I would have found this a month ago!” I posted the next beta of the product and thought nothing more of it.

Today I found another case where the progress bar rolls backwards.

You know, that’s probably all I’m going to find. But this time I’ve put in the assertion. And I’m turning over a new leaf: from now on, I’ll really think about my entry and exit conditions and other flow assumptions, and make sure the code to verifies them. I was in that habit a few years ago in Pascal, but never really brought it over to C/C++.

This was my first time working with Final Cut Pro.

The Bad: The interface is just plain weird. It isn’t very attractive for one thing: The blue-grey reminded me of a submarine. But that’s just the start of it. The widgets are absurdly small even on windows that didn’t need small absurdly widgets. There’s no reason that a “Batch Start” widget should be shorter than Aqua’s close widgets!

Everything was just nonstandard looking, and (worse) nonstandard behaving.Final Cut Pro is an absurdly complicated program, so complexity is expected, but it hasn’t hit the sweet spot. The interface feels like it could have half the complexity while still having all the features.

The Good: Resizable scroll bars. Grabbing the top edge of the scroll car and dragging it up zooms out. This probably sounds weird, but it’s really just the inverse of proportional scrollbars. With proportional scroll bars, as you see more of the document the scroll car gets bigger. With Final Cut’s scroll bars, as you make the scroll car bigger you zoom out to see more of the document. I’d love to have these in many Mac OS X applications.

The main video editing window seems perfectly reasonable, too. I didn’t have a lot of time to try this out.

“ALIGN the tag or the attribute?”

“The tag.”

“Wasn’t it introduced in 1998?”

“No, it was introduced in 1995. It wasn’t supported until 1998.”

[19/Oct/2007:12:12:37 -0700] "GET /wp-content/themes/pyilewptheme/iphone.css HTTP/1.1" 200 355 "http://pyile.com/2007/10/i-want-my-%e2%86%a9/" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3"

[19/Oct/2007:12:12:37 -0700] "GET /wp-content/themes/pyilewptheme/iphone.css HTTP/1.1" 200 354 "http://pyile.com/2007/10/i-want-my-%E2%86%A9/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.5) Gecko/20070718 Firefox/2.0.0.5"

It looks like Safari and Firefox encode the ↩ differently in URLs. I’m not sure which, if either, is “wrong ((I’m sure it’s in the HTTP spec, but I can’t be bothered looking it up right now.)),” but I found this interesting. When I was testing the ↩ in the URL, I only checked that it worked in Firefox and Safari. I didn’t think to check that they requested it the same way. I imagine Apache is doing the conversion here, but would other web servers do it as well?

Apple does respond to feedback, so it’s worth asking. If you’ve got an iPod touch, file feedback here. If you’ve got an iPhone, the feedback site is here.

The trial has 2 days remaining.

That’s really all I needed to see. I immediately uninstalled it. e might very well be great software, but since I never really got to try it the developer is not going to get a purchase from me.

Anyone doing a time limited trial needs to seriously consider how it expires. This kind of 30 day trial doesn’t give me a chance to evaluate the software, and it doesn’t give the developer any chance to make a sale. The developer would be much better off using 30 days of use (like Omni Group products), or reseting the trial when the software is reinstalled, or even just resetting the trial for new releases. How many months in a row do you think someone’s going to do an unnecessary uninstall/reinstall just to avoid paying a reasonable $34.95?

Anyway, that’s all the feedback I have from a 30 day trial. Sad, isn’t it?

Adding XML to a problem means you have two problems: The original problem, plus XML.

Visual Studio 2005 has a much better installer system built into it, though, called Windows Setup.

The first few times I tried it, I quickly moved on because it popped up a installer dialog. It turns out I just needed more patience: After several minutes of waiting, it asked for the Visual Studio CD and installed the components it needed. And that was that. The installer popping up to build an installer wasn’t a daily stupidity, just a one-time thing.

The tool is (comparatively) a joy to use, using Visual Studio editors and the property inspectors. Better, it deals with dependencies in a way that only someone with direct access to the idiot that designed the system could manage. I still don’t fully understand what the installer is doing, but I find that I don’t really care: It works, and works well. I can’t imagine going back to WiX at this point.

The extra inch of depth is mostly in the front of the case and in how the parts fit within the assembly. The design is nicer than it looks in photos. Fan LED is definitely much brighter than the Q-XPACK. How much brighter? Well, my next purchase is probably going to be a fan.

Lack of power cable management is one downside here. The cables are wired directly into the power supply, so unless you’re willing to cut them you’re probably going to end up with at least one that you’re not using. That’s pretty typical, but it hurts a little more here; There’s more cables than the Q-XPACK, and not much space to hide them away.

Of course, it’s much too early to see how the power supply stands up.

I was very pleased with the Q-XPACK right up until the power supply started wavering. The Q-XPACK2 seems to have everything I liked about the Q-XPACK, plus the (theoretically) more robust and standard power supply. Even if the power supply isn’t as robust as I’m expecting, being able to swap it is a major benefit.

Other problems? Well, this was a refurb, and it had some problems from that. The handle wasn’t very well attached, and it didn’t come with a couple cables that it should have. Neither of these was a problem for me, though.

Years later, the desire to be able to write software independent of the company I work for arose in me again. But where? I still liked the objectsatrest name, even if it seemed I wasn’t likely to do musical software again. So I moved my blog to a new domain name I’d just registered and started thinking about the site.

In moving, I attracted the attention of the owner of objectsatrest.org, who wanted to upgrade to the .com domain if possible. Was I interested in selling?

It wasn’t an easy decision. For years, objectsatrest.com had been my online identity. I’d gotten used to thinking it. I think I’ve typed “Objects At Rest” a thousand times since 2004.

In the end, we came to a deal. Objects At Rest now belongs to Objects At Rest Animation Studios. Man, that’s almost as good a reason for the name as I had, and a better reason than I had when I sold!

Another developer here suggested we evaluate Qt. To make a long story short, we’ve placed an order and plan to use it.

Project configuration made easy.

Qt’s cross platform abstraction starts with the project file. For instance, a trivial QT project file might look like this:

TEMPLATE = app
SOURCES += main.cpp

Type qmake on the Mac and it’s converted to a Project Builder or Xcode project. I believe makefiles are supported on Mac, too, but I haven’t tried that yet. Import it into Visual Studio with Qt’s Visual Studio integration and it becomes a vcproj.

Want to add precompiled headers and make it a debug build?

CONFIG +=debug
PRECOMPILED_HEADER = stable.h

(This assumes that stable.h #includes your headers that aren’t going to change.)

Run qmake again on the host platform (or import into Visual Studio), and the project file will be regenerated to use stable.h as a precompiled header and we’re using debug libraries and appropriate settings.

Want a universal build on the Mac?

QMAKE_MAC_SDK = /Developer/SDKs/MacOSX10.4u.sdk
CONFIG +=x86 ppc

Want to build a Visual Studio project? Move over to Visual Studio 2005 and choose Open Solution from .pro File. A second later, you’re looking at a Visual Studio project with the equivalent configuration.

It really is that easy. The difficulty is in finding the variable names, and that’s documented on TrollTech’s website.

An Xcode build on my personal PowerBook (it has 768MB of RAM), with a bunch of applications open:

VM: 5.81G + 150M 220631(1) pageins, 60523(0) pageouts

The highest number I saw there was about 200, and it appeared only once or twice. The vast majority of the build, it was 0.

An Xcode build on the Intel Mac Mini (it has 512MB of RAM), with only Finder and Xcode running:

VM: 8.93G + 7.19M   760989(93) pageins, 277742(22) pageouts

The highest number I saw was 3,180. Usually, it hovered around 100-200, with occasional drops to 0 depending on the phase the build was in.

There’s a couple obvious points here:

• The mini is doing at least one order of magnitude more swapping than the PowerBook. The total pageins don’t reflect that the PowerBook has seen much heavier use since the last restart, but that’s irrelevant to the recent pageins. More pageins is to expected; after all, the mini has less memory.
• The mini is using much more VM to accomplish less than the PowerBook. This I didn’t expect. The PowerBook is running more applications and is even using a FileVault-encrypted home directory. The mini, on the other hand, is as bare as I could get it without wasting time on it.