Posts Tagged ‘ iPhone

iOS Book Reviews: Professional iPhone and iPad Database Application Programming

Disclaimer: I do not generally read programming books from start to finish! Instead, I read them much as I would read a blog that I’ve discovered for the first time, skimming the archives (table of contents), and then taking-in the first few sentences of parts that look interesting to me, and bookmarking posts that I want to read in greater depth (dog-earing pages that deserve a second glance). I almost never go back for those second glances, so basically I have a bunch of programming books laying about that look like they’ve been heavily read, when in fact they’ve hardly been cracked. My excuse is that programming books are so seldom relevant past their publish date that keeping them for reference seems silly. If I’m paging through a book’s contents in search of some solution, it usually means I just don’t know the right search terms. When I find some pages that seem relevant, I then turn to the web with my newfound knowledge, and feel vindicated when I find some piece of web-content that appears (at least at first glance) to be superior and more timely.

I do still tend to keep those books around, however, mostly so I can look through their code examples. I find books that consist of mostly code are almost always more interesting than those that try and teach you some general topic. You can usually find nice code examples on the web, of course, but they are seldom explained in as much detail as you would find in one of these “by example” books. In this case, I have in front of me two books that both attempt to teach some topic, but do so with heavy use of examples. They are hybrids, if you will, of books that teach a general topic, and books that consist of mostly code examples. Maybe all programming books exist on a spectrum with pure thought and abstract theory at one end, and pure code (and more easily out-of-date examples) on the other.

Professional iPhone and iPad Database Application ProgrammingThe first of these is Professional iPhone and iPad Database Application Programming, by Patrick Alessi, published by Wiley (Wrox) in 2011. With chapter titles like “Introducing Data-Driven Applications”, “The iPhone and iPad Database: SQLite”, “Displaying Your Data: The UITableView”, and “iPad Interface Elements”, you would definitely not know at first glance that this is an example-driven book. In fact, each of those sections (and all the other sections of the book) run you through the creation of a sample project, each building on knowledge gleaned in the previous chapters. The first chapter includes a very nice introduction to Xcode and shows you how to create a simple UITableView based application.

The following chapter, “The iPhone and iPad Database: SQLite”, goes a bit farther down the UITableView rabbit hole with its sample project, and introduces SQLite besides. This chapter definitely endeared me to the author when it said: “While Core Data is the recommended framework for creating data on the iPhone, you may want to forego Core Data and use the SQLite API directly for several reasons.” The author then lists several compelling reasons! This may be a heretical position to take, but avoiding Core Data has always been my preference, although I do occasionally wonder if there are ever good reasons to use Core Data of which I am simply ignorant.

The author does later dedicate five chapters (about a third of the book) to using Core Data, so he can’t think it’s entirely useless. He does not, IMHO, (at least in the cursory skimming I gave that portion of the book), provide any compelling reasons to use Core Data. The closest he comes is when he says (repeatedly) that using the graphical data modeling tool will dramatically speed up the development time of your data driven app. I fail to see how this is the case! If creating your db schema is taking up a lot of your development time, I think you’re probably doing something wrong, or possibly you just aren’t familiar with SQL in general.

(A decent db abstraction layer to handle your SELECT, INSERT, UPDATE etc. calls is also a must, and I am disappointed to report that Alessi’s book does not cover this topic. There is at least one decent open source wrapper available (called FMDB), although there are things I would change about it — namely the API for retrieving your result sets.)

Unfortunately, the portions of the book dedicated to the Core Data modeling tool fall into the “already obsolete” category of coding examples, because they do not appear to cover the Xcode 4 interface. I created a sample project using Core Data to look at the modeling tool, and like Interface Builder, it has been consumed by the “one window” paradigm prevalent in all things Xcode 4. Reading the first couple of chapters on Core Data will probably give you the base knowledge needed to use it anyway, but as I said earlier, google can probably do a better job.

The last third of the book consists of a couple of chapters about integration with web services. This topic makes a lot of sense to include in a book about data-driven applications, but it’s definitely given less attention than the previous two sections. I really think the book should have been expanded quite a bit, both to go into more detail about the stuff it does cover, and also to cover additional stuff that was notably absent. Off the top of my head, here are headings I would have liked to see: best practices for storing data retrieved from web services, how to deal with syncing issues, common tools for consuming web services, and at least one code example for parsing and consuming JSON. Unfortunately, JSON is given only a cursory mention, and its superiority to XML for the task at hand is not, as I feel it it should have been, firmly established.

