Blog Archives

Introduction to Objective-C Modules

Unless you’ve written C in the past, your closest encounter with the preprocessor and its code inclusion is probably the #import statement. But before #import, there was #include. The preprocessor command #include is a clever little trick.
via Feedly/Pocket on June 25, 2013 at 06:21PM

Overview of iOS Crash Reporting Tools: Part 2/2

This is the second part of a two-part series where you’ll learn how get started with different iOS crash reporting tools: Crashlytics, Crittercism, Bugsense, TestFlight and HockeyApp.
via Feedly/Pocket on June 25, 2013 at 06:12PM

iPhone Development 101

Code Tips Design Tools for Creating App Mockups User Interface Sizes of iPhone UI ElementsDefault (Launch) Image Sizes for iPhone & iPadView Frames and BoundsThe Status Bar – hiding; setting the colorUIAlertView – pop-up alert messagesUINavigationControllerUITableViewUIView – animating vie
via Feedly/Pocket on March 15, 2013 at 02:17PM

Testing 3.x Apps on Phone Running Beta OS

Like many iPhone devs, I have more than one device that I use for testing. I have an iPod Touch that I usually leave at the current release version, an iPad WiFi that I leave at the current release version for the iPad, and I have an iPhone 3Gs that I keep on the bleeding edge beta release version. This way, I have a device to test and run stuff under the beta SDK and under the release SDK, and I keep both installed on my machine so I have the ability to check out and learn the next release of the SDK while still creating applications using the current release of the SDK.

Normally, this is a perfectly sufficient setup for my purposes, but today, it wasn’t. I have a problem I’m trying to debug that happens when running on EDGE or on a really slow 3G connection; it never happens under WiFi. I’m doing a fix for a client that will need to go onto the App Store long before 4.0 goes GM, so I need to be working under 3.1.2.

In order to try and reproduce this problem, I have to be able to run the app on my phone because the iPod touch and iPad both only have WiFi connections so, therefore, I can’t reproduce the problem there. I don’t want to build against the beta SDK because this is a bug fix on an existing app, and the beta install doesn’t include the current release SDK that I needs to build under, so I can’t build a 3.1.2 app using the beta tools. This is probably done to discourage people from building apps for the App Store with the beta tools (which you really, really shouldn’t do). The only problem is, OS versions have to match between the tools and phone, so I can’t launch the GM Xcode and and debug apps on my iPhone on which I’ve installed the beta OS and if I run on my iPod touch, I can’t reproduce the problem I need to debug because it doesn’t happen under WiFi.

There’s actually a solution, which is to create a symbolic link from SDK in the GM tools folder to the beta tools folder. So, in my case, I have GM tools installed at /Developer and the current beta release installed at /DevBeta. In order to compile a 3.1.3 application so I can test it on a phone that’s been upgraded to 4.0, I can drop to the terminal and do this:

sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.1.3.sdk 

If I need to to run and test an application with a base SDK of 3.0 on a phone that’s been upgraded to 4.0, instead I do this:

sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk 

Do this with Xcode closed, then when you re-open your project with an older base SDK, it should work. All we’re doing is creating a symbolic link from the beta tools directory to the appropriate SDK in the GM tool directory.

Now, be aware, this action is likely to be frowned upon by the Mothership; they excluded those SDKs for a reason. But, I haven’t disclosed anything about the beta release other than its existence, which is widely known, and there are valid reasons to use the beta tools and the GM SDKs, so I though it worth sharing. Caveat emptor – do this at your own risk and don’t get mad at me if it causes problems.

©2008-2010 Jeff LaMarche.

Validate Build Product

In the last post, I mentioned Xcode 3.2’s new Validate option that runs the same checks the App Store Review Team will use before looking at the content of your app and which may be used by Build and Archive (or any other Build command, for that matter), I probably should have mentioned what determines whether it will get run. It’s your project settings. To turn it on or off, select Edit Project Settings from the Project menu, and it’s under the Build Options, and it’s just a checkbox you can turn on or off.

Screen shot 2010-05-01 at 10.14.00 AM.png

I would recommend not waiting until App Store submission to run validate. Do it before you send to testers or to your client. It will allow you to address problems before your app gets tested, reducing the need for regression testing.
©2008-2010 Jeff LaMarche.

Xcode 3.2: Build and Archive

One aspect of iPhone development that I’m no big fan of is ad hoc distribution. In Xcode 3.2, Apple added a new feature to Xcode that makes ad hoc distribution more than a fair bit better. But, for the first few weeks of using Xcode 3.2, I didn’t even notice this item. I know many of you probably have, but I’ve talked to enough people that also missed it, that I figured it’s worth a short post.

This new item lives under the Build menu, but frankly, I don’t use menus much in Xcode. I use a very custom set of key bindings and have all my regular tasks’ key commands memorized. The new option is called Build and Archive.

I still wish Apple would get rid of the whole process, but it’s unlikely they will in the near future. In light of the situation, this makes life much, much better. It’s a pretty good compromise between Apple’s desires and the needs of developers, all in all.

