Mac Developers: Clean Up Your Output!

Over the weekend, I was having some hard drive issues. While I think I fixed the issues, I’ve been keeping a close eye on my console (Console.app) to look for any hints that the issues are more major than those that can be repaired by Disk Utility.

However, while watching my console, I noticed something: there are a LOT of spammy Mac apps out there!

Most Mac/Objective-C developers are aware of the NSLog() function, which, while in an Xcode environment, outputs data to the Xcode console. It’s usually one of the first things a new developer learns about and it’s very useful for debugging. What many developers may not realize is that NSLog() continues to output data to the system logs even when the app is not being run from within Xcode. As a result, the console fills up with messages that don’t mean a whole lot to people looking at the console.

Now, I don’t want to come across as saying you should never use NSLog() outside of Xcode. There are times when outputting debug data to the console is fine. But some of the things I see are people echoing objects into the log or short text strings that are obviously method names. These aren’t helpful to people looking at the console and, arguably, aren’t helpful to a developer once an app is in the wild. Once your app is in the wild, data in the logs should indicate error conditions in your app.

NSLog() is fine for debugging in Xcode, but you should be careful to remove them when you’re done. A good question I ask myself before leaving an NSLog() in place is, “if a user filed a support request with this data, would it help me fix their problem?” Most of the time, the answer is no.

So before releasing an app, do a quick search in your project for all uses of NSLog() and evaluate whether they are really needed.

Did something I wrote help you out?

That's great! I don't earn any money from this site - I run no ads, sell no products and participate in no affiliate programs. I do this solely because it's fun; I enjoy writing and sharing what I learn.

All the same, if you found this article helpful and want to show your appreciation, here's my Amazon.com wishlist.

Read More

The Right Way to Create an iCloud-enabled Mac App in Xcode