In the beginning of chapter 10, “Working with XML on the iPhone”, there is a section called Synchronous Data Retrieval, in which some lip service is given to NSString‘s stringWithContentsOfURL: selector blocking your UI, but then it is not made clear that the subsequent code examples (using NSURL and NSURLRequest) are asynchronous in nature! Also, on the topic of “common tools”, the book pretty much writes everything from scratch in this section. I can understand the impulse that the author may have had to explain all the gory details of xml parsing and NSURLRequests without complicating matters by introducing open source libraries that simplify these processes, but they save far more time than I’m liable to believe you can save by using Core Data. If you are consuming web services from your app, you would be stupid not to use (or at least look at) ASIHTTPRequest. That little project has probably saved me dozens of hours in the last three months. On the subject of XML parsing, the question is not whether you should use an external parser, but rather which XML parser is right for your needs!

Overall, I didn’t expect to read as much of Professional iPhone and iPad Database Application Programming in detail as I ended up reading for this review. I don’t know how much of that was due to wanting to give it a fair read in spite of my bias against using Core Data, and how much was due to the author’s really well written prose. Database applications is about as dry a subject as they come, and yet I never felt lulled to sleep in the way that many programming books have a tendency to do to me. If you are not familiar with SQLite, or programming for UITableView, I would definitely highly recommend the first four chapters of the book. As for whether they are worth the asking price, (currently $30 on amazon), I’ll leave that up to you.

Unfortunately, I think I’m going to have to leave any in-depth review of my second learn-by-example iOS book for another day: Learning iOS Game Programming: A Hands-On Guide to Building your First iPhone Game, by Michael Daley, published by Addison Wesley in 2011. This book takes you through the author’s process of building an iOS game from start to finish. The game you build, Sir Lamorak’s Quest, is available as a free download from the app store, so you could potentially download it and see if it’s got stuff in it you’d like to know about. I haven’t actually looked at the game for more than a minute or two, but I know from personal experience that parsing through the source code of a game, even one I have no interest in ever making, is always fascinating to me, so I’m quite excited to dig into this book.

Cross-posted on Martin’s dev blog, Chesstris.

This Week in Mobile and Web – 02.25.11

This week, Verizon Wireless and Motorola released the XOOM Android tablet.  In my opinion, this is the first Android 3.0 (Honeycomb) tablet that will give the iPad a run for it’s money.  It has a 10.1″ screen, NVIDIA Tegra 2 1GHz dual-core processor, 1GB RAM, 32GB on-board storage, 5MP back cam with flash, 2MP front cam, HDMI, 720P video recording and playback, and a ton of other features (full specs).  As far as I can tell, Motorola and Verizon have not altered the operating system in any way.  There are no V-Cast or MotoBLUR apps preinstalled.  Google has updated the core apps for tablet consumptions; Gmail, Calendar, Browser, Camera, Gallery, Music.  They’ve even included Movie Studio, which allows you to splice, trim, fade, title, score and add photos to your recorded videos.

Keep an eye out for my full review, coming soon.

Development

The Web

Apps, Apps and Additional Apps

Carrier News

Device Central

Friday Video

Friday Infographic

This Week in Mobile and Web – 01.25.2011

Hello, Readers!  It’s been awhile since we last chatted.  A lot has happened.  Let’s dive in.

This Week in Shameless Plugs

Mobile March is back!  Recursive Awesome is, once again, a platinum sponsor for the event.  Mobile March is a day-long (March 19th) event and will have two tracks, much like last year; Business and Development.  Many speakers have already signed up to present.  More are added everyday.  What’s new this year?  How about Mobile 3D?  Mobile 3D (Demos, Dinner, and Drinks) will give developers and business a chance to show off their mobile apps and services.  It will be held Friday night, before the event.  The best part?  It’s included with your Mobile March registration!

Development

OS News

Web

Apps

Carrier News

Devices

This Week in Humor

5 Reasons Why the iPhone on Verizon is a Big Meh

iphone verizon meh

Well, it finally happened.. Today is the day that many an iPhone fan has been waiting for. The iPhone is now available on the Verizon network! It has been hailed for years as the day that Apple would have access to the 93 million subscribers in the US and annihilate any other smartphone on the market ( or that is what Apple would like to have you believe ).

After hearing this news today though, I paused and thought about exactly what this might mean to other mobile OS platforms on the market and in particular, Android. In short, I believe it really does little to harm the adoption of Android.

Here’s why:

1. Android Has Gained Adoptance : Android has been steadily cementing itself as a true contender to the iPhone throughout 2010. Last quarter it outsold the iPhone in number of units sold both in the US and worldwide. Here in the US it’s a little closer, but worldwide Android is being purchased well more than iPhone and is closing in on Symbian.

Why does this matter? The iPhone on Verizon will use CDMA technology. The possible number of carriers and subscribers able to use CDMA is much smaller than what is currently used with a competing technology called GSM. GSM is more portable ( pop your sim card out and move to another phone ), is used by vastly more carrier worldwide and more importantly GSM allows for simultaneous data AND voice to occur at the same time. Remember those iPhone commercials where people are able to call someone AND surf the web at the same time? You won’t be able to do this on the iPhone with Verizon.

2. IPhone not a 4G Device : Not only will the iPhone on Verizon be a CDMA device, it won’t be running on the new LTE (4G) network that the Android smartphone coming out around the same time will be on. What does this mean? If users are looking for fast download speeds ( 12 – 25 Mb/s ), they should skip the iPhone and purchase one of the many Android devices with LTE on the market.

3. Users Are Stubborn : It’s hard for users to change devices. So many of Verizon’s users have bought Android phones. In fact, many phones were probably just bought this past holiday season. Sorry Apple, but these users are now Android users. If the iPhone would have been on Verizon BEFORE, say Thanksgiving or even earlier in the year, it would have carried more weight. But the millions of Android devices ( recall that 300,000 A DAY were being activated at one point ) this past holiday season are now Android users and as we all know, it’s very hard to get a user to convert from one platform to another.

4. Competition is good : The assumption has been all along that when the iPhone came to Verizon, the other platforms would not be able to step up and compete. If there is one thing that I have seen in the past year is that competition in the smartphone market forces companies to innovate and create new products, new ways of solving problems and new technology. Look at Windows Phone 7 for example. Microsoft has put out a very solid device in the face of strict competition. It’s still a first stab ( arguable a much better first stab than Google’s own G1 in 2008 ) and Microsoft is innovating by trying a different design approach and user experience than both Apple and Google. Likewise with Palm WebOS V2. It’s a risk, but something that companies need to do to compete. With the iPhone coming to Verizon, it just means that Google MUST continue to improve Android. It’s a win for Android users!

5. Need Other Carriers Besides Verizon : There is still T-Mobile, Sprint and many other networks around the world that after today still DON’T have the iPhone! Even though we will see many hundreds of millions of user’s having access to the iPhone while staying on a network running CDMA technology, there’s still many, many hundreds of millions more potential user’s that this announcement doesn’t affect. If the iPhone were suddenly announced on all of the carriers in the US and worldwide that Android devices were, this would be much more of a threat.

Some people might read this as a negative article, but in reality I welcome the iPhone to Verizon! The more devices that are accessible to user, regardless of the network are better for consumers. This whole idea of “exclusive” devices per carrier is quite maddening. Owning and using both an Android device and an iPhone, I enjoy each for its own merits. At the end of the day, people will buy what devices they enjoy using and won’t have to deal with carriers exclusive terms. I dream of a day when all phones are available on any network and the consumer has true choice. Until that day though, we’ll have to wait years for an announcement like we heard today and realize that things that maybe seemed so ground breaking in a carrier controlled world, actually aren’t all that special. If things were just more open from the beginning ( imagine the market share Apple would have today if the iPhone was available on all networks back in January of 2007! ), we would have increased competition, advancement in the technology and announcements like we heard today won’t be such a… hmm, what’s the word? meh.

This Week in Mobile and Web – 12.17.10

The big news this week is that the Google Nexus S, by Samsung, is now available.  It’s sold exclusively at Best Buy and Best Buy Mobile stores.  You can buy it carrier unlocked (no A&TT 3G) and without a contact for $529.99.  If you want to sign up for a new T-Mobile contract you can get the phone for $199.99.  However, you can only buy it on contract at Best Buy stores that sell T-Mobile.  Don’t want to hassle with finding the right store?  Buy it online and get free express shipping!

See the ninja unboxing video here.

Development

OS News

The Web

Apps

Carrier News

Devices

Friday Visualization

Facebook put out this neat friendship visualization map. (thanks Jared)

This Week in Mobile and Web – 12.10.10

Good morning!  Google had a busy week, so we dedicated a whole section to them.

Google, Google, and more Google…