Build and Archive builds your application, code signs it, and stores the application folder along with its symbols file (which you need to decode crash logs generated by ad hoc or release builds). Xcode’s Organizer window gives you ready access to any previous build, and lets you e-mail an ad hoc build packaged up as an .ipa file with the mobile provisioning profile you compiled with embedded right into the application. This allows your clients or tester to simply drag the generated .ipa file into iTunes. The organizer will even generate an e-mail with the .iap embedded in it.

Screen shot 2010-05-01 at 9.43.08 AM.png
Screen shot 2010-05-01 at 9.45.42 AM.png

As part of Build and Archive, Xcode checks your application to make sure it’s code signed and provisioned properly. It may also (depending on your project settings) automatically run the new Validate feature that checks to make sure your application is valid for app store submission. This is the same check that the app review team will run on your app before actually looking at it. The details of what Validate checks are not documented, but in general terms, it will make sure everything is okay and that you haven’t used anything you shouldn’t have used. It’s not a guarantee that your app won’t get rejected because there’s still the manual review for content and HIG, but if your app passes validation, that’s one less possible obstacle between you and the app store. In other words, make sure you validate your apps before submitting them.

One thing to note, however, is that when you use Validate for ad hoc builds instead of building for submission to the app store (and I recommend that you do so that you find problems before testing rather than after), your app may fail one of the Validate checks. If you get this warning message when using either Build and Archive or Build and Validate with an ad hoc build:

warning: Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)

You might be fine (assuming you received no other warnings or errors). The difficult thing is that this warning can be generated by more than one specific problem, so there’s no way to know for sure whether this needs to be addressed other than to try and install the generated .ipa file on a non-development phone. You may (will?) get this warning with ad hoc builds even if the build is fine because you don’t use an “Apple submission certificate” for ad hoc builds.

One of the best things you can do is to have a second iPhone or iPod touch that’s not used for development (ever) that you can use to test ad hoc distributions. Even a second-hand, cheap iPod touch is sufficient since all you’re testing is that the install works If you do this, make sure you add the UDID of this unit to your ad hoc distribution profiles, but not to your development profile.

When you see this warning with Validate when building using an Ad Hoc Distribution configuration, don’t panic, but do try and install it on a machine that doesn’t have your development profile installed before sending it to a tester or client.

©2008-2010 Jeff LaMarche.

Precompiler Defines

I had considered writing about this topic at one point, but discarded the idea as being too simple. I assumed it was already common knowledge.

In the last week, I’ve received two e-mails asking about this, so I decided it might be worth a quick post, even though many of you certainly know this already.

A lot of people like to put code in that is compiled into the debug version of their app, but not into the release version. Something along the lines of:

#ifdef DEBUG
NSLog(@"Some Debug Statement telling me the value of %@", foo);

I generally don’t do much of this myself, preferring to use things like breakpoint actions for things that I don’t want in my code. Personally, I want the code that gets compiled in Release and Debug builds to be as similar as possible to minimize unexpected surprises.

But, I recognize that this is a widely used approach that many people will want to use, and how you do it in Xcode isn’t immediately obvious. If you open up the Project Info window by selecting Edit Project Settings from the Project menu, or double-clicking the project’s root node in the Groups & Files pane, then click on the Build tab, you have the ability to set various options on a per-configuration basis. Under the heading GCC x.x – Preprocessing (where x.x is the version of GCC you are using), there is an option called Preprocessor Macros. You can define precompiler constants here on a per-configuration basis. Here’s a screenshot that shows the value DEBUG being defined for the Debug configuration only:

Screen shot 2009-12-27 at 11.52.40 AM.png

The one problem with using this option is that defining a macro here triggers the precompiled headers to get re-compiled every time. Fortunately, the next option after Preprocessor Macros is called Preprocessor Macros Not used In Precompiled Headers, and it does exactly the same thing, only it doesn’t define the macros until after the .pch file is read, meaning it won’t trigger a recompile of the precompiled headers. That will result in shorter compile times. So, most of the time, this is what you want, unless you manually add something to the .pch file that relies on the macro:

Screen shot 2009-12-27 at 12.09.58 PM.png
©2008-2010 Jeff LaMarche.

Xcode Code Completion

What follows is a quick review of how I use code completion in Xcode. Chances are that options and features exist beyond what I’ll cover here, so comments and suggestions are welcome.
Let’s say I want to insert a CGRectMake method. I can begin by typing CG and pressing F5 or Option-esc, which will popup a […]

Changing Application Name on Home Screen

By default, the name of the application shown on the iPhone Home screen (below the icon) is the same as the project name. This will suffice in many cases, however, chances are the day will come when you’ll need to specify a different application name.
Changing the name is as simple as updating the Bundle Display […]

Xcode Expert Preference Settings

Beyond the settings you can access from the Preferences menu of Xcode, there are a number of configurable options that can be set using the defaults command from a terminal window.
Two of the settings that I have configured are to beep when a left bracket ( ] ) is entered without a matching right bracket, […]

WP Like Button Plugin by Free WordPress Templates