Because I’ve encountered this problem twice, I’m going to do a little write-up about it. As much for me as for the next person who encounters this problem. In a very un-Apple way, this process is very poorly documented and very un-intuitive from a user-developer standpoint. Everything that’s here, I’ve culled from Googling about aimlessly and finding on Stack Overflow. **Symptom: **You create a new app in Xcode with no changes and launch it. It launches just fine. You then go to the target summary settings and click “Enable Entitlements” and have an iCloud key/value store and or containers. Now you launch it and nothing happens. Nothing appears, but Xcode still thinks the app is running. **What’s Happening: **To understand what is happening, you have to go have a look in the Console application (note, the actual system Console.app, not the debug console in Xcode). Open that up and select “All Messages”. Look for something that looks like this: 1/28/12 7:49:03.945 PM taskgated: killed <your app ID>[pid 43838] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed What’s happening is that taskgated is killing your app because it’s not properly signed to use iCloud. And for some reason that is not entirely clear to me, the app being killed is not at all reported back to Xcode - Xcode thinks the app is running. So you just sit there waiting for something to happen with no clue that this sinister lurking background process has killed your app. How to fix it: There are two ways you can go from here to fix this. The first and easiest, if you are just turning on entitlements and aren’t intending to use iCloud, you can just remove the iCloud Key/Value Store and iCloud containers from the target summary. After doing this, it should work. But, if you are making an iCloud-enabled app, there’s a long list of things you need to do. First, understand that you need to be a paid member of Apple Developer Program. Log into ADC. Go to the Mac Dev Center, and the Developer Certificate Utility. Create an App ID by going to App IDs and clicking the Create App ID button in the upper right. Enter the name of your app and the bundle identifier. It usually looks something like “com.company.app”. Click Continue. Your app ID should be entered. Click the App ID you just entered, then click “Enable for iCloud.” Click save. Next, go to Certificates. If you haven’t created any certificates yet, click “Create Certificate” in the upper right and follow the directions. Note, you need both a development and an application certificate. Next, go to Systems. Be sure you’ve added your Mac (and, for good measure, any others you’ll use for development). Finally, go to Profiles. 1. Click Create Profile in the upper right. 2. Select "Development Provisioning Profile" 3. Give it a name. 4. Select the app you created in step 3. 5. Select the certificate you want to use. 6. Select the systems you want to use (I did all). 7. Click "Generate" It may take a few seconds, then it will give you a download. 8. Open the downloaded profile. It will open in the "profiles" preference pane (which doesn't seem to appear until you try to install a profile). Click install. Now, in Xcode: 1. Go to Window > Organizer. 2. Select "Devices" on the top, and "Provisioning Profiles" on the left. 3. At the bottom, select "Automatic Device Provisioning" at the bottom, and click "Refresh". If you've never done this before, you'll need to log in with your ADC username and password. 4. Give it a second, it should pull in your profiles. 5. Go to your project, select your app target and select "Build Settings." Scroll down to "Code Signing." You may need to go to "All" from "Basic" in the predicate selector. 6. Under Code Signing Identity, select the dev profile you just created. Note: don't use the wildcard one - it doesn't seem to work. Whew. Now, if everything went as planned (and you sacrificed a goat to Tim Cook and Tim found your sacrifice pleasing) you should be able to launch your app with no errors. But help! I got a weird failure on build! If you get a failure on build that looks like this: Command /usr/bin/codesign failed with exit code 1 Then it is possible that your developer certificate is set to “Always Trust” in Keychain. It needs to be set to “System defaults” for reasons that escape me entirely. Note, this may not be entirely accurate and may even be cargo-cultish. But I’ve encountered this “issue” twice now (once in December, and once now) so I decided to write down my steps so that, in a few months when this befuddles me again, I’ll know where to look for the answer.

App Store Entitlements, and the Crippling of an App

A few months ago, I decided I wanted to try exploring the Mac App Store ecosystem as a developer. I’ve been writing little Objective-C apps for myself for awhile, and I decided I wanted to see what it was like from the other side. So I wrote this little app called Airplane Setting. It was a stupid simple little app that made it easy to turn off your radios with a single action. I wrote the app and paid my $99 admission fee. And after a month of back and fourth with Apple and a couple of rejections for what I consider to be dubious reasons as best (especially seeing as how I could point out existing apps in the store that broke the “rule” they said my app was breaking, but whatever, their store, their rules…), my little App was finally approved for sale. It did moderately well, passing 1,000 downloads with virtually no advertising from me. I had big dreams for this little app. Plugins, global hotkey support, localization, Applescript support, and more potential functionality. But all that was dashed by “Entitlements” and Apple’s requirement that all apps must be sandboxed. Look, in theory, the idea of sandboxing an app is not bad. The problem here is Apple’s all-or-nothing approach to sandboxing. The selection of entitlements are just so limited as to be nearly useless for anyone creating a unique, new or complex app - especially one that requires hardware access. Your choice is either to sandbox your app, choosing from the available selection of entitlements, or not sandbox it and not be in the Mac App Store at all starting in March. There’s no reason to only provide such a limited subset of functionality that a developer must choose from. Would it not be better to provide us a wider set of entitlements and allow us to justify our reasons for needing them when we submit our app? The reason Apple gives for requiring sandboxing is to prevent “rogue apps” from destabilizing the system. But when you consider that the App Store itself is curated, this requirement makes even less sense. If Apple is curating the store, how does a “rogue app” end up in the App Store? I’m a huge Apple fanboy. I have almost all Apple hardware in my house, from my iMac to my Macbook Pros, to my iPad and iPhone and my wife’s iPod Touch. I had AppleTVs before they were cool (and there’s one on every one of my TVs now). I love Apple. But as an developer … I [expletive] hate Apple for this “innovation” that crippled my once-promising little app. So, at this point, my options are: Leave Airplane Setting in the App Store. Doing so will mean no further updates so I’ll likely cease development. Remove Airplane Setting from the App Store and start distributing it exclusively from the website. My original intent with Airplane Setting was to explore what it was like to be an App Store developer. I guess … now I know what it’s like to be an App Store developer, and living in constant fear of Apple as a sword of damocles hanging over your head.