The big news is the release of the Nexus S and Android 2.3 (Gingerbread).  Leaks and rumors have been circulating about this phone for quite some time.  What makes the Nexus S different from the rest of the Android lineup?  For starters, it’s the only phone with the aforementioned Gingerbread…but that won’t last long.  The real difference is that it has a curved display and includes a Near Field Communications chip.  This will allow a user to tap their phone on a pay station to pay for parking, or tap it on an advertisement to go to a website, or tap it on a map to get directions.  Imagine checking into a restaurant, on Foursquare, simply by placing your phone on the menu.  It will take a bit for developers to add the features to their apps as well as marketing folks to start including NFC technology into their ad campaigns.  But we’re now one step closer to having our digital identity live in our pocket.

Development

Devices

The OS Battle

Apps

Carrier News

Friday Infographic

(click for larger view)

Source: DVICE

iPhone Unit Testing – Part 1 : Writing the first test

I was recently given some direction by an iPhone developer on an existing application:

You need to have unit tests. I know there aren’t any unit tests in the code now, but you need to have them. When the original code was written, it was done over weekends and I didn’t have time to write tests.

Not having time is certainly understandable (but aren’t unit tests supposed to *save* time?) – but in reality there are many reasons why a lot of  iPhone applications you see won’t have solid unit test coverage:

  1. The iPhone IDE (yes, you Xcode!) does not encourage TDD.
  2. Apple provides very little guidance around unit testing iPhone applications. And the guidance they provide can be confusing to folks coming from other platforms.
  3. Setting up the environment can be tricky!
  4. There are multiple competing iPhone unit testing frameworks that improve upon the stock OCUnit (SenTestingKit) framework that comes with the iPhone SDK. So it seems that multiple people must have thought OCUnit could be improved upon!

This post will get you started with the “default” unit test framework, OCUnit (a.k.a. SenTestingKit), provided by Apple. Our goal is to understand what is available out of the box with the iPhone SDK and get our first test to execute!

Let’s get started!

Setting up our project.

By far the most confusing part in setting up tests for the iPhone is configuring the project and the build environment to execute tests. Once the project structure has been laid out correctly and we get the first test executing, there is no more infrastructure to prevent us from writing hundreds and hundreds of tests.

Unfortunately when compared to frameworks like ruby on rails – which rightly puts an emphasis on TDD – the iPhone SDK and Xcode look rather silly. In rails, tests are highly encouraged. Not so in Xcode. There is a little setup required outside of the default template. It’s not difficult, but it’s not out of the box either.

Step 1 : Add a new target

I’ve created a project called UnitTestingExample. Add a new Unit Test Bundle target to the project. This target will execute all of our unit tests, so we’ll name it something related to that. I’ve called this target LogicTests.

Adding A New Target

Making a Unit Test Bundle Target

Multiple Targets

Notice in the last screenshot we have two targets – our main application (UnitTestingExample) and our unit test bundle (LogicTests). Behind the scenes, Xcode has configured our target to find OCUnit, which quite confusingly is called SenTestingKit – based on the name of the open source project in which the code was written.

Step 2 : Create Test Cases

Now that we have a target for our tests, let’s create a new class that will contain our tests. Create a class (deriving from NSObject in Xcode). I created one called LogicTests.m. Be sure to add it to the LogicTests target only.

Adding a file for unit testing.

Open LogicTests.h and make a few changes. First, we need to import SenTestingKit. SenTestingKit is the unit testing framework which is also referred to as OCUnit (rather obviously short for “objective-c unit” – to keep in line with the xUnit pattern). We also derive our class from SenTestCase. At this point, the header is done. It’s time to write our tests.

LogicTests.h

In LogicTests.m – create (void) functions with no parameters that start with test. SenTestingKit will automatically execute all functions that have this signature. In the following case, we will let the test fail to understand how SenTestingKit will report errors.

LogicTests.m

Step 3 : Build The Test Target

Now let’s run the tests. Ensure the LogicTests target is setup to run under the Simulator. The tests will not be executed using Device. This is quite unfortunate – the Device build actually succeeds without running any tests! We’ll keep this little fact in mind when we look at other unit testing frameworks.

Run The LogicTests Target

Unlike most all other unit testing frameworks, the tests are run *after* the project has successfully built. Not so with SenTestingKit. The tests are actually ran as part of the build process. The build will fail if any tests fail, which is good. However it is not typical workflow in how unit test frameworks tend to work.  Typically tests run *after* the build step! (Really these are running after the application is built, but the workflow is a bit different than the workflow in other platforms). Looking at the build output we will see where the failures occurred. Xcode does a rather nice job of pointing you at the errors.

Build Errors

Congratulations! If you have made is this far you have unit tests up and running! At this point we can create more tests and more test classes. In the following example, we test a Calculator class and a simple test using NSURLConnection to illustrate that we can test against the Foundation library.

Passing Unit Tests

Limitations

Let’s step back a second. There are a few limitations that are going on here that we need to call out:

  1. We can’t debug tests. Because these tests run during build time (in a shell script build step), we can’t set breakpoints. This will be a deal breaker as the number and complexity of our tests increase.
  2. The tests are executed in what Apple refers to as a “clean room”. i.e., not the real world. We need to be aware that we do not have access to a UIApplication object or the rest of the iPhone application environment. Apple refers to these type of tests as “Logic Tests” (which is why I named my test class LogicTests.m). Logic Tests test your lower level code that is independent of the iPhone application context (run loop, touch events, etc..)
  3. Controlling execution / output. Getting build errors in Xcode helps us solve the problems and fix the tests. That does the job – but it barely scrapes the surface on features when compared to other platforms. We are sorely lacking other helpful features that most all other environments have. How about a GUI runner where we can see log output per test? How about the ability to run one test or a group of tests? A few more simple features would certainly be nice to have.

Next steps

This has been a good first step. We have unit tests running – which puts us ahead of many iPhone applications currently on iTunes! We’ve learned how to create a target specifically for testing, add files to our project that will only be contained in one target, and create tests.

With these fundamentals out of the way, it’s time to get out of our “clean room” and start cranking out tests that actually stress our application – tests that hit UIApplication, our view controllers, and our UI code. We also need to tackle the other limitations – like better debugging and better control over our test execution! We also need to go behind the scenes and see how SenTestingKit really works and how our bundle is created. We didn’t add a reference to SenTestingKit in our application – but hey, we have tests!

In the next post we will address testing UI functionality and getting tests running on a device. Once we have this, we will be able to test cover our entire iPhone application. We’ll then move on to more advanced features that 3rd party toolsets provide – like being able to selectively run tests and control test execution a bit better.

8 Super Super Useful Open Source Projects for iPhone

I’m always on the lookout for great plugins and libraries to use in development. Here are some projects we like @RecursiveAwesum.

json-framework

Any time you need to need to call a web service you’re going to be parsing JSON data. Add json-framework to the project and never, EVER, worry about parsing again. This project has been rock solid for over two years and I can’t recommend it enough. It extended cocoa classes nicely with categories which make working with NSString, NSArray, and NSDictionary a breeze.

json-framework

Zebra Crossing Bar Code Reader

Need bar code or QR code scanning in your app? Call the zebra.

Zebra Crossing Bar Code Reader

Appirater

Appirater is a great tool to ask your users to rate your app. It used to be a great way to foil the App Store’s negative rating bias. However, I’ve noticed you are no longer asked to rate an app when removing it from your phone in SDK 4.1, but this is still a great way to prompt your users.

Appirater

TDBadgedCell

This is a UITableViewCell subclass that adds a “badgeNumber” to a table cell. This badge draws in an identical manner to the badges present in MobileMail.app.

TDBadgedCell

MBProgressHUB

From the README – MBProgressHUD is an iPhone drop-in class that displays a translucent HUD with a progress indicator and some optional labels while work is being done in a background thread. The HUD is meant as a replacement for the undocumented, private UIKit UIProgressHUD with some additional features.

MBProgressHUB provides a very smooth user experience and will add a nice finish to your app.

MBProgressHUB

SyntesizeSingleton.h

If you want to use the Singleton Pattern in your app, Matt Gallagher from Cocoa With Love has a great example on how to do so with his SynthesizeSingleton.h.
SynthesizeSingleton.h

Twitter-OAuth-iPhone

Twitter-OAuth-iPhone

OAuthConsumerFramework

OAuthConsumerFramework

While the above are excellent projects you shouldn’t add them to your project without reviewing the code. Good developers don’t cargo cult code. Always know what you’re code is doing.

Using Git to Manage iPhone Provisioning Profiles

Every iPhone developer with an app in the Apple App Store has dealt with the frustration of code signing. Try searching for “iphone code signing error” on Google and you get almost a million results. The purpose of code signing is to tie developers, apps, and devices together in a tangled web in an attempt to prove you are actually yourself, your iPhone is in fact yours, and Apple has authorized you to run or submit your app.

Sounds like fun right?

The way to sign your app is to associate it with a provisioning profile. Creating a provisioning profile is beyond the scope of this post, but you can find more information here. You’ll need a current iPhone developer account to access the docs. Sorry.

So what is this post about then? Well, once you have a few iPhone apps under your belt you’ll find that you have a ton of profiles to manage. Development profiles to test your apps on your device. Ad-hoc profiles to send out beta versions to your testers, and Distribution profiles for submitting your apps to the App Store. They all live in the same place on your Mac and will have non-human readable names if you’ve followed the Apple documentation and dragged and dropped them into Xcode. This makes it a bit tough to know what profile goes with which app.

What are provisioning profiles?

The docs define provisioning profiles as “… a collection of digital entities that uniquely ties developers and devices to an authorized iPhone Development Team and enables a device to be used for testing. A Development Provisioning Profile must be installed on each device on which you wish to run your application code.” Translated this means you have to have a development profile to run your app on your device or a distribution profile to have the app accepted into the app store.

How XCode/iTunes uses them

I’m not going to cover how to sign your apps in this post either. But, rather explain how XCode uses them and how to organize them. Both XCode and iTunes use profiles. XCode to sign the apps and iTunes to install them. Whether you’re signing or installing profiles they live in the same place. Fire up Terminal.app and issue the following commands to find your profiles.

$ cd ~/Library/MobileDevice/Provisioning Profiles/
$ ls

Profile Installation Methods: Drag & Drop vs. Finder

Most of the Apple documentation tells you to drag and drop a profile into XCode to install it. This works but your profile is renamed along the lines of “0ED00060-C42C-4E3F-932F-30F22F79A14C.mobileprovision”. Good luck on knowing what file is.

I prefer move the profiles manually in Finder to avoid the automatic renaming. I like to name my files project.type.date.mobileprovision or trickiwiki.adhoc.03352010.mobileprovision.

What is Git?

Unless you’ve been out of software development for a few years you’ve probably heard of git. Git is distributed version control system for source code and when coupled with a website like GitHub it makes contributing to open source project easy. One of the great things about git is the ease of branching.

For info on how to use and configure git please refer to Scott Chacon’s Pro Git book & website

Creating a Git Repository

Now that git installed we can finally get to the meat of this post. So fire up Terminal.app and issue the following commands. But first move all of your provisioning files out of ~/Library/MobileDevice/Provisioning Profiles/

$ cd ~/Library/MobileDevice/Provisioning Profiles/
$ git init
$ touch README
$ git add README
$ git commit -m 'first commit'

You have created your git repository and added a blank file named README to it.

Using Git Branches

You new git repo comes with a pre-made branch named master. For our purposes we’ll leave this one alone. Run the following command any time to see the branches in your repo.

$ git branch

I like to create a branch for each app. To create a new branch run…

$ git branch app_name1
$ git checkout app_name1

You’ve just created a new git branch for app_name and moved into it. Now save your profiles for app_name1 in cd ~/Library/MobileDevice/Provisioning Profiles/ and run

$ git add .
$ git commit -m "Profiles for app_name1"

Now your profiles are safely stored in your project branch. Now to make a new project branch we need to move back to the master branch and issues the commands to make a new branch. So run the following…

$ git checkout master
$ git branch app_name2
$ git checkout app_name2

Move the profiles for app_name2 into ~/Library/MobileDevice/Provisioning Profiles/ and commit them into git.

$ git add .
$ git commit -m "Profiles for app_name2"

Did you notice that ~/Library/MobileDevice/Provisioning Profiles/ was empty when you put the profiles for app_name2 in there? That’s because the profiles for app_name1 are tucked into the branch for app_name1. To switch between branches just use the git checkout command.

$ git checkout app_name1
$ ls
app_name1.mobileprovision
$ git checkout app_name2
$ ls
app_name2.mobileprovision

Are you starting to get the idea?

What Branch Am I On?

Now that we have all of these branches how do you tell which one you’re working with. As I said before the command git branch will show you the branches

$ git branch
app_name1
* app_name2

The * indicates the active branch. But typing git branch over and over is annoying so I use some shell scripts from Jon Maddox to always show me which branch I’m on.

[proton:Provisioning Profiles[trickiwiki]$

In the example above the branch is shown as “[trickiwiki]“. Pretty sweet, huh?

Git Checkout Usage with XCode/iTunes

The one thing you need to remember when using this system to manage your profiles is XCode and iTunes are not very smart. They only check for profiles on startup. So you need to remember to checkout the correct branch before opening those apps. This took some getting used to until I made it part of my workflow.